by fzammetti » Feb 10, 2004 @ 2:08am
Well, let me put it this way... In my current project I do this way too much:
int player_frame = 0
int player_frame_delay = 0;
// Then, later on in the main game loop...
blt(player[player_frame]);
player_frame_delay++;
if (player_frame_delay > 5) {
player_frame_delay = 0;
player_frame++;
if (player_frame == 10) { player_frame = 0; }
}
Now, you can obviously ask why I didn't write a class to deal with that, and my simple answer would be that by the time I realized it would have been a good idea, I was so far along that I just said f**k it.
But, my point here is that in my mind, that's a big part of what a sprite class should do. Now, whether it's taking a surface and dividing it into blocks and calling them frames, or taking in an array of pointers to images that are frames, or something else entirely, the abillity to encapsulate code like what you see above is what I would consider a sprite class to be for.
Now, the point that animation is game-specific is valid, but I don't think that means you can't come up with a sprite class that handles a lot of cases, maybe even most cases. I'm not saying I can enumerate all the details here, I'd have to think about it a great deal, but something generic I definitely think is possible.
...and so I said to Mr. Gates: "$640 billion should be enough for anyone!"
