skeezix
Internal Development
kingoddball said:
*sputter*
:huh:
jeff
Last edited by a moderator:
Nds Emulator Running On N900
- Thread starter kingoddball
- Start date
*sputter*
:huh:
jeff
MonkeyChops said:
If I recall correctly, it was stolen from the really early demo pods at a a trade show... Spaceworld I think? They had it broadcasting over WIFI, and some resourceful people captured the files and dumped them to laptops.
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
Comparing Scratchbox performance to N900 performance is pretty crazy. For one thing, Scratchbox has both native and emulated (using qemu) modes. I think this is almost definitely being ran in the native mode, especially if it's using SDL, because SDL doesn't even work in the emulated mode. I know all this because I had to port some things to N900 for work.
Use common sense. If a Pentium M laptop at 1.6GHz can't run desmume at playable speeds for most games then an N900, which is like 3x weaker even when overclocked pretty heavily, is going to totally suck it. There's no magic "for ARM" stuff going on here, if anything it's quite the opposite since the SSE2 routines used for geometry can't be used here.
The performance of 3D will also be even worse than you'd expect. On the one hand we have the software renderer which is very float heavy (and relies on things like division) and very bandwidth heavy (back buffer + depth bufffer + attribute stuff isn't gonna fit in L2 cache) which are exposing weaknesses of the OMAP3, unless the float stuff is using NEON which I'd be skeptical of. On the other hand we have an OpenGL renderer that uses glReadPixels on the framebuffer every frame and isn't even using buffer objects - this is very SGX unfriendly and will impose a huge performance penalty. So you're going to get bad results with either one.
Sure there are going to be some games that are like GBA games with two screens and use no 3D and very low CPU. Turn on frameskip and you might have a shot of running these okay. That's why Yoshi's Island DS is what you see demoed with the desmume ports to PSP. But if you make assumptions as to what these sorts of games will be you're going to be pretty disappointed. For instance, the Castlevania games all use 3D heavily to render their 2D, and use a decent amount of CPU.
Main thing about all this: here I've been saying that getting a VERY optimized/performance minded DS emulator working "good enough" on OMAP3 would be in the realm of doubtful, but you all are still putting your hopes in DS emulator that is accuracy minded and not well optimized.
EDIT: A read through the thread shows he's not running an ARMEL (native, emulated) build, so this is definitely compiled for x86. Let's put that one to bed then.
Use common sense. If a Pentium M laptop at 1.6GHz can't run desmume at playable speeds for most games then an N900, which is like 3x weaker even when overclocked pretty heavily, is going to totally suck it. There's no magic "for ARM" stuff going on here, if anything it's quite the opposite since the SSE2 routines used for geometry can't be used here.
The performance of 3D will also be even worse than you'd expect. On the one hand we have the software renderer which is very float heavy (and relies on things like division) and very bandwidth heavy (back buffer + depth bufffer + attribute stuff isn't gonna fit in L2 cache) which are exposing weaknesses of the OMAP3, unless the float stuff is using NEON which I'd be skeptical of. On the other hand we have an OpenGL renderer that uses glReadPixels on the framebuffer every frame and isn't even using buffer objects - this is very SGX unfriendly and will impose a huge performance penalty. So you're going to get bad results with either one.
Sure there are going to be some games that are like GBA games with two screens and use no 3D and very low CPU. Turn on frameskip and you might have a shot of running these okay. That's why Yoshi's Island DS is what you see demoed with the desmume ports to PSP. But if you make assumptions as to what these sorts of games will be you're going to be pretty disappointed. For instance, the Castlevania games all use 3D heavily to render their 2D, and use a decent amount of CPU.
Main thing about all this: here I've been saying that getting a VERY optimized/performance minded DS emulator working "good enough" on OMAP3 would be in the realm of doubtful, but you all are still putting your hopes in DS emulator that is accuracy minded and not well optimized.
EDIT: A read through the thread shows he's not running an ARMEL (native, emulated) build, so this is definitely compiled for x86. Let's put that one to bed then.
God Ginrai
Godmaster
Exophase said:
You can't blame them for dreaming.
I know I would enjoy a DS emulator on my Pandora. But I'm not going to cry if I don't get one, because I realize that a good one would be a huge undertaking, and we don't even know how fast a well optimized one would run. Still, people attempting these emulators that are at the very edge if not just beyond the edge of a machine's capabilities interest me, because the optimization they go through just to get it to work slightly faster makes for a well-optimized emulator in a more powerful system that it may later be ported to.-God Ginrai
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
God Ginrai said:
The thing is, these ports usually don't get optimized. Usually nothing is done at all, but when something is done it's a matter of hacking. Hacked to be capable of emulating less instructions per second, having various graphical features turned off or weirder things like interleaving. Things that cause new problems and compromises and are often a stab in the dark that just end up getting removed on the more powerful systems.
Thanks to Knuth's "premature optimization is the root of all evil" mantra programmers have developed a strange concept of optimization. Unfortunately they have ignored the first part of his comment regarding "small efficiencies." Optimizing an emulator is ultimately about optimizing a design, not tweaking slow code. That doesn't mean you have to do fast code first thing - god knows I don't - but you need an overarching design strategy where the eventual fast parts fit into your roadmap. And unfortunately for the crowd that believes that you can only know what parts of your program are critical by profiling, some prior insight into where the CPU time will go actually is key in designing a fast emulator. Fortunately this is more a matter of common sense than people care to admit (or at least it seems that way to me). Where parts aren't obvious you plan to do profiling setups well in advance and it becomes part of your roadmap - and for an emulator you plan on doing some really application specific profiling which includes several metrics, instead of just the usual "what are the most often executing functions" kind of profiling.
This article does a good job expressing how I feel about the matter:
http://blogs.msdn.com/b/ricom/archive/2003/12/12/43245.aspx
Last edited by a moderator:
philly
Still Fresh
Where is WizardStan??? He loves discussing DS Emulation on Pandora :lol:
Make a flippent comment about screen positioning instead of how much work it would take to emulate it!
WizardStan exploding in 5... 4... 3...
(Edit) Only kidding Mr. Wizard Sir. B)
Make a flippent comment about screen positioning instead of how much work it would take to emulate it!
WizardStan exploding in 5... 4... 3...
(Edit) Only kidding Mr. Wizard Sir. B)
Exophase
Nothing good will ever come of Exophase.
Ha, I hope Heart Gold really is only swapping buffers every other frame. Man that percentage number is confusing, unless they changed things it should mean percent CPU utilization but is Spirit Tracks really using nearly 0 there? I guess for a cinema scene that's not that hard to believe.
BTW, are you using software rendering or OGL, and if the latter what's your video setup like? I'm guessing it's soft rendering since the allegedly low-CPU but high-3D scene in Spirit Tracks is so slow. Is the Pokemon title screen shot actually running at better than realtime speed? You should turn on throttling and see if it goes down to 30.
BTW, are you using software rendering or OGL, and if the latter what's your video setup like? I'm guessing it's soft rendering since the allegedly low-CPU but high-3D scene in Spirit Tracks is so slow. Is the Pokemon title screen shot actually running at better than realtime speed? You should turn on throttling and see if it goes down to 30.
Exophase said:
I think I switched it to software rendering and got a speed increase. I have a pretty low end Radeon GPU in this old Thinkpad, so I don't really make much use of it.
Pokemon title scene was running less than full speed. The only game so far which seems to running nicely is Warioware.
Where do I set up throttling? It was set to frame-limit.
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
SomeGuy99 said:
Then I guess that 38/30 was misleading. It might mean 38 emulated vsyncs per real second (out of the 60 it should be emulating) but 30 detected swap buffers per emulated second. Are you running with that advanced audio synchronization option? That should make the sound crack when it's not fullspeed. This definitely paints a different story for Pokemon ingame too.
But if the 30 really does mean what I think it does then it's good news because that means half the geometry and soft rasterization load w/o emulator introduced frameskip.
Good news on Wario Ware too, I'll make it a point to look at it more
Last edited by a moderator:
Exophase said:SomeGuy99 said:
Then I guess that 38/30 was misleading. It might mean 38 emulated vsyncs per real second (out of the 60 it should be emulating) but 30 detected swap buffers per emulated second. Are you running with that advanced audio synchronization option? That should make the sound crack when it's not fullspeed. This definitely paints a different story for Pokemon ingame too.
But if the 30 really does mean what I think it does then it's good news because that means half the geometry and soft rasterization load w/o emulator introduced frameskip.
Good news on Wario Ware too, I'll make it a point to look at it more
Well I haven't changed the sound settings at all. In the Windows version there's no crackling, it just plays at a slow speed - in the Linux desmume there was crackling on everything, but my Linux Mint system does this with many things (Pulseaudio maybe?).
I switched to OpenGL rendering for 3D and got a few more frames out of it; the Mario 64 title screen went from 20 to 26fps. The Zelda title screen was still slow, but less choppy.
Warioware runs fullspeed, even in the Linux build (75fps?), but then it probably doesn't use any 3D graphics right? A few of the minigames use it, but I guess even then it should be okay.
Just checked the sound settings:
Last edited by a moderator:
fischju2000
Active Member
- Joined
- Oct 1, 2008
- Messages
- 763
If somebody was going to try a quick port of DeSmuME on the N900 or Pandora (or any other way to emulate NDS on the platform), 0034 Zoo Keeper would probably be the game to go for. One of the first on the DS, it was an early benchmark for the emulator (in speed and compatibility) and is usually what's shown off as 'running' (at least in the past)
But come on, doesn't that 190 euro bounty really make you want to start work on an emulator Exophase? :lol:
But come on, doesn't that 190 euro bounty really make you want to start work on an emulator Exophase? :lol:
Exophase
Nothing good will ever come of Exophase.
SomeGuy99 said:
Use the "synchronous" setting, not the one you're currently using.
Last edited by a moderator:
Drack
Member
- Joined
- Sep 29, 2008
- Messages
- 210
Exophase said:
Coffin, meet nail. This isn't gonna happen, guys. Not with this project.
The other option, writing a DS emulator optimized from scratch is such a huge commitment. I've looked up some technical details and it does not look promising. Add to that that none of the developers here have announced working on it, and DS emulation will remain a pipe dream, possibly for the entire useful life of the Pandora.
I'm sure someone will do a recompile (hell, maybe even I will) just to see how DeSmuME runs on Pandora as-is, but I bet the results are going to be so abysmal that it would only serve to demonstrate how right Exophase has been this entire time.
As for actually playing DS games, I'll stick to my two DSs
Last edited by a moderator:
God Ginrai
Godmaster
Drack said:
Either Pickle or Cpas already did a recompile. I forgot which of the two did it, tho'. Btw, I also have 2 DSes.
And, as for no one having announced making an emulator, we can always hope that someone will pull what Ari64 did with the N64 emulator and just come out of the woodworks saying "I've got this DS emu I need to test.
". (Maybe he will call himself AriDS. <.<)-God Ginrai
Last edited by a moderator:
borgqueenx
Well-Known Member
Exophase, is this what i think it is? Awesome news for pandora? Or not? Please gimme a answer
