Windows full screen and mouse messages

I’m having a little problem with event processing. When my game is in
full screen mode using the DX5 driver, the WindowProc doesn’t seem to be
getting mouse move events.

Let me be a little more specific. After the game starts, I use
GetWindowLong() and SetWindowLong() to point to my own WindowProc. This
WindowProc, in turn, calls the SDL WindowProc. But in some cases I pass
the window messages to another function (a purchasing system developed
by a 3rd party).

It works just fine in windowed mode, but no mouse-related messages are
received when the game is in full screen mode. I still get WM_KEYUP and
WM_KEYDOWN messages though.

Reading through the sources, I’ve found comments about the input being
processed by DirectInput instead of the windows queue.

So, the questions - how do I make this work? I think I could process the
SDL mouse move/click events and post “fake” Windows messages but this
solution is quite ugly…

Thanks,
–Gabriel

An update - it’s even more weird. If I press a key, I start getting
mouse messages again, even in fullscreen mode.> ----- Original Message -----

From: Gabriel Gambetta
Sent: Jueves, 16 de Septiembre de 2004 03:39 p.m.
To: sdl at libsdl.org
Subject: [SDL] Windows full screen and mouse messages

I’m having a little problem with event processing. When my game is in
full screen mode using the DX5 driver, the WindowProc doesn’t seem to be
getting mouse move events.

Let me be a little more specific. After the game starts, I use
GetWindowLong() and SetWindowLong() to point to my own WindowProc. This
WindowProc, in turn, calls the SDL WindowProc. But in some cases I pass
the window messages to another function (a purchasing system developed
by a 3rd party).

It works just fine in windowed mode, but no mouse-related messages are
received when the game is in full screen mode. I still get WM_KEYUP and
WM_KEYDOWN messages though.

Reading through the sources, I’ve found comments about the input being
processed by DirectInput instead of the windows queue.

So, the questions - how do I make this work? I think I could process the
SDL mouse move/click events and post “fake” Windows messages but this
solution is quite ugly…

Thanks,
–Gabriel


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

You can force GDI usage by setting the SDL_VIDEODRIVER environment variable
to “windib”, e.g. call _putenv(“SDL_VIDEODRIVER=windib”) before you
call SDL_Init().
Note that this might impact your performance.

  • AndreasOn Thu, 16 Sep 2004 15:38:59 -0300, Gabriel Gambetta wrote:

Reading through the sources, I’ve found comments about the input being
processed by DirectInput instead of the windows queue.

You can force GDI usage by setting the SDL_VIDEODRIVER
environment variable to “windib”, e.g. call
_putenv(“SDL_VIDEODRIVER=windib”) before you
call SDL_Init().
Note that this might impact your performance.

I know, but that’s not a viable option, precisely for performance
reason. This thingy (http://www.mysterystudio.com/info.php?id=bbb) does
lots of alpha blending and the WinDib driver probably won’t cut it…

Thanks

--Gabriel

You can force GDI usage by setting the SDL_VIDEODRIVER
environment variable to “windib”, e.g. call
_putenv(“SDL_VIDEODRIVER=windib”) before you
call SDL_Init().
Note that this might impact your performance.

I know, but that’s not a viable option, precisely for performance
reason. This thingy (http://www.mysterystudio.com/info.php?id=bbb) does
lots of alpha blending and the WinDib driver probably won’t cut it…

IIUC, alpha blending is done in software by SDL anyway, so the difference
may not be that big.

BrunoOn Fri, 17 Sep 2004 10:16:06 -0300, Gabriel Gambetta wrote:

So, the questions - how do I make this work? I think I could process
the
SDL mouse move/click events and post “fake” Windows messages but this
solution is quite ugly…

Seems like a good idea to me. Can’t you just craft your own window
messages and send them to your application by receiving DirectInput
mouse input events via the SDL event queue? I will agree that it does
SOUND very hairy, but in implementation I bet it won’t be as difficult
or ugly as you’d think. In either case… suck it up! You chose windows
as your development platform; one way or another, we all pay for our
mistakes…On Sep 16, 2004, at 2:38 PM, Gabriel Gambetta wrote:

I will agree that it does SOUND very hairy, but in implementation I bet
it won’t be as difficult or ugly as you’d think.

I did, and it worked fine.

In either case… suck it up! You chose windows as your development
platform; one way or another, we all pay for our mistakes…

Hey, are you trying to over-zealot me??? :slight_smile:

I’d NEVER use Windows as a development platform. Everything you see in http://www.mysterystudio.com is developed on Linux and cross-compiled to Windows using MinGW32. The installers are made from the command line version of NSIS, which works fine under WINE.

But the truth is that most casual gamers (our customers) use Windows…

–Gabriel> -----Original Message-----

From: Donny Viszneki [mailto:smirk at thebuicksix.com]

Bruno Mart?nez Aguerre wrote:> On Fri, 17 Sep 2004 10:16:06 -0300, Gabriel Gambetta wrote:

You can force GDI usage by setting the SDL_VIDEODRIVER
environment variable to “windib”, e.g. call
_putenv(“SDL_VIDEODRIVER=windib”) before you
call SDL_Init().
Note that this might impact your performance.

I know, but that’s not a viable option, precisely for performance
reason. This thingy (http://www.mysterystudio.com/info.php?id=bbb) does
lots of alpha blending and the WinDib driver probably won’t cut it…

IIUC, alpha blending is done in software by SDL anyway, so the
difference may not be that big.

… or sometimes negative, given that alpha blending nead a read-write
cycle which is slower when happening on hardware surfaces.

(note that no video backend currently supports alpha blending in
hardware, but this might change in the future. The only way to tell is
to look at the acceleration flags you get from SDL_GetVideoInfo)

Stephane