[SDL] SDL_PollEvent() with an offscreen render target

Andreas Falkenhahn andreas at falkenhahn.com
Tue Sep 9 10:33:11 PDT 2014

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

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:


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 at falkenhahn.com> 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

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

More information about the SDL mailing list