Well, for the sake of time saving I started with a program called DesMuMe Running Nintendogs (Love the game)... (i found it to be the most stable of any PC Emu)
It's also the only with source available so your only option. But it's pretty slow.
It still isn't very clear to me how you're testing your Pandora build. Is it in qemu? Are your performance numbers for this or running the PC version?
Then i ported it to .Pnd... From there i just descided to try and work down the power required by the system... I also found that by matching the Refreshrate with the screen rate -1 it gave me an enormous performance boost... (why im not sure..)
What does that mean? Setting the screen refresh rate to 60Hz? Non-60Hz can cause a lot of slow down if you have wait for vsync enabled.
Then i changed the audio encoder (Takes about 400mhz just for audio) And changed it down to only 8bit-22150Hz sound quality.. which brought the usage down to only about 170Mhz from 400Mhz...
It's hard to tell what kind of performance improvements you're talking about when you speak in terms of MHz because this is relative: if you go from needing 200MHz to 190MHz this isn't the same as going from 20MHz to 10MHz. You should talk about absolute time, how many ms a rendered frame takes before and after changes. And of course, what you're actually running this on.
I still need to optimize the video to only use open Gl instead of running it throught the cpu.. (A Overclock for the 3D acceleration soon)..
You can't overclock the 3D on Pandora.
You're going to find a lot of problems with porting the OpenGL code. It needs OpenGL 2 to work best (is still much less compatible than the software renderer though), but it still uses immediate mode primitives not available in OpenGL ES 2. So you have to convert it to triangle lists. But there will be a lot of overhead due to state changes that can happen cheaply in DS display lists, like changing texture and format.
Furthermore, there are some features the renderer needs that are plain not available in OpenGL ES 2 on Pandora, like loading and storing the depth buffer. So expect even more compatibility problems.
What's really going to get you performance-wise is that the renderer needs to grab the 3D framebuffer so it can combine it with the rest of the video subsystem. This is slow, even with texture streaming extensions, and desmume doesn't do anything to try to schedule this so it can happen asynchronously with anything.
Which then should get me within a 10% Performance margin of being just right..
If by 10% you mean the emulator running at 1/10th the speed it's supposed to. Since you say "just right" I think you mean more 90% realtime speed, and all I can say is: keep dreaming.
