Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

2D All the way! / DBP - Sprite Priority hurts

Author
Message
Captain GerBear
19
Years of Service
User Offline
Joined: 9th Jul 2006
Location:
Posted: 25th Jul 2006 04:36
I'm writing a map construction utility for my isometric RPG. The maps are made out of sprites, where each tile has its own priority for drawing order, but when I give the cursor the highest necessary priority (My largest map size can contain up to 12000 tiles) of 12000+1, I find it REALLY slows down, even though there are only a handful of sprites on the screen. This problem goes away when I make the priority lower, but then the cursor won't always be on top.

I've tried constructing the map without using priorities (Starting at the back and drawing forward) but sprites still appear on top of one another inappropriately when I do. They seem to appear in the order they were created rather than the order I'm telling them to draw in. Help?
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 25th Jul 2006 05:12
Yes, that's has a been a problem with DBpro since the very first Dbpro alpha's, some 4 years ago.

One approach I used in the globe demo (I have no idea where that is today) is to roll your own rendering functions. Where sprites are stored in a array/list (your choice) then you manually sort the sprite list on their Z depth. Once sorted you run through and manually Paste the Sprites to the screen. Or you could create them (from the back sprite to the front), sync, then delete them. Which will allow Dbpro to han dle the sprite batching for you.

Another is to compress the Z. Since your game engine will most likely be keeping track of real Z, you can actually assign sprites a compressed serialized Z rather than the real value. To do that, you get the list of z's in an array, sort them, then run through and manually set each sprites Z to the array index. So if there's 10 sprites on the screen say, the sprites will range from 0 to 9. Regardless of what there 'real z' was. This will keep the priority/draw order illusion.

Captain GerBear
19
Years of Service
User Offline
Joined: 9th Jul 2006
Location:
Posted: 25th Jul 2006 21:51
You know I didn't really understand your suggestion until I'd thought of a similar idea separately and put two and two together. That's a fantastic idea and it'll make placement of the character and objects work as well, a problem I hadn't tackled yet. Thanks for the help!
Captain GerBear
19
Years of Service
User Offline
Joined: 9th Jul 2006
Location:
Posted: 25th Jul 2006 22:09
I think that a simple GRIDX + GRIDY + GRIDZ for priority is going to work beautifully, and it also means that my upper priority limit is around 90 instead of 12000, which is a HUGE improvement.

Login to post a reply

Server time is: 2026-07-05 13:16:12
Your offset time is: 2026-07-05 13:16:12