SpritesMind.Net

Hi,

At the very first frame of my game, I fill out the visible tiles of the A plane. (when the screen scrolls around, I just fill out the edges that become visible) Currently this plane fill function, which I've only done a first pass on, is noticeably slow. I'm calling VDP_setTileMap for every tile and you can see the screen filling up. So my function is an obvious candidate for optimization. So what's a faster way of doing this?

My first thought was to use VDP_setTileMapRect but it assumes that the source data is no bigger than the plane. My demo level is 256 x 64 which is larger than the 64 x 64 A plane I've configured. And future levels will be bigger than that. I can always make a new version of the function to work for my case but I'm not sure if that's the fastest available method.

Would it be faster to do DMA transfers of the visible rows from the game's level background data to the plane? Are there any other techniques available?

Thanks,
DJCC

You supposed to turn the screen off while putting all needed data (graphics, initial nametable data) into the VRAM. When the screen is turned off, there is no need to fit into the vblank time, so you can fill up the VRAM much faster.

Also, DMA transfers will be significantly faster than writing the data to the VDP data port. For the best performance, use a DMA transfer while the VDP is in vblank, or the display is disabled.

DMA is your friend, and auto increment is your other friend. I could update all needed in my pattern table update by just doing 2x VRAM transfers combined with right auto increment value.

Shiru wrote:You supposed to turn the screen off while putting all needed data (graphics, initial nametable data) into the VRAM. When the screen is turned off, there is no need to fit into the vblank time, so you can fill up the VRAM much faster.

Ah, I didn't know you could turn off the screen! I'll try that tonight.

When turning off the screen, does it keep the last visible image? Or does it just go black or whatever the default background color is?

TmEE co.(TM) wrote:DMA is your friend, and auto increment is your other friend. I could update all needed in my pattern table update by just doing 2x VRAM transfers combined with right auto increment value.

Does the DMA transfer use the auto increment in any way on its own?

DJCC

Auto increment increases the VDP address pointer on any VRAM access, be it CRAM, VRAM, VSRAM, done by 68K or DMA. It only increments though, no decrement.

TmEE co.(TM) wrote:Auto increment increases the VDP address pointer on any VRAM access, be it CRAM, VRAM, VSRAM, done by 68K or DMA. It only increments though, no decrement.

Okay! I'll try that out, thanks!

I haven't had the chance to try this yet, but I was wondering about using DMA and auto-increment together.

Does auto-increment increment only after the completion of the DMA transfer or for every byte/word DMA does?


So, for a DMA transfer of 4 bytes to index 0 and an auto increment of 2 bytes, will it be:

DMA writes be to 0, 2, 4, 6 with auto increment pointer at 8?

or

DMA writes to 0,1,2,3 with auto increment pointer at 5?

It increments the address pointer by value in the register on every word/byte it transfers

TmEE co.(TM) wrote:It increments the address pointer by value in the register on every word/byte it transfers

Does it apply the auto increment to the source location as well as the destination?

If I DMA 4 bytes from address 0 to address 8, will reads be from source address be 0,1,2,3 or 0,2,4,6? (destination addresses, from your answer, will be 8,10,12,14)

Only destination is affected

TmEE co.(TM) wrote:Only destination is affected

ok, thanks!