Thanks!Stef wrote:Wow, that is really impressive
Yes. The SNES can change the screen base register after the frame has been drawn, which allows the Super FX to start work on the next frame before the current one has been fully transferred. This can actually happen before the first available VBlank, as the Super FX's stop instruction issues an interrupt to the SNES by default (you can mask it if you want). The SNES can also temporarily suspend the Super FX's access to Game Pak RAM by changing a flag, which puts the Super FX in a wait state the next time it needs RAM access; this allows the SNES to proceed with the transfer during VBlank without having to forcibly kill the Super FX program.Something i wonder, do you have any kind of double buffering with the SFX memory ?
I'm hoping to be able to keep lag to a minimum when doing 4bpp by drawing one half of the playfield first (possibly the bottom half, because it's likely to be faster) and copying it to VRAM before the other half is finished. Hopefully this won't result in glaring priority issues near the seam... actually, now that I think of it, I could use the anti-wrapping method in FXtest1 to prevent that...
For the convenience of the reader: viewtopic.php?f=12&t=13834&start=45#p164693psycopathicteen wrote:I did a demo like this a while ago and I got 256 bullets at 30fps, though I had to make the bullets really small like 5x5.
Impressive work. (Also gave me an idea for transferring 2bpp graphics into a sprite table - rendering into the source format is going to be interesting, but the transfer itself works beautifully...)