How to handle spritesheets?
Author
I'm currently working on a Dune II clone, and the number of images I have to load is increasing steadily. Right now, I'm starting to add the weapons, and for gun fire itself is already 9 bitmaps, and that's without the explosions, which is another 14 images.
Add the different units and buildings and the tiles for the map to it, and I have a large number of images, and a high number texture changes, and thus, an unnessacery(sp?) slowdown.
I've been thinking, I could cram this all into a tilesheet, and make use of that. But what's the 'best' solution for this? Create several tilesheets, load those and then hardcode the positions on the sheet or use a file, or just load individual images, cram them onto a tilesheet and hand out references to the positions, etc.?
Toolmaker
My preferred way to handle it is by storying similar sprites in a single sheet (maximum 512x512) and then layer them. For instance, all of the frames for a vehicle would be on a single sheet and then each vehicle type would have its own sprite sheet.
Edit: Also, in my opinion, you should never hardcode anything[smile].
Edit: Also, in my opinion, you should never hardcode anything[smile].
Author
Quote:Original post by Programmer16
Edit: Also, in my opinion, you should never hardcode anything[smile].
Same here, that's why I have one of these:
<rules> <buildings> </buildings> <units> <unit name="trike"> <visual base="images/units/trike.bmp" width="14" height="13" /> <stats type="wheeled" speed="50" hp="15" armor="12" attack="15" /> </unit> <unit name="quad"> <visual base="images/units/quad.bmp" width="16" height="16" /> <stats type="wheeled" speed="40" hp="20" armor="20" attack="20" /> </unit> <unit name="light tank"> <visual base="images/units/lt_base.bmp" turret="images/units/lt_turret.bmp" width="16" height="16" /> <stats type="tracked" speed="12" hp="50" armor="40" attack="35" /> </unit> <unit name="siege tank"> <visual base="images/units/st_base.bmp" turret="images/units/st_turret.bmp" width="18" height="18" /> <stats type="tracked" speed="10" hp="70" armor="70" attack="50" /> </unit> <unit name="harvester"> <visual base="images/units/harvester.bmp" action="images/units/harvesting.bmp" width="40" height="26" /> <stats type="tracked" speed="12" harvestspeed="25" hp="50" armor="50" payload="700" /> </unit> <unit name="devastator"> <visual base="images/units/devastator.bmp" width="18" height="20" /> <stats type="tracked" speed="8" hp="100" armor="90" attack="75" /> </unit> <unit name="deviator"> <visual base="images/units/deviator.bmp" width="16" height="16" /> <stats type="tracked" speed="13" hp="25" armor="25" attack="50" /> </unit> <unit name="rocket launcher"> <visual base="images/units/launcher.bmp" width="16" height="16" /> <stats type="tracked" speed="13" hp="25" armor="25" attack="50" /> </unit> <unit name="sonic tank"> <visual base="images/units/sonictank.bmp" width="16" height="16" /> <stats type="tracked" speed="13" hp="25" armor="25" attack="50" /> </unit> <unit name="mcv"> <visual base="images/units/mcv.bmp" width="24" height="24" /> <stats type="tracked" speed="10" hp="35" armor="50" /> </unit> <unit name="carry-all"> <visual base="images/units/carryall.bmp" width="24" height="24" /> <stats type="aircraft" speed="90" hp="5" armor="0" /> </unit> </units></rules>There are only very few things hardcoded into the game, and like I said(Or not), I want to keep it that way. Being able to configure stuff is so much nicer.
Toolmaker
You could do what Steve and I did, which is to design a texture managing system which allocates a giant block of texture memory, then loads all other stuff onto that texture. Essentially its the same thing as having a dynamic spritesheet setup, except that it would manage all the texture coordinates for you (by passing you back a texture object which contained the coordinates, and could be blitted directly pretty easily).
*shrug*
Depends on how much you want to over-engineer. The "cram-them-onto-1-file-yourself" has the benefit of requiring you to acquire and open 1 file, but there are no benefits at run-time over the other method. Then again, you'd have to hand-manage all your image data and the sprite sheets and yuck.
I prefer the system to manage it for me.
*shrug*
Depends on how much you want to over-engineer. The "cram-them-onto-1-file-yourself" has the benefit of requiring you to acquire and open 1 file, but there are no benefits at run-time over the other method. Then again, you'd have to hand-manage all your image data and the sprite sheets and yuck.
I prefer the system to manage it for me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
