Their search section is down right now. It's titled Win32 to Cocoa, something something something. It's not specifically about .NET, but it does hit .NET pretty hard for repeating all the mistakes of Win32, etc.
Jasconius on
0
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
edited April 2009
I found them. Those articles are all hand waving. He spends an entire page rambling about how bad the framework is, and then only gives one specific example of why it is bad. He spends 2/3 of the page talking about how it is "dumbed down" without giving a single examples, and then trots out a corner case that can only happen if you are doing something off the wall like starting a background thread from your form's constructor.
jackal on
0
marty_0001I am a fileand you put documents in meRegistered Userregular
edited April 2009
I'm having a bit of trouble getting my head around using arrays. I have an array that generates a list of values, and returns them. How do I perform operations on these values? I see the "return theResults", which would pass the values back to the method... but I'm not sure how I get the method to actually receive them.
The start and end of the array (snipped for simplicity, let me know if you need the whole thing)
public class Results {
public static int[] getResults() {
...
}
return theResults;
}
My method, placed afterwards:
public static int max(getResults[]) { [COLOR="YellowGreen"]//<identifier> expected[/COLOR]
int maxResult = Math.max(theResults[]); [COLOR="yellowgreen"]//'.class' expected[/COLOR]
System.out.println("The maximum of the results is " +maxResult);
}
I hope what I have tried is to pick up the array, getResults[], and operate on the returned value, theResults[]. Obviously it doesn't like that.
Naming a parameter the same as a method will not make it call the method to get the value of that parameter.
Also, I don't think there's a version of Math.max that takes an int[]. I think you'd be best off using Arrays.sort and then picking the last one off the sorted array.
public class Results{
public static int getResult() {
return 1;
}
public static int doStuff(getResult){//why isn't it getting the result?
...
}
}
Same issue here, you're not calling the method.
You only need the array brackets in two places:
declaring an array (a variable, a new array, or a parameter in a method declaration)
getting a value by index: array[index]
Hey there, programmerinos. I'm trying to make a roguelike in Java to improve my (budding) programming skills, but I've hit a bit of a stumbling block. Implementing a save system would probably be a good idea, but I have no idea where to even start. How would I go about saving an object to a file?
If you have objects and want to save them in some sort of file, you're looking at serialization.
Take a look at the Serializable class interface.
edit: this is maybe not the easiest introduction to Serializable, but it's definitely better than linking you to the API reference.
Thanks, that was surprisingly painless. Now I've run into a new problem, though. How should I store the information that defines items, creatures etc.? Originally I wanted to make every item type its own class, so I could give them their own methods and take advantage of inheritance, but it seems like if I did this, I'd have to store every item type in a separate file, which would get unwieldy fast. Do you have any advice?
Now I've run into a new problem, though. How should I store the information that defines items, creatures etc.? Originally I wanted to make every item type its own class, so I could give them their own methods and take advantage of inheritance, but it seems like if I did this, I'd have to store every item type in a separate file, which would get unwieldy fast. Do you have any advice?
That is a very bad idea. You always want the minimum amount of classes that can solve your problem. Plus, what happens when you want to define new items? We have to write new classes? What happens when you have hundreds of items with slightly different changes?
Here is what you should do. Have an Item interface, it should describe what a generic item has: Name, Weight, Durability, Elemental Properties, etc. It should focus on storing information only.
You then can have Item implementations of any type, and as long as your code uses the Interface, it'll work. But you'll probably have one generic implementation of Item since even special Items have similar info. Unique items can either provide their own Item implementation, or even better, use listeners to know when the item is being used. If the Item Interface provides a way to add listeners, any code that needs to know when a particular item is being used can know about it and respond. The implementation of Item could also allow a listener to change its behavior. A bit much, but do you see why this would be better?
This should be pretty easy, but my brain feels completely wasted right now.
So I have a subtitle file for a movie (that horrible Engrish Star Wars episode 3 with "Do not want", actually), and I got it in my mind to watch my DVD with these subs!
Only thing is, the time stamps in the sub file are off, and I need to delay them by five seconds.
The format is easy enough: (Observe the awesome Engrish!)
1
00:00:18,932 --> 00:00:23,892
Long time ago
in the faraway galaxy
2
00:00:26,206 --> 00:00:31,166
Star war
3
00:00:37,951 --> 00:00:42,911
The third gathers
4
00:00:43,457 --> 00:00:48,417
The backstroke of the west
It's in hours:minutes:seconds,milliseconds - if it was just a millisecond/second time stamp, I'd already be done with it. Does Perl or Ruby have functions for calculating with time? I'd rather not reinvent the wheel yet again (did something similar years ago).
This should be pretty easy, but my brain feels completely wasted right now.
So I have a subtitle file for a movie (that horrible Engrish Star Wars episode 3 with "Do not want", actually), and I got it in my mind to watch my DVD with these subs!
Only thing is, the time stamps in the sub file are off, and I need to delay them by five seconds.
The format is easy enough: (Observe the awesome Engrish!)
1
00:00:18,932 --> 00:00:23,892
Long time ago
in the faraway galaxy
2
00:00:26,206 --> 00:00:31,166
Star war
3
00:00:37,951 --> 00:00:42,911
The third gathers
4
00:00:43,457 --> 00:00:48,417
The backstroke of the west
It's in hours:minutes:seconds,milliseconds - if it was just a millisecond/second time stamp, I'd already be done with it. Does Perl or Ruby have functions for calculating with time? I'd rather not reinvent the wheel yet again (did something similar years ago).
VLC can offset the whole thing by a certain time and save it back into the file. Another dedicated program that I can't remember can do the same thing and allow you to set key points at, like, three places in the movies to ensure sync.
VLC can offset the whole thing by a certain time and save it back into the file. Another dedicated program that I can't remember can do the same thing and allow you to set key points at, like, three places in the movies to ensure sync.
But that's not a programming solution :P
Going to have a look at Chronic later, too tired right now.
Ideally I'd just like to find something that lets me do "00:18:59 + 00:00:05".
VLC can offset the whole thing by a certain time and save it back into the file. Another dedicated program that I can't remember can do the same thing and allow you to set key points at, like, three places in the movies to ensure sync.
But that's not a programming solution :P
Going to have a look at Chronic later, too tired right now.
Ideally I'd just like to find something that lets me do "00:18:59 + 00:00:05".
Took it apon myself to do this, since it seemed interesting. I don't do alot of manipulation of time, so I thought I'd try it with python. Whether it's useful to you or not is questionable since you wanted a Perl or Ruby solution but I did learn about the datetime module so not all is lost. ( I didn't test it well but I think it will work.)
#!usr/bin/env python
from datetime import datetime, time, timedelta
import re
import sys
#regex used to validate time and get miliseconds
pat_str ="""( #this group will be the standard time of hours:minutes:seconds
\d{2}#the hours digits, must have 2 digits
:
\d{2}#the minutes digits, must have 2 digits
:
\d{2}#the seconds digits, must have 2 digits
)
,#comma separates seconds from possible milliseconds
(\d{0,3})#this group is the milliseconds group, which may be zero to three digits
"""
valid_time = re.compile(pat_str, re.VERBOSE)
def shift_time(in_stream, out_stream, millisecs):
"""will shift all times found by the miliseconds supplied.
Will read the stream word by word and replace times with
a time shifted forward.
in_stream : some iterable of lines, like a file
out_stream : some object that supports write of a str
millisecs : the number of milliseconds needed to shift all
time by."""
for line in in_stream:
linebegin = True
for word in line.split():
#only add one space between words; doesn't preserve previous whitespace
if not linebegin:
out_stream.write(' ')
linebegin = False
mat = valid_time.match(word)
if mat:
[B]#convert str of time to a datetime we can shift as we want
thistime = datetime.strptime(mat.group(1), '%H:%M:%S')
#the amount to shift by is the amount of milliseconds supplied added to the amount found
shift = timedelta(milliseconds=(int(mat.group(2) or '0') + millisecs))
#resulting time can now be backconverted to right format
tim = thistime + shift
newstr = '%02d:%02d:%02d,%03d' % (tim.hour, tim.minute, tim.second, tim.microsecond//1000)
out_stream.write(newstr)[/B]
else:
#this word isn't a time, just write it out
out_stream.write(word)
#don't forget to end each line with a newline
out_stream.write('\n')
def test():
"""test the function on the example input and print out"""
s = """1
00:00:18,932 --> 00:00:23,892
Long time ago
in the faraway galaxy
2
00:00:26,206 --> 00:00:31,166
Star war
3
00:00:37,951 --> 00:00:42,911
The third gathers
4
00:00:43,457 --> 00:00:48,417
The backstroke of the west"""
def get_lines(s):
return (line for line in s.split('\n') if line != '\n')
shift_time(get_lines(s), sys.stdout, 5000)
usage = """timeshift milliseconds
Will take input from stdin and write out the updated times to stdout.
Use like so: timeshift 5000 < subfile > newsub
"""
def main(args=None):
if args is None: args = sys.argv[1:]
if len(args) != 1:
sys.stderr.write('Not right amount of args')
sys.stderr.write(usage)
sys.exit(1)
try:
millisecs = int(args[0])
except ValueError:
sys.stderr.write('%s is not an int' % args[0])
sys.stderr.write(usage)
sys.exit(1)
shift_time(sys.stdin, sys.stdout, millisecs)
if __name__ == '__main__':
test()
## main()
You're in a college and taking Visual Basic courses?
I'm not sure why that's surprising, or even a question.
Despite your stabbing at M$ from afar, Visual Basic is (re: was) a major player in the RAD field. Despite its obviously dubious origin as an easy way to get into programming (and making horrible programmers) it's a decidedly powerful language, and the retarded cousin of .NET.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Hey there, programmerinos. I'm trying to make a roguelike in Java to improve my (budding) programming skills, but I've hit a bit of a stumbling block. Implementing a save system would probably be a good idea, but I have no idea where to even start. How would I go about saving an object to a file?
If you have objects and want to save them in some sort of file, you're looking at serialization.
Take a look at the Serializable class interface.
edit: this is maybe not the easiest introduction to Serializable, but it's definitely better than linking you to the API reference.
Thanks, that was surprisingly painless. Now I've run into a new problem, though. How should I store the information that defines items, creatures etc.? Originally I wanted to make every item type its own class, so I could give them their own methods and take advantage of inheritance, but it seems like if I did this, I'd have to store every item type in a separate file, which would get unwieldy fast. Do you have any advice?
This is where you'll have to come up with some sort of file format of your own. I assume you are saying a file for each item type because you're just writing and reading an arbitrary number of these same class objects, and the only way you know it's that class is because those are the only type put in that file?
You'll need to deliminate your file in some way, so that you can see when loading "this is a character" and "this is a weapon" etc. Let's say I was saving a character, I just need to come up with some rules.
First, come up with some kind of scheme for marking and organizing your file. Let's just use 4 byte identifiers for the example, which are pretty common.
1. Write the 'Character' identifier.
2. Writeobject the Character object.
Now since we are unable to save the object members that belong to Character, we have to iterate and save those ourselves! And we have to let the loader know that we've switched over to something else. We saved attributes like the name, level, experience, etc. with our primitive data types, but the inventory Item object array we have in our Character class will not be automatic.
3. Write the 'CharacterInventory' identifier.
4. Write an integer to the stream for how many Item objects we have.
5. Writeobject each Item object.
And so on until we have something that we can load back in without any ambiguity. The start of the file usually will have some unique ID (pretty standard to make the first 4 bytes be a "tag" that's human readable) and then you will have whatever data needed to be known to sort out the rest of the file there. That's your header. Let's say I only had to worry about characters, my file might look like this in the end:
Address / Contents
0000: "INF!" (ID header bytes)
0004: 0x00000004 (32-bit int storing how many characters saved in this file)
0008: "CHAR" (end of header, start of data, we look for a tag and find CHAR, start reading a Character)
000C: Character object serialized, let's say it takes 100 bytes, we readobject it in.
0070: "CINV" (after reading the base Character data, we see if there are any objects attached to this Character object, and there is an Inventory found)
0074: 0x00000008 (8 Item objects in our Inventory array for this character)
0078: "ITEM"
007C: Item object serialized
00A2: "ITEM"
00A6: Item object serialized
etc.
When it's done with the 8 specified Items, it will look at the next tag. It would see either (a) another tag that "belongs" to this Character object or (b) a new Character because it reads the CHAR tag.
You could expand on this idea to save virtually anything, so long as you keep your structure organized and unambiguous. Note that you can override the serializable methods, that means you could put some of this parsing code in your objects directly. For example, in Character I could add the dumping of inventory Items to the stream by overriding writeobject for Character and adding a loop to iterate and writeobject each Item, first of course writing a tag (i.e. CINV) and item count if I needed it in my format. Then to save a Character I would just need to serialize it like normal and it saves everything I need to recursively, which is a much nicer way to do things.
That is a very bad idea. You always want the minimum amount of classes that can solve your problem. Plus, what happens when you want to define new items? We have to write new classes? What happens when you have hundreds of items with slightly different changes?
Here is what you should do. Have an Item interface, it should describe what a generic item has: Name, Weight, Durability, Elemental Properties, etc. It should focus on storing information only.
You then can have Item implementations of any type, and as long as your code uses the Interface, it'll work. But you'll probably have one generic implementation of Item since even special Items have similar info. Unique items can either provide their own Item implementation, or even better, use listeners to know when the item is being used. If the Item Interface provides a way to add listeners, any code that needs to know when a particular item is being used can know about it and respond. The implementation of Item could also allow a listener to change its behavior. A bit much, but do you see why this would be better?
That way is probably more appropriate for most roguelikes, but I suppose mine is more of a roguelikeish. I want to differentiate items based on unique physical properties and the actions that can be performed with them rather than by numbers. Pretty much every item will require its own methods and would be considered "unique" in this context. I'd just end up with a thousand event handlers all dangling somewhere away from where the items themselves are defined. Is that really better than using subclasses?
This is where you'll have to come up with some sort of file format of your own. I assume you are saying a file for each item type because you're just writing and reading an arbitrary number of these same class objects, and the only way you know it's that class is because those are the only type put in that file?
You'll need to deliminate your file in some way, so that you can see when loading "this is a character" and "this is a weapon" etc. Let's say I was saving a character, I just need to come up with some rules.
First, come up with some kind of scheme for marking and organizing your file. Let's just use 4 byte identifiers for the example, which are pretty common.
1. Write the 'Character' identifier.
2. Writeobject the Character object.
Now since we are unable to save the object members that belong to Character, we have to iterate and save those ourselves! And we have to let the loader know that we've switched over to something else. We saved attributes like the name, level, experience, etc. with our primitive data types, but the inventory Item object array we have in our Character class will not be automatic.
3. Write the 'CharacterInventory' identifier.
4. Write an integer to the stream for how many Item objects we have.
5. Writeobject each Item object.
And so on until we have something that we can load back in without any ambiguity. The start of the file usually will have some unique ID (pretty standard to make the first 4 bytes be a "tag" that's human readable) and then you will have whatever data needed to be known to sort out the rest of the file there. That's your header. Let's say I only had to worry about characters, my file might look like this in the end:
Address / Contents
0000: "INF!" (ID header bytes)
0004: 0x00000004 (32-bit int storing how many characters saved in this file)
0008: "CHAR" (end of header, start of data, we look for a tag and find CHAR, start reading a Character)
000C: Character object serialized, let's say it takes 100 bytes, we readobject it in.
0070: "CINV" (after reading the base Character data, we see if there are any objects attached to this Character object, and there is an Inventory found)
0074: 0x00000008 (8 Item objects in our Inventory array for this character)
0078: "ITEM"
007C: Item object serialized
00A2: "ITEM"
00A6: Item object serialized
etc.
When it's done with the 8 specified Items, it will look at the next tag. It would see either (a) another tag that "belongs" to this Character object or (b) a new Character because it reads the CHAR tag.
You could expand on this idea to save virtually anything, so long as you keep your structure organized and unambiguous. Note that you can override the serializable methods, that means you could put some of this parsing code in your objects directly. For example, in Character I could add the dumping of inventory Items to the stream by overriding writeobject for Character and adding a loop to iterate and writeobject each Item, first of course writing a tag (i.e. CINV) and item count if I needed it in my format. Then to save a Character I would just need to serialize it like normal and it saves everything I need to recursively, which is a much nicer way to do things.
Really sorry, what I meant is that I need a way to organize the info that defines what each game object is, not a way to save instances of those objects. I store items and characters as part of the map itself, so all I have to do is serialize the map, and it saves everything else with it.
What I meant by having everything in a separate file is Java's stubborn insistence that every class be in a different .java file (except for inner classes, which aren't appropriate here). So with the way I'm doing things, if I wanted to make changes to the Wrench and Screwdriver classes, I'd need to search for them both in a huge list of files rather than finding them next to each other in a big Tools.java file.
That is a very bad idea. You always want the minimum amount of classes that can solve your problem. Plus, what happens when you want to define new items? We have to write new classes? What happens when you have hundreds of items with slightly different changes?
Here is what you should do. Have an Item interface, it should describe what a generic item has: Name, Weight, Durability, Elemental Properties, etc. It should focus on storing information only.
You then can have Item implementations of any type, and as long as your code uses the Interface, it'll work. But you'll probably have one generic implementation of Item since even special Items have similar info. Unique items can either provide their own Item implementation, or even better, use listeners to know when the item is being used. If the Item Interface provides a way to add listeners, any code that needs to know when a particular item is being used can know about it and respond. The implementation of Item could also allow a listener to change its behavior. A bit much, but do you see why this would be better?
That way is probably more appropriate for most roguelikes, but I suppose mine is more of a roguelikeish. I want to differentiate items based on unique physical properties and the actions that can be performed with them rather than by numbers. Pretty much every item will require its own methods and would be considered "unique" in this context. I'd just end up with a thousand event handlers all dangling somewhere away from where the items themselves are defined. Is that really better than using subclasses?
Feel free to ignore this, but...
It sounds like you want to use the command pattern.
Essentially, each item has to Execute(). What that execution entails depends on the object itself. So, like the estimable Mr. FragBait suggested, create an abstract base class with as much of the shared item interface as possible:
Using C# since I don't know Java:
public abstract class Item
{
protected string name;
protected int weight;
// etc
public Item(string name, int weight)
{
this.name = name;
this.weight = weight;
}
public abstract void Execute() { }
}
You then subclass from that, with each subclass having item-specific functionality:
public class FlamingSwordOfFire : Item
{
private int atkPower;
public FlamingSwordOfFire(string name, int weight, int atkPower) : base(name, weight)
{
this.atkPower = atkPower;
}
public override void Execute()
{
//attack, or something
Enemy enemy = (Enemy)System.Web.HttpContext.Current.Session["enemy"];
enemy.HP -= this.atkPower;
System.Web.HttpContext.Current.Session["enemy"] = enemy;
}
}
Each child object can be unique because it can define those physical properties themselves. If you have essentially a family of child objects that share a particular kind of implementation (all potions, or scrolls, or whatnot), you could strengthen type by adding an interface mixin (IPotion, or IScroll for example).
Of course, all this assumes that there is some shared underlying behavior for all items - that they each share some members (the basics, like name, value, etc), and that each can do something (Execute()).
Just an idea. Again, feel free to ignore if this doesn't help.
Nightslyr on
PSN/XBL/Nintendo/Origin/Steam: Nightslyr 3DS: 1607-1682-2948 Switch: SW-3515-0057-3813 FF XIV: Q'vehn Tia
I like Nightslyr's idea, though I still think this is a more constrained version than what I am suggesting. Making an abstract execute method means all behavior must be defined in one place. I do think "a thousand event handlers all dangling somewhere" is better. I don't think you should couple an Item and its behavior so closely. It may seem intuitive that a special Item class would have it's behavior written in the class, but it will quickly become hard to maintain. Here is some examples of why I think listeners would be better:
Say we want to make an Item unbreakable, your description would imply each item that is unbreakable would need its own class with it's own code written (ignoring abuse of inheritance so you wouldn't need to write it multiple times.)
I would suggest something like this:
public class ItemProperties{
/**Makes this Item unbreakable by adding a listener
*/
public static void makeItemUnbreakable(Item i){
i.addItemListener( new UnbreakableListener() );
}
}
class UnbreakableListener implements ItemListener{
public void itemChanged(Item i){
//we only get here if the item has been changed
if(i.getDurability() != i.getMaxDur(){
i.setDurability(i.getMaxDur());
}
}
}
This means we can generically make ANY item unbreakable without adding any code to a special Item class.
Maybe we want to make a weapon get weaker as it's durability gets lower, we could add a listener to do that.
class WeakerWear implements ItemListener{
public void itemChanged(Item i){//something like this
i.setAttack( i.getMaxAttack() * (i.getDurabity()/i.getMaxDur()));
}
}
And as long as you write the listener handler code well, this will have no side effects, makes it extremely easy to add and change Item behavior, and probably be easily serialized separately. Of course you need to handle adding, removing, and keeping track of listeners attached, but in the long run it is no worse than the multiple class idea.
You're in a college and taking Visual Basic courses?
I'm not sure why that's surprising, or even a question.
Despite your stabbing at M$ from afar, Visual Basic is (re: was) a major player in the RAD field. Despite its obviously dubious origin as an easy way to get into programming (and making horrible programmers) it's a decidedly powerful language, and the retarded cousin of .NET.
I'm not stabbing at M$ from afar... my school offered no VB courses unless there was one tucked away in the business school or some such (where RAD would be useful). As is, I'm not sure where VB, even the .NET version, fits into what I'd consider a "normal" CS curriculum.
You're in a college and taking Visual Basic courses?
I'm not sure why that's surprising, or even a question.
Despite your stabbing at M$ from afar, Visual Basic is (re: was) a major player in the RAD field. Despite its obviously dubious origin as an easy way to get into programming (and making horrible programmers) it's a decidedly powerful language, and the retarded cousin of .NET.
I'm not stabbing at M$ from afar... my school offered no VB courses unless there was one tucked away in the business school or some such (where RAD would be useful). As is, I'm not sure where VB, even the .NET version, fits into what I'd consider a "normal" CS curriculum.
Technically speaking VB.NET is actually in a lot of ways a more powerful language than Java*, and a lot of schools offer Java courses. It has a PR problem mostly, and some unfortunate features that are in there for VB6 compatibility only.
*For example VB.Net has closures and reified generics.
VLC can offset the whole thing by a certain time and save it back into the file. Another dedicated program that I can't remember can do the same thing and allow you to set key points at, like, three places in the movies to ensure sync.
But that's not a programming solution :P
Going to have a look at Chronic later, too tired right now.
Ideally I'd just like to find something that lets me do "00:18:59 + 00:00:05".
Each child object can be unique because it can define those physical properties themselves. If you have essentially a family of child objects that share a particular kind of implementation (all potions, or scrolls, or whatnot), you could strengthen type by adding an interface mixin (IPotion, or IScroll for example).
Sorry for not explaining myself correctly. This is what I meant by taking advantage of inheritance. Of course there'd be an abstract Item superclass with everything common to items, along with categories for similar items. Almost every item will be able to do multiple actions, so instead of execute() I'd have a method for selecting an action, but aside from that, our ideas are pretty much the same.
Edit: Also aside from the stats being passed in as parameters. If two items were so similar that the only difference between them could be expressed in numbers, I'd just remove one of them.
If I do it your way, I'd need to make my own custom events that can be fired manually and can pass any appropriate information to the listeners, right? How do I do that?
If I do it your way, I'd need to make my own custom events that can be fired manually and can pass any appropriate information to the listeners, right? How do I do that?
Not sure if this is what you want, but does this help?
interface ItemListener
void itemChanged(Item i);...
interface Item
blah blah blah methods
void addItemListener(ItemListener lis);
void removeItemListener(ItemListener lis);
maybe other methods useful to listener, like "setNotifyListeners(boolean notify);"
genericItem implements Item
blah blah blah implementation
list or set of listeners, like an ArrayList or HashSet
void addItemListener(ItemListener lis)
add to listeners
void removeItemListener(ItemListener lis)
find and remove listener
//any time this Item is changed in a method this is called by that method
void notifyAll()
for each listener l in listeners
l.itemChanged(this)
How were old 2D sidescrollers of the 8 and 16 bit era programmed?
I don't really have any game programming experience, and all the game development tutorials I'm finding involve 3d games
The easiest (perhaps the naive) way I could think of is having each element on the screen represented as an object. Each object instance stores, as a minimum, a 2d polygon, a transformation, and a spritesheet, and is represented on the screen as equiplanar polygons with the sprite as a texture. Scrolling is handled by just moving a viewport facing perpendicular to the 2d plane. Everything is then updated with an eventloop, updating any object bounded by the viewport.
However, I can't imagine this approach being efficient enough to work on hardware of the era. Having a polygon bounding box for each sprite seems pretty taxing, especially given how Starfox still managed to bring the SNES to its knees despite a pretty low polygon count and additional hardware. Yet somehow, late SNES games had very beautiful sprite scaling and rotation effects.
Is this approach pretty close to what actually occurred back then?
There weren't polygons, just 2d sprites. If you look at the architecture of the (S)NES you'll see that it works off layers of sprites. In the NES it is just the background sprites laid out as tiles (think about how Super Mario Bros is constructed) and then one layer of sprites for objects like characters and monsters, on the SNES you are given multiple layers beyond these two but it's still limited. Think of the background layers as tile maps / roguelikes.
Collision detection was very easy since everything was easily represented by a primitive instead of a polygon. You would just count everything as either rectangles, or sometimes circles, and those are computationally easy to resolve. Sometimes you wouldn't even do that and just use the video engine, it could detect overlapping sprites iirc.
If I do it your way, I'd need to make my own custom events that can be fired manually and can pass any appropriate information to the listeners, right? How do I do that?
Not sure if this is what you want, but does this help?
interface ItemListener
void itemChanged(Item i);...
interface Item
blah blah blah methods
void addItemListener(ItemListener lis);
void removeItemListener(ItemListener lis);
maybe other methods useful to listener, like "setNotifyListeners(boolean notify);"
genericItem implements Item
blah blah blah implementation
list or set of listeners, like an ArrayList or HashSet
void addItemListener(ItemListener lis)
add to listeners
void removeItemListener(ItemListener lis)
find and remove listener
//any time this Item is changed in a method this is called by that method
void notifyAll()
for each listener l in listeners
l.itemChanged(this)
What I needed was that notify method at the end there. At school they taught me how to attach listeners to things like JButtons, but not how they actually work. I should've known it would be that easy.
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
edited April 2009
Also, it's pretty unlikely that any of it was object oriented. I don't know for sure but I assume the vast majority of NES and SNES programming was in assembly or C.
Yeah, as far as I can tell, object oriented programming only started being used practically in the mid 1990's. It must have been pretty frustrating, but at least there's less overhead
Anyway, I'm not very familiar with tilemaps. I'm assuming by how certain games glitch up (garbled up squares all over the screen), that it's just a bunch of squares laid out across the screen. I could see how this would greatly reduce resources, but how would the screen scroll? Let's say I was trying to scroll left to right. Would I just remove the leftmost column of tiles, shift the rest of the tiles left 1, and add the next column of tiles to the right side of the screen?
What I needed was that notify method at the end there. At school they taught me how to attach listeners to things like JButtons, but not how they actually work. I should've known it would be that easy.
Yeah, you get used to writing code in a certain way or use libraries and they start to feel like magic. Often looking at the source quickly dispels that. After talking to someone who was working on a quicksort assignment, I looked at java.util.Arrays.java to see what Sun had done. I was vaguely horrified by what I saw, but since I don't have to maintain the code it's not my problem. I did like the comment on line 465, which showed that Sun's engineers probably felt similarly:
/*
* The code for each of the seven primitive types is largely identical.
* C'est la vie.
*/
Yeah, as far as I can tell, object oriented programming only started being used practically in the mid 1990's. It must have been pretty frustrating, but at least there's less overhead
Anyway, I'm not very familiar with tilemaps. I'm assuming by how certain games glitch up (garbled up squares all over the screen), that it's just a bunch of squares laid out across the screen. I could see how this would greatly reduce resources, but how would the screen scroll? Let's say I was trying to scroll left to right. Would I just remove the leftmost column of tiles, shift the rest of the tiles left 1, and add the next column of tiles to the right side of the screen?
Many early video games followed object orientation design patterns even though they did not contain a real object model as we would think of it today.
Scrolling was controlled entirely in hardware. You'd tell the hardware to shift your tile map by x pixels and it would do that. If you just shifted tiles, the scrolling wouldn't be smooth. The level would appear to jump in 8x8 or 16x16 pixel chunks. The advantage to controlling scrolling by the pixel is that you get to arrange objects with more granularity than the tile size. The disadvantage is that you are limited in level size by the size of the hardware tile map. So some developers would use the hardware to scroll across a small portion of their tile map and then shift in/out columns, rows, or blocks and then undo the shift with the pixel-wise scroller to snap it back into position, making the game appear to be able to scroll long distances when in reality, the pixel-wise hardware scroller is only moving 32 or so pixels in any given direction.
(This is an overview of the techniques, not intended to describe any platform in particular.)
Ooh, TimeSpan looks handy. That's what I was looking for in Ruby, since it felt like too much work to write my own implementation for this little work.
...but I could use the exercise. Haven't done any proper programming in ages.
So if this works anything like the GBC or the GBA, I might be able to help.
graphics are arranged into preset Tile sets, which are basically the aformentioned 8x8 tiles. I forget the max tiles you can have loaded in at one time, I feel like it was like 128 max, divided evenly between "sprite" tiles and "background" tiles.
Those tile sets are basically just an array of indices into a preset color palette, of which have 4 colors per each palette, there was actually only 3 colors for sprites though, since one of the colors denoted transparency. You can use a different keys for a different tiles (in fact two tiles with same tile set index can use a different palette, so you can do color swapping) you can have 8 palettes for the "background" and I forget how many for the sprites, but they are different palettes for each.
Finally collections of tile sets using those color keys can be loaded into preset backgrounds, backgrounds have a limit of being the aformentioned 256x256 pixels, or 32x32 tiles, but since the screen width of the GBC at least is 160x144, this only covers like 2 screen widths maybe.
This means that you have to swap out backgrounds on the fly from the cartridge onto memory if you want big scrolling backgrounds.
The sprites operated simply within pixel screen space, 0x0 being the top left of the screen, and 160x144 being the bottom right of the screen. Much like scrolling the background while the tiles operated in 8x8 chunks, you can move them on the screen with the granularity of a single pixel.
I dunno if there was any proprietary stuff at the time, but when I did this (for a class), the thing that really sucked was if you wanted a character bigger than 8x8 pixels, because you had to composite him out of 8x8 chunks which weren't really associated, so a large 16x16 character had to be made out of 4 8x8 tiles, and you have to manage those in assembly to keep them facing the right way etc.
Collision detection WAS really easy, since you pretty much had a bounding box right there for you, so that wasn't too hard.
As far as the corruption you would see in those era games, I know I had some problems with accidentally pairing up the wrong tile set with the wrong palette under some conditions which caused all sorts of interesting colors to appear on my screen. Accidentally loading the wrong tile set, or any sort of memory corruption when loading new parts of the map could cause that corruption.
Anyway that was probably tl:dr for most of ya, but doing that definitely gave me a ton of respect for the people who worked on those NES and GBC titles. I am also certain that if I was tasked to make the open world map system for Pokemon:Red/Blue, I would have quit my job right there.
You're in a college and taking Visual Basic courses?
I'm not sure why that's surprising, or even a question.
Despite your stabbing at M$ from afar, Visual Basic is (re: was) a major player in the RAD field. Despite its obviously dubious origin as an easy way to get into programming (and making horrible programmers) it's a decidedly powerful language, and the retarded cousin of .NET.
I'm not stabbing at M$ from afar... my school offered no VB courses unless there was one tucked away in the business school or some such (where RAD would be useful). As is, I'm not sure where VB, even the .NET version, fits into what I'd consider a "normal" CS curriculum.
Technically speaking VB.NET is actually in a lot of ways a more powerful language than Java*, and a lot of schools offer Java courses. It has a PR problem mostly, and some unfortunate features that are in there for VB6 compatibility only.
*For example VB.Net has closures and reified generics.
Operator overloading. :P
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Hey guys, I was wondering if someone could point me in the right direction.
A lot of the code I'm currently reading in my studies is C++ (Gang of Four book). I've had some experience with it in college, but some of the simple things confused me at the time, and still cause me to scratch my head now.
I get the basics of argument passing. Pass by value and reference are pretty simple to understand. I get confused when constant reference enters the scene, as well as pointers.
For the first, is only the reference constant? Can the value of the argument be changed/modified? How is this different from constant methods/functions?
For the second, what's the difference between a pointer and a memory address?
Are there any decent links/tutorials that go over this?
Nightslyr on
PSN/XBL/Nintendo/Origin/Steam: Nightslyr 3DS: 1607-1682-2948 Switch: SW-3515-0057-3813 FF XIV: Q'vehn Tia
Hey guys, I was wondering if someone could point me in the right direction.
A lot of the code I'm currently reading in my studies is C++ (Gang of Four book). I've had some experience with it in college, but some of the simple things confused me at the time, and still cause me to scratch my head now.
I get the basics of argument passing. Pass by value and reference are pretty simple to understand. I get confused when constant reference enters the scene, as well as pointers.
For the first, is only the reference constant? Can the value of the argument be changed/modified? How is this different from constant methods/functions?
For the second, what's the difference between a pointer and a memory address?
Are there any decent links/tutorials that go over this?
I find this to be a good link to provide to people who have a difficulty with the whole notion of pointers and addresses:
Constants don't change, ever. So if you ever need a static value to be consistent, use a constant. Don't just throw const in front of things though, that's what retarded books and examples sometimes show you.
Example: const float Pi = 3.14f; would be a good place to use a const.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
When would be a bad place to use a constant (other than the obvious situations where you do want/need to change the value of a variable...)? Or is your warning simply to be certain you aren't "consting" something that really isn't?
Posts
Their search section is down right now. It's titled Win32 to Cocoa, something something something. It's not specifically about .NET, but it does hit .NET pretty hard for repeating all the mistakes of Win32, etc.
The start and end of the array (snipped for simplicity, let me know if you need the whole thing)
public class Results { public static int[] getResults() { ... } return theResults; }My method, placed afterwards:
public static int max(getResults[]) { [COLOR="YellowGreen"]//<identifier> expected[/COLOR] int maxResult = Math.max(theResults[]); [COLOR="yellowgreen"]//'.class' expected[/COLOR] System.out.println("The maximum of the results is " +maxResult); }I hope what I have tried is to pick up the array, getResults[], and operate on the returned value, theResults[]. Obviously it doesn't like that.
Naming a parameter the same as a method will not make it call the method to get the value of that parameter.
Also, I don't think there's a version of Math.max that takes an int[]. I think you'd be best off using Arrays.sort and then picking the last one off the sorted array.
public class Results{ public static int getResult() { return 1; } public static int doStuff(getResult){//why isn't it getting the result? ... } }Same issue here, you're not calling the method.You only need the array brackets in two places:
declaring an array (a variable, a new array, or a parameter in a method declaration)
getting a value by index: array[index]
You never need it when passing arrays around.
That is a very bad idea. You always want the minimum amount of classes that can solve your problem. Plus, what happens when you want to define new items? We have to write new classes? What happens when you have hundreds of items with slightly different changes?
Here is what you should do. Have an Item interface, it should describe what a generic item has: Name, Weight, Durability, Elemental Properties, etc. It should focus on storing information only.
You then can have Item implementations of any type, and as long as your code uses the Interface, it'll work. But you'll probably have one generic implementation of Item since even special Items have similar info. Unique items can either provide their own Item implementation, or even better, use listeners to know when the item is being used. If the Item Interface provides a way to add listeners, any code that needs to know when a particular item is being used can know about it and respond. The implementation of Item could also allow a listener to change its behavior. A bit much, but do you see why this would be better?
So I have a subtitle file for a movie (that horrible Engrish Star Wars episode 3 with "Do not want", actually), and I got it in my mind to watch my DVD with these subs!
Only thing is, the time stamps in the sub file are off, and I need to delay them by five seconds.
The format is easy enough: (Observe the awesome Engrish!)
It's in hours:minutes:seconds,milliseconds - if it was just a millisecond/second time stamp, I'd already be done with it. Does Perl or Ruby have functions for calculating with time? I'd rather not reinvent the wheel yet again (did something similar years ago).
VLC can offset the whole thing by a certain time and save it back into the file. Another dedicated program that I can't remember can do the same thing and allow you to set key points at, like, three places in the movies to ensure sync.
But that's not a programming solution :P
Going to have a look at Chronic later, too tired right now.
Ideally I'd just like to find something that lets me do "00:18:59 + 00:00:05".
Took it apon myself to do this, since it seemed interesting. I don't do alot of manipulation of time, so I thought I'd try it with python. Whether it's useful to you or not is questionable since you wanted a Perl or Ruby solution but I did learn about the datetime module so not all is lost. ( I didn't test it well but I think it will work.)
#!usr/bin/env python from datetime import datetime, time, timedelta import re import sys #regex used to validate time and get miliseconds pat_str ="""( #this group will be the standard time of hours:minutes:seconds \d{2}#the hours digits, must have 2 digits : \d{2}#the minutes digits, must have 2 digits : \d{2}#the seconds digits, must have 2 digits ) ,#comma separates seconds from possible milliseconds (\d{0,3})#this group is the milliseconds group, which may be zero to three digits """ valid_time = re.compile(pat_str, re.VERBOSE) def shift_time(in_stream, out_stream, millisecs): """will shift all times found by the miliseconds supplied. Will read the stream word by word and replace times with a time shifted forward. in_stream : some iterable of lines, like a file out_stream : some object that supports write of a str millisecs : the number of milliseconds needed to shift all time by.""" for line in in_stream: linebegin = True for word in line.split(): #only add one space between words; doesn't preserve previous whitespace if not linebegin: out_stream.write(' ') linebegin = False mat = valid_time.match(word) if mat: [B]#convert str of time to a datetime we can shift as we want thistime = datetime.strptime(mat.group(1), '%H:%M:%S') #the amount to shift by is the amount of milliseconds supplied added to the amount found shift = timedelta(milliseconds=(int(mat.group(2) or '0') + millisecs)) #resulting time can now be backconverted to right format tim = thistime + shift newstr = '%02d:%02d:%02d,%03d' % (tim.hour, tim.minute, tim.second, tim.microsecond//1000) out_stream.write(newstr)[/B] else: #this word isn't a time, just write it out out_stream.write(word) #don't forget to end each line with a newline out_stream.write('\n') def test(): """test the function on the example input and print out""" s = """1 00:00:18,932 --> 00:00:23,892 Long time ago in the faraway galaxy 2 00:00:26,206 --> 00:00:31,166 Star war 3 00:00:37,951 --> 00:00:42,911 The third gathers 4 00:00:43,457 --> 00:00:48,417 The backstroke of the west""" def get_lines(s): return (line for line in s.split('\n') if line != '\n') shift_time(get_lines(s), sys.stdout, 5000) usage = """timeshift milliseconds Will take input from stdin and write out the updated times to stdout. Use like so: timeshift 5000 < subfile > newsub """ def main(args=None): if args is None: args = sys.argv[1:] if len(args) != 1: sys.stderr.write('Not right amount of args') sys.stderr.write(usage) sys.exit(1) try: millisecs = int(args[0]) except ValueError: sys.stderr.write('%s is not an int' % args[0]) sys.stderr.write(usage) sys.exit(1) shift_time(sys.stdin, sys.stdout, millisecs) if __name__ == '__main__': test() ## main()I'm not sure why that's surprising, or even a question.
Despite your stabbing at M$ from afar, Visual Basic is (re: was) a major player in the RAD field. Despite its obviously dubious origin as an easy way to get into programming (and making horrible programmers) it's a decidedly powerful language, and the retarded cousin of .NET.
This is where you'll have to come up with some sort of file format of your own. I assume you are saying a file for each item type because you're just writing and reading an arbitrary number of these same class objects, and the only way you know it's that class is because those are the only type put in that file?
You'll need to deliminate your file in some way, so that you can see when loading "this is a character" and "this is a weapon" etc. Let's say I was saving a character, I just need to come up with some rules.
First, come up with some kind of scheme for marking and organizing your file. Let's just use 4 byte identifiers for the example, which are pretty common.
1. Write the 'Character' identifier.
2. Writeobject the Character object.
Now since we are unable to save the object members that belong to Character, we have to iterate and save those ourselves! And we have to let the loader know that we've switched over to something else. We saved attributes like the name, level, experience, etc. with our primitive data types, but the inventory Item object array we have in our Character class will not be automatic.
3. Write the 'CharacterInventory' identifier.
4. Write an integer to the stream for how many Item objects we have.
5. Writeobject each Item object.
And so on until we have something that we can load back in without any ambiguity. The start of the file usually will have some unique ID (pretty standard to make the first 4 bytes be a "tag" that's human readable) and then you will have whatever data needed to be known to sort out the rest of the file there. That's your header. Let's say I only had to worry about characters, my file might look like this in the end:
Address / Contents
0000: "INF!" (ID header bytes)
0004: 0x00000004 (32-bit int storing how many characters saved in this file)
0008: "CHAR" (end of header, start of data, we look for a tag and find CHAR, start reading a Character)
000C: Character object serialized, let's say it takes 100 bytes, we readobject it in.
0070: "CINV" (after reading the base Character data, we see if there are any objects attached to this Character object, and there is an Inventory found)
0074: 0x00000008 (8 Item objects in our Inventory array for this character)
0078: "ITEM"
007C: Item object serialized
00A2: "ITEM"
00A6: Item object serialized
etc.
When it's done with the 8 specified Items, it will look at the next tag. It would see either (a) another tag that "belongs" to this Character object or (b) a new Character because it reads the CHAR tag.
You could expand on this idea to save virtually anything, so long as you keep your structure organized and unambiguous. Note that you can override the serializable methods, that means you could put some of this parsing code in your objects directly. For example, in Character I could add the dumping of inventory Items to the stream by overriding writeobject for Character and adding a loop to iterate and writeobject each Item, first of course writing a tag (i.e. CINV) and item count if I needed it in my format. Then to save a Character I would just need to serialize it like normal and it saves everything I need to recursively, which is a much nicer way to do things.
Really sorry, what I meant is that I need a way to organize the info that defines what each game object is, not a way to save instances of those objects. I store items and characters as part of the map itself, so all I have to do is serialize the map, and it saves everything else with it.
What I meant by having everything in a separate file is Java's stubborn insistence that every class be in a different .java file (except for inner classes, which aren't appropriate here). So with the way I'm doing things, if I wanted to make changes to the Wrench and Screwdriver classes, I'd need to search for them both in a huge list of files rather than finding them next to each other in a big Tools.java file.
Feel free to ignore this, but...
It sounds like you want to use the command pattern.
Essentially, each item has to Execute(). What that execution entails depends on the object itself. So, like the estimable Mr. FragBait suggested, create an abstract base class with as much of the shared item interface as possible:
Using C# since I don't know Java:
public abstract class Item { protected string name; protected int weight; // etc public Item(string name, int weight) { this.name = name; this.weight = weight; } public abstract void Execute() { } }You then subclass from that, with each subclass having item-specific functionality:
public class FlamingSwordOfFire : Item { private int atkPower; public FlamingSwordOfFire(string name, int weight, int atkPower) : base(name, weight) { this.atkPower = atkPower; } public override void Execute() { //attack, or something Enemy enemy = (Enemy)System.Web.HttpContext.Current.Session["enemy"]; enemy.HP -= this.atkPower; System.Web.HttpContext.Current.Session["enemy"] = enemy; } }Each child object can be unique because it can define those physical properties themselves. If you have essentially a family of child objects that share a particular kind of implementation (all potions, or scrolls, or whatnot), you could strengthen type by adding an interface mixin (IPotion, or IScroll for example).
Of course, all this assumes that there is some shared underlying behavior for all items - that they each share some members (the basics, like name, value, etc), and that each can do something (Execute()).
Just an idea. Again, feel free to ignore if this doesn't help.
Switch: SW-3515-0057-3813 FF XIV: Q'vehn Tia
Say we want to make an Item unbreakable, your description would imply each item that is unbreakable would need its own class with it's own code written (ignoring abuse of inheritance so you wouldn't need to write it multiple times.)
I would suggest something like this:
public class ItemProperties{ /**Makes this Item unbreakable by adding a listener */ public static void makeItemUnbreakable(Item i){ i.addItemListener( new UnbreakableListener() ); } } class UnbreakableListener implements ItemListener{ public void itemChanged(Item i){ //we only get here if the item has been changed if(i.getDurability() != i.getMaxDur(){ i.setDurability(i.getMaxDur()); } } }This means we can generically make ANY item unbreakable without adding any code to a special Item class.
Maybe we want to make a weapon get weaker as it's durability gets lower, we could add a listener to do that.
class WeakerWear implements ItemListener{ public void itemChanged(Item i){//something like this i.setAttack( i.getMaxAttack() * (i.getDurabity()/i.getMaxDur())); } }And as long as you write the listener handler code well, this will have no side effects, makes it extremely easy to add and change Item behavior, and probably be easily serialized separately. Of course you need to handle adding, removing, and keeping track of listeners attached, but in the long run it is no worse than the multiple class idea.
I'm not stabbing at M$ from afar... my school offered no VB courses unless there was one tucked away in the business school or some such (where RAD would be useful). As is, I'm not sure where VB, even the .NET version, fits into what I'd consider a "normal" CS curriculum.
SE++ Forum Battle Archive
Technically speaking VB.NET is actually in a lot of ways a more powerful language than Java*, and a lot of schools offer Java courses. It has a PR problem mostly, and some unfortunate features that are in there for VB6 compatibility only.
*For example VB.Net has closures and reified generics.
For fun, this is how you'd do it in C#:
static void Main(string[] args) { string originalText = File.ReadAllText("subtitles.txt"); Regex regex = new Regex(@"\d{2}:\d{2}:\d{2},\d{3}"); string newText = regex.Replace(originalText, MatchEvaluator); File.WriteAllText("subtitles_processed.txt", newText); } private static string MatchEvaluator(Match match) { string originalTime = match.Value.Replace(',', '.'); TimeSpan time = TimeSpan.Parse(originalTime); time += TimeSpan.FromSeconds(5); return time.Hours.ToString("00") + ":" + time.Minutes.ToString("00") + ":" + time.Seconds.ToString("00") + "," + time.Milliseconds.ToString("000"); }Of course you could hook in for more extensibility, etc, but that's the heart of it.
Edit: Also aside from the stats being passed in as parameters. If two items were so similar that the only difference between them could be expressed in numbers, I'd just remove one of them.
Mine would be as short as yours if I had read the whole file into memory, so my solution is cooler than yours. So there.
Not sure if this is what you want, but does this help?
I don't really have any game programming experience, and all the game development tutorials I'm finding involve 3d games
The easiest (perhaps the naive) way I could think of is having each element on the screen represented as an object. Each object instance stores, as a minimum, a 2d polygon, a transformation, and a spritesheet, and is represented on the screen as equiplanar polygons with the sprite as a texture. Scrolling is handled by just moving a viewport facing perpendicular to the 2d plane. Everything is then updated with an eventloop, updating any object bounded by the viewport.
However, I can't imagine this approach being efficient enough to work on hardware of the era. Having a polygon bounding box for each sprite seems pretty taxing, especially given how Starfox still managed to bring the SNES to its knees despite a pretty low polygon count and additional hardware. Yet somehow, late SNES games had very beautiful sprite scaling and rotation effects.
Is this approach pretty close to what actually occurred back then?
Collision detection was very easy since everything was easily represented by a primitive instead of a polygon. You would just count everything as either rectangles, or sometimes circles, and those are computationally easy to resolve. Sometimes you wouldn't even do that and just use the video engine, it could detect overlapping sprites iirc.
Anyway, I'm not very familiar with tilemaps. I'm assuming by how certain games glitch up (garbled up squares all over the screen), that it's just a bunch of squares laid out across the screen. I could see how this would greatly reduce resources, but how would the screen scroll? Let's say I was trying to scroll left to right. Would I just remove the leftmost column of tiles, shift the rest of the tiles left 1, and add the next column of tiles to the right side of the screen?
Yeah, you get used to writing code in a certain way or use libraries and they start to feel like magic. Often looking at the source quickly dispels that. After talking to someone who was working on a quicksort assignment, I looked at java.util.Arrays.java to see what Sun had done. I was vaguely horrified by what I saw, but since I don't have to maintain the code it's not my problem. I did like the comment on line 465, which showed that Sun's engineers probably felt similarly:
Many early video games followed object orientation design patterns even though they did not contain a real object model as we would think of it today.
Scrolling was controlled entirely in hardware. You'd tell the hardware to shift your tile map by x pixels and it would do that. If you just shifted tiles, the scrolling wouldn't be smooth. The level would appear to jump in 8x8 or 16x16 pixel chunks. The advantage to controlling scrolling by the pixel is that you get to arrange objects with more granularity than the tile size. The disadvantage is that you are limited in level size by the size of the hardware tile map. So some developers would use the hardware to scroll across a small portion of their tile map and then shift in/out columns, rows, or blocks and then undo the shift with the pixel-wise scroller to snap it back into position, making the game appear to be able to scroll long distances when in reality, the pixel-wise hardware scroller is only moving 32 or so pixels in any given direction.
(This is an overview of the techniques, not intended to describe any platform in particular.)
Yeah well all it needs to deal with is subtitle tracks for movies, which aren't going to be more than a few KB. Don't need to overengineer it.
Ooh, TimeSpan looks handy. That's what I was looking for in Ruby, since it felt like too much work to write my own implementation for this little work.
...but I could use the exercise. Haven't done any proper programming in ages.
graphics are arranged into preset Tile sets, which are basically the aformentioned 8x8 tiles. I forget the max tiles you can have loaded in at one time, I feel like it was like 128 max, divided evenly between "sprite" tiles and "background" tiles.
Those tile sets are basically just an array of indices into a preset color palette, of which have 4 colors per each palette, there was actually only 3 colors for sprites though, since one of the colors denoted transparency. You can use a different keys for a different tiles (in fact two tiles with same tile set index can use a different palette, so you can do color swapping) you can have 8 palettes for the "background" and I forget how many for the sprites, but they are different palettes for each.
Finally collections of tile sets using those color keys can be loaded into preset backgrounds, backgrounds have a limit of being the aformentioned 256x256 pixels, or 32x32 tiles, but since the screen width of the GBC at least is 160x144, this only covers like 2 screen widths maybe.
This means that you have to swap out backgrounds on the fly from the cartridge onto memory if you want big scrolling backgrounds.
The sprites operated simply within pixel screen space, 0x0 being the top left of the screen, and 160x144 being the bottom right of the screen. Much like scrolling the background while the tiles operated in 8x8 chunks, you can move them on the screen with the granularity of a single pixel.
I dunno if there was any proprietary stuff at the time, but when I did this (for a class), the thing that really sucked was if you wanted a character bigger than 8x8 pixels, because you had to composite him out of 8x8 chunks which weren't really associated, so a large 16x16 character had to be made out of 4 8x8 tiles, and you have to manage those in assembly to keep them facing the right way etc.
Collision detection WAS really easy, since you pretty much had a bounding box right there for you, so that wasn't too hard.
As far as the corruption you would see in those era games, I know I had some problems with accidentally pairing up the wrong tile set with the wrong palette under some conditions which caused all sorts of interesting colors to appear on my screen. Accidentally loading the wrong tile set, or any sort of memory corruption when loading new parts of the map could cause that corruption.
Anyway that was probably tl:dr for most of ya, but doing that definitely gave me a ton of respect for the people who worked on those NES and GBC titles. I am also certain that if I was tasked to make the open world map system for Pokemon:Red/Blue, I would have quit my job right there.
Operator overloading. :P
A lot of the code I'm currently reading in my studies is C++ (Gang of Four book). I've had some experience with it in college, but some of the simple things confused me at the time, and still cause me to scratch my head now.
I get the basics of argument passing. Pass by value and reference are pretty simple to understand. I get confused when constant reference enters the scene, as well as pointers.
For the first, is only the reference constant? Can the value of the argument be changed/modified? How is this different from constant methods/functions?
For the second, what's the difference between a pointer and a memory address?
Are there any decent links/tutorials that go over this?
Switch: SW-3515-0057-3813 FF XIV: Q'vehn Tia
I find this to be a good link to provide to people who have a difficulty with the whole notion of pointers and addresses:
http://www.cplusplus.com/doc/tutorial/pointers.html
http://www.cplusplus.com/doc/tutorial/constants.html
Constants don't change, ever. So if you ever need a static value to be consistent, use a constant. Don't just throw const in front of things though, that's what retarded books and examples sometimes show you.
Example: const float Pi = 3.14f; would be a good place to use a const.