SDL_PollEvent() with an offscreen render target

SDL Development
1

Hi,

is SDL_PollEvent() only supposed to be used with the window being the current
render target?

I’ve noticed that in case an offscreen texture is the current render target
SDL_PollEvent() can do quite some strange things to the renderer. For example,
if the user resizes the window while an offscreen texture is the current
render target, the window’s viewport dimensions will not be adapted automatically.
Instead, SDL probably adapts some parameters concerning the offscreen rendering
to the texture but IMHO it doesn’t really make sense to take updated window
dimensions and apply them to the offscreen texture… they should be applied to
the window instead.

This behaviour can cause quite some confusion because in that case you’d have
to call SDL_RenderSetViewport() manually although this is normally done automatically
by the event handler on window resize.

I am attaching a small demo program which shows the issue. You can see that
the viewport coordinates aren’t adapted correctly in case SDL_PollEvent() is
called while an offscreen texture is selected as the render target (SDL_RenderCopy
in line 101 is supposed to scale the offscreen texture to the window dimensions
but it doesn’t do it because the viewport coordinates haven’t been updated.)

If SDL_PollEvent() can’t deal with render targets other than the window I
think this should be mentioned both in the docs of SDL_PollEvent() and SDL_SetRenderTarget().–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn
-------------- next part --------------
A non-text attachment was scrubbed…
Name: test.c
Type: application/octet-stream
Size: 3067 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140815/f6a00ea9/attachment.obj

2

Can you try with the latest SDL snapshot? I fixed something that could
cause this a few weeks ago:
http://www.libsdl.org/tmp/SDL-2.0.zip

Thanks!On Fri, Aug 15, 2014 at 6:39 AM, Andreas Falkenhahn wrote:

Hi,

is SDL_PollEvent() only supposed to be used with the window being the
current
render target?

I’ve noticed that in case an offscreen texture is the current render target
SDL_PollEvent() can do quite some strange things to the renderer. For
example,
if the user resizes the window while an offscreen texture is the current
render target, the window’s viewport dimensions will not be adapted
automatically.
Instead, SDL probably adapts some parameters concerning the offscreen
rendering
to the texture but IMHO it doesn’t really make sense to take updated window
dimensions and apply them to the offscreen texture… they should be
applied to
the window instead.

This behaviour can cause quite some confusion because in that case you’d
have
to call SDL_RenderSetViewport() manually although this is normally done
automatically
by the event handler on window resize.

I am attaching a small demo program which shows the issue. You can see that
the viewport coordinates aren’t adapted correctly in case SDL_PollEvent()
is
called while an offscreen texture is selected as the render target
(SDL_RenderCopy
in line 101 is supposed to scale the offscreen texture to the window
dimensions
but it doesn’t do it because the viewport coordinates haven’t been
updated.)

If SDL_PollEvent() can’t deal with render targets other than the window I
think this should be mentioned both in the docs of SDL_PollEvent() and
SDL_SetRenderTarget().

–
Best regards,
Andreas Falkenhahn mailto:andreas at falkenhahn.com

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

3

Can you try with the latest SDL snapshot? I fixed something that could cause this a few weeks ago:
http://www.libsdl.org/tmp/SDL-2.0.zip

I can try but CMakeLists.txt needs to be fixed first. This is what I get:

CMake Error at CMakeLists.txt:1246 (add_library):
Cannot find source file:

d:/temp/SDL2-2.0.3-9063/src/joystick/windows/SDL_dxjoystick.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txxOn 16.08.2014 at 21:40 Sam Lantinga wrote:

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

4

I think this fixes it, can you try it?

This fix is in the latest snapshot now.On Sat, Aug 16, 2014 at 2:42 PM, Andreas Falkenhahn wrote:

On 16.08.2014 at 21:40 Sam Lantinga wrote:

Can you try with the latest SDL snapshot? I fixed something that could
cause this a few weeks ago:
http://www.libsdl.org/tmp/SDL-2.0.zip

I can try but CMakeLists.txt needs to be fixed first. This is what I get:

CMake Error at CMakeLists.txt:1246 (add_library):
Cannot find source file:

d:/temp/SDL2-2.0.3-9063/src/joystick/windows/SDL_dxjoystick.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

5

CMake works fine now but it stops compiling at SDL_directsound.c:

d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(36) : error C2016: C requires that a struct or union has at least one member
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(36) : error C2061: syntax error : identifier 'LPDIRECTSOUND’
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(37) : error C2061: syntax error : identifier 'mixbuf’
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(37) : error C2059: syntax error : ';'
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(42) : error C2059: syntax error : '}'
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) : error C2143: syntax error : missing ‘)’ before ''
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) : error C2081: ‘LPDIRECTSOUND’ : name in formal parameter list illegal
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) : error C2143: syntax error : missing ‘{’ before ''
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) : error C2059: syntax error : ','
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) : error C2059: syntax error : ')'
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(42) : error C2061: syntax error : identifier 'pDirectSoundCreate8’
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(42) : error C2059: syntax error : ‘;’
…followed by many more errors…On 17.08.2014 at 00:20 Sam Lantinga wrote:

I think this fixes it, can you try it?
https://hg.libsdl.org/SDL/rev/98d13a381299

This fix is in the latest snapshot now.

On Sat, Aug 16, 2014 at 2:42 PM, Andreas Falkenhahn <@Andreas_Falkenhahn> wrote:

On 16.08.2014 at 21:40 Sam Lantinga wrote:

Can you try with the latest SDL snapshot? I fixed something that could cause this a few weeks ago:
http://www.libsdl.org/tmp/SDL-2.0.zip

I can try but CMakeLists.txt needs to be fixed first. This is what I get:

CMake Error at CMakeLists.txt:1246 (add_library):
Cannot find source file:

 d:/temp/SDL2-2.0.3-9063/src/joystick/windows/SDL_dxjoystick.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

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

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

6

I don’t have that build environment, so you’ll have to debug it yourself.
If you’re stuck, try just disabling audio for the test.On Sat, Aug 16, 2014 at 3:31 PM, Andreas Falkenhahn wrote:

CMake works fine now but it stops compiling at SDL_directsound.c:

d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(36) :
error C2016: C requires that a struct or union has at least one member
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(36) :
error C2061: syntax error : identifier 'LPDIRECTSOUND’
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(37) :
error C2061: syntax error : identifier 'mixbuf’
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(37) :
error C2059: syntax error : ';'
d:\temp\sdl2-2.0.3-9073\src\audio\directsound\SDL_directsound.h(42) :
error C2059: syntax error : '}'
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) :
error C2143: syntax error : missing ‘)’ before ''
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) :
error C2081: ‘LPDIRECTSOUND’ : name in formal parameter list illegal
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) :
error C2143: syntax error : missing ‘{’ before ''
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) :
error C2059: syntax error : ','
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(39) :
error C2059: syntax error : ')'
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(42) :
error C2061: syntax error : identifier 'pDirectSoundCreate8’
d:\temp\SDL2-2.0.3-9073\src\audio\directsound\SDL_directsound.c(42) :
error C2059: syntax error : ‘;’
…followed by many more errors…

On 17.08.2014 at 00:20 Sam Lantinga wrote:

I think this fixes it, can you try it?
https://hg.libsdl.org/SDL/rev/98d13a381299

This fix is in the latest snapshot now.

On Sat, Aug 16, 2014 at 2:42 PM, Andreas Falkenhahn < andreas at falkenhahn.com> wrote:

On 16.08.2014 at 21:40 Sam Lantinga wrote:

Can you try with the latest SDL snapshot? I fixed something that could
cause this a few weeks ago:

http://www.libsdl.org/tmp/SDL-2.0.zip

I can try but CMakeLists.txt needs to be fixed first. This is what I
get:

CMake Error at CMakeLists.txt:1246 (add_library):
Cannot find source file:

 d:/temp/SDL2-2.0.3-9063/src/joystick/windows/SDL_dxjoystick.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm
.hpp
.hxx .in .txx

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

7

I don’t have that build environment, so you’ll have to debug it
yourself.

Well, it’s just Windows SDK, Direct X SDK, Visual C, CMake and a shell. Nothing special,
really. The latest release SDL 2.0.3 builds fine on my setup. It’s just the snapshot
that doesn’t build so this should be fixed in the CVS.

It seems that HAVE_DSOUND_H and HAVE_DINPUT_H aren’t defined leading to dsound.h and
dinput.h not getting included. After defining these constants, it compiles fine.

Back on topic: The issue I reported isn’t gone with 2.0.3-9073. It behaves in exactly
the same way. Please try the very small demo program I sent in my first mail on this
topic. It is very easily reproducable as it happens every time. SDL will never adapt
the viewport dimensions on window resize in case an offscreen texture is the current
render target.On 17.08.2014 at 03:52 Sam Lantinga wrote:

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

8

Your sample code gives missing symbol errors for Get(R/G/B)Value.

After defining them to some macros (no idea how they are intended to
work), i could confirm it on Mac OS 10.6 with SDL 2.0.3 and the latest
HG snapshot (9086:22232029f074)Am 17.08.2014 21:03, schrieb Andreas Falkenhahn:

On 17.08.2014 at 03:52 Sam Lantinga wrote:

I don’t have that build environment, so you’ll have to debug it
yourself.

Well, it’s just Windows SDK, Direct X SDK, Visual C, CMake and a
shell. Nothing special,
really. The latest release SDL 2.0.3 builds fine on my setup. It’s
just the snapshot
that doesn’t build so this should be fixed in the CVS.

It seems that HAVE_DSOUND_H and HAVE_DINPUT_H aren’t defined leading
to dsound.h and
dinput.h not getting included. After defining these constants, it
compiles fine.

Back on topic: The issue I reported isn’t gone with 2.0.3-9073. It
behaves in exactly
the same way. Please try the very small demo program I sent in my
first mail on this
topic. It is very easily reproducable as it happens every time. SDL
will never adapt
the viewport dimensions on window resize in case an offscreen texture
is the current
render target.

9

Is DXSDK_DIR set in the environment? It seems like this ought to work:

set(CMAKE_REQUIRED_FLAGS "/I\"$ENV{DXSDK_DIR}\\Include\"")

check_include_file(d3d9.h HAVE_D3D_H)

check_include_file(d3d11_1.h HAVE_D3D11_H)

check_include_file(ddraw.h HAVE_DDRAW_H)

check_include_file(dsound.h HAVE_DSOUND_H)

check_include_file(dinput.h HAVE_DINPUT_H)On Sun, Aug 17, 2014 at 12:03 PM, Andreas Falkenhahn <andreas at falkenhahn.com wrote:

On 17.08.2014 at 03:52 Sam Lantinga wrote:

I don’t have that build environment, so you’ll have to debug it
yourself.

Well, it’s just Windows SDK, Direct X SDK, Visual C, CMake and a shell.
Nothing special,
really. The latest release SDL 2.0.3 builds fine on my setup. It’s just
the snapshot
that doesn’t build so this should be fixed in the CVS.

It seems that HAVE_DSOUND_H and HAVE_DINPUT_H aren’t defined leading to
dsound.h and
dinput.h not getting included. After defining these constants, it compiles
fine.

Back on topic: The issue I reported isn’t gone with 2.0.3-9073. It behaves
in exactly
the same way. Please try the very small demo program I sent in my first
mail on this
topic. It is very easily reproducable as it happens every time. SDL will
never adapt
the viewport dimensions on window resize in case an offscreen texture is
the current
render target.

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

10

This is fixed, thanks!
https://hg.libsdl.org/SDL/rev/a8cbb653aea4On Fri, Aug 15, 2014 at 6:39 AM, Andreas Falkenhahn wrote:

Hi,

is SDL_PollEvent() only supposed to be used with the window being the
current
render target?

I’ve noticed that in case an offscreen texture is the current render target
SDL_PollEvent() can do quite some strange things to the renderer. For
example,
if the user resizes the window while an offscreen texture is the current
render target, the window’s viewport dimensions will not be adapted
automatically.
Instead, SDL probably adapts some parameters concerning the offscreen
rendering
to the texture but IMHO it doesn’t really make sense to take updated window
dimensions and apply them to the offscreen texture… they should be
applied to
the window instead.

This behaviour can cause quite some confusion because in that case you’d
have
to call SDL_RenderSetViewport() manually although this is normally done
automatically
by the event handler on window resize.

I am attaching a small demo program which shows the issue. You can see that
the viewport coordinates aren’t adapted correctly in case SDL_PollEvent()
is
called while an offscreen texture is selected as the render target
(SDL_RenderCopy
in line 101 is supposed to scale the offscreen texture to the window
dimensions
but it doesn’t do it because the viewport coordinates haven’t been
updated.)

If SDL_PollEvent() can’t deal with render targets other than the window I
think this should be mentioned both in the docs of SDL_PollEvent() and
SDL_SetRenderTarget().

–
Best regards,
Andreas Falkenhahn mailto:andreas at falkenhahn.com

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

11

Is DXSDK_DIR set in the environment? It seems like this ought to work:

Yes, it is there:

PS C:\Users\andreas> echo $env:DXSDK_DIR
C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\

And as I said, there are no such building problems with the official 2.0.3
from libsdl.org. It only happens with the work snapshot.On 17.08.2014 at 22:52 Sam Lantinga wrote:

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

12

Thanks. Have you seen my other mail titled “Refresh trouble with SDL_WINDOWEVENT_EXPOSED”?
This could also be a bug. And there’s also a very short test case attached ;)On 17.08.2014 at 23:35 Sam Lantinga wrote:

This is fixed, thanks!
https://hg.libsdl.org/SDL/rev/a8cbb653aea4

On Fri, Aug 15, 2014 at 6:39 AM, Andreas Falkenhahn <@Andreas_Falkenhahn> wrote:

Hi,

is SDL_PollEvent() only supposed to be used with the window being the current
render target?

I’ve noticed that in case an offscreen texture is the current render target
SDL_PollEvent() can do quite some strange things to the renderer. For example,
if the user resizes the window while an offscreen texture is the current
render target, the window’s viewport dimensions will not be adapted automatically.
Instead, SDL probably adapts some parameters concerning the offscreen rendering
to the texture but IMHO it doesn’t really make sense to take updated window
dimensions and apply them to the offscreen texture… they should be applied to
the window instead.

This behaviour can cause quite some confusion because in that case you’d have
to call SDL_RenderSetViewport() manually although this is normally done automatically
by the event handler on window resize.

I am attaching a small demo program which shows the issue. You can see that
the viewport coordinates aren’t adapted correctly in case SDL_PollEvent() is
called while an offscreen texture is selected as the render target (SDL_RenderCopy
in line 101 is supposed to scale the offscreen texture to the window dimensions
but it doesn’t do it because the viewport coordinates haven’t been updated.)

If SDL_PollEvent() can’t deal with render targets other than the window I
think this should be mentioned both in the docs of SDL_PollEvent() and SDL_SetRenderTarget().

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

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

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

13

Can you report it as a bug in bugzilla so it doesn’t get lost in e-mail?

Thanks!On Mon, Aug 18, 2014 at 1:47 PM, Andreas Falkenhahn wrote:

Thanks. Have you seen my other mail titled “Refresh trouble with
SDL_WINDOWEVENT_EXPOSED”?
This could also be a bug. And there’s also a very short test case attached
:wink:

On 17.08.2014 at 23:35 Sam Lantinga wrote:

This is fixed, thanks!
https://hg.libsdl.org/SDL/rev/a8cbb653aea4

On Fri, Aug 15, 2014 at 6:39 AM, Andreas Falkenhahn < andreas at falkenhahn.com> wrote:

Hi,

is SDL_PollEvent() only supposed to be used with the window being the
current
render target?

I’ve noticed that in case an offscreen texture is the current render
target
SDL_PollEvent() can do quite some strange things to the renderer. For
example,
if the user resizes the window while an offscreen texture is the current
render target, the window’s viewport dimensions will not be adapted
automatically.
Instead, SDL probably adapts some parameters concerning the offscreen
rendering
to the texture but IMHO it doesn’t really make sense to take updated
window
dimensions and apply them to the offscreen texture… they should be
applied to
the window instead.

This behaviour can cause quite some confusion because in that case
you’d have
to call SDL_RenderSetViewport() manually although this is normally done
automatically
by the event handler on window resize.

I am attaching a small demo program which shows the issue. You can see
that
the viewport coordinates aren’t adapted correctly in case
SDL_PollEvent() is
called while an offscreen texture is selected as the render target
(SDL_RenderCopy
in line 101 is supposed to scale the offscreen texture to the window
dimensions
but it doesn’t do it because the viewport coordinates haven’t been
updated.)

If SDL_PollEvent() can’t deal with render targets other than the window
I
think this should be mentioned both in the docs of SDL_PollEvent() and
SDL_SetRenderTarget().

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

14

I’m not sure why this wouldn’t work. Can you debug it in your environment?On Mon, Aug 18, 2014 at 1:46 PM, Andreas Falkenhahn wrote:

On 17.08.2014 at 22:52 Sam Lantinga wrote:

Is DXSDK_DIR set in the environment? It seems like this ought to work:

Yes, it is there:

PS C:\Users\andreas> echo $env:DXSDK_DIR
C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\

And as I said, there are no such building problems with the official 2.0.3
from libsdl.org. It only happens with the work snapshot.

–
Best regards,
Andreas Falkenhahn mailto:
andreas at falkenhahn.com

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

15

Done:
https://bugzilla.libsdl.org/show_bug.cgi?id=2725On 20.08.2014 at 07:10 Sam Lantinga wrote:

Can you report it as a bug in bugzilla so it doesn’t get lost in e-mail?

Thanks!

On Mon, Aug 18, 2014 at 1:47 PM, Andreas Falkenhahn <@Andreas_Falkenhahn> wrote:

Thanks. Have you seen my other mail titled “Refresh trouble with SDL_WINDOWEVENT_EXPOSED”?
This could also be a bug. And there’s also a very short test case attached :wink:

On 17.08.2014 at 23:35 Sam Lantinga wrote:

This is fixed, thanks!
https://hg.libsdl.org/SDL/rev/a8cbb653aea4

On Fri, Aug 15, 2014 at 6:39 AM, Andreas Falkenhahn <@Andreas_Falkenhahn> wrote:

Hi,

is SDL_PollEvent() only supposed to be used with the window being the current
render target?

I’ve noticed that in case an offscreen texture is the current render target
SDL_PollEvent() can do quite some strange things to the renderer. For example,
if the user resizes the window while an offscreen texture is the current
render target, the window’s viewport dimensions will not be adapted automatically.
Instead, SDL probably adapts some parameters concerning the offscreen rendering
to the texture but IMHO it doesn’t really make sense to take updated window
dimensions and apply them to the offscreen texture… they should be applied to
the window instead.

This behaviour can cause quite some confusion because in that case you’d have
to call SDL_RenderSetViewport() manually although this is normally done automatically
by the event handler on window resize.

I am attaching a small demo program which shows the issue. You can see that
the viewport coordinates aren’t adapted correctly in case SDL_PollEvent() is
called while an offscreen texture is selected as the render target (SDL_RenderCopy
in line 101 is supposed to scale the offscreen texture to the window dimensions
but it doesn’t do it because the viewport coordinates haven’t been updated.)

If SDL_PollEvent() can’t deal with render targets other than the window I
think this should be mentioned both in the docs of SDL_PollEvent() and SDL_SetRenderTarget().

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

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

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

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

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

16

I’ve found some time to debug this now and it seems that there is some conflict in the way
SDL_config.h is included from the SDL source files.

Let me first clarify how I build SDL. The way I build SDL on Windows is this:

$ mkdir build_win32
$ cd build_win32
$ cmake … -DCMAKE_BUILD_TYPE=Release
$ nmake

Doing it like this results in many many errors because the DirectX headers are not
included correctly. Also note the official 2.0.3 release builds fine, the problems
only occurs with the latest snapshot from http://www.libsdl.org/tmp/SDL-2.0.zip

So here’s my diagnosis of the problem:

I’m not sure whether this is intended or not but running cmake like above leaves me
with two different copies of SDL_config.h: One is inside “build_win32/include” and the
other one is in “include”.

The trouble now starts because “build_win32/include/SDL_config.h” does not include
the OS headers. This is only done by “include/SDL_config.h”. “include/SDL_config.h”,
however, is only included in case a header file that is in the “include” directory
issue a

#include “SDL_config.h”

preprocessor statement. All other statements of

#include “SDL_config.h”

will fall back to the copy in “build_win32/include” because this directory is in
the include path but as I said above, the SDL_config.h in "build_win32/include"
doesn’t include any OS headers which leads to lots of errors when trying to build
it.

I think this needs a fix. There should really be only a single copy of SDL_config.h
around and not entirely two different copies that seem to be included rather arbitrarily
(i.e. SDL_assert.h will include the SDL_config.h inside “include” whereas SDL_internal.h
would include the SDL_config.h inside “build_win32/include”). To complete the
confusion, both copies share a single #define name, namely #define _SDL_config_h
This has the effect that “include/SDL_config.h” won’t be included at all if
"build_win32/include/SDL_config.h" has already been included although the two
files are not the same. So this really should be fixed.

Furthermore, I’d suggest to always use

#include <SDL_config.h>

to make it clear that the header is not to be loaded from the current directory
but from a directory that has been added to the paths of include files. Then it is
really clear that SDL_config.h is always loaded from the platform dependent include
directory and not from the current directory. Currently, the following headers will
load SDL_config.h from the current directory:

include/SDL_assert.h
include/SDL_opengl.h
include/SDL_stdinc.h

I think it is good programming practice to use brackets instead of quotes to indicate
that the header is meant to be loaded from a system dependent directory instead of
the current one.On 20.08.2014 at 07:10 Sam Lantinga wrote:

I’m not sure why this wouldn’t work. Can you debug it in your environment?

On Mon, Aug 18, 2014 at 1:46 PM, Andreas Falkenhahn <@Andreas_Falkenhahn> wrote:

On 17.08.2014 at 22:52 Sam Lantinga wrote:

Is DXSDK_DIR set in the environment? It seems like this ought to work:

Yes, it is there:

PS C:\Users\andreas> echo $env:DXSDK_DIR
C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\

And as I said, there are no such building problems with the official 2.0.3
from libsdl.org. It only happens with the work snapshot.

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn

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

–
Best regards,
Andreas Falkenhahn mailto:@Andreas_Falkenhahn