Tuesday, September 12, 2006

Slowdown of the day

Next version of desmume will have more accurate emulation, even if some new stuff will still be kind of hacked (for example, the 3D core uses openGL, even if I think a software renderer would be more accurate). The main problem with accurate emulation (or, to make it short, more stuff being emulated) is that it requires more processing power.

Today's post is about one of the features I added, that'll make the emulator slower in certain situations. To make it simple, I just added fading. The DS hardware, can fade in/out the backgrounds / sprites, and after these backgrounds and sprites are correctly layered, there's a master brightness (more fading in out) that affects the final mix. The problem with that, is that involves a multiplication and an addition per pixel. And, to make things worse, you've 3 components in a pixel (red, green, blue), and every pixel is a single 16bit value, so some bit shifting and masking is also needed. I'll probably get it faster in the future (simd instructions come to mind to make it way faster), but for now, it'll only make rendering slower.

Some screenshots, as usual, one at the beggining of the fade-in, and one at the end of the fade:



It's way better on runtime, fades don't make good screenshots. More stuff coming in the next days, if I get enough motivation to explain more stuff.

10 comments:

RockmanRotties said...

Amaze! You are doing a good job. I am very proud of you. You never cease to amaze me, you keep me from going crazy, LOL! No, I am kidding. Keep up the good work.;)

umnop said...

I don't care about speed, what I want is "pre-test" my homebrew stuff if it runs on the ds without "bombs" or "guru meditations" ;) so keep up the good work...

Low Lines said...

No$GBA has fade emulation, though I am pretty sure it slows down speed too so you're doing just as well probably ;)

Federelli said...

Amazing :D. Still why do you consider using OpenGL for the renderer as a hack?
Software can be more accurate but slow as hell :P.
OpeGL/Direct3D/Directdraw is the way to go :P

Danos said...

very nice man
great work
you are great!!!!
congratulation!!!
from Peru and South America, we don't speak english very well, but we follow your progress everyday......
thanks man

shash said...

Federelli: due to some strange features of the rasterizer of the DS not that easy supportable by openGL, but that would be easy to do on software rendering.

I know that software rasterizing will be slower, but it could be an option (in the far future).

Danos said...

yes
it will be good to use Software rendering, but openGL is good
how about Directx?
it's good
but for perfomance, software is better

shash said...

From DirectX, I'm just used to dsound and ddraw. So I'll stick to openGL for now, and maybe in the future GDI/ddraw if I want to make a software rasterizer :)

Danos said...

thanks man
you are great
fantastic work

RockmanRotties said...

(red, green, blue), you say ?

Here I am:

The VRAM Viewer allows to view the various BG layers, Tiles, Objects, and other video memory.