devkitPro

yea I read your move from DS to android on your blog. I've always enjoyed reading your post and trying to anwser your questions (or reading the anwsers from somebody else, if I didn't knew it). I wish you good luck with your development for android and java, and hopefully you'll like java better ...

Sorry to make a lame post like this here, but since there's not really an off-topic space, it was the best place. I wanted to give a very big thank you to everyone on this forum for sticking with all of my questions over the last year or two. From transitioning away from PALib to my recent foray ...

No need to really head down that road... I do tend to share those feelings...

*Not intending on starting anything... just adding a comment* You should absolutely go to setup questions regarding PALib to it's own forum. Wintermute directing there is the right way to go. Yes, there was an issue for a very long time where PALib users were being told to use older version of the ...

VRAM_A_MAIN_BG_0x06000000 and VRAM_B_MAIN_BG_0x06020000 I'm not going to say this quite right, but I'll try. All of VRAM actually starts at address 0x06800000. When you're using those enumerations above, you're setting up the VRAM Control Registers and defining a particular usage for them. When the ...

Are you planning on using bmp sprites? They're pretty uncommon due to the extra space they take up. 256 color paletted sprites are pretty well tested and shouldn't give you any issue. I'm not sure looking at the oamSet() code... but you could specify the index value yourself like this after oamSet ...

Looks like a bug in oamSet(). Adding this output: consoleClear(); iprintf("%d %d %d\n", (int)sprites[0].gfx, (int)sprites[1].gfx, (int)sprites[2].gfx); iprintf("%d %d %d", oamSub.oamMemory[0].gfxIndex, oamSub.oamMemory[1].gfxIndex, oamSub.oamMemory[2].gfxIndex); The gfx pointers are all 512 bytes ...

The bg really shouldn't have anything to do with sprites... totally separate subject :) 1 through 3... sorry... no wifi nor eeprom experience here... 4. NitroFS appends data to the nds file. It's basically accessed the same as FAT (same i/o functions) but the data is written to the rom when you ...

Well, you could surely do some kind of 16 bit tiled system... it would just take more manual coding of the system. Ex-Rot backgrounds from that spec page (gbatek): Of which, the "Extended" modes are sub-selected by BGxCNT bits: BGxCNT.Bit7 BGxCNT.Bit2 Extended Affine Mode Selection 0 CharBaseLsb rot ...

dmaCopy's second parameter is a void pointer... but bgGetGfxPtr() returns a pointer to an unsigned short (u16*). I would gather that pointer arithmetic used on the return value would make it move 32*sizeof(u16), so 64 bytes. There is no native 16 bit tiled format, I'm afraid. 16 bit Extended ...