SetVideoMode triggers VIDEORESIZE Win7 (1.2.15)

Hi everybody

Well, as written in the title, since 1.2.15, SDL_SetVideoMode launches
SDL_VIDEORESIZE events when called with different width and height
(possibly bpp ?) than the current ones. Even at the very first call. But
not when the call follows a precedent SDL_VIDEORESIZE nor with same
precedent values .

To describe the problem:
I run an app with the SDL_RESIZABLE flag in windowed mode and I can
put it in full-screen mode with the SDL_FULLSCREEN flag (Win7, no
SDL_WM_ToggleFullScreen
http://sdl.beuc.net/sdl.wiki/SDL_WM_ToggleFullScreen magic). So each
SDL_VIDEORESIZE event is caught and a call to SDL_SetVideoMode is done
to effectively resize the surface in windowed mode.

The resizing following an SDL_VIDEORESIZE works perfectly.

 But, when the app is passed in Full-screen mode, it goes 

full-screen, and then catches an SDL_VIDEORESIZE event from nowhere and
so, a 2nd call to SDL_SetVideoMode is uselessly done (making it loose
its OpenGL context because done outside of the fullscreen switch code
which normally recreate it).
The behavior is similar even without the full-screen flag. I’ve wrote a
little test code to show it.

When using 1.2.14, the SDL_VIDEORESIZE are only generated when the user
resize the window witch I think would be the correct behavior.
It is also correct using the directx driver.

I fixed this with SDL_EventState(SDL_VIDEORESIZE, SDL_IGNORE/ENABLE)
around SDL_SetVideoMode but I would like to know if it is effectively a bug.

Thanks
-------------- next part --------------
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <time.h>
#include “SDL.h”

int main() {

SDL_Surface *screen;
SDL_Event event;
bool done = false, pressedReturn = false;
int w = 200, h = 200;

srand(time(NULL));
//SDL_putenv("SDL_VIDEODRIVER=directx");
SDL_Init(SDL_INIT_VIDEO);

screen = SDL_SetVideoMode(w, h, 32, SDL_RESIZABLE);

while(!done) {

    while(SDL_PollEvent(&event)) {

        switch(event.type) {

            case SDL_QUIT:
                done = true;
                break;
            case SDL_VIDEORESIZE:
                // A new surface is recreated following the dimensions asked by the user
                printf("\n[CASE SDL_VIDEORESIZE]\n");
                screen = SDL_SetVideoMode(event.resize.w, event.resize.h, 32, SDL_RESIZABLE);
                break;
            case SDL_KEYDOWN:
                 // Each press on [Return] a different surface is created
                if (event.key.keysym.sym == SDLK_RETURN && !pressedReturn) {
                    pressedReturn = true;
                    screen = SDL_SetVideoMode(rand() % 400, rand() % 400, 32, SDL_RESIZABLE);
                }
                break;
            case SDL_KEYUP:
                if (event.key.keysym.sym == SDLK_RETURN && pressedReturn)
                    pressedReturn = false;
                break;
            }

    }

    SDL_Flip(screen);
}

return 0;

}

Hey, I’ve been playing with your program, and I’m not really sure what the
issue is that I’m trying to reproduce. To summarize in one line (correct me
if I’m wrong): Is it that you’re getting SDL_VIDEORESIZE message when
SDL_SetVideoMode(…,SDL_FULLSCREEN) is set, causing the second
SDL_SetVideoMode() to kill your GL context? Just reading through the Win32
implementation, I think the first resize message may be unneeded and a mere
artifact of the Win32 API…

PatrickOn Wed, Jul 11, 2012 at 9:01 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Hi everybody

Well, as written in the title, since 1.2.15, SDL_SetVideoMode launches
SDL_VIDEORESIZE events when called with different width and height
(possibly bpp ?) than the current ones. Even at the very first call. But
not when the call follows a precedent SDL_VIDEORESIZE nor with same
precedent values .

To describe the problem:
I run an app with the SDL_RESIZABLE flag in windowed mode and I can
put it in full-screen mode with the SDL_FULLSCREEN flag (Win7, no
SDL_WM_ToggleFullScreenhttp://sdl.beuc.net/sdl.wiki/SDL_WM_ToggleFullScreenmagic). So each SDL_VIDEORESIZE event is caught and a call to
SDL_SetVideoMode is done to effectively resize the surface in windowed mode.

The resizing following an SDL_VIDEORESIZE works perfectly.

But, when the app is passed in Full-screen mode, it goes full-screen,

and then catches an SDL_VIDEORESIZE event from nowhere and so, a 2nd call
to SDL_SetVideoMode is uselessly done (making it loose its OpenGL context
because done outside of the fullscreen switch code which normally recreate
it).
The behavior is similar even without the full-screen flag. I’ve wrote a
little test code to show it.

When using 1.2.14, the SDL_VIDEORESIZE are only generated when the user
resize the window witch I think would be the correct behavior.
It is also correct using the directx driver.

I fixed this with SDL_EventState(SDL_VIDEORESIZE, SDL_IGNORE/ENABLE)
around SDL_SetVideoMode but I would like to know if it is effectively a bug.

Thanks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Actually, it looks like there is a call to SDL_PrivateResize() inside of
SDL_SetVideoMode() (src/video/SDL_video.c line 687), which creates the
SDL_VIDEORESIZE event. This happens on all platforms. It seems like the
best behavior then is to ignore SDL_VIDEORESIZE events in fullscreen mode,
or at least the first one, since it is artificially generated after OpenGL
context creation (i.e. not in response to a window system / user event).

PatrickOn Wed, Jul 11, 2012 at 10:11 AM, Patrick Baggett <@Patrick_Baggett wrote:

Hey, I’ve been playing with your program, and I’m not really sure what the
issue is that I’m trying to reproduce. To summarize in one line (correct me
if I’m wrong): Is it that you’re getting SDL_VIDEORESIZE message when
SDL_SetVideoMode(…,SDL_FULLSCREEN) is set, causing the second
SDL_SetVideoMode() to kill your GL context? Just reading through the Win32
implementation, I think the first resize message may be unneeded and a mere
artifact of the Win32 API…

Patrick

On Wed, Jul 11, 2012 at 9:01 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Hi everybody

Well, as written in the title, since 1.2.15, SDL_SetVideoMode launches
SDL_VIDEORESIZE events when called with different width and height
(possibly bpp ?) than the current ones. Even at the very first call. But
not when the call follows a precedent SDL_VIDEORESIZE nor with same
precedent values .

To describe the problem:
I run an app with the SDL_RESIZABLE flag in windowed mode and I can
put it in full-screen mode with the SDL_FULLSCREEN flag (Win7, no
SDL_WM_ToggleFullScreenhttp://sdl.beuc.net/sdl.wiki/SDL_WM_ToggleFullScreenmagic). So each SDL_VIDEORESIZE event is caught and a call to
SDL_SetVideoMode is done to effectively resize the surface in windowed mode.

The resizing following an SDL_VIDEORESIZE works perfectly.

But, when the app is passed in Full-screen mode, it goes full-screen,

and then catches an SDL_VIDEORESIZE event from nowhere and so, a 2nd call
to SDL_SetVideoMode is uselessly done (making it loose its OpenGL context
because done outside of the fullscreen switch code which normally recreate
it).
The behavior is similar even without the full-screen flag. I’ve wrote a
little test code to show it.

When using 1.2.14, the SDL_VIDEORESIZE are only generated when the user
resize the window witch I think would be the correct behavior.
It is also correct using the directx driver.

I fixed this with SDL_EventState(SDL_VIDEORESIZE, SDL_IGNORE/ENABLE)
around SDL_SetVideoMode but I would like to know if it is effectively a bug.

Thanks


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, I talked about my case with full-screen and OpenGl loss because
it’s when I first see those strange SDL_VIDEORESIZE events but as I
tried to show in the example code, I was asking whether or not the fact
that SDL_SetVideoMode generates an SDL_VIDEORESIZE event is normal.

In the example code, each time you press Return, you will see [CASE
SDL_VIDEORESIZE] in the output (Well, I now remember there may be some
trick to do to use the console with SDL that I enabled by default on my
system…)

What is the point of having an SDL_VIDEORESIZE when we explicitly call
SDL_SetVideoMode ? We already know it changed, we commanded it !

Le 11/07/2012 17:29, Patrick Baggett a ?crit :> Actually, it looks like there is a call to SDL_PrivateResize() inside

of SDL_SetVideoMode() (src/video/SDL_video.c line 687), which creates
the SDL_VIDEORESIZE event. This happens on all platforms. It seems
like the best behavior then is to ignore SDL_VIDEORESIZE events in
fullscreen mode, or at least the first one, since it is artificially
generated after OpenGL context creation (i.e. not in response to a
window system / user event).

Patrick

On Wed, Jul 11, 2012 at 10:11 AM, Patrick Baggett <baggett.patrick at gmail.com <mailto:baggett.patrick at gmail.com>> wrote:

Hey, I've been playing with your program, and I'm not really sure
what the issue is that I'm trying to reproduce. To summarize in
one line (correct me if I'm wrong): Is it that you're getting
SDL_VIDEORESIZE message when SDL_SetVideoMode(....,SDL_FULLSCREEN)
is set, causing the second SDL_SetVideoMode() to kill your GL
context? Just reading through the Win32 implementation, I think
the first resize message may be unneeded and a mere artifact of
the Win32 API...

Patrick

On Wed, Jul 11, 2012 at 9:01 AM, D'Archivio Thibault <@Thibault_D_Archivio <mailto:@Thibault_D_Archivio>> wrote:

    Hi everybody

    Well, as written in the title, since 1.2.15, SDL_SetVideoMode
    launches SDL_VIDEORESIZE events when called with different
    width and height (possibly bpp ?) than the current ones. Even
    at the very first call. But not when the call follows a
    precedent SDL_VIDEORESIZE nor with same precedent values .

    To describe the problem:
        I run an app with the SDL_RESIZABLE flag in windowed mode
    and I can put it in full-screen mode with the SDL_FULLSCREEN
    flag (Win7, no SDL_WM_ToggleFullScreen
    <http://sdl.beuc.net/sdl.wiki/SDL_WM_ToggleFullScreen> magic).
    So each SDL_VIDEORESIZE event is caught and a call to
    SDL_SetVideoMode is done to effectively resize the surface in
    windowed mode.

    The resizing following an SDL_VIDEORESIZE works perfectly.

        But, when the app is passed in Full-screen mode, it goes
    full-screen, and then catches an SDL_VIDEORESIZE event from
    nowhere and so, a 2nd call to SDL_SetVideoMode is uselessly
    done (making it loose its OpenGL context because done outside
    of the fullscreen switch code which normally recreate it).
    The behavior is similar even without the full-screen flag.
    I've wrote a little test code to show it.

    When using 1.2.14, the SDL_VIDEORESIZE are only generated when
    the user resize the window witch I think would be the correct
    behavior.
    It is also correct using the directx driver.

    I fixed this with SDL_EventState(SDL_VIDEORESIZE,
    SDL_IGNORE/ENABLE) around SDL_SetVideoMode but I would like to
    know if it is effectively a bug.

    Thanks

    _______________________________________________
    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.org

Well, I talked about my case with full-screen and OpenGl loss because
it’s when I first see those strange SDL_VIDEORESIZE events but as I tried
to show in the example code, I was asking whether or not the fact that
SDL_SetVideoMode generates an SDL_VIDEORESIZE event is normal.

In the example code, each time you press Return, you will see [CASE
SDL_VIDEORESIZE] in the output (Well, I now remember there may be some
trick to do to use the console with SDL that I enabled by default on my
system…)

What is the point of having an SDL_VIDEORESIZE when we explicitly call
SDL_SetVideoMode ? We already know it changed, we commanded it !

A fair point, but we have no way of know if applications depend on that
behavior, i.e. they only update internal variables based on SDL_VIDEORESIZE
events and not based on whatever they pass to SDL_SetVideoMode().

PatrickOn Wed, Jul 11, 2012 at 11:49 AM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Le 11/07/2012 18:58, Patrick Baggett a ?crit :

Well, I talked about my case with full-screen and OpenGl loss
because it's when I first see those strange SDL_VIDEORESIZE events
but as I tried to show in the example code, I was asking whether
or not the fact that SDL_SetVideoMode generates an SDL_VIDEORESIZE
event is normal.

In the example code, each time you press Return, you will see
[CASE SDL_VIDEORESIZE] in the output (Well, I now remember there
may be some trick to do to use the console with SDL that I enabled
by default on my system...)

What is the point of having an SDL_VIDEORESIZE when _we_
explicitly call SDL_SetVideoMode ? We already know it changed,
_we_ commanded it !

A fair point, but we have no way of know if applications depend on
that behavior, i.e. they only update internal variables based on
SDL_VIDEORESIZE events and not based on whatever they pass to
SDL_SetVideoMode().

Patrick


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hum sorry, I didn’t understood what you meant in your last post ^^’. I’m
not a native english speaker, doesn’t help :p> On Wed, Jul 11, 2012 at 11:49 AM, D’Archivio Thibault <@Thibault_D_Archivio mailto:Thibault_D_Archivio> wrote:

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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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
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 :slight_smile:

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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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.

PatrickOn Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> wrote:

Can’t just change the size variables I believe. Gotta SDL_SetVideoMode too.
Either you forgot to mention this or you did not do it. Read the manual is
a mantra.

"When an SDL_VIDEORESIZE is recieved the window should be resized to the
new dimensions using
SDL_SetVideoMode<file:///C:/pork/SDL-1.2.15/docs/html/sdlsetvideomode.html>
."On Mon, Jul 16, 2012 at 4:15 PM, Patrick Baggett <baggett.patrick at gmail.com>wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> 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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

R Manard,

Please, before you send emails that basically say “you didn’t read”, read
the context of the conversation first!

He wrote that when he gets an SDL_VIDEORESIZE event, he does call
SDL_SetVideoMode() in response to it. If you read my review of the source
code, you’d see that the first time the window is shown, there is a
SDL_VIDEORESIZE event sent without the window being resized. Then his code
calls SDL_SetVideoMode(), like a good SDL program. This destroys the OpenGL
context he just created with SDL_InitVideo(). This is why he is asking for
help in the first place! Furthermore, this behavior is apparently new
post-SDL 1.2.13, which makes it odd. Do you have anything to add to this
thread?

PatrickOn Mon, Jul 16, 2012 at 7:41 PM, R Manard wrote:

Can’t just change the size variables I believe. Gotta SDL_SetVideoMode
too. Either you forgot to mention this or you did not do it. Read the
manual is a mantra.

“When an SDL_VIDEORESIZE is recieved the window should be resized to the
new dimensions using SDL_SetVideoMode.”

On Mon, Jul 16, 2012 at 4:15 PM, Patrick Baggett < @Patrick_Baggett> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> 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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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
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.org

Le 17/07/2012 02:41, R Manard a ?crit :

Can’t just change the size variables I believe. Gotta SDL_SetVideoMode
too. Either you forgot to mention this or you did not do it. Read the
manual is a mantra.
“When an SDL_VIDEORESIZE is recieved the window should be resized to
the new dimensions using SDL_SetVideoMode
<file:///C:/pork/SDL-1.2.15/docs/html/sdlsetvideomode.html>.”

    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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

 Yeah, I know that a call to SetVideoMode must be done after each 

SDL_VIDEORESIZE. No problem with this, it’s logic to reset the surface
after its size has changed, if we don’t want this we simply shouldn’t
use the SDL_RESIZABLE flag.

 SDL_RESIZABLE is supposed to be generated when the user change the 

size of the window, by pulling an edge or a coin with the mouse or
others depending on the Window Manager.
BUT, what should happen if we place somewhere a call to
SetVideoMode changing the size and that call is done without VIDEORESIZE
event ?
It may seems strange, but not forbidden. Furthermore, there’s a case
where it would make sense: going fullscreen at native resolution .
(without SDL_WM_ToggleFullscreen, not implemented on Windows)
In both cases, I don’t think we need an SDL_VIDEORESIZE event,
because the change came from us (the app), not from the Window Manager,
so we know what has happened.

This behavior is what I would have expect and seems like how the SDL
have behave. Until now:

different values for width or height than those of the precedent call_
generates an SDL_VIDEORESIZE event. I’ve wrote a little documentation
<cid:part12.09050001.05000201 at free.fr>.

 I don't know how many apps/games manually resize themselves, but in 

my case, I was trying to copy the Minecraft behavior of going fullscreen
at native resolution with F11. But here, when the app changes itself
its width and height, a VIDEORESIZE is generated.
Ah, and also, like I wrote in the doc: a VIDEORESIZE will be created at
the first SetVideoMode call
, which is even more unexpected.

Btw, I recently found a case where this new behavior makes sense :

It is when an user try to go fullscreen with a resolution which is not
supported by the device (640x480, 800x600, etc…).
When a call to SetVideoMode is done with inappropriate values with the
FULLSCREEN flag, SDL automatically gives the user a FULLSCREEN surface
with the closest dimensions to the ones asked. So the user could be
thinking that his surface has some dimensions whereas in reality they
have been corrected by SDL.
In 1.2.13 and 1.2.14 nothing tells the user his request couldn’t be
correctly executed (no error and the w and h fields of SDL_Surface stays
incorrect whereas the current resolution has been corrected).
In 1.2.15 however, a VIDEORESIZE is effectively triggered with the
corrected dimensions, in correspondence with the set resolution.

Remind that I tested this only on Windows 7 and in fact, the directx
driver is also concerned (Unlike I said in my first post), along with
windib one.

PS: Oh and also, please keep cool, everybody can tl;dr or misread, I’m
sure you R Manard didn’t want no harm :)> On Mon, Jul 16, 2012 at 4: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:

From my tests, in 1.2.15, each call to SetVideoMode _which has

Woops there was a problem with the link here it is:
http://bayfiles.com/file/h0ID/nvPwAZ/Document.rtf
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Document.rtf
Type: application/msword
Size: 2177 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120717/1b82e8ac/attachment.wiz

Please, I said “Either you forgot to mention this or”. So you didn’t
mention this. I advised this could be the case. Now that I know this is the
case, let’s see… ok. How about since we realize how it works we leave it
that way? I mean if we got this far without it being a big deal and since
we are so close to the next sdl release maybe we could simply let it slide?

If you read my review of the source code, you’d see that the first time the
window is shown, there is a SDL_VIDEORESIZE event sent without the window
being resized. Then his code calls SDL_SetVideoMode(), like a good SDL
program. This destroys the OpenGL context he just created with
SDL_InitVideo(). This is why he is asking for help in the first place!

My thinking was that this part was answered. Why rock the boat?

I guess my projects avoid any duplication of setting the video mode. Each
code cycle my project does has a basic directive like init, startup, run,
cleanup, or close. In code design I find that a big lump sum of
instructions that can be triggered from any cycle of execution is asking
for trouble when I write an app or game.
Don’t get me wrong. If people start showing up all over the place saying
their stuff is not right then no matter the issue it needs attention. How
many people does this issue effect? I guess only time will tell.On Tue, Jul 17, 2012 at 9:12 AM, Patrick Baggett <baggett.patrick at gmail.com>wrote:

R Manard,

Please, before you send emails that basically say “you didn’t read”, read
the context of the conversation first!

He wrote that when he gets an SDL_VIDEORESIZE event, he does call
SDL_SetVideoMode() in response to it. If you read my review of the source
code, you’d see that the first time the window is shown, there is a
SDL_VIDEORESIZE event sent without the window being resized. Then his code
calls SDL_SetVideoMode(), like a good SDL program. This destroys the OpenGL
context he just created with SDL_InitVideo(). This is why he is asking for
help in the first place! Furthermore, this behavior is apparently new
post-SDL 1.2.13, which makes it odd. Do you have anything to add to this
thread?

Patrick

On Mon, Jul 16, 2012 at 7:41 PM, R Manard <@R_Manard> wrote:

Can’t just change the size variables I believe. Gotta SDL_SetVideoMode
too. Either you forgot to mention this or you did not do it. Read the
manual is a mantra.

“When an SDL_VIDEORESIZE is recieved the window should be resized to the
new dimensions using SDL_SetVideoMode.”

On Mon, Jul 16, 2012 at 4:15 PM, Patrick Baggett < baggett.patrick at gmail.com> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> 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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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
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.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It seems that either the behavior needs to be corrected, documented, or
made consistent. In particular, what’s bothersome to just leaving alone is
in the original message:

When using 1.2.14, the SDL_VIDEORESIZE are only generated when the user
resize the window witch I think would be the correct behavior.
It is also correct using the directx driver.

So changing the video driver gets different results? I didn’t build SDL
with DX support, but that does seem odd that an output driver change should
change whether an event is sent to the application. Also, we haven’t yet
considered Linux/OS X. Do they have the same behavior? If not, why? I don’t
think we can put this issue to bed just yet – looks like there are a few
things more to examine. Can anyone help with this? Specifically, compile &
run the original test case with the DX driver, Linux, Mac OS + SDL 1.2.15
and report whether the same behavior occurs.

Patrick

On Wed, Jul 18, 2012 at 4:50 AM, R Manard wrote:

Please, I said “Either you forgot to mention this or”. So you didn’t
mention this. I advised this could be the case. Now that I know this is the
case, let’s see… ok. How about since we realize how it works we leave it
that way? I mean if we got this far without it being a big deal and since
we are so close to the next sdl release maybe we could simply let it slide?

If you read my review of the source code, you’d see that the first time
the window is shown, there is a SDL_VIDEORESIZE event sent without the
window being resized. Then his code calls SDL_SetVideoMode(), like a good
SDL program. This destroys the OpenGL context he just created with
SDL_InitVideo(). This is why he is asking for help in the first place!

My thinking was that this part was answered. Why rock the boat?

I guess my projects avoid any duplication of setting the video mode. Each
code cycle my project does has a basic directive like init, startup, run,
cleanup, or close. In code design I find that a big lump sum of
instructions that can be triggered from any cycle of execution is asking
for trouble when I write an app or game.
Don’t get me wrong. If people start showing up all over the place saying
their stuff is not right then no matter the issue it needs attention. How
many people does this issue effect? I guess only time will tell.

My take is that resizing the window and intensive OpenGL shouldn’t really
be mixed a whole lot.
In a gaming context, it’s usually just a case of setting the resolution and
opting into fullscreen/windowed mode. If this isn’t a game, then
reloading your OpenGL stuff (which I thought you had to do if the
resolution changed…could be wrong on that one) isn’t really a big deal,
and if it is a game, resizing the window doesn’t make a whole lot of sense
since you can end up with some really bizarre resolutions, which may or may
not be good for your game/app (since some of your textures may get
stretched or contorted in a strange way).

So it sort of boils down to whether or not it’s necessary to have a
user-resizable window. If it is, then you’ll have to reload your opengl
textures/objects after a resize (again, I’m pretty sure this was what the
programmer is supposed to do, I could have sworn I read that here on the
mailing list a year or two ago), and if not, then this isn’t a problem.

-AlexOn Wed, Jul 18, 2012 at 5:50 AM, R Manard wrote:

Please, I said “Either you forgot to mention this or”. So you didn’t
mention this. I advised this could be the case. Now that I know this is the
case, let’s see… ok. How about since we realize how it works we leave it
that way? I mean if we got this far without it being a big deal and since
we are so close to the next sdl release maybe we could simply let it slide?

If you read my review of the source code, you’d see that the first time
the window is shown, there is a SDL_VIDEORESIZE event sent without the
window being resized. Then his code calls SDL_SetVideoMode(), like a good
SDL program. This destroys the OpenGL context he just created with
SDL_InitVideo(). This is why he is asking for help in the first place!

My thinking was that this part was answered. Why rock the boat?

I guess my projects avoid any duplication of setting the video mode. Each
code cycle my project does has a basic directive like init, startup, run,
cleanup, or close. In code design I find that a big lump sum of
instructions that can be triggered from any cycle of execution is asking
for trouble when I write an app or game.
Don’t get me wrong. If people start showing up all over the place saying
their stuff is not right then no matter the issue it needs attention. How
many people does this issue effect? I guess only time will tell.
On Tue, Jul 17, 2012 at 9:12 AM, Patrick Baggett < baggett.patrick at gmail.com> wrote:

R Manard,

Please, before you send emails that basically say “you didn’t read”, read
the context of the conversation first!

He wrote that when he gets an SDL_VIDEORESIZE event, he does call
SDL_SetVideoMode() in response to it. If you read my review of the source
code, you’d see that the first time the window is shown, there is a
SDL_VIDEORESIZE event sent without the window being resized. Then his code
calls SDL_SetVideoMode(), like a good SDL program. This destroys the OpenGL
context he just created with SDL_InitVideo(). This is why he is asking for
help in the first place! Furthermore, this behavior is apparently new
post-SDL 1.2.13, which makes it odd. Do you have anything to add to this
thread?

Patrick

On Mon, Jul 16, 2012 at 7:41 PM, R Manard wrote:

Can’t just change the size variables I believe. Gotta SDL_SetVideoMode
too. Either you forgot to mention this or you did not do it. Read the
manual is a mantra.

“When an SDL_VIDEORESIZE is recieved the window should be resized to
the new dimensions using SDL_SetVideoMode.”

On Mon, Jul 16, 2012 at 4:15 PM, Patrick Baggett < baggett.patrick at gmail.com> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> 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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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
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.org


SDL mailing list
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.org

@Patrick: In fact, the behavior is the same with the DirectX driver, I
got a bit confused.

@Barry: Since 1.2.14, October 20, 2009, the loss of OpenGL context when
setting the video mode in response to a window resize event has
disappears on Windows.
This works even when resetting the video mode without RESIZE event, but
not when going/exiting FULLSCREEN.

But really, this OpenGL context problem I talked about is not the real
problem I came to describe, it was just a bad consequence in my
particular way of doing things.

Well it seems I found something that occurs during 1.2.14 -> 1.2.15 period:


http://bugzilla.libsdl.org/show_bug.cgi?id=1117

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>wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> 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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

PatrickOn Wed, Jul 18, 2012 at 3:17 PM, Sam Lantinga 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 < @Patrick_Baggett> wrote:

On Wed, Jul 11, 2012 at 12:46 PM, D’Archivio Thibault < thibault.darchivio at free.fr> 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 :stuck_out_tongue:


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://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 :slight_smile:

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
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.org