I just tried it on my actual installation. I am getting a bit further. When I start my application I got SDL initialized with the KRM driver, but cannot open a SDL window. On the console I get three times the message
MESA-LOADER: failed to retrieve device information
And in my logfile I get
08.09.2017,05:17:59: DEBUG : SDL version 2.0.6 found
08.09.2017,05:17:59: DEBUG : Videodriver found: RPI
08.09.2017,05:17:59: DEBUG : Videodriver found: KMSDRM
08.09.2017,05:17:59: DEBUG : Videodriver found: dummy
08.09.2017,05:17:59: DEBUG : Using display driver 'KMSDRM'.
08.09.2017,05:17:59: ERROR : Could not create Window: Could not load EGL library
I think I will reinstall Raspian. Maybe I cracked somethink with my many tries.
Ok, after a fresh install I get SDL up and see some of my GUI elements. But now I have several other issues which I have not on my Ubuntu PC.
“Mixer Build without MP3 support”, I had that once, but cannot remember what I did against it.
The SDL image library seems to not support JPGs, on the PC it does.
I don’t see my cached textures (much like my initial problem)
My program crashes at some point with a segmentation fault. May have something with error 1 or 2
What is also strange: I get two messages about the used video driver in my log:
08.09.2017,10:11:22: DEBUG : Using display driver ‘KMSDRM’.
08.09.2017,10:11:22: DEBUG : Using display driver ‘opengl’.
The first is directlectly after SDL_init using SDL_GetCurrentVideoDriver().
The second is after opening the SDL windows and the renderer using info.name from SDL_GetRendererInfo(renderer, &info)
I had to configure sdl2_mixer with --enable-music-mp3-smpeg and maybe smpeg needed ffmpeg.
I had to install libjpeg9 and NOT libtiff. libtiff deinstalls libjpeg and uses another jpeg library which fail to load at least my jpgs.
No idea yet, this is nearly the problem for which I opened this thread.
Had to do with 2. Because no jpeg support my bachgound image load failed, but later I free’d it. And freeing a null-pointer is not a godd idea.
But now I recognized a new very bad problem. The keypresses at the console keyboard arrive in my SDL up but they also arrived at the console prompt. When I close my programm all my keypresses are seen on the underlying console.
The first is a SDL video driver. This is what interface SDL uses for that platform or operating system to get video stuff up and running.
The second is a SDL render driver. These are backed by graphics APIs (like the OpenGL and Direct3D variants) provided by the platform or operating system. Every platform is a bit different on how to get to these APIs and that’s what the video driver takes care of. The exception is the software renderer which comes with SDL.
Can you provide a simple, complete test case that shows this problem? We can then investigate in detail. It really should not disappear on you like that.
Yes, this is a known issue. It’s apparently really tricky to capture the terminal input. SDL has something in place that locks the terminal, but only for an actual non-remote console. And if SDL doesn’t get properly shut down, all input will be locked.
As a workaround, you can do something like this:
script -q -c "/usr/bin/sdl2application" /dev/null
Input does not get suppressed, but the shell won’t interpret the key presses as commands.
However, if you’re starting the application remotely… Hm, not sure. I have to think about that.
I fear, I can build a test case only in two weeks, because I go on holiday tomorrow and don’t want to take Raspberry, monitor, PC and all the stuff with me. I think my girlfriend would not like that.
That keyboard capture issue does not happen on old installation with SDL 2.0.4 and Wheezy.
If I start my application locally I cannot use the console anymore if I terminate it. As you said, the input seems stuck.
The “test case” is in the first post, but not as a complete program. It is an excerpt of my whole application. But you can see what I am trying. At the first pause the screen is black (with the old SDL I see a black screen with a blue box). At the second pause the screen is black again, in both versions of SDL. After the second pause my application starts and draws all the nice things it should, only not my precreated textures.
Very much thanks for support this far. I will come back to this issue in two weeks.
It seems that the first SDL_RenderPresent does nothing. The following work as intended. But the offscreen texture seems to be a transparent texture, despite what I drawed onto it. If the blendmode is set to SDL_BLENDMODE_BLEND did not see the texture at all, otherwise you see a black rectangle instead of the blue.
I thought, maybe I have to do a RenderPresent also to the offscreen texture, but that does draw the blue rectangle directly to the screen, not onto the texture.
For me it seems the renderer cannot draw onto a target texture, despite it’s flags that indicate it can.
When I see all that overhead using GPU acceleration (draw onto a surface, convert surface to texture, transfer texture to GPU and draw it to screen), I wonder if it is effective at all for such simple things like a 2D GUI.
Maybe it is more effective to draw everything in the SDL1 manner to one surface and then “copy” it to the screen. But this copying is also slow (convert it to texture, draw to screen by GPU). Maybe I should use SDL1 or direct framebuffer access and skip all that SDL2 stuff. But I read about the framebuffer is very slow on the Raspberry. The only backdraw I see is, if I later want to show full HD video with overlaid GUI elements. There I surely need the GPU.
But maybe you know a more efficient way to draw a 2D GUI. What I want is a background image and onto it some semitransparent GUI buttons and scrollable picture lists (album covers or something like that.)
SDL_SetRenderTarget only works with textures created with SDL_TEXTUREACCESS_TARGET. It will throw an error at you if you try with anything else.
I’m sorry I didn’t ask more specifically about that streaming texture comment in your first post. It confused me because it didn’t reflect your code sample, which was correct.
Also for the first SDL_RenderPresent going wrong. Try a loop with SDL_PumpEvents instead of SDL_Delay.
Edit: I just saw you’re always using the first renderer by passing 0 as the second argument to SDL_CreateRenderer. For me, that was opengl which is not supported by the RPI driver. You might want to use -1 for an automatic selection or search for a specific one by name with SDL_GetNumRenderDrivers and SDL_GetRenderDriverInfo.
Ok, that works on the demo, but not in my application. But it shows that it is working. I thought I tried that already. So I have to investigate what else did I wrong.
What should the delay have to do with the rendering. I had no delay at all first. I made it only because I thought, maybe the renderer needs some time.
I don’t think it has to do with the second parameter 0 at CreateRenderer. But I tested -1 and there is no difference. I also read that you shouldn’t give the flag SDL_RENDERER_ACCELERATED when using the GL driver. I tried that too, with no difference.
Technically, it shouldn’t. I tried your code on Windows with Direct3D and the delay somehow broke the renderer. Didn’t investigate further what went wrong. I also experienced a similar issue with the KWin window manager of the KDE project where the window didn’t show up fast enough and the first update of the window content was dropped. Now I’m always very suspicious of the first update right after window and renderer creation.
There’s no effect if you leave it out or not. The opengl renderer is always flagged as accelerated and the flag doesn’t have an effect on context creation. Unless an older version of SDL2 had something weird going on I don’t know about…
