Evil Activity
2009-11-02 11:55:12
Hello, thanks for the response :) , you are talking about collision detection optimization correct? I think this approach could be very useful for that, because from what I see, it could handle different sized 2D sprites with less problems than a static grid.
Mr.Gando
2009-11-02 12:36:05
Indeed, but as always: never prematurely optimize! Get things working first, perhaps you don't even need such a system, but that's up to you to decide.Additionally to this sytem, you can also shift the higher level grids so if an item doesn't fit well inside one box, you would have to place it a box higher. In the worst case scenario in a default quadtree, you had to move it all the way to the top-most box (think of an overlap between box 00 and 01). This requires you to have a collision detection with that object every time (not necesserly bad if it's just one).
Evil Activity
2009-11-02 14:28:20
+1
A:
Fire them out to the Z buffer and let that worry about it.
If you find that in the future it is too slow (via profiling obviously) then look at optimizing it.
Take the simplest solution and move on.
graham.reeds
2009-11-02 11:58:53
+1
A:
Your method fails if you have two sprites occupying the same box in the grid. Suppose you have two enemies both standing in the same box. One stands slightly in front of the other. Which do you draw first? You would need two algorithms - one which divides the sprites into the grid, and the second which looks at the z co-ordinates of all the sprites in a given grid box and draws them based on that value.
A far simpler method is to have a single collection of all sprites. It should store all sprites sorted by their z co-ordinates (from the back of the screen at the head of the list to the front of the screen at the back). Loop through the collection and draw each sprite as it appears. When a sprite moves into or out of the screen (ie. its z co-ordinate changes) you can perform a very simple sort to move that single sprite within the collection. Keep swapping it with the next sprite in the list until the next sprite's z co-ordinate is greater than/less than (as appropriate) the changed sprite's co-ordinate.
Ant
2009-11-02 12:17:51
Yeah that seems way more simple, and has a lot of sense... but what if most of the sprites will happen to be moving most of the time ? Do you think it will be efficient enough?
Mr.Gando
2009-11-02 12:34:50
All you're doing is swapping at most half a dozen pointers around. Cost should be essentially negligible.
Ant
2009-11-02 19:54:56