Bug: Player sprite draws on top of NPCs

[pushfoo]

Describe the bug The player sprite is rendered above mobile NPCs which are located lower down on the screen and should be drawn later.

To Reproduce Steps to reproduce the behavior:

1. Start the game with python -m rpg after install
2. Use WASD/arrows to move the Player Character so its center XY position is above a cat's center XY, but is close enough for the outlines of the two sprites to intersect

Expected behavior If the player's XY is placed higher on the screen than the cat's, the player should be drawn under the cat to preserve classic top-down RPG aesethetics.

Actual behavior The player sprite is drawn over the cat sprite

[Cleptomania]

This is probably a bit of a tough one to tackle, and likely requires some changes Arcade side to enable it really. Roughly what we need is to be able to Z-index sprites, and then use a depth buffer during rendering to handle global z-index across spritelists, but Arcade doesn't currently support that. This issue has been discussed a lot on Arcade and there are some ideas floating around, so we will probably just hold off on this until there's a solution available in Arcade(or at least a recommended way to handle it).

The depth buffer solution mentioned above isn't necessarily a silver bullet, as any sprites with an alpha that's not 0.0 or 1.0 will cause issues(AKA partially transparent sprites).

[einarf]

EDIT: Ignore this comment. I did not fully understand the problem.

[pushfoo]

We could solve this without changing rendering by using assets, map design, and collision logic that prevent drawing the player on the same tile as another foreground sprite (NPCs, buildings, interior furniture, etc). Pokemon Red/Blue/Yellow on the Gameboy use this technique. Tall grass is the only exception I know of.

The problem with this solution is it requires a notion of grid tiles in the game. From what Clepto told me on discord, the game currently only has unpacked sprites at pixel locations. Most classic JRPGs seem to use a grid approach, so adding it would definitely be authentic to the inspiring material. Maybe we could do modulo?

The map design part of this solution would tie into #10, but we can also leave solving this problem until after PyCon. There are more pressing issues for the sprint, some of which I'll be filing today.

[einarf]

It is that expensive to sort a player + npc spritelist by x and y position every frame? If we're talking about 10-20 sprites it can't be that bad?