Of course. There's no way to buffer this; sprites are drawn on every scanline based on what's in OAM at that moment. If you want to multiplex a sprite, you have to overwrite its OAM entry after the PPU has drawn the sprite with the old parameters but before it's drawn the same sprite with the new parameters. This also means that the updated sprite must have a Y-coordinate further down the screen than the old one, otherwise the updated sprite simply won't show up because the PPU will assume it already drew it.iNCEPTIONAL wrote: ↑Tue Jul 05, 2022 4:26 pmdoes the forced blanking used to do this type of multiplexing on SNES have to be in between the multiplexed sets of sprites
Yeah, you need a full reload if you want to change every sprite entry, including the packed data in HiOAM. That's 544 bytes. If you can get away with less, the black bar can be thinner; this depends on the game design.iNCEPTIONAL wrote: ↑Tue Jul 05, 2022 4:30 pmIs there a reason you need to do a full reload vs a partial reload?
Of course. That's why I was talking about forced blanking during HBlank, so as to squeeze a few sprite updates in without having to blank any visible pixels. Obviously this kills or glitches sprite display on the subsequent line, so you'd have to be sure there weren't any.
It's also why I want to try an advanced DMA redirection approach, because it wouldn't be limited in this way. I don't think it's likely to succeed (if it requires half-dot alignment to work, it will at best only be reliable on certain models of SNES), but I don't know for a fact that it won't...