Vertical callback or per pixel callback : I understand/How does Tilengine work?

[System64]

Unfortunately yes, I can only give support for Tilengine itself, not for other bindings. But I can take a look, maybe I can see something suspicious

Fortunately Nim programs can be debugged with GDB so it can help
I'll try to do a minimal reproductible example, because I don't want to ship the entire server with it.

[System64]

Hi, sorry I didn't do the minimal reproductible exemple but I will do this as soon as possible.
But I wonder something, how does sprite display work? Both sprites and tiles also have priority, so, sprites seems a bit complicated.
Thanks for your answer!

[megamarc]

Hi!

From top priority to least priority, the draw stack is:

Top  ->      Priority sprites
                Priority tiles
                Regular sprites
                Regular tiles
Bottom ->  Background color or bitmap

• In layers of the same priority, lower indexes are drawn on top of higher indexes (so layer 0 always on top)
  
• In sprites of the same priority, there is a display list order that can be altered with TLN_SetFirstSprite() and TLN_SetNextSprite()
  

Hope this helps!

[System64]

Hi!

From top priority to least priority, the draw stack is:

Top  ->      Priority sprites
                Priority tiles
                Regular sprites
                Regular tiles
Bottom ->  Background color or bitmap

• In layers of the same priority, lower indexes are drawn on top of higher indexes (so layer 0 always on top)
  
• In sprites of the same priority, there is a display list order that can be altered with TLN_SetFirstSprite() and TLN_SetNextSprite()
  

Hope this helps!

Hi!
So if I understand well, sprites layer is drawn 2 times and tiles layers are drawn 2 times too?

[megamarc]

There are four passes, on each pass only effective items for that pass are drawn.

So the first pass of sprites only renders regular sprites, and the second pass only renders priority ones. The same for tiles: first pass draws regular tiles, second pass draws priority tiles. Items drawn last overdraw the ones drawn fist, so this is how priority is achieved.

[System64]

There are four passes, on each pass only effective items for that pass are drawn.

So the first pass of sprites only renders regular sprites, and the second pass only renders priority ones. The same for tiles: first pass draws regular tiles, second pass draws priority tiles. Items drawn last overdraw the ones drawn fist, so this is how priority is achieved.

Oh, that makes sense now.
So if I understand well, you first draw all layers with normal tiles, then you draw the normal sprites, then you draws all layers again but priority tiles only, and then you draw priority sprites?

[megamarc]

Yes! That's it

[System64]

Yes! That's it

Totally makes sense! But how do you manage sprite drawing? They are not necessary in order. You probably use an array for storing sprites. Do you iterate through it at each line?

[megamarc]

There's a list that stores, for each sprite, what index to draw next after the current one. It also stores the first sprite to draw. When you need fine control of sprite ordering, for example to implement a 3/4 view for pseudo 3D where sprites at the bottom of the screen are nearer and must be drawn overlapping the ones that are located upper on the screen, you can use TLN_SetFirstSprite() and TLN_SetNextSprite() to arrange this list. It can be tricky however.

This feature is inspired by the Sega Genesis/MegaDrive, it has a similar concept of a display list of indexes but implemented differently.

[System64]

There's a list that stores, for each sprite, what index to draw next after the current one. It also stores the first sprite to draw. When you need fine control of sprite ordering, for example to implement a 3/4 view for pseudo 3D where sprites at the bottom of the screen are nearer and must be drawn overlapping the ones that are located upper on the screen, you can use TLN_SetFirstSprite() and TLN_SetNextSprite() to arrange this list. It can be tricky however.

This feature is inspired by the Sega Genesis/MegaDrive, it has a similar concept of a display list of indexes but implemented differently.

Oh alright, so you iterate through it at each scanline? Sounds quite CPU demanding.