How to run FF3 properly in DeSmuME v0.9?

first of all, 0.9.4 is the latest official build, so update yours.

Second, post your CPU specs. You likely dont have enough power.

To update, click 6000 times in the desmume window. It is an easter egg. But be sure not to move the mouse or you will have to start over.

He meant to download new version, learn to use google, it's useful for other thing and save you some time from waiting a reply, yah? ;p
and your cpu most likely won't be able to play FF3 at full speed

nanaya said:

He meant to download new version, learn to use google, it's useful for other thing and save you some time from waiting a reply, yah? ;p
and your cpu most likely won't be able to play FF3 at full speed

Click to expand...

Let me rephrase it: his CPU is ancient nowadays. My older PC is 2.4GHz, and has over 7 years. Go buy a new PC, or stay away from new consoles emulation.

shashClp said:

Let me rephrase it: his CPU is ancient nowadays. My older PC is 2.4GHz, and has over 7 years. Go buy a new PC, or stay away from new consoles emulation.

Click to expand...

Very true, wah, I though his vga was 9600GT but turned out to be a Radeon *facepalm*
Yap, the only way to play any current emu is to buy a new PC...or just play it on your NDS

Just go to the official site

shashClp said:

Let me rephrase it: his CPU is ancient nowadays. My older PC is 2.4GHz, and has over 7 years. Go buy a new PC, or stay away from new consoles emulation.

Click to expand...

Or hope that someone does a faster DS emulator.

Exophase said:

Or hope that someone does a faster DS emulator.

Click to expand...

You're invited to try, you know how to do it, but of course speaking is easier than doing

Thanks for the invitation! Undoubtedly it'd be a tremendous amount of work for anyone. I just posted this because I don't think DS emulation should be lumped together with say, PS2 emulation, even if the CPU specs are similarly demanding right now.

Exophase said:

Or hope that someone does a faster DS emulator.

Click to expand...

easier said than done. it was touched upon recently
http://forums.ngemu.com/desmume-discussion/124600-desmume-vista-7-a-2.html

Guess we'll see if NHervé has what it takes then! Recompilers are very effective for ARM because there's a lot of decode overhead, even in a full decode-bit switched interpreter (12bit switches, which I don't think DeSmuME is and that approach has its own drawbacks as well)

I dont know what a full decode-bit switched interpreter is, but desmume has a 4096 entry function table pointer in its arm core.

I don't get why some emulator authors still think function tables are better than switches for interpreters :/ For 12bit lookup that's even worse because there'll be even more function boilerplate overhead, meaning icache genocide.

i dont think the function call overhead is significant relative to the work done by each opcode function, making it only a tiny contributor to the icache genocide. At least in windows, we use fastcall for those. Especially since databus reads/writes get handled by some inline code for fast-pathed for common cases, so that the opcode handlers tend to be larger than they otherwise would be.

but maybe ill try making it a switch and see if it helps any. I havent tried that yet.

Function call/return overhead is a time thing more than a space thing (wrt. icache pain - fastcall certainly helps, but there's still some overhead if there's any frame generation, and you're relying on global variables a lot which probably aren't getting passed in reigsters.. and some of this is moot on a platform like x86 that doesn't have a lot of regs anyway but still)

I think all the edge case code for shifts probably bloats a big section of your ops too, not that there are that many nicer things you can do about it. But for so many expanded entries it's pretty brutal. I'm actually surprised you hand expanded all that, that's like 8000 lines of code. Crazy.

Personally I'd wait and see where this dynarec goes anyway, before worrying much about speeding up the interpreter. There's no way an ARM interpreter can ever be anywhere near in the same performance league as a properly done recompiler.

I wish it wasnt hand-expanded. It is full of bugs. Well, by now full is an exaggeration, but we know there are still cpu bugs and we keep finding them. Maybe thats the extra edge it needed to be usable speed though, I dunno.

There are ways you can get the same result without hand expanding nearly as much. I won't go into it too much though >_>