Re: A better-looking design for the site.

[Brett_A._Letner@notes.up.com]

Group-
Note:  Unfortunately, my comments aren't really answers to your questions,
but since these are pretty basic to most 2-D games I thought the group
might be interested in how others are tackling the same problems (in my
case for a 2-D football game).  Comments, criticisms, etc.. are welcomed.

>> 1. Load an image, either from a file or from a buffer
>> containing the file data, into an RGBA color array.
>> I need GIF support.  PNG and TGA might be nice too.
I started out trying to use PNG, it has some very nice features (especially
the transparency and compression).  I ended up rendering my images to ppm
format(the simplest I could find) and then I convert them to my own format
based on run length encoding (RLE). More information on RLE can be found
at:http://www.geocities.com/Silicon_valley/Vista/6774/Rle.html

>> 2. A really basic sprite-based collision dectection
>> system.
My players are rendered as though you were looking at them from the stands,
so pixel-wise collision detection doesn't make sense for me (Imagine 2
players standing next to each other, the front one will mostly obscure the
back, but they still aren't touching).  So I am planning on giving each
sprite a width and depth and doing simple rectangle collisions.

>> 3. A library that renders sprites, clipped to an
>> arbitrary rectangle, and drawn in one of the 8
>> standard orientations (with flipping and/or rotating
>> at increments of 90 degrees).
My players will also have 8 directions, but since my players have a 3-D
look (rendered with Pov-ray), I am unable to do simple rotations to acheive
this.  Instead I have rendered each direction seperately.  Unfortunately
this can lead to alot of images.  e.g. my players running take
8(directions)*7(frames)*2(teams)*2(carrying ball or not)=224 images.
Fortunately not all actions are allowed in all 8 directions (such as
kicking).

>>A library that keeps track of sprite animation frames
>>would also be nice, but I don't really need it.
This _is_ kind of painful, since in my case the next frame can depend on
the sprites state,speed,direction, and last frame.
-Brett