A way to affect sprite draw order

NES draws sprites based on the index in OAM associated with that sprite (0 through 64), however NES Maker doesn't manipulate it properly so the sprites are ordered as they should be and this makes for certain glitches where player is on top of a monster or sprite object when it should be behind it.

Obviously, how you'd sort the sprites depends on the type of game you're making (in zelda-like and a JRPG you'd sort based on sprite's Y value where in a platform game you'd may want to enforce certain order, so e.g. enemies are never drawn on top of the player while other things (such as sprite hud) may be. What makes me sad is that the sorting in NM (for adventure module) is either non-existent or implemented in so bad way that it may just as well not be there. Explain this to me, for example:



It's true that if I continue to go down, it eventually straightens itself out, so some sorting clearly is applied, but it seems to sort based on coordinates of the top-left pixel of the sprite instead of very bottom of it (as it should be the case for a 2.5d game like this).

Meanwhile, some monsters should be drawn below player at all times. For example, I got these things here:



See the grey dots? They're lasers - they act in a similar way that in some games spikes do. You may go through them if they're off, but when they activate (they're on a timer) they'll hurt player. Functionally, they work. But what when you are going through them?



Whoops, suddenly they're on top of you. Instead, there should be a way to force certain monsters to always be drawn under the player (or on top of him and other monsters if it's an environmental thing, such as a bird flying over, I guess) for occasions such as this.

Yes, this thread is nitpicky AF, but is it really so wrong for me to want from others the same thing I want from myself - absolute and utter perfection (or at least fixing basic bugs that can be seen with basic testing)?

The engine, by default, respects depth, of the collision boxes. It draws based on y of the collision boxes. It sorts every frame. If you're seeing something different, this may be because your collision boxes are set strange? Not sure....

Oh I see what you're saying. You want a way NOT to draw from back to front, in certain cases. Hm. This is tougher. It's sort of an all or nothing prospect here. There are ways to do it of course, but none of them pretty! None of them that, say, could be easy to just do with a toggle switch.

TheNew8bitHeroes said:

Oh I see what you're saying. You want a way NOT to draw from back to front, in certain cases. Hm. This is tougher. It's sort of an all or nothing prospect here. There are ways to do it of course, but none of them pretty! None of them that, say, could be easy to just do with a toggle switch.

Click to expand...

I see. And actually I want both - when it depth sorts it seems like it takes top of the box into consideration, when it should consider bottom of the collision box so it sorts properly.

And for monsters that should be drawn always on top/always on bottom if it couldn't be done easily (like, e.g. having additional listbox in monster group or monster details where the monster should be drawn with choices such as above player, same as the player (depth sort), below player), then I'm kinda sad that you can't pull it off - as they say, there are no impossible things, there is only lack of skills needed to complete the task.

It takes their y+bbkx top into consideration, I think.

There is a script that handles deaw order. An advanced user could make this a define and do anything they want in this space.

Another possible technique would be to develop a faux z coordinate and give it a quasi true depth, which is how we handled more 2.5d solutions in mystic origins.

TheNew8bitHeroes said:

Another possible technique would be to develop a faux z coordinate and give it a quasi true depth, which is how we handled more 2.5d solutions in mystic origins.

Click to expand...

Maybe you should port it over to the NM? I remember seeing the early version of NM that had MO engine underneath and it was working much better than sorting in the adventure module.

It should be generally the same, honestly. Just...the player can't jump, and there is no "birds flying over" in a top down type game (no true depth). But anything standing on the ground should be the same, I think, if the bounding boxes are set up correctly. I can do some evaluations to check that, though.