Monday, September 25, 2006

Texture compression and register hacking

Well, today I'll talk a bit about how the ds texture compression works and what I've accomplished with it (not that much, really). It's actually quite simply, if I understood it correctly (not sure I did). Well, a compressed texture is theorically, quite simple. We use one texture slot (even if not fully) for actual texture data, being it texture slot 0 or slot 2 (there're 4 possible slots in the DS).

For every 4x4 pixels block, we'll use one 32bit number from slot0 or slot2, that'll define the actual pixel data, 8bit a row per 4 columns, makes the total 32bit. So we define every pixel with a 2bit number, that'll use after for palette indexing. Now we need some more data, a 16bit value: the palette offset and a mode how this will be used, that'll will be located in texture slot1.

So, the general idea is quite simple in the end. Read a 32bit value from either slot0 or slot2, read a 16bit value from slot1. Then, use the 16bit value to determine the mode (there 4 possible modes, each filling each row in different manners) and palette index. With this palette index, go through each of the 2bit values, contained in the 32bit, and add each of them (separately, of course, for each colour) to the palette index, to get the final palette index to be used for each pixel. Then, with this value, you can just index in the normal palette data to get the colour. Depending on the mode, colours will be (or not) treated in different manners. Seems it's not that simple :P

My implementation is far from complete, I've severe bugs that just show lots of garbage. I'll try to fix it tomorrow.

I also have been doing some severe register hacking, that is just, that some memory locations are mapped to specific hardware of the DS. So, for example, writing to 4000490h will push a new 10b vertex to the render queue. So, I've just hacked a few of the registers so make games/demos work better, even if it's not correct emulation.

Just a simple screenshot today:




Seems today's posts was a bit complex, anyway, have fun :)

16 comments:

Low Lines said...

So are you saying that you are trying to make the garbled stuff display properly??
Nyeh well having a pic at the end I think helps a bit in understanding all this practical/technical lingo :p lol

Federelli said...

Umm which texture is being compressed in the demo? The submarine sprite?
Nice post and update :D

shash said...

Federelli: almost all the textures of the submarine demo are compressed

Danos said...

great work
we give pur support to Normmatt
You are great
Take your time to a release

we will wait
we know your work
take care

lukeskyd said...

Ot Desmume why don't support 64 mb cart??

shash said...

lukeskyd: Do you mean the save card, or the games bigger than 64mb ?

lukeskyd said...

Yeah games bigger than 64 mb
why desmume don't support them?? All other emu (dualis, ideas, no$gba, etc) yes..

shash said...

They are supported, they load correctly :P

If some game bigger than 64mb isn't running correctly, it's not due to it's size.

umnop said...

don't be so harsh to shash, releasing applications isn't as easy as you think(I'm an author of an open-source tool by myself)! If you release stuff you normaly should make smoketests of the stuff to prevent releasing broken stuff. and if something doesn't work guys like you are disappointed, too.

and some words about goodnds: the changes from the guy aren't that big! perhaps he's learning to code (I really don't know), but his changes are the work of half an day for an experienced coder. perhaps less...

shash, perhaps it would help to checkin the sources to sourceforge so other guys can help you writing the 3d-emulation (I've some experience in writing a wrapper to convert openGL-code to directx). and other guys can make releases from your stuff so you have not to do that... I would contribute changes to make the emulator compilable in vc6.

shash said...

umnop: I'll commit when I'm ready. Oh, and it already compiles on visualc, I use it as my main dev tool :)

Oh, thanks to the sucker that posted comments before, I'll moderate comments from now on.

umnop said...

that's ok , too. I can wait :)

vc+visual assist rocks :) do you use the c-core of the arm-emulator or the assembler-version? btw, there's a source-release of the jit-compiler for arm-emulation from microsoft, if you have some spare time... ;)

Luke said...

Pls shash don't lie :-O
64mb games aren't supported if i load one desmume says it's not a rom.. :-(
Pls add support to 64 mb games
Thanks

Cheers

shash said...

luke: I'm not lying, one of the roms that I've tested a lot is way bigger than 64mb (128mb, in fact). Could you be more specific which one is the one not loading, because I didn't have any problems loading 64 or 128 mb roms.

Federelli said...

Luke you must have something that is not even a ROM, get your facts straight.

Luke said...

Ok the rom is CVDS.NDS (castlevania dawn of Sorrow) of 67.108.864 64 MB when Desmume load that rom it says [this is a file nds] and i think that it's not a rom instead Ideas and others load this rom but run but not emulated well or screen black.. strange?!!

shash said...

luke: you seem to have a bad rom, I tested "Castlevania: Dawn of Sorrow" a while ago, and it loaded and worked (to a certain degree)