Next Generation Emulation banner
1 - 12 of 12 Posts

JKKDARK

· Banned
Joined
·
6,678 Posts
Discussion starter · #1 · (Edited)
News from Shash blog

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
New improvements in the Nintendo DS emulator. Just check these pictures, this emulator will be great :D

Image
Image
Image
 
I'm so glad this emulator is open source now, it seems to have a nice future. :D

And I was betting on iDeaS some months ago to be the 1st very nicely working emulator but I started to doubt it once v0.3.4 and especially v0.4.0 and now I know which one will be. :lol:
 
"to shash: If You can do it better, why dont make your own emulator, and dont *Fudge* in this place, I Can say that You can't understand a code like this, First you have to make a Hello World in NDS CPU, in other words, you can't say the problem in a destructive form, first see how U can help, make a constructive request."

That made me :rotflmao:

It's like telling Michael Schumacher how to drive a formula 1 car or sth.
 
About the GoodNDS guy, I just can't stand people making false claims or (in the first two versions) violating the GPL license.

Anyway, I'm glad you like the improvements done to desmume. I'll keep updating the blog whenever I've time :p
hey shash nice to see you here :) totally agree, that guy is the kind of scum i hate in the emu world, its no better than the cassini team who just take someone elses emu, alter the gui using a reshacker then call it their own.

You on the other hand seem to be working very hard on it and im looking forward to your next release :) I thought of looking at Desmume source at some point, might wait till you make a release so i know im not trying to fix something thats already been done :p ill have to read up on the NDS a bit tho, not use to working with ARM or nintendo hardware as i work on PCSX2 so :p

all the best
 
1 - 12 of 12 Posts