Pandora improved SDL for pandora

[notaz]

(continuation of gp32x thread here: http://www.gp32x.de...6-improved-sdl/ )

ok so I did some updates to my SDL hack (almost exactly a year since last update) so I thought I'd do some advertising here. Let's start with the links:

binaries:

currently no longer built separately, they are now included in firmware, so you should do firmware update or build from source to get the latest version.

source (git):

git://notaz.gp2x.de/~notaz/sdl_omap.git

http://notaz.gp2x.de...p.git;a=summary

readme:

http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=sdl_omap.git;a=blob;f=README.OMAP;hb=HEAD

so what's different from stock x11 SDL?

• hardware scaling support (up and down)
• doublebuffering support (can eliminate tearing)
• vsync support (can give smooth scrolling if done right)
• keymap change with a config file (porting aid)
• touchscreen input translation to scaler source image coordinates
• screen surface cropping / border removal support

caveats:

• no windowed mode support, fullscreen only
• because of the above, new behavior must be enabled by setting environment variable

See readme for other details, read before use
Edit: updated with latest info

 

[Darkknight512]

Awesome


Will, "automatic touchscreen input translation to scaler source image coordinates" fix the current problems with the Homeworld port?

 

[PokeParadox]

Does this include any of the alpha optimisation via neon that you PM'd me about?

 

[skeezix]

Given this has some few downsides (no windowed mode, possible app problems due to unexpected behaviour?), presumably this is not the default SDL, but an alternative SDL? If so, it'd be in a different path and the pnd's run-script would have to set LD_LIBRARY_PATH differently?


Or are we wholesale replacing standard SDL with this one? (that would at least get bugs worked out fast


Most SDL apps would be games and emus so likely not so many people would miss windowed mode anyway, but some apps and users would have their feathers ruffled, and apps may need some code changes or repackaging (ie: to handle layer sizing, lack of windowing). Example, BattleJewels pnd has 2 runscripts, one that does windowed mode and one that is fullscreen (it was for testing multiple apps in a pnd when we built that


Otherwise... awesome as usual


jeff

 

[sebt3]

Given this has some few downsides (no windowed mode, possible app problems due to unexpected behaviour?), presumably this is not the default SDL, but an alternative SDL? If so, it'd be in a different path and the pnd's run-script would have to set LD_LIBRARY_PATH differently?

Or are we wholesale replacing standard SDL with this one? (that would at least get bugs worked out fast

To use notaz improvement you need to ask SDL to use notaz driver, else it still use x11 or fb

Spoiler

I'm doing this in the zelda's games

export SDL_VIDEODRIVER="omapdss"

export SDL_OMAP_VSYNC="1"

export SDL_OMAP_LAYER_SIZE="640x480"

 

[skeezix]

Ah, quite, thats true; so there are no 'negative' side effects using his new SDL, without cherrypicking the new features? (there is a list of env-vars in the README, but to be precise...)


If all true, then.. extra awesome


jeff

 

[sandwhich]

Thanks notaz!


What does "true 24bpp/32bpp support" mean? That we can use R8G8B8 videosurfaces without major FPS drops? I think it was possible before, but wasn't very fast...


Also that:

Does this include any of the alpha optimisation via neon that you PM'd me about?

would be so awesome.

 

[notaz]

Does this include any of the alpha optimisation via neon that you PM'd me about?

SDL implementation was so bad that I did 16bpp colorkeyed blitting (one slow in PandoraPanic) at the C level for now. If you can find some cases that are still slow with this let me know, it can then be NEONized. There is simply far too many variations of blit functions {8/16/24/32bpp} * {8/16/24/32bpp} * {colorkeying,alpha,morethatIforgot} to try to optimize them all.

What does "true 24bpp/32bpp support" mean? That we can use R8G8B8 videosurfaces without major FPS drops? I think it was possible before, but wasn't very fast...

It was always converting surfaces to 16bpp before displaying, now it can display them as is.


As for things being slow you can report them (best with a testcase), blit functions can be potentially sped up at least 2-3 times with NEON.

 

[PokeParadox]

Ah ok, I'll need to update my PNDs to load this new version... Thanks for you work Notaz!

 

[Dead1nside]

Sounds great Notaz, thanks.

 

[fusion_power]

Does the Pandora even display 32bpp graphics? I always had the impression htat everything looks suspicious 16bpp on screen, should be easy to spot with fine 32bpp gradient images... but maybe I'm wrong. ^^"

 

[sebt3]

Does the Pandora even display 32bpp graphics? I always had the impression htat everything looks suspicious 16bpp on screen, should be easy to spot with fine 32bpp gradient images... but maybe I'm wrong. ^^"

X11 on Pandora is working at 16bpp, so most think are actually displayd as 16bpp, but Notaz sdl driver hook the hardware more directly. And the hardware is certainly capable of these 32bpp

 

[EvilDragon]

Does the Pandora even display 32bpp graphics? I always had the impression htat everything looks suspicious 16bpp on screen, should be easy to spot with fine 32bpp gradient images... but maybe I'm wrong. ^^"

As notaz wrote above, it can display 32bpp, but the current SDL did only 16bpp.


You can check the 32bpp with the LCD Gamma Tool.

 

[captain_coconut]

Thanks for this update. 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.


WIth your previous release from a year ago, this worked ok and eliminated tearing, however scaling was a bit ugly. From what I recall, it seemed as though the scaling was ugly because it was not using the default filter which is slightly blurred.


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

 

[Michoko]

Thanks Notaz! If we can get a tearing-less mplayer (ideally a panplayer recompilation) that would be awesome!

 

[Mr Rob]

And a tearing-less gpFCE-GP2X. I would be one happy camper.

 

[milkshake]

And a tearing-less gpFCE-GP2X. I would be one happy camper.

I wish we had a better pandora native gpFCE, which just used pixel doubling instead of the strange filter and which had a menu more like gpSP and supported 7z files containing nes roms

 

[Mr Rob]

I wish we had a better pandora native gpFCE, which just used pixel doubling instead of the strange filter and which had a menu more like gpSP and supported 7z files containing nes roms

True. An NES emulator is actually kind of missing in the lineup (well, gpFCE is pretty good, but not nearly as perfect as the PS1, SNES, and a host of other emulators). The NES needs some love. Shame I don't know much about emulation development....

 

[milkshake]

shame indeed


*points the notaz spotlight towards the clouds*


"and they say that a hero can save us


im not going to stand here and wait


ill hold on to the wings of the eagles


watch as we all fly away"

 

[Miner49er]

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