Bug reported #1544.
http://bugzilla.libsdl.org/show_bug.cgi?id=1544
The 1.2 / default (2.0/1.3) branches are confusing me, the changeset I
cited was in 2.0
Le 18/07/2012 22:25, Patrick Baggett a ?crit :> D’Archivio,
If you report the bug then I’ll see if I can come up with an
appropriate patch and attached it to bugzilla.Patrick
On Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga <slouken at libsdl.org <mailto:slouken at libsdl.org>> wrote:
The intent is that you only get the resize event if the window size is changed outside of SDL_SetVideoMode(). If it's not working that way, it's a bug. I don't have access to a windows machine at the moment, so patches (and a bug report in http://bugzilla.libsdl.org) are welcome. On Mon, Jul 16, 2012 at 5:15 PM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.com>> wrote: On Wed, Jul 11, 2012 at 12:46 PM, D'Archivio Thibault <@Thibault_D_Archivio <mailto:@Thibault_D_Archivio>> wrote: Le 11/07/2012 19:20, Patrick Baggett a ?crit :
Suppose there is a program "Super Blah Game", that links to SDL.dll. You can't change the code, just SDL.dll Then, if the game's code was: int g_width = -1, g_height = -1; /* ... some menu where user picks screen size ... */ int w = userSelectedMode.width; int h = userSelectedMode.height; SDL_InitVideo(... SDL_FULLSCREEN ... ); SDL_SetVideoMode(..., w, h, ... ); /* ...Event handling... */ case SDL_VIDEORESIZE: g_width = event.resize.x; g_height = event.resize.y; If the application only sets "g_width" and "g_height" when it sees SDL_VIDEORESIZE, then /not/ sending it can cause the application to break because the values are never initialized. We don't know how many applications do this. If this change was made, then we may find reports like "My game crashes in SDL 1.2.16, it has worked for years -- this must be a bug in SDL!" So while I agree that sending SDL_VIDEORESIZE probably isn't necessary and makes your life harder, changing it now will likely do more damage. Patrick Hum sorry, I didn't understood what you meant in your last post ^^'. I'm not a native english speaker, doesn't help :p _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
... But that's pointless to have 2 sets of size of the same surface and even more weird not to initialize one to the other ^^' While I perfectly understand that breaking previous applications should be avoided as possible, I just checked and 1.2.13 didn't do that as well, so only apps made in the last 6 months since 1.2.15 are concerned... I never looked at the SDL source since today so I could try to read it and try to understand why and what has changed but I may not be experienced enough to. Thanks for your time :) If you want to remove this behavior, it seems like it would be best to find out why it was added in 1.2.14 in the first place. Checking the mercurial history should give some context behind it. Patrick _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.orgAucun virus trouv? dans ce message.
Analyse effectu?e par AVG - www.avg.fr http://www.avg.fr
Version: 2012.0.2197 / Base de donn?es virale: 2437/5139 - Date:
18/07/2012