Black screen on Raspberry Pi about hypseus HOT 24 CLOSED

It is, at long last, fixed with my latest pull request.
@h0tw1r3 : Do you have time to enable overlays (like DL2 score table, etc) or should I give it a go instead?

from hypseus.

@h0tw1r3 : I have also fixed aspect ratio correction when starting in fullscreen mode. On the Pi, for example, you start in fullscreenmode no matter what because SDL2 on dispmanx/GLES works outside stinky Xorg (good thing!), but you need to pass -fullscreen to tell the emulator you WANT fullscreen mode (even if you get it anyway) so it enables aspect ratio correction. That's how it's supposed to be working.
So, when you test it on the Pi, use a line like this:

./hypseus lair vldp -framefile mpeg/lair/lair.txt -fastboot -fullscreen

Note that working accelerated YUV conversion saves ~40% of CPU on a Pi3, which is very nice: Dragon's Lair with 640x480 video decompression uses ~30% CPU usage according to TOP. Yay! 💃

from hypseus.

It seems that this call:

SDL_RenderCopy(video::get_renderer(), g_yuv_texture, NULL, NULL);

in void display_frame_callback(), in src/ldp-out/ldp-vldp.cpp, is returning -1. So I guess a black screen is expected as no video frames are being copied.

SDL_GetError() says the problem is: "Failed to load the shader", so it's clerly something that's wrong from earlier.

from hypseus.

All GL calls on the PI must done on the main thread. Right now display_frame_callback is called from a mpeg decoder thread. This needs to be fixed!
My intention is to use SDL mutex/condwait (ex. http://lazyfoo.net/tutorials/SDL/49_mutexes_and_conditions/) unless someone has a better idea.

from hypseus.

@h0tw1r3 : If that's the case, I think it's the only solution I see also...

from hypseus.

Is anyone working on this problem? I think the same bug is at work with #2.

@vanfanel, what distribution of Linux did you use such that Hypseus worked for you?

from hypseus.

@DavidGriffith if you force SDL to use software rendering it will work on anything. Just started a new job so my time is very limited at the moment. I will get back to it when things have settled.

from hypseus.

@DavidGriffith : I have built with your patch and still it's all black screen on the Pi.
In fact, there is no way to disable acceleration on the Pi: whatever you pass to SDL_CreateRenderer() is luckily accelerated because SDL2 uses an internal GLES renderer on this platform always. And that's how it should be IMHO. I can't see in what kind of situation would we want software scaling and tearing artifacts when we have this good GPU to to the job.

Also, I don't get what is Hypseus doing different from the likes of SDLPop (https://github.com/NagyD/SDLPoP), rawgl (https://github.com/cyxx/rawgl) and a long list of 2D games working great using SDL2 on the platform...

h0tw1r3 says it's a matter of having all GL calls on the PI done on the main thread, but there's NO need for an in-game GL renderer, since SDL2 alreay uses that under the hood. It's very simple: tell SDL2 to draw to screen, and forget about GL or whatever, SDL2 will take care of it. In the case of the Pi, it's ALWAYS accelerated as I said.

I see it done in
3rdparty/src/libmpeg2/libvo/video_out_sdl.c
src/video/SDL_FontCache.c
src/video/video.cpp
src/ldp-out/ldp-vldp.cpp
...among others.

Also, building in Lubuntu GNU/Linux Hypseus works well, the games are perfectly playable with video.

from hypseus.

@vanfanel Take a closer look. SDL2 yuv convert is GL accelerated (in SDL2) and must be on the main thread for RPI. It's a straightforward fix, I just don't have the time right now.

from hypseus.

@h0tw1r3: There's interest on this to work on the Pi... I can try the fix if you give me the small change you mentioned, so even if you don't have time, I can try.

from hypseus.

I'd like to give this a try too.

from hypseus.

@vanfanel Thanks for the PR, I'll test it after work tonight. Please give the overlay support a go. New job is taking all my time at the moment.

from hypseus.

@h0tw1r3 : I am fighting with the overlay stuff. It's supposed to be easy, but devil is in the details and I could use some ideas...
How were you planning to implement the overlay on top of the video streaming? The video streaming is passed to the video class from the vldp class on an SDL2 YUV texture, but then:
-Were you considering drawing the overlay on top of the SDL2 YUV texture? How? There seem to be no way to specify transparent pixels for the SDL2 Surface containig the final overlay so these pixels are considered transparent in SDL_UpdateTexture()
-Were you considering to have the overlay on an SDL2 texture and then somehow combine it with the FMV YUV texture? How? I don't see any way to combine two textures.

EDIT: NVM, just came up with a solution, consisting on setting SDL_SetTextureBlendMode() to SDL_BLENDMODE_ADD for the overlay texture (scores, etc), and let SDL_RenderCopy() do the work: I first rendercopy the FMV YUV texture, and then rendercopy the overlay texture that has it's blend mode set to SDL_BLENDMODE_ADD, and it looks like a very nice overlay 👍

from hypseus.

Is there a way to have overlay graphics in games like Interestellar without a framefile or ldp?
Only overlay graphics
I tried "novldp", but then I get no overlay graphics at all

from hypseus.

@vanfanel novldp shouldn't disable all of the graphics, sounds like graphics init being skipped erroneously.

from hypseus.

@h0tw1r3 : Why are you using a 24bpp mode for g_screen_blitter SDL_Surface in video.cpp?
I will have to use RGBA8888 or ARGB8888 instead, because we need some opaque pixels (those non-black) and some transparent pixels (those 0x00000000 black ones) to get the overlays working right on modern SDL2, but blitting from 8bpp to 32bpp does not seem to work right...
IMHO, 24bpp is not an option for overlay texture: no alpha component.

from hypseus.

@vanfanel No reason. An alpha surface makes sense.

from hypseus.

@h0tw1r3 : I have now added scoreboard overlay support on yesterday's pull request.
It works on Dragon's Lair at least. I don't know if full overlay support will be possible as things are (SDL2 calls using Dispmanx/GL functions under the hood needing to be in the same thread) without affecting the FMV smoothness, but I will investigate a bit longer.

from hypseus.

@h0tw1r3 : Fully working overlays implemented now. More details in the pull request. Please merge the new code 👍

from hypseus.

Thanks to the contributions from @vanfanel , this issue is fixed.

from hypseus.

Hello,
First thanks for the good job you did ;)

I just compiled Hypseus yesterday on a fresh installed raspbian 9 and I'm facing exactly the same problem than in the first message:
[ldv1000::pre_display_disable@451] Display disable received (unsupported)
Do you have any idea?

Thanks.

from hypseus.

Same problem on a fresh raspbian stretch. (PI3B)

Test procedure :
Fresh raspbian stretch installed and updated.
SDL2.0.8, SDL2_image-2.0.2, SDL2_mixer-2.0.2, SDL2_net-2.0.1, SDL2_ttf-2.0.14 compiled and installed.

Without -sdl_software_rendering i get :
WARN;1221;0;ldv1000::pre_display_disable@451;"Display disable received (unsupported)"
(sound is playing)

With -sdl_software_rendering i get :
;WARN;1175;0;video::init_display@213;"Could not initialize renderer: Couldn't find matching render driver"

All tested from console.

FYI
Daphne-pi also do not work anymore on raspbian stretch

from hypseus.

i think this might be a stretch issue because i just tried it on debian strech and the screen opened but the video didnt play can post output if its needed

With -sdl_software_rendering didnt work either

from hypseus.

Yes, for sure it's a stretch issue.
If you start from a working jessie environement and update it to stretch, daphne, hypseus will not work anymore.
(I'm "happy" to see that I'm not the only one with this problem)

from hypseus.