The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

SDL Forum Index
SDL
Simple Directmedia Layer Forums
Problem with SDL2: SDL_RenderClear (Windows)
fejoa


Joined: 16 Apr 2016
Posts: 5
Post Posted: Thu Jun 09, 2016 12:55 pm
Thought I'd move this post here from the games since more people post here and it is a technical question.

After the full screen is toggled in the configuration menu, the graphics are blitted to the screen and the following functions are invoked:
Code:

  packcol16* SrcPtr = DoubleBuffer->GetImage()[0];
  void* DestPtr;
  int Pitch;

  if (SDL_LockTexture(Texture, NULL, &DestPtr, &Pitch) < 0)
    ABORT("Can't lock texture");

  memcpy(DestPtr, SrcPtr, Res.Y * Pitch);

  SDL_UnlockTexture(Texture);

  SDL_RenderClear(Renderer);
  SDL_RenderCopy(Renderer, Texture, NULL, NULL);
  SDL_RenderPresent(Renderer);


When it gets to SDL_RenderClear the application crashes.

Could it be related to this: https://forums.libsdl.org/viewtopic.php?t=11885?

Original post from "Game Development":

fejoa wrote:
Hello SDL community!
We at IVAN community development are faced with a rather insoluble problem with our game at the moment, and I was wondering if anyone would like to take a look under the hood?
https://github.com/Attnam/ivan/issues/80


The problem has to do with switching between full screen mode and windowed mode. When the application is running, attempting to toggle between windowed and full screen (and vice versa) in Windows results in a crash.
The application behaves correctly in Linux and remains stable, which makes me suspicious.

In the graphics.cpp file we have, preprocessor directives help the compiler distinguish which parts are SDL1 and which are SDL2 - and even which parts are for DJGPP (in case of a nuclear winter, you know...). There is no big endian support. We are interested in SDL2, which we have working fairly stably at the moment, apart from this bug.

The full screen mode is toggled here: https://github.com/Attnam/ivan/blob/master/FeLib/Source/graphics.cpp#L314

The relevant functions for clear, copy and present are here: https://github.com/Attnam/ivan/blob/master/FeLib/Source/graphics.cpp#L272
We are using SDL_TEXTUREACCESS_STREAMING in conjunction with texture locking because it is marginally faster.

The application seems to crash when it gets to
Code:
SDL_RenderClear
, after the window has been toggled. The game can start initially in windowed or full screen mode by changing the application's configuration file, but can't toggle in Windows without crashing.

Some system information:
Compiler: GNU gcc 4.8.1 (compiling for 32-bit binaries)
SDL version: 2.0.4.0
Operating system: Windows 7, 64-bit


If anyone would like more information to help solve, please feel free to ask.
ChliHug


Joined: 05 May 2016
Posts: 7
Post Posted: Thu Jun 09, 2016 5:09 pm
This might be Bug 3147.

Not sure if that was the same problem AntTheAlchemist had, but we talked about something similar here.
fejoa


Joined: 16 Apr 2016
Posts: 5
Post Posted: Fri Jun 10, 2016 8:54 am
ChliHug wrote:
This might be Bug 3147.

Not sure if that was the same problem AntTheAlchemist had, but we talked about something similar here.


Thanks for posting this lead ChliHug :)

Further ways to produce crashes: Not only was there a crash when full screen was toggled, but the crash also happened if the system went to sleep, or if the task manager was called up via ctrl-alt-delete during normal program operation.

I changed the SDL_RENDER_DRIVER environment variable to "opengl", on both a Windows 7 system and a Windows 8.1 system. The bug went away, so it seems like there is a problem with the render driver and loss of context in SDL2 with Direct3D...

My next question is, where can I find a bleeding-edge release of SDL2 that fixes this bug, that I can deploy with the game so that eager fans no longer have to put up with this? I can't find any trace of the proposed patch https://bugzilla.libsdl.org/attachment.cgi?id=2364&action=diff in the SDL2 mercurial... What's the current status? Or is there another way around this that I should be aware of?
rtrussell


Joined: 10 Feb 2016
Posts: 88
Post Posted: Fri Jun 10, 2016 9:09 am
fejoa wrote:
Or is there another way around this that I should be aware of?

If it is bug #3147 then the workaround is to ensure that you choose a 'supported' pixel format for your renderer target. For example you can call SDL_GetRendererInfo and iterate through the texture formats to find which are suitable.
fejoa


Joined: 16 Apr 2016
Posts: 5
Post Posted: Fri Jun 10, 2016 10:12 am
rtrussell wrote:

If it is bug #3147 then the workaround is to ensure that you choose a 'supported' pixel format for your renderer target. For example you can call SDL_GetRendererInfo and iterate through the texture formats to find which are suitable.


I remember reading Ant's post using SDL_PIXELFORMAT_RGB888 and it seemed like a similar problem: https://forums.libsdl.org/viewtopic.php?t=11885&highlight=SDL_PIXELFORMAT_RGB888
We're using SDL_PIXELFORMAT_RGB565 to create our texture. It might just be one of these unsupported pixel formats. I'd rather not change this because of the way the application's material subsystem links to change the material colours of items in the game. How can I tell if a pixel format is supported or not?
rtrussell


Joined: 10 Feb 2016
Posts: 88
Post Posted: Fri Jun 10, 2016 10:22 am
fejoa wrote:
How can I tell if a pixel format is supported or not?

As I said, one way is to call SDL_GetRendererInfo and iterate through the returned texture_formats comparing them with your preferred option(s).

A more drastic solution might be to switch to using the OpenGL renderer, but of course that won't help if you are targeting WinRT/UWP:

Code:
SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengl");
fejoa


Joined: 16 Apr 2016
Posts: 5
Post Posted: Sun Jun 12, 2016 4:57 am
rtrussell wrote:
fejoa wrote:
How can I tell if a pixel format is supported or not?

A more drastic solution might be to switch to using the OpenGL renderer, but of course that won't help if you are targeting WinRT/UWP:

Code:
SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengl");


That is indeed quite drastic, but a solution I'm willing to try for the time being. The game is a graphical roguelike, played on PC with a keyboard preferrably sporting a keypad, and it's not coming to a Windows phone any time soon. I'm picking that OpenGL is widespread enough for this fix to work.
Does anyone know if SDL dev knows about this problem and will it be fixed in the next release? Is it best to post on bugzilla?
rtrussell


Joined: 10 Feb 2016
Posts: 88
Post Posted: Sun Jun 12, 2016 11:54 am
fejoa wrote:
I'm picking that OpenGL is widespread enough for this fix to work.

OpenGL is universally available on 'desktop' Windows AFAIK, but whether it will work in a trouble-free fashion for you depends on your app playing by all the rules. I developed my first SDL app on Windows/D3D and that was a mistake as it turned out because porting it to other platforms (which use OpenGL for rendering) showed up incompatibilities with the way I was doing things. Now I use OpenGL even on Windows (like you I'm not interested in WinRT/UWP).
fejoa


Joined: 16 Apr 2016
Posts: 5
Post Posted: Sun Jun 12, 2016 12:03 pm
rtrussell wrote:
fejoa wrote:
I'm picking that OpenGL is widespread enough for this fix to work.

OpenGL is universally available on 'desktop' Windows AFAIK, but whether it will work in a trouble-free fashion for you depends on your app playing by all the rules. I developed my first SDL app on Windows/D3D and that was a mistake as it turned out because porting it to other platforms (which use OpenGL for rendering) showed up incompatibilities with the way I was doing things. Now I use OpenGL even on Windows (like you I'm not interested in WinRT/UWP).


Cool, thanks for answering my questions and helping me understand rt.