Recommended Posts

hi everyone !
I am currently working on a small but versatile 2d game engine based on SDL, and i've hit a litlle problem with the rendering logic :
-i have a tileset class wich parses a graphic file and creates a one dimentional array containing the info on each tile in the tileset, and can draw any chosen tile (by numerical index) to an SDL surface: works perfectly and is fast and flexible
-i have different game "objects" which need to be drawn: but here is the first catch : for flexibility reasons, i dont want them to be tied to a specific tile or tileset (ie , i don't want to have a member that is simply a pointer to a tileset or something similar)
For maximum flexibility , i would like the objects, when they need to be drawn, to simply return the data usefull for rendering to the main rendering function looping through the list of objects: this way, there is only ONE main rendering function which is easy to tweak , instead of having to modify each game object's "draw" function:
the question is , how would i do this ?
here are a one idea i have come up with to achieved it :
- at initialisation time : create an index with tileset numbers and corresponding pointers to tilesets
- when an object needs to be drawn, it simply return the desired tileset number and tilenumber (of course i would need to remember exactly which tileset and tile to draw,but this can be simplified)
-have the main drawing function get the pointer from the index and draw the tile that needs to be drawn from the desired tileset
Now of course things get more complicated: for example for a tilemap with animated tiles: how would i return an incremented tilenumber each time for each tile that needs to be animated ? or should i return (to the rendering function) a range of tiles to be drawn instead of a single tilenumber?
Is the whole logic i have going on completely flawed and clunky ?
Sorry for the very lengthy post! and thanks in advance for any suggestions and ideas on how to solve these!

0

Share this post

Link to post

Share on other sites

That sounds like a good general approach. The main advantage of refering to sprites by id is that you can store the information in data files and modify these resources without rebuilding. I would probably create a sprite object that sits between the game object and the sprite sheets. This object would know which sprite sheets to use, which animations it can play, and where to find those animations on the sheets. Store this information in a data file, and either load all your sprites at start up or lazy load them as needed. Then when you create a game object that uses a sprite, it can look up the sprite object it wants based on ID. The game object should know which animation it wants to play and which frame of the animation it is on (it can just increment this every frame). At draw time it tells the sprite which animation and frame to draw. (Or it could pass sprite id, animation id and frame num to some other drawing function, but I would probably make the sprites draw themselves).

I would also suggest using strings instead of ints for storing resource ids in data files. This makes it a lot easier to manage your art resources. At load time you can convert the strings to int ids or even pointers to objects as needed. For debugging builds I would probably hold on to the strings at run time as well so that they can be printed to logs if needed. One way to do this is to create a custom type to hold resource ids. Give it a string member that is compiled out in release builds.

0

Share this post

Link to post

Share on other sites

Guest Anonymous Poster

Guest Anonymous Poster

Making animated sprites can be done by storing the current sprite id in an array with one entry per object. In the animation update, custom code can swap these ids to new ones without doing any drawing. You can also place other info, like layer position next to the sprite info. This way the code can specify other info required for rendering. During the drawing a single loop can draw all sprites along with the backgroung.

For animated background, which animates but are mostly static in position, the ids can be stored as a from-to range, so the background matrix doesn't need a change for every frame. The renderer should cycle through these ids and step the current id on every frame (or the desired animation speed).