author Sam Lantinga <>
Thu, 02 Apr 2009 04:43:36 +0000
changeset 4167 a6f635e5eaa6
parent 1888 488eba319a25
child 3568 8c72321542f6
child 12987 ad20a4424a57
permissions -rw-r--r--
Fixed bug #611

From Tim Angus 2008-08-12 11:18:06

I'm one of the maintainers of, an updated version of the
Quake 3 engine. Relatively recently, we moved ioq3 to use SDL as a
replacement for 95% of the platform specific code that was there. On the
whole it's doing a great job but unfortunately since the move we've been
getting complaints about the quality of the mouse input on the Windows
platform to the point where for many the game is unplayable. Put in
other terms, the current stable SDL 1.2 is basically not fit for purpose
if you need high quality mouse input as you do in a first person shooter.

Over the weekend I decided to pull my finger out and actually figure out
what's going on. There are basically two major problems. Firstly, when
using the "windib" driver, mouse input is gathered via the WM_MOUSEMOVE
message. Googling for this indicates that often this is known to result
in "spurious" and/or "missing" mouse movement events; this is the
primary cause of the poor mouse input. The second problem is that the
"directx" driver does not work at all in combination with OpenGL meaning
that you can't use DirectInput if your application also uses OpenGL. In
other words you're locked into using the "windib" driver and its poor
mouse input.

In order to address these problems I've done the following:

* Remove WM_MOUSEMOVE based motion event generation and replace with
calls to GetCursorPos which seems much more reliable. In order to
achieve this I've moved mouse motion out into a separate function that
is called once per DIB_PumpEvents.

* Remove the restriction on the "directx" driver being inoperable in
combination with OpenGL. There is a bug for this issues that I've
hijacked to a certain extent
( I'm the first to admit
I don't really understand why this restriction is there in the first
place. The commit message for the bug fix that introduced this
restriction (r581) isn't very elaborate and I couldn't see any other bug
tracking the issue. If anyone has more information on the bug that was
avoided by r581 it would be helpful as I/someone could then look into
addressing the problem without disabling the "directx" driver.

* I've also removed the restriction on not being allowed to use
DirectInput in windowed mode. I couldn't see any reason for this, at
least not from our perspective. I have my suspicions that it'll be
something like matching up the cursor with the mouse coordinates...

* I bumped up the DirectInput API used to version 7 in order to get
access to mouse buttons 4-7. I've had to inject a little bit of the DX7
headers into SDL there as the MinGW ones aren't up to date in this respect.
     2 Using SDL under Windows with the OpenWatcom compiler
     3 ====================================================
     5 Prerequisites
     6 -------------
     8 I have done the port under Windows XP Home with SP2 installed. Windows
     9 2000 should also be working. I'm not so sure about ancient Windows NT,
    10 since only DirectX 3 is available there. Building should be possible,
    11 but running the compiled applications will probalbly fail with
    12 SDL_VIDEODRIVER=directx. The windib driver should work, though.
    14 To compile and use the SDL with Open Watcom you will need the following:
    15 - Open Watcom compiler. I used version 1.5. The environment variables
    16   PATH, WATCOM and INCLUDE need to be set appropriately - please consult
    17   the OpenWatcom documentation and instructions given during the
    18   installation of the compiler.
    19   My setup looks like this in owvars.bat:
    20     set WATCOM=C:\watcom
    21     set INCLUDE=%WATCOM%\h;%WATCOM%\h\nt
    22     set PATH=%PATH%;%WATCOM%\binnt;%WATCOM%\binw
    23 - A fairly recent DirectX SDK. The original unmodified DX8 SDK works, as
    24   well as the minimal DirectX 7 SDK from the Allegro download site
    25   (<>).
    26 - The SDL sources from Subversion
    27 - The file (now available in Subversion)
    30 Building the Library
    31 --------------------
    33 1) In the SDL base directory extract the archive This
    34    creates a subdirectory named 'watcom'.
    35 2) The makefile expects the environment variable DXDIR to be set to the
    36    base directory of a DirectX SDK. I have tried a stock DX8 SDK from
    37    Microsoft as well as the minimal DirectX 7 SDK from the Allegro
    38    download site.
    39    You can also edit the makefile directly and hard code your path to
    40    the SDK on your system.
    41    I have this in my setup:
    42      set DXDIR=D:\devel\DX8_SDK
    43 3) Enter the watcom directory and run
    44      wmake sdl
    45 4) All tests from the test directory are working and can be built by
    46    running
    47      wmake tests
    49 Notes:
    51  The makefile offers some options to tweak the way the library is built.
    52  You have at your disposal the option to build a static (default)
    53  library, or a DLL (with tgt=dll). You can also choose whether to build
    54  a Release (default) or a Debug version (with build=debug) of the tests
    55  and library. Please consult the usage comment at the top of the
    56  makefile for usage instructions.
    58  If you specify a test target (i.e. 'wmake tests' for all tests, or
    59  selected targets like 'wmake testgl testvidinfo testoverlay2'), the
    60  tests are always freshly compiled and linked. This is done to
    61  minimise hassle when switching between library versions (static vs.
    62  DLL), because they require subtly different options.
    63  Also, the test executables are put directly into the test directory,
    64  so they can find their data files. The clean target of the makefile
    65  removes the test executables and the SDL.dll file from the test
    66  directory.
    68  To use the library in your own projects with Open Watcom, you can use
    69  the way the tests are built as base of your own build environment.
    71  The library can also be built with the stack calling convention of the
    72  compiler (-6s instead of -6r).
    75 Test applications
    76 -----------------
    78 I've tried to make all tests work. The following table gives an overview
    79 of the current status.
    81  Testname        Status
    82 ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    83 checkkeys       +
    84 graywin         +
    85 loopwave        +
    86 testalpha       +
    87 testbitmap      +
    88 testdyngl       +
    89 testerror       +
    90 testfile        +
    91 testgamma       +
    92 testgl          +
    93 testhread       +
    94 testiconv       - (all failed)
    95 testkeys        +
    96 testlock        +
    97 testoverlay     + (needs 'set SDL_VIDEODRIVER=directx')
    98 testoverlay2    + (needs 'set SDL_VIDEODRIVER=directx')
    99 testpalette     +
   100 testplatform    +
   101 testsem         +
   102 testsprite      +
   103 testtimer       +
   104 testver         +
   105 testvidinfo     +
   106 testwin         ? (fading doesn't seem right)
   107 testwm          +
   108 torturethread   +
   109 testcdrom       +
   110 testjoystick    not tested
   111 threadwin       +
   112 testcursor      +
   115 TODO
   116 ----
   118 There is room for further improvement:
   119 - Test joystick functionality.
   120 - Investigate fading issue in 'testwin' test.
   121 - Fix the UTF-8 support.
   122 - Adapt the makefile/object file list to support more target systems
   123 - Use "#pragma aux" syntax for the CPU info functions.
   126 Questions and Comments
   127 ----------------------
   129 Please direct any questions or comments to me:  <>
   131    Happy Coding!
   133    Marc Peter