SNES game programing help

[bazz]

OK Sik, I finally get you.. Ya I mean obviously set the ones you need and not the ones you don't... Ugh people these days.. Lol
The point is that if you are trying to set off-screen sprite.. Dont use 0x100 for X.. cause it will uck shi up. If you must use 0x100H, then at least have the Y coordinate at 240 (that's what Yoshi's island does That's what I'm going to do

[MottZilla]

I would still avoid setting X = 0x100 simply because Nintendo's manual firmly warns against it.

I'm pretty sure you can set X to 100h all you want. They probably warn against it because it affects sprite evaluation. So just setting the high X bit would be a bad way of hiding unused sprites. You should be setting the Y to just after the last rendered line for that obviously. So if you were putting sprites on the screen you'd probably want to decide that if any sprite was going to be placed with the high X bit set, unless it's lower 8bits make it so that it would be entering from the left, you should probably set the Y to off screen and forget about that sprite, or reuse the OAM entry for the next sprite since this one would not be seen anyway.

I can't think of any other good reason for why they'd warn against setting X to 100h.

[Sik]

The problem mentioned earlier seems to imply it can give problems even with the Y coordinate being off-screen, although I may have been misreading. What's the exact behavior that happens when X = 0x100?

[lidnariq]

I think I remember reading that X=100h is always parsed as "on screen" even if it should be off the side, and so uses up a render slot out of the SNES's sprite limitation per scanline.

[Sik]

Yeah, I recall reading that, but how does it interact with the sprite size and Y coordinate? Are they handled as usual (i.e. only the lines that normally would have that sprite have the problem) or are there other side effects?

[MottZilla]

This is what I assume but have not tested. If you set the Y coordinate to off screen, it won't matter what X is. X and S only matter if the Y places it on screen somewhere. If you do have Y on screen and X at 100h then that sprite will be counted toward the sprite limit and will take priority over sprites that actually might be visible if this sprite has higher priority.

It's something you could test fairly easily, but I think the behavior would be like I describe. It's probably best to not draw/hide any sprite which has an X value of 100h all the way up until 1FFh - Maximum Sprite Width. That would allow smooth entering of sprites from the left side of the screen but also cut down on any non visible sprites taking up sprite cells that might be needed for things actually visible.

If someone's bored or concerned enough then maybe they'll write a test ROM.

[tomaitheous]

I think I remember reading that X=100h is always parsed as "on screen" even if it should be off the side, and so uses up a render slot out of the SNES's sprite limitation per scanline.

That sounds exactly like the Megadrive and PC-Engine as well; it parses ALL sprites on the Y line regardless of it's horizontally off screen or not (assuming Y line is part of the display window). Thus, use Y to remove the sprite from the list when it's completely off screen (fully clipped).

[lidnariq]

That sounds exactly like the Megadrive and PC-Engine as well; it parses ALL sprites on the Y line regardless of it's horizontally off screen or not (assuming Y line is part of the display window). Thus, use Y to remove the sprite from the list when it's completely off screen (fully clipped).

The reason it's a caveat is that with the SNES, 0x101 ≤ X ≤ 0x1C0+ is correctly parsed as off-screen and so doesn't count against overdraw: http://wiki.superfamicom.org/snes/show/Sprites

[Sik]

If I recall correctly, it only counts the visible tiles, so if a sprite is partially off-screen, the tiles that are not visible don't count towards the limit (the SNES per-line sprite limit is tile-based, not sprite-based). It's just that when X = 0x100 that for some reason this check fails to work properly. I'm really clueless as to what could cause that, though (maybe the check against tiles is only with 8-bit coordinates, since a sprite with bit 8 clear always has its left side visible while a sprite with 8 bit set always has its left side hidden?)