Sprite table to VRAM with or without DMA?

[Manveru]

Hi guys!

I am reading some info about sending the sprite table without DMA because DMA can cause some glitches for this operation. Is that right? Do you know the reason for that?

Thanks!

[TmEE co.(TM)]

You can get problems when you update sprite table during active frame regardless of using CPU or DMA to do the transfer.

[BigEvilCorporation]

I've recently gone down the DMA route and it's working just fine for me.

Previously I was setting individual sprite properties (X, Y, flip flags) by reading bytes from the VDP, setting values and writing them back, but this slowed my game down to a crawl.

Now I keep a local copy of the entire sprite table in RAM, and DMA it across in the vertical interrupt routine. Works a treat!

[Manveru]

Now I keep a local copy of the entire sprite table in RAM, and DMA it across in the vertical interrupt routine. Works a treat!

I usually do that, but in some wikis say that DMA works fine but the cache should not be completely update, causing some problems with the drawn sprites. I have some random sprite disappearing (not because a known reason) and the problem should be DMA writing. I see that SGDK did not use DMA also for that stuff, so i think it should be a good reason.

[TmEE co.(TM)]

The cache not updating happens when your DMA (or CPU transfer) reaches active frame. When your update happens and finishes in the blanking/border there will not be problems.

[Stef]

Next SGDK version will use DMA for sprites update. Definitely use it if you can, it's a lot faster than updating sprites independently and from 68K.

[Manveru]

Ok i understand. Thanks guys!!!