I was being sarcastic, but a dynarec might help SNES emulation, however that would require alot of work/time from a developer. Keep in mind they do this for free and out of their own personal time.damned said:no just wondering how much it would help like getting emulation picodrive quality
thanks for explainingExophase said:Three things.
First, SNES isn't CPU heavy, its power is more in the rendering and audio. If the 2D rendering engine and the audio DSP are heavily optimized (especially the former) you'll probably see much bigger wins. The CPU is all in all pretty slow.
Second, SNES's CPU is a CISC design. It's the type that lends itself well to a highly efficient interpreter, and doesn't lend itself well to being translated to RISC code. So you don't get the kind of performance improvement you do when recompiling a RISC CPU like the one in GBA or PS1. On the other hand, there are some word size flags that could make things rather expensive for an interpreter. If these things don't change frequently then you recompile as if they were fixed.
Third, the SNES games that people complain most about when it comes to emulation are the ones that use special chips. Doing a dynarec for those, especially SuperFX, would make a huge difference (maybe from the realm of unplayable to fullspeed, if everything else is done better too).. but it'd probably be difficult to motivate people into writing a dynarec for a CPU used in just a few games.
And this isn't worthy of being on the list, but since you mentioned Picodrive.. Genesis emulation has always fared better than SNES and always will. It's a simpler and slower console. Even the CPU, clocked over twice as high, isn't really faster (if at all) because m68k has such bad cycle timings. But then again, 65c816 does too, so I hear. Really old consoles just have super slow CPUs, that's why people didn't bother with dynarec until PS1 emulators came around.
I am too lazy to look at it myself, so I hope someone can tell me if the GP2x SNES emulators use asm in the video renderer. If not, it seems like a good point to start optimising them.Squidge said:If your remove the graphic rendering functions from snes9x, every game I've tried runs at full 60 fps with sound enabled. If you remove the frame limiter, a lot of games get > 100fps.
ZSNES was originally 100% Intel X86 Assembler. Since it has been ported to Linux, it is now about 75%. SNES9X has always been in 100% C, so it's the most ported emulator.
Ehhh? What about "render8 orr.S"? Tile renderers written in ARM ASM, aren't they?Squidge said:Nope, there's no asm in any of the snes emulators, and asm implementation would be quite a task.
Optimising parts of the renderer at the expense of graphic quality seems to just get people complaining ("Why create a snes emulator that looks like nes" for example).
If you created your own from the ground up with speed in mind, people would complain about compatibility (and probably the above too).
So, developers lose interest & motivation.
It's easier to just wait for processor speeds to increase in future GP2X's
Godmil said:Cool answers, Very informative.
On a side note I was listening to Retronauts today and they were talking a lot about Secret of Mana. I was wondering if 2 (or 3) player joypad support could ever be implemented?
I'm a fan of Retronauts too, but even with joypad support, you couldn't read the text, because of the Mana games' hi-res text display.
These are the remains of OS9XGP for GP32 (AFAIK ssnes was started from OS9XGP code). GP32 has it's video memory laid out differently (it's rotated), so those renderers are not suitable for GP2X and the code is unused. I've used that code for my UIQ2 port of snes9x, and it's not that much faster anyway.Exophase said:Ehhh? What about "render8 orr.S"? Tile renderers written in ARM ASM, aren't they?