Language…
4 users online: Alex No, CONLUSH666, Rykon-V73,  Tahixham - Guests: 262 - Bots: 370
Users: 64,795 (2,377 active)
Latest user: mathew

instant NMI

a friend found the next subroutine on a japanese sprite.

Link

but this routine doesn't work,

i am doing this:

Code
JSL INSTANT_NMI
JSR DMA_Routine
NOP


who knows how to do an instant nmi routine for do dinamic sprites without patchs?

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
That routine looks like it might handle nmi (besides the fact that it ends with RTL instead of RTI, though I'm pretty sure rtl will work fine, just won't clear the interrupt flag), but it doesn't CAUSE NMI, because thats impossible. Admittedly I can't tell exactly what that routine is doing, but it's not that. NMI happens at fixed intervals, it can't be forced. You can force blank, but that routine doesn't touch $2100, and that would be stupid to put in a sprite anyway.

If the sprite that came from immediately uploads graphics data, then it is a poorly made sprite that doesn't conform to reality, it would only work in old versions of zsnes.

Dynamic sprites really work by storing the size and address of the graphics you want to upload to somewhere in ram, and then hijacking NMI to look at those addresses and upload the graphics during the next vblank, not really a better way around this.
i normally use a hijack nmi but when i do an dinamic sprite i can only put 1 dinamic sprite on the screen because the next sprite overwrite the same graphics and if i want put more than 1 dinamic sprite i need to do another version of the sprite that write graphics in another position. For that i am searching another form to do NMI and makes this more flexible.

how can i do a flexible routine that allows me to puts more than 1 dinamic sprites on the screen?

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
You need to come up with a format that allows you to tell NMI to upload multiple places at once. Imagine you reserve 0x100 bytes, all of which you clear to 0 at game boot. Now, we can use that RAM to store the instructions to upload. Something like:

Flag byte: 0 or 1, depending on whether there are instructions for uploads here.

DMA source address: long address to your graphics you want to decompress.

VRAM destination address: Word VRAM address to decompress to.

Number of bytes: Word holding how many bytes to upload into VRAM.

So if you wanted to upload 0x80 bytes from $118280 to VRAM address $2000, that area of RAM might look like this:
Code
___F_____Source________Dest______Bytes__
|    |              |         |         |
 0x01 0x80 0x82 0x11 0x00 0x20 0x00 0x80


Then for each time you want to upload graphics, you add it to that table.

If you want, you can replace the flag byte with a byte somewhere outside of the table that keeps track of the number of records it has to upload. This will save space and make finding slots faster, so it's usually the way I go.

Also: The dynamic sprites patch we have here allows 4 dynamic sprites, so I'm not sure what you are doing...
safest you can transfer in smw is x800 bytes (which is what the dynamic sprites patch does, aka half a GFX file).

for ram, anything large should work, like the $7F9C7B area
dma is done sequentially, not at once (if 2 dmas are enabled via $420B, channel 0's will run first, then channel 1's, etc). a x800 byte dma is the same as two x400 byte ones, different channel or not.

so no