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