DGEN-SDL-v1.32 - A "Beginners Guide" to Compiling and Using


39 posts   Page 1 of 2   1, 2
by welshy » Tue Feb 12, 2013 8:14 pm
As previously stated, I have never been a “Fan” of the Megadrive*. I already owned an NEC PC Engine when the news of SEGA’s imminent new console began circulating. As an “Early Adopter”, always eager for new hardware, I contacted my Importer at the time and pre-ordered one. On arrival the resulting console was a crashing disappointment, after 3 months I traded it in for a CD attachment to go with my PC Engine! It would go on to fail miserably in its native Japan, crushed by the now market leading PC Engine (Which preceded it into retail by a year and is, in actuality, more powerful!) and Nintendo’s incumbent Famicom (NES). However, in the West, due to aggressive and quite brilliant marketing “Sega does what Nintendon't”, it was a colossal success and has a fond place in many a “Retro Gamers” heart

*Genesis in the USA due to copyright issues

Source Code - dgen-sdl-1.32.tar.gz*
Dependencies - sdl1.2-dev
Additional Files Required - Game ROMS#

*Download Here - http://sourceforge.net/projects/dgen/fi ... z/download

# NB DOES NOT play compressed Files (i.e. .zip) if yours are, uncompress them in appropriate folder (See 6)

1. Can be compiled from Console or a Terminal within “X”
2. If using an RPi of the 256MEG variety RPi, make sure you have the RAM split set up attributing ALL the RAM to the ARM (Use the config (sudo raspi-config))
3. Install libsdl1.2-dev dependencies (apt-get install libsdl1.2-dev)
4. CD into the directory where you uncompressed the source code and Type -
./configure --disable-opengl
The “Default” configuration uses Open GL rendering, which DOES NOT work on the RPi! Without this addition it will run, but you will have to add a Boolean expression to turn off Open GL rendering EVERY TIME its run!!!
make
sudo make install (Optional, but useful in this case as running straight from Terminal (Not in X) gives a significant performance increase and negates the need for “CDing” into the folder when you want to use it!)
5. Exit Terminal
6. Make an appropriately named folder (I called mine dgenroms) and put any ROMS you have in it
(NB DECOMPRESSED! See Above!)

To Run dgen from a Terminal (Or Console) Type -
dgen “folder name”/”game name”.”extension” (NB MUST have the File extension! .bin, .gen etc)

e.g. dgen dgenroms/sonic.bin

CONTROLS
GAME PAD:
Directional Control - Cursor Keys
Button “A” - A
Button “B” - S
Button “C” - D
Start - Enter

Exit - Esc

F5
Toggles “TV Modes”: blur, scanline, interlace, swab, off

F6
Toggles “Scale” Modes: hqx, scale2x, default (NONE)

For a FULL description of the Controls and Options see Here - http://dgen.sourceforge.net/
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by kalehrl » Tue Feb 12, 2013 9:26 pm
hi welshy
Have you tested it with analogue video output?
I get sound but the picture remains black.
This happens both with retropi and my dgen binary cross-compiled using --disable-opengl.
Please read here for additional information:
https://github.com/petrockblog/RetroPie-Setup/issues/82
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by welshy » Tue Feb 12, 2013 10:06 pm
kalehrl
I have just, at your request, tested with Analogue Video Output. Running straight from Console, same result, Blank Screen. However, it works fine under “X” and the performance is such that usage of DGEN is entirely acceptable in this manner, even at a “Vanilla” 700MHz Clock
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by kalehrl » Wed Feb 13, 2013 9:15 am
Indeed it works in graphical environment but I tried playing Jim and got 21fps with 900MHz overclock. :(
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by welshy » Wed Feb 13, 2013 11:05 am
kalehrl
(Sorry to repeat myself in the first part of my Reply from a previous Thread (AdvMAME 0.94), but it may be of interest to other users)

With regards to “Speed” I have posted before if you are new to Emulation, try not to get obsessed with “Performance” (i.e. actual FPS), many of the original consoles DIDNT run at a constant 60 FPS (Against the CRT Refresh Rate 60 Hz), it’s just with modern Emulators there is in built diagnostics to see what is happening. E.g. with the Atari VCS it depends on the “Kernel” (Which writes the graphics to the screen) some are single, Combat 25/PAL 30/NTSC FPS, some are 2 Part, Pitfall 50/60 FPS! For further proof check SNES Super R-Type (Actual FPS vary wildly!) or StarFox/Wing (Which averages 25 FPS on a 60Hz Refresh), although some hackers have improved this to 35 FPS by overclocking the SuperFX chip in the Cart! Rather, does it look/play like the original? With AdvMAME I cross check performance against MAME 0.103 running on a Quad Core 3GHz CPU with a GeForce 9600 GT Grafix Card, 4GB of RAM and a dedicated Sound Card, visually/sonically there is little difference in perceived performance (Which in itself is quite amazing!). Even on this set up, Donkey Kong for instance, ISNT running at a constant 100%, but running side by side with AdvMAME on the RPi (Average 66%) it’s undetectable!

On DGEN (Or any of my other “Guides” for that matter when using Composite Output), I suggest reducing the size of the RPi screen output (Using sudo nano /boot/config.txt) and the screen size rendering in DGEN to suit, which can be achieved by adding -G XxY Desired window size (e.g. 640x480, 800x600, etc.) to the Command Line Instruction -

i.e. dgen dgenroms/sonic.bin -G 320x224 (You only have to do this ONCE, it is saves to the dgenrc.auto config file)

This action DOUBLES the rendering performance (When using HDMI)

I do this with Mednafen as to use X1 (PC Engine) X2 (NES) scaling but reduce the available window as increasing more than this drastically reduces performance! Remember the Genesis/Megadrive console output was only 320x448 (NTSC) 320x480 (PAL) MAXIMUM, most titles ran at 320x224 (To free up more time for processing during Vertical Blank) so in essence you are losing nothing by setting your RPi to these resolutions (Most Emulators increase the resolution to fit bigger screens but in actuality there is no detail gain, if running at X2 it just renders four dots as opposed to one with the performance hit that the processing entails)

AND/OR reduce the fidelity of the sound, (dgenrc.auto File, it’s located in the Hidden Folder .dgen) this COULD have a serious impact as Analogue Sound is the major overhead -

Change: int_soundrate = 22050, To: int_soundrate = 11025

Admittedly, I only tested with Composite Video NOT Audio, using the Analogue Output for Sound (As opposed to HDMI) seriously impacts the performance of the RPi (There is little you can do about this). HDMI to Composite Converters are available, but EXPENSIVE, (For a similar monetary investment you could purchase a small LCD TV)

Hope That Helps!
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by Vanfanel » Wed Feb 13, 2013 11:16 am
With regards to “Speed” I have posted before if you are new to Emulation, try not to get obsessed with “Performance” (i.e. actual FPS), many of the original consoles DIDNT run at a constant 60 FPS (Against the CRT Refresh Rate 60 Hz), it’s just with modern Emulators there is in built diagnostics to see what is happening. E.g. with the Atari VCS it depends on the “Kernel” (Which writes the graphics to the screen) some are single, Combat 25/PAL 30/NTSC FPS, some are 2 Part, Pitfall 50/60 FPS! For further proof check SNES Super R-Type (Actual FPS vary wildly!) or StarFox/Wing (Which averages 25 FPS on a 60Hz Refresh), although some hackers have improved this to 35 FPS by overclocking the SuperFX chip in the Cart! Rather, does it look/play like the original? With AdvMAME I cross check performance against MAME 0.103 running on a Quad Core 3GHz CPU with a GeForce 9600 GT Grafix Card, 4GB of RAM and a dedicated Sound Card, visually/sonically there is little difference in perceived performance (Which in itself is quite amazing!). Even on this set up, Donkey Kong for instance, ISNT running at a constant 100%, but running side by side with AdvMAME on the RPi (Average 66%) it’s undetectable!


This is absolute nonsense. Consoles RAN at 50 or 60 FPS. Some games however didn't refresh screen in every vblank so, if they missed an vblank, they could use the next to refresh screen.
By not running at 60 fps, you're lowering the chances the games have to refresh screen, hence you're losing FPS and visual information, even if the games didn't run at 1screen-per-vblank. Your examples have no sense.

In vintage gaming, fps are essential: playability used to be precisse in terms of timing, so losing fps in an undetermined amount IS a problem and HAS consequences.

I'm always learning myself, and I often need and offer technical help, but please, I humbly ask you not to talk about things you don't understand well.
Emulation can be a good, sweet thing if done properly, but running a MD/Genesis game with halved framerate (or even worse, non-constant framerate) is awful, period. It's now how it should look and it's now how it should play. Don't go confusing people, please.
Posts: 370
Joined: Sat Aug 18, 2012 5:58 pm
by welshy » Wed Feb 13, 2013 12:38 pm
Vanfanel
Fair Point! Reading it again, it is badly composed/explained and doesn’t really convey what I was trying to articulate. The main point I was attempting to make is that, for the most part, even if an emulator isn’t “Perfect” Refresh/Framerate wise, does it really make a difference for most people? I’m testing/comparing these Emulators against the Original Hardware (In most cases). Other than the poor scrolling (Inherent in SDL as opposed to Open GLES) they play/look relatively faithfully to the Original Hardware (In my opinion) and rather than get into a technical argument about their “Accuracy” isn’t that all that matters?

If you delete your Post, I’m quite happy to remove the part that is causing you umbrage....
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by Vanfanel » Wed Feb 13, 2013 4:15 pm
Other than the poor scrolling (Inherent in SDL as opposed to Open GLES)


Ah, whelsy, I appreciate your enthusiasm, really, but I must make it clear again: there's no souch thing as "poor scrolling inherent in SDL". Wrong. It's NOT true and we MUST NOT accept this fact. It's our labor to observe and correct it.
SDL uses different backends: among different hardware, you can use different backends.

-There are some backends wich have problems in some hardware, while they run flawlessly on other. For example, the "default" backend used in the Raspberry Pi is the FBDEV backend. This backend runs great on X86 machines if the underlying framebuffer has certain features: for example, if you configure your kernel for using the UVESAFB framebuffer, compatible across most graphics controllers on X86, you'll get perfect scroll in games, great video mode setting capabitilies (provided you have a good /etc/fb.modes database), etc. It's also great for Matrox cards :D
However, on the Pi, this backend is a complete disaster. It can't be worse. It barely does anything but displaying images. No hardware scaling, tearing all the way... it makes me.. violent.
This is the problem. on the Pi: you're using a poor deffective piece of code to interface SDL and the graphics hardware.
I partially corrected it with my Dispmanx backend. With it, you will see perfect scroll in games and emulators (if the emulator is able to provide a new frame each 1/60 seconds in a 60hz display), and scaling to fullscreen is done using hardware overlays.
I'm however missing the most important part: blitting is still done in the slowest possible way, using a generic C implementation: this is what prevents the Pi from taking off for SDL-based games and emulators. On X86 this is done using MMX instructions: think of it as a kind of hardware acceleration method.

-There are also backends wich have problems in every possible hardware configuration: X11 (Xorg) comes to mind. You will ALWAYS have tearing with this backend as the X11 protocol lacks the functions to implement a proper double-buffered display that swaps buffers during vsync. It's one of the worst ways to run SDL apps if you aim for smoot scroll. Xorg is a stinky pile of shite anyway.

So, as you can see, there's no souch thing as inherent jerky scrolling with SDL. It's a complex problem with a complex solution. But it can be done. It has partially been corrected already, and accepting the facts is not the way to change things for better.
Posts: 370
Joined: Sat Aug 18, 2012 5:58 pm
by welshy » Wed Feb 13, 2013 6:15 pm
Vanfanel
Thanks for the Reply, a much more eloquent/exacting explanation than I managed! But as you can appreciate, it also gets frustrating when offering/sharing work and receiving replies such as “It Won’t Do “X” or “That’s Rubbish” (Without offering anything in return as an alternative) can also be frustrating! As you say “It's a complex problem with a complex solution” which I attempted (Badly!) to encompass in an unadorned “Simile”. I will endeavour to be more measured in my posting in the Future!
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by badman12345 » Thu Feb 14, 2013 3:08 am
Just want to add a few things to help everyone out:

1) dgen is fully capable of opening compressed images, provided you have libarchive-dev installed before configuring. It should automatically enable it if you have libarchive-dev installed, if not, you can force it with ./configure --with-libarchive

2) Vanfanel's SDL12 w/ dispmanx backend is EXCELLENT for dgen from the framebuffer. It won't work within X, but fullscreen performance from the framebuffer is excellent, especially when overclocked.

3) The newest git version of dgen (and I think the newest release 1.32 version) includes ASM optimized emulators for the m68k and z80... make sure you enable them =). You must edit the dgenrc file and set the following
emu_z80_startup = drz80
emu_m68k_startup = cyclone
The defaults are cz80 and musa, and they are not optimized for the arm platform.
Posts: 33
Joined: Thu Feb 14, 2013 3:00 am
by kalehrl » Thu Feb 14, 2013 9:53 am
2) Vanfanel's SDL12 w/ dispmanx backend is EXCELLENT for dgen from the framebuffer. It won't work within X, but fullscreen performance from the framebuffer is excellent, especially when overclocked.

I've only got average 20fps with dgen playing Jim.
How do you disable scaling in dgen?
I already have:
Code: Select all
emu_z80_startup = drz80
emu_m68k_startup = cyclone

in dgenrc.auto which means they are used by default.
I run it with '-f' (fullscreen switch).
Tried without it but it's the same.
Also tried disabling opengl but it's already compiled without it.
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by X-death » Thu Feb 14, 2013 10:06 am
Did it works with composite Outpout ?
Posts: 10
Joined: Thu Dec 20, 2012 5:32 pm
by kalehrl » Thu Feb 14, 2013 10:14 am
Yes it does.
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by welshy » Thu Feb 14, 2013 1:06 pm
Badman12345
Excellent! Thanks for the info! It did seem odd that the Home Page says it can use compressed files, but on completion of. /configure it noted - Compressed Roms: No!? Armed (No pun intended!) with this information I can confirm if libarchive-dev is installed it will Default to: Compressed Roms: Yes, no need to Force it. I wrongly assumed as Mednafen is installed it was already added (Mednafen must have an inbuilt Decompression Tool?)

If compiling dgen-sdl-1.32 (As described above), as kalehrm indicated, Default Settings for the different Processor Emulation Cores Are - z80: drz80 and m68k: cyclone. However, the can be scrolled through Thusly -

F10 - z80
F11 - m68k

But you will have to alter the Configuration File (rc) to change them permanently (Probably not advisable as the Default ones are the best for ARM)

On further Testing it seems to handle any ROM I have thrown at it (Including .smd Files) with the exception of Virtua Racing, not surprising, the Original Cart included an additional Processor dubbed the “Sega Virtua Processor” (A Samsung SSP1601 DSP with Sega branding), the only Emulator I am aware of that can (Correctly) is Kega Fusion

Just One Last Thing, you can also squeeze a bit more performance out of the Emulator (As always seems to be the case) by using Image 2012-09-18-wheezy-raspbian

kalehrm
Did you try my suggestions of altering the resolution settings on your RPi/Emulator Output. Using HDMI or Composite it almost DOUBLES the FPS, (Against Default Settings) when run in “X”. Or the config rc for soundrate to 11025KHz? (I haven't tested this myself), which could help as Analogue Sound is a Major Overhead
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by badman12345 » Thu Feb 14, 2013 2:00 pm
kalehrl wrote:I've only got average 20fps with dgen playing Jim.
How do you disable scaling in dgen?

Are you using the custom SDL w/ dispmanx backend, from the framebuffer rather than X?

You mentioned before running it in X... this indicates to me that you are using a stock SDL (the SDL w/dispmanx backend won't run at all in X....). The performance I was referring to earlier refers specifically to running with the SDL w/ dispmanx backend, directly from the console... I never even enter a desktop in my scenario.

Are you overclocked?

At stock clocks, it's still a bit slugish, but if you set overclocking to "Medium" (900mhz on-demand... only boosts to 900 if it's called for, otherwise it idles at 700) in raspi-config, you should get silky smooth(-ish) playback with the custom SDL version. I have only tested wish Sonic so far, but it runs great... no tearing, very smooth. I don't have my fps counter on, but I'll check it when I get home. I don't think you need to force fullscreen with dispmanx... dispmanx scales it up to fullscreen for you.

I already have:
Code: Select all
emu_z80_startup = drz80
emu_m68k_startup = cyclone

in dgenrc.auto which means they are used by default.

Noted... odd, for me it defaulted to cz80 and musa... oh well

I run it with '-f' (fullscreen switch).
Tried without it but it's the same.

I don't think you want to use the fullscreen switch if you are using the dispmanx SDL version.

Also tried disabling opengl but it's already compiled without it.

Yeah it won't make a difference if it's compiled without it. (As a matter of fact, for me, at least... it doesn't work at all with opengl enabled when using the dispmanx SDL...)

TL;DR
If you're not overclocked, try overclocking to ~900... that cleared up all performance issues for me when used with the dispmanx backend for SDL. I am using it at 1280x720 over HDMI, and dispmanx handles all scaling and upsizing.

If you're using the stock SDL, give the dispmanx backend version a try... worked great for me, but remember, doesn't work at all in X.
Posts: 33
Joined: Thu Feb 14, 2013 3:00 am
by kalehrl » Thu Feb 14, 2013 2:25 pm
Are you using the custom SDL w/ dispmanx backend, from the framebuffer rather than X?

Yes, I'm using dispmanx backend and I'm sure it's used because when I exit the game, it prints something regarding dispmanx and the resolution.
You mentioned before running it in X

I very rarely start X so yes, I tested it in the console, not X.
I mentioned X because welshy said it worked for him in X and not in console and my experiences are the same.
Before I installed dispmanx, dgen would give me just sound with blank picture.
Once I installed dispmanx, I got the picture.
Are you overclocked?

Yes, Medium preset - 900MHz.
I don't think you want to use the fullscreen switch if you are using the dispmanx SDL version.

If I don't I get left and right parts of screen cut off and the fps isn't any better.
Aspect ratio of the game should be 16:9 so with '-f' I get black bars on top and bottom.
Without '-f', The entire screen is filled with picture but parts of it are cut off.
My TV is 4:3 CRT.
Could you attach your dgenrc.auto and dgenrc files?
What dgen version are you using.
I'm using 1.32, the l;latest one.
Thank you.
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by badman12345 » Thu Feb 14, 2013 2:55 pm
I'm actually recompiling dgen right now as we speak, because I'm having joystick issues, so I can't attach my dgenrc files just yet... but honestly I don't think your issue is with dgen. As I said, at (1280x720), I start it without the -f switch, and dispmanx scales it up perfectly to fit my screen without lopping any off. Also, I could be wrong, but I think that by forcing the -f switch, you are negating any performance help that dispmanx would provide you... I think that by forcing -f, you are allowing dgen to scale for you... If you don't force -f, dispmanx will scale for you.

Have you tried any other games? It could just be that the game you are playing is more demanding than some others. As I said, I've only tried Sonic with it, and it works flawlessly... I haven't had a chance to try too much else.

Anyway, once my dgen recompiles, I will come back and attach my dgenrc for you... but I don't think you'll see much difference there.

You might want to post support requests over at the dgen sourceforge page, or the SDL w/ dispmanx github page. I have personally contacted the author of the SDL w/ dispmanx, and he promptly and politely helped me out with my issues.

Also, check this out from the github page
No physical video mode adjustments are done: the aplication resolution is hardware-scaled to fullscreen native resolution via KMS or DISPMANX overlays, so SCANLING SETTINGS IN THE APLICATIONS SHOULD BE DISABLED to save CPU. This means that a 320x240 aplication will automatucally be scaled to 1920x1080 using the overlays. If the aplication has the ability to run in a higher resolution (most 320x240 apps will have this kind of options) you must avoid using that. The application HAS to be run at 320x240 and it will be scaled by the backend.

So yeah, I don't think you want to use the -f switch... I think your issue is possibly poor resolution settings for your entire system. Have you ever tinkered with your config.txt? Have you properly adjusted your overscan settings in there? Have you properly adjusted the resolution settings in there?

Also, 320x240 is already a 4:3 aspect ratio resolution... it shouldn't be rescaling to 16:9... dispmanx should detect you are using a 4:3 ratio, and scale 320x240 up to your native 4:3 resolution, whatever that may be... Try forcing 320x240 in your dgenrc, and then starting without the -f switch...

I think you have a system wide setting misconfigured somewhere....

As far as the version of dgen I'm using, I'm currently using the most recent git clone revision.
Posts: 33
Joined: Thu Feb 14, 2013 3:00 am
by kalehrl » Thu Feb 14, 2013 3:33 pm
Thanks badman12345 for your extensive help.
I've got it!
I should have read changelog earlier!
* Double-buffering can now be disabled, useful on slow machines
(bool_doublebuffer).
* Added an optional separate thread (bool_screen_thread) for displaying
frames. Only useful on slower machines where flipping video buffers takes
time, especially when V-sync is enabled and doing so blocks DGen/SDL until
the next frame without consuming CPU time (such as the case of Dispmanx on
the Raspberry Pi when bool_doublebuffer is also enabled).

Once I set:
Code: Select all
bool_doublebuffer = false
bool_screen_thread = true

(bool_screen_thread = true should be enough without bool_screen_thread)
I have more than doubled my fps - from 21 to 46 :D
It wasn't the '-f' switch which was causing the trouble but this option.
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by badman12345 » Thu Feb 14, 2013 3:50 pm
Great news! Glad you got it worked out.

Don't feel bad... I also did not read the changelog, or I would have figured out the problem with my joysticks :-)... they changed the joystick configuration syntax and I never updated my rc files lol!
Posts: 33
Joined: Thu Feb 14, 2013 3:00 am
by kalehrl » Thu Feb 14, 2013 4:30 pm
So, any speed differences between your previous dgen and the latest one?
Do you use any other games emulators?
I use snes via retroarch and I'm not sure if it's using the dispmanx.
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by badman12345 » Thu Feb 14, 2013 9:37 pm
kalehrl wrote:So, any speed differences between your previous dgen and the latest one?
Do you use any other games emulators?
I use snes via retroarch and I'm not sure if it's using the dispmanx.


I'm not familiar with retroarch, do you know which snes emulator they use? If it's not an SDL based emulator, then it's not using the dispmanx backend.

I have been tinkering with a standalone snes emulator: snes9x-sdl, and I have successfully compiled it against the dispmanx backend, but I haven't had a lot of time to test it yet with optimized settings. It ran pretty crappy straight out of the chute with default settings, so I need to tinker a bit. Also, it took 4 hours (yes, 4 hours!) to compile lol... compilation chewed up so much memory that you need to use a swapfile to get it to fully compile, and once you start using swap on an SD card.... it REALLY slows the process down , even on a class 10, lol...

All of that comes from compiling the hqx filters.... which is pointless since you're probably not gonna use them on the pi anyway... Luckily, dgen makes it easy to disable compiling them (./configure --disable-hqx), but snes9x-sdl does not have such an easy option....
Posts: 33
Joined: Thu Feb 14, 2013 3:00 am
by kalehrl » Thu Feb 14, 2013 10:20 pm
They use pocketsnes-libretro so I don't think it's using sdl unfortunately.
Super Nintendo was my favourite games console and it's a shame there's no proper emulator for it on raspi.
pocketsnes-libretro gives crappy sound and the picture is pixelated a lot.
Posts: 350
Joined: Tue Jul 24, 2012 10:49 am
by welshy » Fri Feb 15, 2013 9:05 am
palerider has posted a version of snes9x-1.39-rpi which uses oss sound but it probably the best solution (Thus Far) for SNES Emulation Here - viewtopic.php?f=78&t=23272

eix is working on a version of snes9x to run with native OpenGL, upscaled through DispmanX. It’s currently a pre-alpha version but is looking very promising Here - viewtopic.php?f=78&t=29242

Toad King and Petrockblog have kindly provided the information of the current Cores used by Retro Pie/Retroarch, which I have posted along with specifics on chameleon remix (The idea being, armed with that knowledge, users could “Tinker” with the Original Emulator for their own purposes) which can be Found Here - viewtopic.php?f=78&t=31966n
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm
by badman12345 » Fri Feb 15, 2013 7:28 pm
Great info, thanks Welshy! I'm trying to avoid using the snes9x-sdl 1.39 if I can... trying my damnedest to make 1.53 work as well as possible first.
Posts: 33
Joined: Thu Feb 14, 2013 3:00 am
by welshy » Fri Feb 15, 2013 8:15 pm
badman12345
I did “Tinker” with 1.53 and post a “Guide” a while back, but haven’t been back to it lately as eix’s solution should eventually give much better results (Looks very promising so far). As for the “Vanilla” 1.53 version, I wouldn’t say its “Perfect” (Far from it). It runs “Fullspeed”, although, you have to make “liberal” use of frameskip to attain this performance (I cheekily used a “Mr Benn” analogy to explain this (If you are not in the UK that many be lost on you!)) but it will play ALL games (Even SuperFX Titles) and run “Fullscreen” in Console without the need to change any config settings on the RPi. As for compiling, I originally only had a 256MEG RPi (It ran out of memory), adding --enable-debug to configure prevents this (Although the completed Binary is larger) and it will compile a lot faster than 4 Hours! As always, using Image 2012-09-18-wheezy-raspbian squeezes better performance from it, perhaps the DISPMANX backend can improve it further? (It wasn’t released at the time of posting). Here’s the link if you’re interested - viewtopic.php?f=78&t=24318
"The list of things I have heard now contains everything!"
Posts: 1609
Joined: Mon Oct 29, 2012 2:07 pm