Pandora improved SDL for pandora


What, no nes emualator? Surely this can't be right. Well, how do people play Super Mario Bros.? I use advanceMESS at home, it runs many nes games very well. Might see if I can compile for Pandora tonight :)

I use mednafen that I built a while back for nes emulation. It doesn't have a nice interface like gpfce, but it does work quite well IMO and has lots of features like movie recording, cheat support, and netplay. Search repo.openpandora.org for the latest version.
 
Streak ported Nestopia, which does 100% accurate emulation if im not mistaken, so it needs minor overclock at times. only gripe is...he has yet to make use of pandora controls, as A/B buttons are on O/P on pandora keyboard...good emu though
 
nope its too much or a farce, gpFCE is nice it just needs that little extra polish that gpSP and PCSX ReARMed got.
 
I may have found a regression when using this library with mplayer unless I'm doing something wrong. Here is the summary of what I tried. I built the latest version of this using the openembedded recipe on git.openpandora.org and copied the library into a directory on my SD card. I set LD_LIBRARY_PATH Then ran: mplayer -vo sdl:driver=omapdss -fs movie.avi I get mostly a black picture with an occasional flicker of an image.
Fixed and pushed out.

I may have found a regression when using this From what I recall, it seemed as though the scaling was ugly because it was not using the default filter which is slightly blurred.
That's because mplayer's SDL code is always setting 640x480 (or similar) and forces mplayer core to scale to that using software. I'd say mplayer's sdl output is not a good choice for playing videos, although I don't have anything better to suggest..
 
Last edited by a moderator:
f-keys work here on SDL's test, how is openMSX reading those keys?
After a quick crawling in the multiple CPP files, if think this is because it activates SDL_EnableUNICODE(1);


This is the only key difference i see easily, compared to usual SDL_Keyboard handling stuff.
 
After a quick crawling in the multiple CPP files, if think this is because it activates SDL_EnableUNICODE(1);
Shouldn't be a problem, test does that too, does it read .key.scancode or .key.unicode from event or something?
 
Last edited by a moderator:
Shouldn't be a problem, test does that too, does it read .key.scancode or .key.unicode from event or something?
In fact OpenMSX is reading all : keysym.sym, keysym.mod,keysym.scancode and keysym.unicode.


After a comparison, with HF6 SDL, i get :


F10 : Unicode 0X0000, Keycode0x400123, KeyName F10


F11 : Unicode 0X0000, Keycode0x400124, KeyName F11


And with this SDL :


F10 : Unicode 0X0000, Keycode0x600123, KeyName F10+MODE


F11 : Unicode 0X0000, Keycode0x600124, KeyName F11+MODE


Hence, the internal key decoder does not recognized the key due to the +MODE stuff.


So, is it a normal behavior with the new library, leading to change keycodes management in existing SW ? Or is it a wrong side effect ?
 
Thanks for checking, yeah it was kind of intentional but I'm dropping this MODE stuff now because of incompatibilities. You can redownload fixed version from the first post now.


You mentioned it's reading keysym.scancode too, what is it using that for?
 
Thanks Notaz for the fix

You mentioned it's reading keysym.scancode too, what is it using that for?
Honestly ? No idea :) openMSX is ~250 CPP files, with plenty of interconnected objects, so i didn't spent a lot of time to analyze the whole code...
 
Great work!

SDL_OMAP_BORDER_CUT:
This can be used to move parts of SDL surface out of screen, in other


words cut borders and zoom in. Format: <left>,<right>,<top>,<bottom>


For example, "0,0,16,0" would hide top 16 lines offscreen, making 17th


(16th if you count from 0) line the first visible.


Note: like for layer size ranges are limited.
^ Is there some way to change this image movement & zooming on the fly (not just once prior to starting your application)?
 
Last edited by a moderator:
Good to hear that UAE4ALL is still being worked on, it's one of my most used emulators! :)
 
Nice - thanks for the quick reply!


@ED & stouffa: Yeah sounds very promising indeed. Will try it out soon.
 
I don't have any programming knowledge at all, but does this updated SDL fix that issue where there was conflct between using the SDL and using the nubs? (eg. UAE4ALL (again))?
 
Back
Top