Other odd bugs that could use a bounty.


TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,411
Issue 1: Proper Video playback, I have yet found a good combination of video output on mpv, VLC or smplayer/mplayer that produces good playback. The default (I think XV) output that has fairly decent performance, however it seems to be switching the Red and Blue channels, so the colors are all wrong. I'm not sure if this is some artifact of our TILER system or something else wrongly setup in the userspace. Using SDL or X11 will produce proper coloring, but performance is horrendous, this can be somewhat mitigated by adding more CPU threads to decoding, but not quite a good solution as frames are still dropped.

Issue 2: Scaling to Fullscreen with SDL1.2, currently there doesn't seem to be a good method of scaling to full screen, and many games either don't have scaler options that go high enough to fill the 1280x720 screen and those that can have extremely bad performance scaling that high. The goal here is to allow these games to scale to full screen with a minimal performance hit. As there is a bunch of SDL1.2 games out there ready to be ported, having access to either a modified version of SDL1.2 or some other technical solution that would allow all SDL1.2 games to work properly would improve the software catalog quite a bit.

I don't quite have the budget to put out as much of a bounty as the Audio driver bounty EvilDragon is hosting, but willing to hand out 200 Euro for each one of these issues if they're fixed. So 400 Euro total on the table.
 
Last edited:
Maybe some of the SDL1.2 games can be made to work with sdl12-compat.
Was hoping for a solution that didn't require recompiling from source, as there are a bit of these games just on the debian repo. Although I may try this on a few of my ports.
 
You shouldn't need to recompile the games. sdl12-compat is a binary compatible replacement for SDL1.2 which uses SDL2 internally.
 
You can use environment variables like LD_LIBRARY_PATH to just override loading the original SDL 1.2 lib with this one when starting a game.
 
I'll give it a try when I get home from work, with some mild optimism.
 
Last edited:
Honestly I'd be surprised if it works, it may just have the same issues just with an extra layer of SDL2 complexity as this is a 2D issue. If it does scaling correctly, but the performance is still bad, then I don't see that as a fix either. If it does work, however I'd pretty much give the credit to M-HT as he gave the actual solution. Although It bugs me that if it did work, why after asking for 7 years (including Devboard time) why no one mentioned this as a solution.
 
If it does work, however I'd pretty much give the credit to M-HT as he gave the actual solution. Although It bugs me that if it did work, why after asking for 7 years (including Devboard time) why no one mentioned this as a solution.

Because there was no money on the table :D

Joke aside, let's first check if this really works without issues...
 
Last edited:
If it does work, however I'd pretty much give the credit to M-HT as he gave the actual solution.
I consider it more a workaround rather than a solution.

Although It bugs me that if it did work, why after asking for 7 years (including Devboard time) why no one mentioned this as a solution.
The initial release of sdl12-compat was only a year ago. And maybe people who don't have Pyra aren't watching the Pyra section as closely as those that do.
 
So the Pyra already uses a recompiled SDL1.2 with some position and scaling fixes made by @ouzle, but it is still not working well for fullscreen. Hopefully sdl12-compat will do it, I will give it a try as well.

About the Issue 1 (proper video playback):
I have some questions about what the the Pyra is capable according video decoding. Do the video players from the debian repository make use of all OMAP5 2D acceleration features like the NEON SIMD instructions?
Can they use GPU acceleration on the Pyra? Is the Vivante GC320 2D Accelerator any good for video decoding? Or is the PowerVR 3D accelerator the better choice for decoding?
I remember that on the tinker board Asus provided an extra video player using the abilities of the RK3288 that normal players couldn't...
 
Is the Vivante GC320 2D Accelerator any good for video decoding? Or is the PowerVR 3D accelerator the better choice for decoding?
Plot twist: Neither are any good for decoding, you want a dedicated video decoding hardware module for that. All modern desktop GPUs have one, within an SoC they are often not even considered to be part of the GPU. The UVD module found on Radeon cards has an own microcontroller core dedicated for decoding, someone even managed to use Linux' radeon driver code to use the UVD processor of a HD 3000 series card to control the GPU without any mainboard. On the OMAP5 it's the IVA-HD accelerator - not sure if that one can even be used directly or just as a part of the IPU (i.e.: the M4 cores), some TI documents imply the latter.

Shader-based software decoders do exist, but they do such an awful job that they are a rather rarely used niche. Like the MPEG2 implementation of Mesa for several vintage GPUs.
 
Last edited:
The initial release of sdl12-compat was only a year ago. And maybe people who don't have Pyra aren't watching the Pyra section as closely as those that do.
Okay I feel better that it wasn't some well known solution that no one ever thought to mention.
 
Last edited:
I've tested it on a few games, and it's pretty good outside a few cases where it will exit on a segfault. In one case I tried it on Wally's Dosbox port and it works great on Terminal Velocity, however trying Blood causes it to randomly crash hard enough for lightdm to reset itself, I guess it's still it's an active project so likely will improve overtime.

Could be nice to package this with some script that turn on sdl12-compat + gl4es or disable it to run the program as usual.
 
Last edited:
Also ironically this does solve some of the video playback issues I was facing, but doesn't solve the lack of actual hardware decoding. running mpv with this and setting '-vo sdl' will produce acceptable video playback with correct colors, but still doesn't have the decoding power to downscale a 1080p h264 videos and even seen it struggle with some less optimized 720p videos.
 
Regarding mpv, I posted my personal config... 2 years ago (wow). I haven't touched my Pyra in a good while, less watched videos on it, but I hope it's still kinda working and useful: https://pyra-handheld.com/boards/threads/video-playback-on-pyra.99364/post-1688821
SDL output with GL4es is probably the bulk of improvements which you already figured out. Most other stuff makes falling behind more bearable iirc.
 
Regarding mpv, I posted my personal config... 2 years ago (wow). I haven't touched my Pyra in a good while, less watched videos on it, but I hope it's still kinda working and useful: https://pyra-handheld.com/boards/threads/video-playback-on-pyra.99364/post-1688821
SDL output with GL4es is probably the bulk of improvements which you already figured out. Most other stuff makes falling behind more bearable iirc.
Now I remember this being mentioned, but forgot to loop back and try it out.
 
Back
Top