gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > Data corrupts

#7764 - shoaib - Tue Jun 24, 2003 9:55 am

I have written a custom library for Background management and sprite management. I have used OOP , basically just classes no polymorphism or inheritence.
Somehow whenever the image data for the sprite exceeds a certain limit 12Kbytes to be exact (this data is loaded in the ROM area, only one frame of the sprite lies in VRAM), this corrupts the tile data or sometimes the other sprite data, reducing the data seems to correct the problem and the library works perfectly for smaller amounts of data
If someone has encountered similar problems and solved them please let me know[/list]

#7771 - Sweex - Tue Jun 24, 2003 1:15 pm

Since recuding the amount of data fixes the problem, I would say that it takes too much time to load all data into VRAM before the drawing starts. Therefore, you will get some sprites drawn with the old data, and some with the new (or maybe even combined). You should make sure all the copying is after the scanline is at 160 and before it retraces to 0 again (So basically during retrace)

#7782 - johnny_north - Tue Jun 24, 2003 4:42 pm

12kb for a single sprite cell? The largest sprite is 64x64 pixels. At 256 colors, this is only 4096 bytes. Half that if you're using 4bit color.

#7802 - Cyberman - Wed Jun 25, 2003 1:44 am

Sounds as though you have 3 frames for a 64x64 pixel sprite. You should use DMA to load the sprite data into the tile memory. If your sprite data is compressed then you should unpack it into WRAM and then DMA it to sprite memory.

I think on many games that use lots of large sprites they use this strategy as well as swap sprite information about a lot. This increases the affective bandwidth as well as You might consider not updating the sprite information every vertical synce for animation. That's a considerable bandwidth payload. Perhaps every other sync would be better.

These are just a few ideas.

Cyb