Dingoonity.org

Hi, I have been working on porting RetroArch to the gcw0.  Basically I simply wrote a Makefile using the sdl drivers and built several of the libretro cores using gcw0's toolchain.

Today, I started testing each core with one or two roms to see how they run.  The cores were tested with the smooth filter disabled, no scaling and no threaded video. Here are some results:

- fceumm: tested mega man 2, runs fullspeed as expected.
- Nestopia: tested mega man 2, runs fullspeed most of the time with minor hickups.
- gambatte: tested metroid 2, runs fullspeed.
- vbam: tested the hively player demo, runs slow. The gpsp core will run better but it hasn't been released.
- nxengine: runs slow (fullspeed with threaded video option)
- snes9x-next: tested megaman x and chrono trigger, runs slow, very slow actually.  Using threaded video helps a lot but it was still far from fullspeed.
- fba: Tested street fighter iii - new generation, runs slow. Marvel super heroes runs better, but still slow.
- mame078: tested snow bros, runs fullspeed .  I guess it will depend on the game here.
- mednafen_pce: tested salamander, runs fullspeed.
- mednafen_wswan: tested final fantasy i, runs very slow. Super robot wars runs fullspeed.
- mednafen_npc: tested king of fighters, runs fullspeed.
- picodrive: tested contra hard corps, runs fullspeed.
- gensplusx: tested contra hard corps, runs slow most of the time.

Ok, first sorry for not putting more accurate results (fps, exact options, etc) but I didn't have much time to test the roms. Retroarch logs an Average monitor Hz value at the exit, maybe I should post that value.  For instance, sfiii got a 20 Hz value and Mega Man 2 got 60 Hz.

Threaded video option helps a lot, for instance nxengine core runs fullspeed with that option enabled. But it doesn't help some cores that much, like fba and snes9x-next.  Actually, I was expecting better performance in snes9x-next but I guess it's a bit heavy for the zero, since it's based on snes9x 1.51 and uses the accurate apu. And I have to point that retroarch doesn't use frameskip and will never do.  The good thing about it is that, when a core runs fullspeed, it runs beautifully.

I did not changed anything from the sources, simply wrote the necessary makefiles to build retroarch and the cores, so there might be room for improvements.  Using the GL driver might help and we could really get some performance boost in all cores if the cpu could be overclocked.

Anyway, I'm not releasing anything, since I haven't properly contacted the retroarch project members, and because I don't really feel happy with the results. My main interest was having accurate and fast snes emulation on the console.
But if any serious dev would like to properly work on the port, please pm me.

I think its great, hope it gets released!

Is it allowed to make libretrocores specific to platforms?
Just because the "standard" cores arent fast enough doesnt mean that it isnt great that you can implement the api and not have to worry about alot of things.

Is it allowed to make libretrocores specific to platforms?
Just because the "standard" cores arent fast enough doesnt mean that it isnt great that you can implement the api and not have to worry about alot of things.

Of course, anyone is free to write a new core.  As long as you follow the GPL license in which libretro is based, in other words, you have to release the full sources of your changes.  For instance ToadKing wrote an unofficial pocketsnes based core for the Raspberry Pi.  The libretro devs don't really like all the 'ugly' snes9x forks based on old and hacked code though.

And what is most important for the libretro devs, do not make any kind of profit using libretro code.

I had built the retroarch with PicoDrive and snes9x-next cores for the Dingoo A320 and GCW-Zero some weeks ago. As expected, the Dingoo ran very slow. The GCW version I could not test because I have not received my device yet...

Anyways, good to know somebody else is doing some tests  :)
Good to know that .  Have you received your device yet?  Are you planning to make any optimizations for the gcw0? I tryied to use the mips optimized code in the picodrive core, but I got a relocation error when building the shared library.

I had built the retroarch with PicoDrive and snes9x-next cores for the Dingoo A320 and GCW-Zero some weeks ago. As expected, the Dingoo ran very slow. The GCW version I could not test because I have not received my device yet...

Anyways, good to know somebody else is doing some tests 

I got a question. Why porting Picodrive and SNES from retroarch when we still have these emulators ?
And you say, "the dingo ran very slow". Why using these cores, which are running SLOWER than originals one
If these core are slower on dingoo they will be slow on GCW Zero too...

I got a question. Why porting Picodrive and SNES from retroarch when we still have these emulators ?
And you say, "the dingo ran very slow". Why using these cores, which are running SLOWER than originals one
If these core are slower on dingoo they will be slow on GCW Zero too...

For picodrive, it'd be one way to get the latest version of the core emulator instead of the older release found in the standalone version currently available. notaz has been improving 32x emulation recently. If it can be optimized enough that Genesis Plus GX, SNES9x Next and VBA Next can run fullspeed, you'd get more accurate emulation with less glitches, better sound, ect. Even if those cores are too slow after everything that can be done to speed them up on the Zero, I think it'd still be worth it for Picodrive, Nestopia, Gambatte, and Mednafen (PCE, Wswan and NPC) all in one app. Hopefully with a good enough interface with customizable buttons and aspect ratio per core 

Right, but is someone going to update the standalone GCW port?

Hello the_gama.
Could you compare the general performance using Genesis Plus GX as a libretro core vs the standalone build?


Thank you.

No problem, ok tested several roms from Sega Genesis, and the standalone build runs quite better than the retroarch core.

In the standalone build most games ran, what seemed to me, fullspeed or almost fullspeed.  The games tested were: Castlevania Bloodlines, Panorama Cotton (this one may not run fullspeed), Contra Hard Corps.  And I tested Virtua Racing which run very poorly in both.

What I can tell, is that retroarch has better sound, maybe because of the sinc resampler.  What is the audio output rate in genplusgx.dge?

And one more question, does the genplusgx.dge build is using any kind of frameskip? Maybe auto frameskip? We need to know that to ensure it is a fair comparison.

Thank you the_gama.
It's using 48000 as sound frequency and 2048 samples size with no frameskip that I can know. SVP is running really bad 

About the OpenGL ES, I don't know if it will help the Genesis Plus GX core, maybe other cores that support it.

Thank you the_gama.
It's using 48000 as sound frequency and 2048 samples size with no frameskip that I can know. SVP is running really bad 

About the OpenGL ES, I don't know if it will help the Genesis Plus GX core, maybe other cores that support it.

Genesis Plus GX requires at least a Wii-caliber CPU for SVP (Virtua Racing) to run at fullspeed (Genesis Plus GX has no recompilers - only interpreters).

The 1GHz MIPS CPU of the GCW Zero is unlikely to be as fast in real-world performance terms as the Wii CPU - not to mention that blitting is probably much slower. By comparison, the 1GHz Pandora (ARM Cortex A8) does not run Virtua Racing with Genesis Plus GX at fullspeed either (Picodrive does though), and the 1GHz MIPS CPU inside the GCW Zero is probably slower per-clock than that.

Normally I'd say it would be better to use Picodrive, but the problem is that it doesn't have any MIPS recompilers - so you would still fall back on interpreter in Picodrive. Even still, it should be at least somewhat faster than Genesis Plus GX at the same game even with the interpreter.

For Mupen64 Plus - yes, you will need at least OpenGL ES 2 support - it might take some time for those homespun GLES drivers for the GCW Zero to mature I guess - so I dunno how well you can expect it to run. There are also no MIPS->MIPS recompilers so there is also that - you would have to fall back to interpreter for now - pretty sure it will be way too slow on GCW Zero.

I am open to pull requests for a MIPS->MIPS recompiler in case you feel like writing one, and the same goes for any other patches you come up with.

Regarding the RetroArch port - SDL driver is the absolute worst driver you can go for. I would say either use the OpenGL driver (best case scenario, but requires that your GL drivers are decent - even commercial vendors can get it wrong most of the time) or write your own low-level graphics driver.

The sound driver (and configuration)  is crucial to get right - you need to get the audio latency option set exactly right to avoid sound crackling and not getting audio right will result in a bad experience since it blocks on audio - thus audio is the bottleneck in case the driver is bad or it is not configured right. I don't know what sound driver you are using right now - I assume ALSA?

Quote from: Squarepusher2 on September 16, 2013, 09:20:36 am

... and the 1GHz MIPS CPU inside the GCW Zero is probably slower per-clock than that.

It does surprisingly well; while ARM may lead to a better performance with hand-written ASM, MIPS is more compiler-friendly.

Quote from: Squarepusher2 on September 16, 2013, 09:20:36 am

Normally I'd say it would be better to use Picodrive, but the problem is that it doesn't have any MIPS recompilers - so you would still fall back on interpreter in Picodrive. Even still, it should be at least somewhat faster than Genesis Plus GX at the same game even with the interpreter.

I never heard of a recompiler for Picodrive. I don't know what Genesis Plus GX uses, but FAME/C is proved to be extremely fast on MIPS.

Picodrive has SVP and SH2 recompilers for ARM done by notaz. Without them, Virtua Racing and 32X would be going a lot slower on ARM.

Genesis Plus GX does not use FAME/C for the 68K interpreter core but Musashi. Picodrive does use FAME/C for the interpreter 68K core - for ARM an optimized version of Cyclone is used instead though.