I’m using SDL 1.2.4 in an environment with a touch screen: 800x600x32 video
display. It’s actually being used via Ruby and the RUDL library but that’s a
very thin layer which I can see is doing the right thing.
The problem I’m seeing concerns the times when MOUSEBUTTONDOWN events come
through: on Windows NT terminals, everything works as expected. Under
Windows 2000, the touches are detected wrongly: most of them come through to
the program with either the X or Y co-ordinates set to 0 or 799 (X) or 599
(Y), as if the user is consistently poking at one edge of the screen (they’re
not, I’m assured).
I’ve not got physical access to the machine where this happens, and I cannot
duplicate it on my own Linux, Windows 2000 Pro, NT4, XP or 98 setups. I
suspect that it’s the fault of the touch-screen drivers, but it’s still my
problem in that “well all the other games work on this terminal, why doesn’t
yours”.
So assuming nobody recognises the problem, Is there some way in the SDL API
that I can read the mouse co-ordinates through a different native API? Any
other suggested hacks?
It wouldn’t be perfectly accurate, but couldn’t you keep track of where
the mouse is on the screen with local variables and then use those for
the click, rather than the ones returned by the click event?On Fri, 2002-09-06 at 10:22, Matthew Bloch wrote:
Hi there;
I’m using SDL 1.2.4 in an environment with a touch screen: 800x600x32 video
display. It’s actually being used via Ruby and the RUDL library but that’s a
very thin layer which I can see is doing the right thing.
The problem I’m seeing concerns the times when MOUSEBUTTONDOWN events come
through: on Windows NT terminals, everything works as expected. Under
Windows 2000, the touches are detected wrongly: most of them come through to
the program with either the X or Y co-ordinates set to 0 or 799 (X) or 599
(Y), as if the user is consistently poking at one edge of the screen (they’re
not, I’m assured).
I’ve not got physical access to the machine where this happens, and I cannot
duplicate it on my own Linux, Windows 2000 Pro, NT4, XP or 98 setups. I
suspect that it’s the fault of the touch-screen drivers, but it’s still my
problem in that “well all the other games work on this terminal, why doesn’t
yours”.
So assuming nobody recognises the problem, Is there some way in the SDL API
that I can read the mouse co-ordinates through a different native API? Any
other suggested hacks?
I tried using Mouse.pos (which uses SDL_GetMouseState) after every event to
get an ‘independent’ assessment of where the mouse is. Apparently that’s more accurate but still hopeless. Time to have a good peer over DirectX
and see what my options are.On Friday 06 September 2002 16:30, Jimmy wrote:
It wouldn’t be perfectly accurate, but couldn’t you keep track of where
the mouse is on the screen with local variables and then use those for
the click, rather than the ones returned by the click event?
If your application is fullscreen, you might try disabling DirectX and
see if it’s a problem with the DirectInput drivers (which it seems fewer
and fewer games are using these days)
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
If your application is fullscreen, you might try disabling DirectX and
see if it’s a problem with the DirectInput drivers (which it seems fewer
and fewer games are using these days)
Really? What controller standards are being used these days? Oh… or was
that a shameless plug for SDL?
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
Jakob.Am Freitag, 6. September 2002 22:34 schrieb Neil Bradley:
If your application is fullscreen, you might try disabling DirectX and
see if it’s a problem with the DirectInput drivers (which it seems fewer
and fewer games are using these days)
Really? What controller standards are being used these days? Oh… or was
that a shameless plug for SDL?
– http://www.obilot.de | Windows is a 32 bit shell for a 16 bit extension to an
8 bit Operating System designed for a 4 bit microchip by a 2 bit company
which can’t stand one bit of competition.
If your application is fullscreen, you might try disabling DirectX and
see if it’s a problem with the DirectInput drivers (which it seems fewer
and fewer games are using these days)
Really? What controller standards are being used these days? Oh… or was
that a shameless plug for SDL?
No, it just seems like most games, with the exception of FPSs, are just
using Windows messages for input, rather than bothering with DirectInput.
SDL uses DirectInput internally when in fullscreen mode.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Is there any way to get it to not use DirectInput, or is that part & parcel of
the DirectX backend? Should I just issue calls to the Win32 API to read the
mouse pointer position myself?On Saturday 07 September 2002 00:14, Sam Lantinga wrote:
If your application is fullscreen, you might try disabling DirectX and
see if it’s a problem with the DirectInput drivers (which it seems
fewer and fewer games are using these days)
Really? What controller standards are being used these days? Oh… or was
that a shameless plug for SDL?
No, it just seems like most games, with the exception of FPSs, are just
using Windows messages for input, rather than bothering with DirectInput.
SDL uses DirectInput internally when in fullscreen mode.
Is there any way to get it to not use DirectInput, or is that part & parcel of
the DirectX backend? Should I just issue calls to the Win32 API to read the
mouse pointer position myself?
Well, you should probably find out if it really is DirectX that’s the problem,
first.
If it really is the problem, and the end user has the latest updated drivers,
you’ll probably have to hack SDL or make Win32 API calls directly.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
If your application is fullscreen, you might try disabling DirectX and
see if it’s a problem with the DirectInput drivers (which it seems fewer
and fewer games are using these days)
Really? What controller standards are being used these days? Oh… or was
that a shameless plug for SDL?
No, it just seems like most games, with the exception of FPSs, are just
using Windows messages for input, rather than bothering with DirectInput.
SDL uses DirectInput internally when in fullscreen mode.
Really? Oh, my! So I now understand why the input response is alledged as very
erratic on current games (I live in Europe, and here home computers are
not so cutting-edge; we’re targetting for only 500 MHz/Riva TNT as minimum
requirements and some people said that’s too high).
gulp Actually your saying that reminds me why I never test the game in
full-screen mode under 2000-- I get exactly that “stuck to the sides” effect.
I have to move the mouse hard to the right to get it to move off the
left-hand side, but then it’s only moved about a 3 millimetres before the
pointer is stuck to the right-hand side. For some reason I didn’t think this
was the same problem as they were having with the touch-screen. Shit shit
shit, talk about blinding yourself to the truth I still have no idea why
it does this, though.On Saturday 07 September 2002 03:22, Sam Lantinga wrote:
Is there any way to get it to not use DirectInput, or is that part &
parcel of the DirectX backend? Should I just issue calls to the Win32
API to read the mouse pointer position myself?
Well, you should probably find out if it really is DirectX that’s the
problem, first.