Pandora improved SDL for pandora

[milkshake]

there are nes emulators but they havent had much love and they could be so much better.

 

[captain_coconut]

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.

 

[SladeCraven]

Tested quickly with my openMSX port, and it seems that functions keys are not recognized (ie F1-> F12). But its fast !

 

[DaMummy]

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

 

[milkshake]

nope its too much or a farce, gpFCE is nice it just needs that little extra polish that gpSP and PCSX ReARMed got.

 

[notaz]

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..

 

[notaz]

Tested quickly with my openMSX port, and it seems that functions keys are not recognized (ie F1-> F12). But its fast !

f-keys work here on SDL's test, how is openMSX reading those keys?

 

[SladeCraven]

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.

 

[notaz]

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?

 

[notaz]

If this worked, we could finally be able to play video without the ugly tearing that affects all the video players on the pandora.

Try building mplayer with some hacks I just pushed, and run it with -vo omapfb .

 

[SladeCraven]

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 ?

 

[notaz]

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?

 

[SladeCraven]

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...

 

[john4p]

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)?

 

[EvilDragon]

^ Is there some way to change this image movement & zooming on the fly (not just once prior to starting your application)?

Uuuh... I smell it would be very useful for UAE4ALL

 

[NoeleyC]

Good to hear that UAE4ALL is still being worked on, it's one of my most used emulators!

 

[notaz]

Is there some way to change this image movement & zooming on the fly (not just once prior to starting your application)?

It's taken into account on every SDL_SetVideoMode call, and you can update it with setenv().

 

[john4p]

Nice - thanks for the quick reply!


@ED & stouffa: Yeah sounds very promising indeed. Will try it out soon.

 

[NoeleyC]

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))?

 

[notaz]

Not sure what you mean here, but it sounds more like a problem with the app itself.