Vanfanel
Posts: 433
Joined: Sat Aug 18, 2012 5:58 pm

Re: SDL 1.2 with dispmanx backend

Thu Jan 09, 2014 4:45 pm

Hi Whelsy

Yes, I know what the problem is. It requires a somewhat long explanation, so here we go:
SDL 1.x API (and SDL 1.x programs) assumes that changing the physical video mode is a good idea. That was the case back in the day, with CRT monitors that didn't have a "fixed" physical resolution. while it's a somewhat extravagant idea today in the digital video interfaces era where our monitors have just ONE native phisical resolution and that's it.

So, for example, let's say you have a program that outputs it's video information at 320x240, but your Raspberry Pi is connected through it's HDMI interface to a monitor physically running at 1320x768 or some other crazy hi-res numbers. By default, you would see your 320x240 program in a tiny screen are inside you huge monitor, wich is no nice.
To fix this, you have two obvious options:
-Change the monitor physical resolution. Not always a good idea, and not always easy. On the Pi, for example, you can change the framebuffer size but you can't really set a video mode. Even if you do, you'd be depending on the monitor's capability to scale it with better or worse results. It's somewhat confusing, I know. To hell with that solution.
-Keep the physical native resolution your Pi has chosen to boot in, and scale the images that 320x240 program produces. You can use the CPU for this (that's what SDL 1.x programs do UNLESS you use OpenGL, not GLES, specific code), but then the PI wouldn't be able to run any emulator at all, because your CPU would be savagely used by the scaling code.
OR you can use Raspberry Pi's nice (but never properly documented) native 2D API, wich can scale anything for free! For free! No CPU involved! Isn't it awesome? Your 320x240 game/emu/program becomes full-HD just with the right code.

OK; So we KNOW we don't want to change the physical resolution. But that stupid 320x240 program from the SDL 1.x days will try to do so! Most of those programs do the following:
1) They ask the SDL API for the current resolution using that nasty GetVideoInfo() function.
(Why should a program ask for the physical video mode? It's trying to change physical resolution or, EVEN WORSE; it's trying to activate it's internal software scaling functions.. Bad, bad program!)

2) They try to change the physical video mode if the one in use doesn't fit their needs OR they activate these evil software-scaling functions that will make bad things with your precious Rpi CPU cycles.

So an ancient SDL 1.x program must be domesticated, educated: when he asks for a video surface to draw into, he will get it, but if that program's original, minimal resolution is 320x240, that's what he will get. NOTHING MORE. No asking for physical video mode allowed. Nothing.
And then, that 320x240 surface will be scaled to the crazy hi-res mode your monitor uses, like 1320x768 or 1920x1080 or any other stupidly high numbers. It will be scaled in such a way that the program will "think" it's running in a native 320x240 video mode, because that's what he will get with my modified SDL 1.x when he asks for a video surface to draw into.

So that's why GetVideoInfo() won't work.
I simply remove that call from the SDL 1.x programs I build and tell them to use their minimal resolution.

As for Mednafen, don't waste time with it outside RetroArch: with RetroArch, you will get perfect frame rate, GLES2 scaled graphics and no input delay at all.
Mednafen on SDL will run at a crazy frame rate (59.whatever) wich doesn't mach your monitor's refresh rate and you will get micro-stutters once every few seconds, something RetroArch takes care about by dynamically resampling audio and making the core run at your monitor's refresh rate.
Or.. is there any other special reason to use non-RetroArch Mednafen?

NOTE: You will note I break the SDL 1.x API. Yes, I know. It's already broken by today's standards, that's why SDL 2.x exists :D

welshy
Posts: 1667
Joined: Mon Oct 29, 2012 2:07 pm

Re: SDL 1.2 with dispmanx backend

Thu Jan 09, 2014 4:58 pm

Vanfanel wrote:Or.. is there any other special reason to use non-RetroArch Mednafen?
Well, I noticed the new rev keeps A/R correct so was just doing some 'quick' testing (I have previously run Mednafen with the Dispmanx but didn't much like the incorrect A/R). The problem with RetroArch is SGX and CD Rom games are far to slow at my overclock so would rather have slightly incorrect refresh than not being able to run them acceptably, currently I run them in Mednafen with the screen Res changed to PCEngine native which isn't ideal! Looks like I will have to recompile Mednafen then, just wondered if there was a 'simple' fix and I was missing something obvious! Thanks for the reply
Last edited by welshy on Thu Jan 09, 2014 5:01 pm, edited 1 time in total.
"The list of things I have heard now contains everything!"

Vanfanel
Posts: 433
Joined: Sat Aug 18, 2012 5:58 pm

Re: SDL 1.2 with dispmanx backend

Thu Jan 09, 2014 5:00 pm

Well, I don't see any simple fix really.
As for the SDL dispmanx backen aspect ratio, it's now respected by default.
Are you saying the SGX and PCE-CD games are faster (well, less cpu-heavy) with SDL using the dispmanx backend than using the Mednafen PCE core in RetroArch? Are you sure of that?

welshy
Posts: 1667
Joined: Mon Oct 29, 2012 2:07 pm

Re: SDL 1.2 with dispmanx backend

Thu Jan 09, 2014 5:13 pm

Vanfanel
As for the SDL dispmanx backen aspect ratio, it's now respected by default.
Sorry, that's what I meant, when using the back end with Mednafen before the A/R was incorrect

Are you saying the SGX and PCE-CD games are faster (well, less cpu-heavy) with SDL using the dispmanx backend than using the Mednafen PCE core in RetroArch? Are you sure of that?
Not quite, its a few FPS slower framerate for SGX and CD Tiles at X1 scale (320x232) in Mednafen but frameskip can be evoked (they are too slow to be 'acceptable' played via RetroArch) but the dispmanx could be added to run in Console at full res (so no messing about changing resolutions, or awful XWindows!), I don't recall what they were WITH the back end. I just noticed while doing some testing with the new version of Raspbian the scrolling 'tearing' (which was previously terrible!) is vastly improved (although still slightly noticeable) so was just going to do a quick experimentation with the new A/R correct back end. It just seemed odd my Binary worked ok with the old version.

Edit - OR you can use Raspberry Pi's nice (but never properly documented) native 2D API, wich can scale anything for free! For free! No CPU involved! Isn't it awesome? Your 320x240 game/emu/program becomes full-HD just with the right code.
Mmm, that's interesting...
"The list of things I have heard now contains everything!"

welshy
Posts: 1667
Joined: Mon Oct 29, 2012 2:07 pm

Re: SDL 1.2 with dispmanx backend

Thu Jan 09, 2014 7:31 pm

Vanfanel
Sorted! I just pulled a previous version* from the Git, built it, and all is well!

*SDL12-kms-dispmanx-ef612f203eb6bf13d58621d7504c0684c0e7677c.zip

In answer to your question, no, it isn't faster than RetroArch (I would be surprised if it was), without frameskip SGX Titles are approximately 7 FPS down on RetroArch (38-45), but at least they are now playable at full res (1920x1200) without resorting to XWindows (Mednafen doesn't work in Console) and reducing the res. CD Titles are the same at 48 FPS (but again applying frameskip makes them infinitely more playable). Nice one!
"The list of things I have heard now contains everything!"

itsmedoofer
Posts: 359
Joined: Wed Sep 25, 2013 8:43 am

Re: SDL 1.2 with dispmanx backend

Tue Oct 28, 2014 11:10 am

Hi,

Forgive me if this is a stupid question, and I suppose for reviving a necrothread, however....

Should I just be able to compile this, install and then compile my own programs against it to gain the acceleration ?

I have just tried it with Chocolate-Doom 2.1 but the config program exits almost immediately without even opening a window, defaulting back to standard SDL and it works.....

Is there any “Patching” required ?

Again sorry for a noobie question.......

Return to “Gaming”