nesdev.org

It could be possible to obtain 8x8 and 16x32 changing during a frame, after the drawing, the setting of the obsel?.


I explain myself:
-Setting the obsel to 111 to obtain 16x32 & 32x64
-Dividing the screen in to sections, and sending into the vram 16x32 sprites to be drawn in the upper screen.
-Now setting to normal 8x8, and sending to the vram to be drawn in the down part of the screen.

The point is, snes doesn't have frame buffer, so the line buffer passes in order from the first scanline to the last, one by one, and this can let you to change everything before all the line buffering passes be done.


So, 8x8 and 16x32 cant be done in the same scanline, being from different obsel valors. BUT, What if you interrupt the line buffering to change the obsel before to continue outputting the signal to the tv?.

I can't even explain myself in spanish, so i think i'm daring too much testing my english like that xD

Maybe. You'd want to test it to make sure it works - I only messed with it a bit*. Lots of stuff gets done by per-scanline raster effects in commercial SNES games (fun fact: Mode 7 can't do perspective on its own), but I'm not aware of anybody trying this.

And of course, even assuming it works, any 16x32s that overlapped the line on which the switch was made would be cut off, and any 8x8s that overlapped the line would have an extra garbage tile rendered on the lines above the switch. So you'd need strict separation of "small" sprites, and unless you were using 32x32 for the large size in both settings, you'd need strict separation of large sprites too.

This is not the easiest scenario to actually realize in a practical game engine. I'd recommend forgetting I said anything.

...also keep in mind that the non-square sprites don't do vertical flipping properly. There's a reason they're not in the manual.


* I was experimenting with OBSEL with a view toward proving that you can in fact change where in VRAM the 8 KB OBJ tables are assumed to be partway through a frame, without glitching like in First Try. This effort was successful; you can indeed change the OBJ table locations glitch-free outside of VBlank, as long as you do it during an active scanline while the PPU is scanning OAM (ie: you need an IRQ; you can't use HDMA). Changing the sprite sizes is presumably the opposite; I'd expect glitches if you try to change them during OAM scan, so it would need to be done during HBlank.