I'll get right to the point. I want to force a sprite's graphics to be drawn in front of mario. I know it's possible, because, well... one of the tiles of a door sprite does it.



It's 8 8x8 tiles. I've no clue why one goes in front of mario, as they all have the same settings. The only unique thing about that tile is that it is rather high in the OAM order.
EDIT: The graphics routine of that sprite, if interested. The last tile is the one being drawn over mario.

I want to prevent tiles drawing over mario in this case, and cause it elsewhere.


Everything I've ever read about sprite priority in SMW states that they're drawn over each other in relation to the order of the OAM. I want to know exactly what that means. I thought lower OAM order meant higher priority, as evidenced by mario's tiles being at $0310, when the sprite tile OAM starts at $0300 (only allowing for 3 tiles to be below him, which I presume to be used by yoshi).
But if that's true, why is the tile in my above screenshot acting the way it is?


Oh, and another thing. Here's an excerpt from a SNES graphics reference I've been using:

I'm mostly interested in bits p and m of that register. From all.log:

This, as far as I can tell, is a regular level's settings. #$09 means that it is mode 1, and the priority bit is set (00001001).

Now, back to the graphic reference:



My question is: Is my reference incorrect? Am I misreading it? It states that, in a regular SMW level, sprites with both priority bits set should be drawn above other sprites, and in fact everything but layer 3. In other words, sprites should be drawn over each other based on priority. But they are not in SMW... Is this true for every SNES game, or is it a quirk of SMW?

Maybe I am misreading it. Does that list of priorities only matter when comparing different BG/sprite layers? So, if you could somehow had a tile of BG1 with priority and one without overlap, would they theoretically also respect some sort of VRAM order, and not priority bits? (I'm pretty sure it's impossible for BG tiles from the same layer to overlap, but )


I'm certain I can do what I want regardless of the answer. I'm just a little confused as to how these things work.

Mod edit: stretch--;

In $2105, bits 0-2 are used to determine the BG mode. I'm sure you once heard of this. Mode 7, anyone? SMW uses Mode 1. These bits are irrelevant to your priority questions though. (Unless you want to have the list of which layer goes above another, but I can see you already have that one.)

Yes, the p bit gives Layer 3 ultimate priority over everything else. You can see this in the status bar.
It only works in Mode 1. (Obviously not in Modes 2-6 since those don't have Layer 3. Not sure why it doesn't work in Mode 0.)

From what I've tested, sprite <-> sprite overlap depends on the OAM order.
The lower in the OAM table, the higher the sprite <-> sprite priority. This is why extended sprites, cluster sprites, etc. are always in front of other sprites. (They use $0200-$02FF IIRC.) This is why Mario is in front of most normal sprites. (Most normal ones are drawn on $0318 and beyond. Not sure about Yoshi.)
The PP bits in YXPPCCCT don't seem to have any effect in sprite <-> sprite overlap at all. Their effect goes into layer <-> sprite. (And here, the order in OAM doesn't matter, again.)
The higher the value of the PP bits, the higher the priority of sprites over layers.
Again, I assume you have a good reference of this. I myself prefer regs.txt.

I hope this helped a small bit. I don't think this is something specific to SMW, I believe SMAS has it too but I might have to double-check that.

--------------------
--------> Don't follow "Find Roy's Dignity", my hack. Because it's pretty outdated. <--------

Alright then. The tile in my screenshot must be a victim of the OAM index overflowing back to 00, though I'm not sure why it does. I have no where near 64 sprite tiles being displayed on that level (more like 20, including mario).
I'll have to make a patch that moves Mario's OAM index on a per-level basis. Shouldn't be too hard.

I still wonder if sprite/bg layers all ignore priority bits in relation to tiles on the same layer, but I guess it really makes no difference. The sprite layer is the only layer which tiles can overlap.

http://romhacking.net/utils/274/

Make a savestate and view it in this tool, you can see the entire machine state including a handy OAM viewer so it beats posting here wondeirng what is going on inside. It's a very useful tool, fully graphical and all of that.

sprite to sprite priority is based on OAM order yes but is subject to OAM priority rotation, see regs.txt for that. Usually it is not used at all.



nope, not true at all.

If you have a sprite with a higher OAM priority than another sprite, but the higher priority sprite has LESS BG ('pp') priority then the sprite is masked and you just see the BG instead of either sprite, where it looks like the sprite is 'overlapping' with transparency.

to quote regs.txt

Ah, I already have vSNES. Didn't know it could do all that! Checking it out, and I'm going to see if I can make the OAM rotation thing work for my purposes.

EDIT: Well, my current solution is to set $3F to the sprite OAM index of the sprite I want Mario to go behind. Not sure of any adverse effects from this yet.

All.log shows SMW setting $2102 to this value right after some sprite DMA during the NMI. Dunno why after and not during...

I'd like to find out a way to do this as well. I was trying to make a mine cart sprite quite a while ago, and the number-one biggest problem with it was that the player always went in front of it even though I really needed him to go behind. If copying the sprite's OAM index to $3F works, then that's what I'll do. I just have a feeling that it might mess something else up....

Yeah, me too. Haven't found any real problems yet. Something tells me, though, that this will make mario go behind other sprites on the screen as well, though maybe not all. I doubt anything worse than that could happen.