sprite drawing order

you didn''t say what language you are using, but if you are using one which supports polymorphism (i.e. c++) you can create a base class which has a virtual member function for drawing... all of your other classes could be derived from this, and implement the drawing function.

then, you can cycle the array of pointers and call the draw() function for each one.

as for drawing order, you''ll have to sort them back to front.

here''s the way i handled (moveable)objects in an old iso-engine, perhaps it helps:

i had every object class inherit from a CSprite base class and one gloabl identifier for each sprite-subclass.
I then had an object layer for my map which held the class identifier and a CSprite pointer to the sprite currently on this place on the map for every tile, or a null pointer if there was no object/sprite standing there.
then in the map drawing function i would do something like
Map->DrawTile(x,y);
Map->DrawObject(x,y), which would just call the Draw() function that was defined in CSprite and thus inherited by all it''s subclasses
and do this for every tile from back to front. This worked pretty nice and was fast.

Of course with the object layer this only works for an iso or tile map where only one sprite can be on a tile at a time, but if you just inherit every sprite class from one sprite baseclass you can as well all hold them in a linked list, so it''s possible to have them standing anywhere on the map.
That''s the nice thing of classes and inheritance...you don''t need to worry exactly what kind of sprite there is, as long as it inherits from a sprite baseclass and can draw itself.

Hope that made some sense

---

My Homepage

thanks for your replies, the inheritance will be good...

Map->DrawTile(x,y);
Map->DrawObject(x,y), which would just call the Draw() function that was defined in CSprite and thus inherited by all it''s subclasses




no offense but this look like it will slow your engine down
ever heard of a "function call overheat?

What you are talking about Basiror?

quote:

---

Original post by Basiror
no offense but this look like it will slow your engine down
ever heard of a "function call overheat?

---

please show me a computer where those few hundred function calls per frame decrease the framerate measurably whith all the thousands of other gameplay/AI/GUI/etc. related functions being called every frame

Edit: sorry, but i just have to add this:
no, actually i never heard of a function call overheat ..AFAIK only hardware can overheat

---

My Homepage

[edited by - Burning_Ice on March 16, 2003 1:05:47 PM]

I encountered the same problem in my game that I''m currently working on (a classic SCUMM-like adventure game) and I took care of this using inheritance (as was mentioned) where the base class had an overloaded < operator, and all the sprites inherited that. I then had a vector containing pointers to the base sprite and sorted them every frame. I used an insertion sort since it''s generally faster than all other sorts in this case (the sprites are usually already sorted, and if not, only one or two sprites are out of order each frame). I also used an insertion sort because I didn''t know how to use functors at that point and std::sort() won''t work on pointers (properly) without a functor. std::sort() will probably be fast enough though, since RPG don''t usually require a lot of speed.