DesMuMe mods !!!

[shashClp]

Originally Posted by NHervé

Shash : before, DeSmuME was written in C++. Why did you rewrite it to pure C ? I always thought that C++ was faster.

I didn't, my 3D core was written in C++ (and still is on my build, with the texture cache being C++ and the math helpers being C++ also), and my build uses C++. I don't know the exact reasons to loose such a large amount of time porting it over C (maybe due to most know machines have at least a C compiler, maybe due to author preference, don't know), but it was done by the Desmume team (CyberwarriorX, Guillaume, etc), not me, and it's something I definitely don't support.

[NHervé]

Ah, okay. Do you think C++ is faster than C ?

[shashClp]

Originally Posted by NHervé

Ah, okay. Do you think C++ is faster than C ?

They should be comparable as long as you don't abuse certain stuff (mainly abstract classes and other stuff that can only be resolved during runtime). I mainly code C++ because I'm more productive with it. I've coded on C for almost a decade, but now I prefer C++.

[NHervé]

Okay.

After some debugging on Worms2, I noticed it's always reading/writing to some IRQ/timer related I/O regs (namely IME, IE, IF, TM0CNT_L, TM1CNT_H). So I think the problem COULD be related to timers/IRQs, this isn't sure at all, it needs more debugging, especially on which proc is this happening and also what values are read/written.

[NHervé]

Some news :

Before releasing Mod 4, I'll be focused on fixing Rayman DS. The game works, but instead of the "press start" screen, there's a black screen, and when I press Start, the game does strange things, like overwriting data at some memory locations. For the black screen, I noticed that the game sends data to the 3D core and all of these data seem valid, except the vertex coordinates that are always zero (don't know why, it needs more debugging).

Anyway, I've fixed one of the big bugs of Mario Party : the players were "not fully visible", even almost invisible. After doing some logging, I noticed that the game was changing material colors for each vertex. I thought that it wasn't allowed in OpenGL. While searching a way to do this, I found the official description page for glMaterial. I read there that OpenGL allows, just like the DS, to call glMaterial between glBegin and glEnd in order to set a material color per vertex.
The bug was that the 3D core was stopping and resuming vertex list at each glMaterial call. Try drawing some geometry with OpenGL, and calling glEnd and glBegin between each vertex. OpenGL won't draw anything. Here the problem was the same. So I modified the 3D core to don't stop vertex list at each glMaterial call, and then the characters in Mario Party now look correct.
There're still some bugs in this game : some lighting bugs, and the star being badly placed and giant !
Here're two shots of Mario Party, I let you guess which one is the fixed one. :P

[NHervé]

I found an interesting thing with Rayman DS : this game uses DMAs in Repeat mode, and DeSmuME doesn't seem to support this feature. I'll try to implement it, maybe it's the cause of the vertices with zero-coords, data overwriting and a lot of other strange memory operations.

[shashClp]

Originally Posted by NHervé

I found an interesting thing with Rayman DS : this game uses DMAs in Repeat mode, and DeSmuME doesn't seem to support this feature. I'll try to implement it, maybe it's the cause of the vertices with zero-coords, data overwriting and a lot of other strange memory operations.

Afaik, it's supported. Source code reference (line 2838-2839):

if(!(MMU.DMACrt[proc][num]&(1<<25)))
        MMU.DMAStartTime[proc][num] = 0;

[NHervé]

Did you check it with a homebrew or any other sort of test ?
It seems that the DMAs are stopped when word count has been reached, no matter if they're in repeat mode. The code you're showing only sets start mode to 0 (start immediately) if DMA isn't in repeat mode.

[shashClp]

That's because DMA on mode zero, start only when the control word is written. Repeat mode is only meant for DMAs on VBlank/timers/etc, which is why it is reset to immediate mode: this way, it won't repeat. Thus my code shows that repeat is correctly emulated, afaik. You're free to prove me wrong, though, but I don't recommend you re-implementing things that already work based only on assumptions.

[NHervé]

Okay, I believe you, I tried changing some things, but it didn't solve anything, so I reverted my changes.

[NHervé]

Hi ! What do you think if 3D renderer was having its own thread ?
This could work, since it only requires synch with VBlank when swapping rendering buffers. (this synch is missing and this causes 3D screens to be reversed when there're 3D graphics on both screens).
I think this would give some speed-up, even if minor (at least on dual-cores), but I would like to do this mainly for accuracy purposes (correct gfx fifo (render queue) and irq emulation, synch on VBlank, would fix "Mario&Sonic at the Olympic Games").

[Normmatt]

NHervé,

Why don't you join the official desmume team? wouldn't it be better than releasing a seperate mod?

[dreampeppers99]

Yes, Normatt saids all!!!

[NHervé]

I'm wondering if I'll do this.

[Normmatt]

If you do be sure you join the official irc channel on freenode #desmume