I’m currently trying to port ASC to Windows using Watcom C/C++. The
problem I have is that quite a lot of things that are usually handled
by Windows and SDL without having to care about don’t work when I’m
calling SDL_PollEvent from a second thread. These things include:
moving the window around
pressing the icons in the title bar
redrawing the window if I move it from background to foreground
Why is this happening? The technique of processing all events in a
second thread works fine under Linux.
I’m now thinking about swapping the threads, just processing the events
in the original one and running the game in a second one…
And I’ve got another problem: Moving the mouse leaves nasty graphical
artefacts on the screen when running the game (which uses 8 bit color)
fullscreen under Win98. It reminds me of the old DOS times where I have
to switch the mouse off each time I’m updating something on the screen.
Why isn’t SDL using a hardware mouse cursor?
Since I haven’t succeeded in (and have given up trying…) compiling
SDL.DLL with Watcom myself,
I’m using the precompiled one from the SDL homepage ( version 1.1.5 ).
I’m currently trying to port ASC to Windows using Watcom C/C++. The
problem I have is that quite a lot of things that are usually handled
by Windows and SDL without having to care about don’t work when I’m
calling SDL_PollEvent from a second thread. These things include:
moving the window around
pressing the icons in the title bar
redrawing the window if I move it from background to foreground
Why is this happening? The technique of processing all events in a
second thread works fine under Linux.
I’m now thinking about swapping the threads, just processing the events
in the original one and running the game in a second one…
As far as I remember (correct me, if I’m wrong) uses windows a thread
orientented management of windows. This means, if you create a window
in a thread and this thread ends, the window is destroyed, too. I really
would suggest to do, as you said, because it would be necessary to "move"
the input bindings to the other thread. The window is simply not visible for
the other thread. The message processing of windows is based on a
slightly different idea than X-Windows and SDL follows more these concepts.
Not much of help, but should be clarifying.
Why is this happening? The technique of processing all events in a
second thread works fine under Linux.
I’m now thinking about swapping the threads, just processing the events
in the original one and running the game in a second one…
As explained in the other message, there’s no way of accessing the
event queue for the window from another thread, or transferring ownership
of the window to another thread (if this isn’t the case, PLEASE let know!
And I’ve got another problem: Moving the mouse leaves nasty graphical
artefacts on the screen when running the game (which uses 8 bit color)
fullscreen under Win98. It reminds me of the old DOS times where I have
to switch the mouse off each time I’m updating something on the screen.
Why isn’t SDL using a hardware mouse cursor?
Fullscreen DirectX usually doesn’t give you access to the mouse cursor.
This is nominally a bug, but I don’t have any fix offhand, since both
you and the mouse code are drawing directly to hardware memory.
Since I haven’t succeeded in (and have given up trying…) compiling
SDL.DLL with Watcom myself,
I’m using the precompiled one from the SDL homepage ( version 1.1.5 ).
Somebody reported that they were able to do this with a packing change
in begin_code.h. I added the code to do this to CVS.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’m currently trying to port ASC to Windows using Watcom C/C++. The
problem I have is that quite a lot of things that are usually handled
by Windows and SDL without having to care about don’t work when I’m
calling SDL_PollEvent from a second thread. […]
As far as I remember (correct me, if I’m wrong) uses windows a thread
orientented management of windows. This means, if you create a window
in a thread and this thread ends, the window is destroyed, too. I really
would suggest to do, as you said, because it would be necessary to "move"
the input bindings to the other thread.
I’ve swapped the game- and event-threads and now everything works
perfectly.
Bye,
MartinOn Wed, 18 Oct 2000 01:16:33 +0200, Andreas Podgurski wrote:
And I’ve got another problem: Moving the mouse leaves nasty graphical
artefacts on the screen when running the game (which uses 8 bit color)
fullscreen under Win98. It reminds me of the old DOS times where I have
to switch the mouse off each time I’m updating something on the screen.
Why isn’t SDL using a hardware mouse cursor?
Fullscreen DirectX usually doesn’t give you access to the mouse cursor.
This is nominally a bug, but I don’t have any fix offhand, since both
you and the mouse code are drawing directly to hardware memory.
I’m now hiding the mouse cursor each time I’m updating the screen: #ifdefWIN32
SDL_ShowCursor(0); #endif
SDL_UpdateRect ( screen , 0,0,0,0 ); #ifdefWIN32
SDL_ShowCursor(1); #endif
Not an elegant solution, but it works. Couldn’t this be done by SDL
itself?
If I was able to compile SDL.DLL myself with Watcom, I’d take a look at
it. But, as I already wrote, I haven’t succeeded in doing so…
Since I haven’t succeeded in (and have given up trying…) compiling
SDL.DLL with Watcom myself,
I’m using the precompiled one from the SDL homepage ( version 1.1.5 ).
Somebody reported that they were able to do this with a packing change
in begin_code.h. I added the code to do this to CVS.
That was me
But the patch was just to use the SDL include files with Watcom, not
for compiling the DLL. Else I would have send project files as well.
Bye,
MartinOn Tue, 17 Oct 2000 16:46:05 -0700, Sam Lantinga wrote:
Since I haven’t succeeded in (and have given up trying…) compiling
SDL.DLL with Watcom myself,
I’m using the precompiled one from the SDL homepage ( version 1.1.5 ).
This isn;t specific to your problem but you should really get rid of SDL
1.1.5, it is very buggy.
