Sprite sorting

[mix256]

Stef!

I've noticed that most of the sprites I add to the scene need to be sorted to end up on top of previous sprites, since default the sprites end up behind previously added sprites.

There are a lot of explosions, pickups and enemy bullets that should be placed on top of enemies, and since there are a lot more of those created the sprite list need to be sorted at most additions (I'm using SPR_setDepth).

I only bring this up because I recently had an address error in the spriteSort function in sprite_eng but I guess it's a waste of precious cycles as well?

A quick way for me to move forward from this is to have each sprite added first in the list instead of at the back of it.
But since I'm not that familiar with the inner workings of the sprite list I thought I'd ask you if this could be easily changed by me?
Doing something in the setVDPSpriteIndex function, I guess?

Cheers and a happy new year to everybody!

[Stef]

I really recommend you to not directly deal with sprite index (you still can but definitely more complicatd for you). If you want to sort sprite, just use the SPR_setDepth(..) method, allowing you to define "depth" for a sprite (and so defining sprite display order)

[mix256]

Thanks.
So there is no way to have it the other way around? To always have the newly sprites added in front without having to sort?

[Stef]

by default SGDK linearly allocate sprite so index should go in ascending order so that should work, but a safer way is to use :

Code: Select all

SPR_set Depth(depth++);

Each time you add a new sprite...
And sort occurs *only* when you set depth (and if needed) so it should be almost optimal here

[mix256]

But for me it would be SPR_setDepth(depth--) which would make it sort always, right?
So instead of inserting it at the beginning of the list it will get inserted last in the list with addSprite and then sorted to the top with setDepth each time?
Or maybe I'm thinking about this the wrong way?

[Stef]

Nope, using SPR_setDepth(..) will sort the sprite only if it's not already in place, if you do SPR_setDepth(depth++); for each sprite you add then they should be added at the end and the "farther" depth mean it will keep it in last position.

[mix256]

But I want the next sprite to be in front of the previous sprite. Visually in front of the the previous sprite.
depth++ will make it get behind the previous sprite, right? So I need depth-- and that will make it always sort.
Or what am I missing?

[Stef]

In fact the linked list on Megadrive work the opposite way :
first sprites have higher priority (draw in front) and last sprites have lower priority (draw in back).
So when you add sprites in natural order in the list, the new added sprite has lower priority (and so draw below) than previous sprite.
If you want them to have higher priority you have to put them first in the linked list.
So that is the same for SGDK, as you said you will need to start with a default depth (0 is ok as depth accept signed value) then use depth-- at each new sprite, and indeed that will sort your sprite at each new add (remember that it will only sort this sprite so that is not a big hit).

[mix256]

But it will be a big hit when I add 16 sprites on the same frame and there already are 16 sprites on screen.
That is why I'm asking for a way to add them first to the linked list.

[cero]

By adding them first.

[Stef]

Well, i could add a way to add sprite at the beginning instead of at the end of the list but that would make the sprite engine a bit more complex (and add a new parameter to addSpritexx methods). When you are adding 16 sprites in a frame (which is a lot indeed) can't you reverse add ordering so they are added from top to bottom priority order in the meantime (i will probably add the feature but it can take sometime) ?

[mix256]

Thanks Stef!

...can't you reverse add ordering so they are added from top to bottom priority order in the meantime...

No I can't, since the order of the 16 added sprites aren't important. It is only important that they all appear in front of the already existing sprites (especially the sprite that fired of the bullets or created the explosions).

So, as I asked in the original post, can I do some easy hack for this in setVDPSpriteIndex() or somewhere else ?

[Stef]

Well no unfortunately you can't do that, the sprite engine use a more complex linked list structure internally and changing the VDP sprite index won't affect display ordering :-/

[Sik]

Thanks Stef!

...can't you reverse add ordering so they are added from top to bottom priority order in the meantime...

No I can't, since the order of the 16 added sprites aren't important. It is only important that they all appear in front of the already existing sprites (especially the sprite that fired of the bullets or created the explosions).

So, as I asked in the original post, can I do some easy hack for this in setVDPSpriteIndex() or somewhere else ?

But inserting sprites in the order they're meant to be sorted is how games normally do it…

This is also why it's a good idea to separate game logic routines from drawing routines for the objects: they may need to be run in a different order.

[mix256]

But inserting sprites in the order they're meant to be sorted is how games normally do it…

Sure, if I had the possibility to re-insert all sprites each frame. Are you doing that with SGDK? if so, please tell me how.
Releasing all sprites and then re-adding them each frame is not something SGDK was meant to do since it would re-allocate the required vdp mem all over again. And even if not, re-sorting the required sprites would probably be quicker.

Well no unfortunately you can't do that, the sprite engine use a more complex linked list structure internally and changing the VDP sprite index won't affect display ordering :-/

Ah, thanks! Too bad.