We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 339

Summary: picture "losing textures" on resizing
Product: SDL Reporter: guinux <guinux7>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 1.2.11   
Hardware: x86   
OS: Windows (XP)   
URL: http://guinux.is.dreaming.org

Description guinux 2006-10-07 12:04:35 UTC 
Hello,

I found this bug on PlanetPenguin Racer (fork of Tux Racer which is not developped anymore), but it is already in Tux Racer. It is important to note that it only concerns the Windows operation system (Windows XP to be more precise, I have not tested on other versions). It appears when resizing the window. The fact that there is no problem on Linux (I tested on Ubuntu) made me believe this must be a bug within SDL and not a problem in the game's source code.

So if you get the latest version of Tux Racer for Windows (the first link in the download section of http://tuxracer.sourceforge.net/ should be fine), and change in the file config\options.txt the line "set fullscreen true" to "set fullscreen false", you'll have the game running in a window. Now, say you are in the menu, if you try resize the window, the picture will kind of lose his textures, in the way that you will only see squarres of color that seem to correspond to the original picture. Restarting the game and now resizing the window while in a race will make the picture "loses his textures" as well. What's more in PlanetPenguin Racer is that you can also change the screen resolution and the fullscreen mode in the configuration menu, and you have the same bug. This was definitively with SDL 1.2.11, while it was most probably an older version of SDL in the case of Tux Racer.
Furthermore, I tried (modification in PlanetPenguin Racer code) to kind of "reload the textures" after a screen resolution change has been made. The picture then is more accurate in comparison to what we have without reloading the textures, but still, this is not the "real picture". And some textures were appearing where they shouldn't have. I don't know if this can be of any help and let's remind it was a rough test to see what it would give.
Could it be some pointer that is not correct after memory free and reallocate in the process of changing the resolution or something like that?

I think I have said everything, and hope that maybe you will be able to fix it. I would add that, to the student I am, SDL is really wonderful. Please keep working on this ultimate portable library.

guinux

PS: right below I have to fill in the fields "depends on" and "blocks", but have no clue of what they are, I hope it doesn't matter if I leave them blank.
Comment 1 Ryan C. Gordon 2006-10-07 20:39:34 UTC 
Likely the call to SDL_SetVideoMode() in response to the resize event is causing a new GL context to be created, which destroys all the textures.

Has this ever been tested on Windows? Or is this just assumed to not work?

--ryan.
Comment 2 guinux 2006-10-08 06:50:44 UTC 
I am not familiar with OpenGL (but I have already used SDL), all I was doing is a port of PlanetPenguin Racer for Windows and noticed that bug which you don't have on Linux. What do you suggest trying?
Comment 3 Ryan C. Gordon 2007-05-28 22:07:11 UTC 
(Sorry to reply so late to this, it got lost on my TODO list...)

This isn't an SDL bug...it's a shame that the Windows and Linux codepaths work differently, but calling SDL_SetVideoMode() destroys the Windows GL context, which destroys the textures. They need to be reuploaded. I'd probably wait until 1000 or so milliseconds have gone by since the last resize event (so it doesn't happen continuously), then reload all the textures.

Arguably, SDL shouldn't require a SetVideoMode call to properly handle the resize event, but that's not going to change for 1.2 ... Sam might have a better plan for 1.3, though.

--ryan.