I'd like to know if it would be possible or not to change between 8x16 sprites and 8x8 sprites mid-scanline. That would be pretty cool, but I doubt it would work because the sprites are fetched one scanline early, so it would only affect the fetches for the next sprites ?
Changing sprite size mid-scanline would be absolutely meaningless, since it would be near impossible to time it and achieve usable results. If your first 4 sprites were 8x8 and the second 4 were 8x16, you would have to change sprite size FOUR times per scanline - once [to 8x8] at the very beginning (before sprite evaluation starts), again [to 8x16] after the four 8x8 sprites are evaluated, again [back to 8x8] after the remaining (8x16) sprites have been evaluated, and yet again [back to 8x16] after the first 4 (8x8) sprites have been fetched; the NES CPU simply is not capable of that sort of high resolution timing.
Changing sprite size mid-FRAME should be possible, though...
That's what I was afraid off.
Actually, I originally wanna to show 8x8 sprites in the status bar at the top and 8x16 sprites in the game play screen, so it would work with only one midframe change.
But, when the player goes up into the status bar, his sprites suddently becomes 8x8 instead and it has glitches, so I *could* use some kidna mid-scanline change to handle that. I was wondering if the PPU doens't evaluate the size while rendering instead of while fetching.
All that all want is sprite 0 8x8 and all other sprites 8x16, I think this would be tough to handle (or ?).
Is there a reason why you cannot use 8x16 sprites in the status bar (or simply prevent the player from going up there)?
Well, I also could use 8x16 sprites in the status bar, but I don't know yet what I'll put into. I've just guessed it could economy precious tiles in the pattern table.
Prevent the player to go in the status bar isn't really possible because I use screens of 8x6 blocks large of 8x8 tiles, that left just 4 rows for the status bar. The only solution would be to not use thoose whole 4 rows (let one or two rows blank), or use definitely 8x16 spites. I'll solve that problem.
Bregalad wrote:
Well, I also could use 8x16 sprites in the status bar, but I don't know yet what I'll put into. I've just guessed it could economy precious tiles in the pattern table.
If you're using a VROM mapper or a bankswitchable VRAM mapper (CPROM or Squeedo), you can bankswitch in a separate pattern table for tiles, using either sprite 0 or a mapper IRQ to detect the boundary between the status bar and the playfield.