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.

Graphics > pcx2sprite vs. usenti output format

#25627 - Code Monkey - Thu Aug 26, 2004 7:38 am

As a newbie gba coder, I've been reading devoto's PERN Project tutorials along with the TONC guide. I've managed to write a small gba app that blits a 64x64 tiled sprite onto the screen in mode0, mostly modelled from PERN tutorial code.

the sprite data is generated from a 64x64 256-color pcx image using pcx2sprite.
[Images not permitted - Click here to view it]

This works. However, when replacing this with the USENTI's generated code (tile mode 64x64 8bpp) , the sprite is garbled.
[Images not permitted - Click here to view it]
(Usenti is a very cool paint-style app written by the guy who did the TONC tutorials. I like it, so i'd rather use that than pcx2sprite)

I'm assuming the data is generated in a slightly different way, and there is some small nuance of this that i'm misunderstanding. Can anyone explain it?

Code is below, sprite data included in links above.
Code:

   OAM_Entry oam_buffer[128];
   int i;

   //set video mode.. zero out oam
   SetMode(MODE_0 | OBJ_ENABLE | OBJ_MAP_1D);

   //sets that bit in all the oam entries so that the sprites will be hidden
   initOAM(oam_buffer);

   //init oam buffer;
   oam_buffer[0].attribute[0] = COLOR_256 | SQUARE;
   oam_buffer[0].attribute[1] = SIZE_64;
   oam_buffer[0].attribute[2] = 0;
   
      //copy data from pcx2sprite into video memory
   for(i = 0; i < 64 * 64 / 2; i++)
      OAMData[0 * 16 + i] = plane1Data[i]; 
   for(i = 0; i < 256; i++)
      OBJPaletteMem[i] = plane1Palette[i];

   //update oam entry from buffer
   updateOAM(oam_buffer);

   while(1);


The TONC tutorials that use usenti-generated images use dma, and I'd rather get a grasp for things with simple for loop-style copying operations before i start relying on dma transfers.
Thanks.

#25868 - Cearn - Mon Aug 30, 2004 9:06 am

I can't open the links to the images or code, but I might know what's going on.

Code Monkey wrote:
I'm assuming the data is generated in a slightly different way, and there is some small nuance of this that i'm misunderstanding. Can anyone explain it?

Usenti exports to 32bit data (u32), while pcx2sprite exports to 16bit (u16). Since VRAM (and hence OAMData, you might want to use another name for that, btw, to avoid confusion with the real OAM data at 0x700:0000) is usually defined via a u16 pointer/array, copying Usenti's data via a simple loop will miss half the data. To avoid this, either cast VRAM to an u32 pointer, or the exported data to u16*. (or use DMA)

Code Monkey wrote:
The TONC tutorials that use usenti-generated images use dma, and I'd rather get a grasp for things with simple for loop-style copying operations before i start relying on dma transfers.

Yeah yeah, I know; I should have realised that when I started. My bad, sorry. I'm trying to get rid of a number of my idiosyncrasies in both Usenti and Tonc, but unfortunately time is something I currently lack so it might be a while before I get everything fixed.

#25946 - Code Monkey - Wed Sep 01, 2004 6:28 pm

Brilliant!

That was the exact problem. I casted the usenti data to u16* (as vram was defined as.) and magically, eveything works!

Sorry about my links, i host them on my internal webserver, the damn netgear router's been on the fritz lately, locking up and whatnot. It's ok now. They should work now (although it doesn't really matter at this point).

Thanks a lot! :)

Btw: Usenti is amazing.