SDL 1.2 fullscreen position fix

[ouzle]

@aTc To get the NEON acceleration enabled, could you give us a third libSDL deb, named like libsdl1.2pyraNEON-git06315b7?

The Ubuntu packagers sometimes take this approach, or they put the unstable packages in a "PPA" / lanchpad. Do we have a staging repo for unstable debs?

 

[Bosbeetle]

Ok the SDL Fix was aplied: I can now just push F11 on the Playstation Emulator instead of pulling the Stylus Out to maximise the Window,
Firefox will also get Fullscreen by Pressing F11, but Thunderbirth and Libre Office dosnt do this whit F11...
I wonder what happens now: Will the SDL gets its way to the Official Update? , And will future Ports gets now Fullscreen Mode?

Since it is in the pandora repo it is more or less in the official updates. If all is stable aTc might choose to put this library in the first image by default. I dont think there will be a change made in the SDL1.2 debian package since this was apparantly a bug they just left lying around since 2013. Maybe somebody has an idea who to poke to get this in into debian, but it is not neccesary since we have this fork.

 

[ouzle]

The problem is that our new libsdl1.2pyra still doesn't include the NEON bitblit acceleration.

Our libsdl1.2pyra package is the SDL1.2.15 (457d4e5) release version from 21 Jan 2012! This is deprecated so none of the recent bug fixes or NEON acceleration will ever be added to a release version.

If we want NEON acceleration for SDL 1.2, we'll need to package a more recent version. I've not noticed any problems using the "main" branch with '--enable-arm-neon' here but it might break something, somewhere, one-day.

 

[matzesu]

NEON is for Graphic? So if someone makes a Pyra Game that needs NEON, whe who allready installed the SDL1.2 Pyra, cant play it because whe deletet the NEON Support in Exchange for Fullscreen Playstation ?

 

[ouzle]

NEON is just some CPU instructions that the ARM CPU can use to move memory quicker. It can help make graphics faster and more efficient for SDL1.2. For example, it can move a sprite around the screen faster without using the GPU, or fill an area of the image with a color quickly. Its used in new versions SDL 1.2 because that doesnt have any GPU acceleration features.

More recent games wil use SDL2, or OpenGLES, or OpenGL with gl4es to do graphics fast using the GPU.

Post automatically merged: Apr 23, 2021

The NEON version doesnt change functionality, it just goes faster. Unless the new NEON version has new bugs of course.

 

[matzesu]

Ok, so at least it ditnt harm to took the Pyra SDL Package?
But when OpenGL also handled the FullScreen Mode, isnt there enough Power left for other things?

So when i use the PCSXRearmed whit the SDL is it then faster? or Just Fullscreen instead of Maximiced Window Mode?
And was it just a discover by accidend that i also pushed F11 in Firefox and it got Fullscreen, or do this SDL Fix also work whit Firefox?

 

[levi]

It's similar as to when Exo modified DraStic to make use of NEON opcodes. It just ran faster (and broke more often on my GHz unit, until I backed off the overclock).

It shouldn't affect functionality if it's been coded right. Therefore PCSXrearmed shouldn't change, and if you have to use maximised windows rather that going full screen that won't change.

 

[TrashyMG]

And was it just a discover by accidend that i also pushed F11 in Firefox and it got Fullscreen, or do this SDL Fix also work whit Firefox?

I don't think I had issues with Firefox and fullscreen before this SDL fix, I believe it's unrelated.

 

[sebt3]

I can disable my port of OpenTyrian off the Repo if need be, I'm not sure I have time to maintain it properly anyway, my current Job is sucking away all my free time and motivation... I was hoping to compile a version with the Comp4All support I did with the Pandora version.

Or set Ouzle as maintainer (go to the package edit page : https://pyra-handheld.com/repo/packages/OpenTyrian_C4ALL/edit, then select ouzle as maintainer)

 

[ptitSeb]

if I

sudo apt install libsdl1.2pyra libsdl1.2pyra-dev

I loose access to

libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev

@aTc can you create the "pyra-dev" version of those too?

 

[aTc]

I'll first try to shuffle around some of the provides/dependencies of the libsdl1.2pyra-dev package and see if I can fix it that way.

 

[aTc]

Fixed it, and pushed it onto the repo.
Problem was that I was using the wrong name, and it seems debian is very picky about including the package version in the Provides: field.

Stuff like this is why I hadn't included it in the default image yet, but if this works without problems I think I can include it.

I also have updated the gl4es package on the repo to the latest version.

I also have a test version of the box86 package here : https://packages.pyra-handheld.com/images/extra/box86-pyra_0.14_armhf.deb
It still needs a bit of work, and it seems you need to manually do a "systemctl restart systemd-binfmt" before it'll pick those up. (or reboot)
I'll continue work on it tomorrow, if it behaves like it should, or needs other compiler options set, please let me know.
Your openarena benchmark ran at 2 fps using the fixed libsdl and gl4es, so i guess there's some room for improvement somewhere.
(and 1 fps using 1280x720 fullscreen)

 

[ptitSeb]

Fixed it, and pushed it onto the repo.
Problem was that I was using the wrong name, and it seems debian is very picky about including the package version in the Provides: field.

Stuff like this is why I hadn't included it in the default image yet, but if this works without problems I think I can include it.

I also have updated the gl4es package on the repo to the latest version.

I also have a test version of the box86 package here : https://packages.pyra-handheld.com/images/extra/box86-pyra_0.14_armhf.deb
It still needs a bit of work, and it seems you need to manually do a "systemctl restart systemd-binfmt" before it'll pick those up. (or reboot)
I'll continue work on it tomorrow, if it behaves like it should, or needs other compiler options set, please let me know.
Your openarena benchmark ran at 2 fps using the fixed libsdl and gl4es, so i guess there's some room for improvement somewhere.
(and 1 fps using 1280x720 fullscreen)

Thanks!

About the box86 deb, the deb recipie from the cmake project is not ok? (because that one should do the restart of binfmt automaticaly, I think)

Yeah, the OpenArena benchmark is super heavy on the GL card. It's untouched setup from Phoronix, so targeted at desktop OpenGL card, so they have put all sort of graphics effect and detail. I got a similar result an a Pi4, so it's not an error.

 

[TrashyMG]

So I guess now the dumb question is there any kind of solution to scale up a native software only 320x240 SDL 1.2 game for example? Am I missing something simple or still a flaw somewhere.

 

[aTc]

I prefer to build all the packages using the same method, and it gives me a bit more control over what goes on inside the package.

Nice to know the box86 results are what you expected, I was a bit worried seeing the 30+fps average on the website.
Please let me know if there are any other easy ways to test box86.

I'm not sure where exactly the best way is to get things stretched to fullscreen, if a patched SDL is needed, or if it can be done accelerated automatically through the xorg driver.

 

[ptitSeb]

well, you can use "ctest" after building box86, there are a few unit test.

 

[cjam]

@ouzle, thanks for your post

if I understand correctly, pyra is using debian-arm's libsd1.2 by default. You can grab it with apt-get source libsdl1.2

Debian includes a number of patches which I think ought to be reviewed if you want to replace the distro's libsdl1.2. On my system libsdl1.2-1.2.15+dfsg2 these are:

dpkg-source: info: applying replace-relicenced-SDL_qsort.patch
dpkg-source: info: applying x11_keytounicode.diff
dpkg-source: info: applying dont_propagate_lpthread.diff
dpkg-source: info: applying fix_build_joystick_freebsd.diff
dpkg-source: info: applying fix_window_resizing.diff
dpkg-source: info: applying fix_joystick_misc_axes.diff
dpkg-source: info: applying sdl-check-for-SDL_VIDEO_X11_BACKINGSTORE.patch
dpkg-source: info: applying avoid_maybe_non-DFSG_file.patch
dpkg-source: info: applying SDL-1.2.15-vec_perm-ppc64le.patch
dpkg-source: info: applying CVE-2019-7572_CVE-2019-7574.patch
dpkg-source: info: applying CVE-2019-7573.patch
dpkg-source: info: applying CVE-2019-7575_7577.patch
dpkg-source: info: applying CVE-2019-7578.patch
dpkg-source: info: applying CVE-2019-7635_636_638.patch
dpkg-source: info: applying CVE-2019-7637.patch
dpkg-source: info: applying CVE-2019-7637-2.patch
dpkg-source: info: applying CVE-2019-7577-1_2.patch
dpkg-source: info: applying CVE-2019-13616.patch
dpkg-source: info: applying properly_handle_focus_events.patch

Had pasted the wrong rules file here, sorry. I wonder why doesn't debian version have the --enable-arm-simd or --enable-arm-neon?

I noticed SDL1.2 apps typically look for key scancodes, which assume a pc-style keyboard. This causes problems for portable devices if they use remapped keys. SDL provides translated 'unicode' keycodes but most SDL programs don't explicitly ask for those.

[EDIT] is test/testblitspeed.c (./testblitspeed --screen) useful to test neon acceleration?