Page 1 of 5

Future PF features

PostPosted: Feb 9, 2004 @ 7:03pm
by fzammetti

PostPosted: Feb 9, 2004 @ 7:11pm
by mlepage

PostPosted: Feb 9, 2004 @ 8:18pm
by fzammetti

PostPosted: Feb 9, 2004 @ 8:35pm
by Birdiestyle
Frank,
For the bitmapped font class for now I just grabbed the one on your site from Jason Chong, and changed it a little bit so it will return string lengths, and works right with the current GD/MetalShard type fonts (they grab the column on either side of the mask line on top for spacing, etc...).
I wanted to get my current project ported over fast and this worked pretty well, and the tool is then already written, as Im guessing MetalShard might be coming this way too... As long as that doesnt cause any problems with GD?!?!? I would think it would be good if we are all working with the same font types(easier port back to GD in the future)....

PostPosted: Feb 9, 2004 @ 8:45pm
by fzammetti
Thanks birdiestyle, I was not aware of that (I haven't looked at my own site in some time!). I'll talk to Jason as well as Metalshard and see how they feel about using their work. Maybe Metalshard would even update the tool themselves to add some of the features I was talking about, and then I can just work on the actual render code (heck, maybe Jason might even want to continue on with it himself, in which case I can move right into the GUI stuff - Jason, are you reading this by any chance?!?).

PostPosted: Feb 9, 2004 @ 8:54pm
by Birdiestyle

Re: Future PF features

PostPosted: Feb 9, 2004 @ 10:41pm
by Pam

PostPosted: Feb 10, 2004 @ 12:37am
by fzammetti

PostPosted: Feb 10, 2004 @ 12:44am
by Kzinti

PostPosted: Feb 10, 2004 @ 12:53am
by fzammetti

PostPosted: Feb 10, 2004 @ 1:04am
by StephC

PostPosted: Feb 10, 2004 @ 1:06am
by wyrd

PostPosted: Feb 10, 2004 @ 1:09am
by Dave Johnston

PostPosted: Feb 10, 2004 @ 1:12am
by wyrd

PostPosted: Feb 10, 2004 @ 2:08am
by fzammetti
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.