SDL :: View topic - SDL_PollEvent() with an offscreen render target

SDL
Simple Directmedia Layer Forums

SDL_PollEvent() with an offscreen render target

Andreas Falkenhahn

Guest

Posted: Tue Sep 09, 2014 4:27 pm

Done:
https://bugzilla.libsdl.org/show_bug.cgi?id=2725

On 20.08.2014 at 07:10 Sam Lantinga wrote:

Quote:

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

Quote:

Thanks!

Quote:

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

Quote:

On 17.08.2014 at 23:35 Sam Lantinga wrote:

Quote:

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

Quote:

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

Quote:

Hi,

Quote:

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

Quote:

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.

Quote:

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.

Quote:

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

Quote:

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().

Quote:

--
Best regards,
Andreas Falkenhahn mailto:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Quote:

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL_PollEvent() with an offscreen render target

Andreas Falkenhahn

Guest

Posted: Tue Sep 09, 2014 5:32 pm

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:

Quote:

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

Quote:

On Mon, Aug 18, 2014 at 1:46 PM, Andreas Falkenhahn wrote:

On 17.08.2014 at 22:52 Sam Lantinga wrote:

Quote:

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.

Quote:

--
Best regards,
Andreas Falkenhahn mailto:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The SDL forums have moved to discourse.libsdl.org. This is just a read-only archive of the previous forums, to keep old links working.

The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.