USB Light Gun

SDL Development
1

Hello

I am developing a game as part of a research project using the Act-Labs
USB PC Light Gun. The gun emulates a USB mouse. I have written the
game using SDL on win32 and it works well with really good accuracy.
However when I move across to Linux (Red Hat,Gnome, X11) I get
inconsistent accuracy. Accuracy in the centre of the screen is good but
gets worse towards the periphery. Does the mouse system under linux
differ appreciably from win32? Or should I be looking for the problem
at a driver level (currently a generic USB mouse driver)?

Any advice would be greatly appreciated.

Cheers

Sean

2

Hello

I am developing a game as part of a research project using the
Act-Labs USB PC Light Gun. The gun emulates a USB mouse. I have
written the game using SDL on win32 and it works well with really good
accuracy. However when I move across to Linux (Red Hat,Gnome, X11) I
get inconsistent accuracy. Accuracy in the centre of the screen is
good but gets worse towards the periphery. Does the mouse system
under linux differ appreciably from win32?

About the only things they have in common are the requirement to deliver
events to applications and to work with common off the shelf hardware.

Or should I be looking for the problem at a driver level (currently a
generic USB mouse driver)?

Please define what you mean by accuracy? Is it positioning accuracy,
timing accuracy, or both?

Are you using the mouse directly through the mouse driver or are you
using it through X? The delay between the time the X server gets input
from the mouse driver and the time it delivers it to you, while usually
not noticeable, can really be a problem where fine motion detection is
needed. Also, look at the mouse handler code in your X server. Some
servers compress mouse motion events. That is, as the mouse moves they
just update the location of the mouse and deliver the accumulated motion
in one event. So, you only get one event for a huge movement of the
mouse. Of course, they have to create a new event every time a button is
pushed to maintain consistent click semantics and when ever a non-mouse
event is added to the queue to maintain time order semantics.

Why it would get worse at the edge of the screen is hard for me to
understand. It could be the result of motion event compression. But,
it could also be the result of miss-calibration of the light pen with
the refresh rate of the screen. If the light gun doesn’t have the
correct timing information it can’t really tell where it is pointing and
the error will accumulate as you get toward the left edge of the screen.
How does your light pen sync with the horizontal and vertical retrace
markers in the video signal?

Any advice would be greatly appreciated?

Hope I helped.
Bob PendletonOn Thu, 2003-06-26 at 08:21, Sean Fitzgibbon wrote:

Cheers

Sean
–
±----------------------------------+

  • Bob Pendleton: independent writer +
  • and programmer. +
  • email: Bob at Pendleton.com +
    ±----------------------------------+
3

Hello

I am developing a game as part of a research project using the
Act-Labs USB PC Light Gun. The gun emulates a USB mouse. I have
written the game using SDL on win32 and it works well with really good
accuracy. However when I move across to Linux (Red Hat,Gnome, X11) I
get inconsistent accuracy. Accuracy in the centre of the screen is
good but gets worse towards the periphery. Does the mouse system
under linux differ appreciably from win32?

About the only things they have in common are the requirement to deliver
events to applications and to work with common off the shelf hardware.

Or should I be looking for the problem at a driver level (currently a
generic USB mouse driver)?

Please define what you mean by accuracy? Is it positioning accuracy,
timing accuracy, or both?
[Sean Fitzgibbon] Positioning accuracy.

Are you using the mouse directly through the mouse driver or are you
using it through X?
[Sean Fitzgibbon] I am accessing the mouse events using SDL events, as
such I presume that it is coming from X.

The delay between the time the X server gets input
from the mouse driver and the time it delivers it to you, while usually
not noticeable, can really be a problem where fine motion detection is
needed.
[Sean Fitzgibbon] Timing of the response is not important to the
software. It is logged via hardware for analysis later.

Also, look at the mouse handler code in your X server. Some
servers compress mouse motion events. That is, as the mouse moves they
just update the location of the mouse and deliver the accumulated motion
in one event. So, you only get one event for a huge movement of the
mouse. Of course, they have to create a new event every time a button is
pushed to maintain consistent click semantics and when ever a non-mouse
event is added to the queue to maintain time order semantics.
[Sean Fitzgibbon] This sounds as though it may be related to the
problem.

Why it would get worse at the edge of the screen is hard for me to
understand. It could be the result of motion event compression. But,
it could also be the result of miss-calibration of the light pen with
the refresh rate of the screen. If the light gun doesn’t have the
correct timing information it can’t really tell where it is pointing and
the error will accumulate as you get toward the left edge of the screen.
How does your light pen sync with the horizontal and vertical retrace
markers in the video signal?
[Sean Fitzgibbon] The light gun splices into the vga signal to the
monitor to sync with the retrace. It works perfectly with win32 so I
don’t think that it will be due to a failure to sync.

Any advice would be greatly appreciated.

Hope I helped.
Bob PendletonOn Thu, 2003-06-26 at 08:21, Sean Fitzgibbon wrote:

Cheers

Sean
–
±----------------------------------+

  • Bob Pendleton: independent writer +
  • and programmer. +
  • email: Bob at Pendleton.com +
    ±----------------------------------+

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

4

Hello

Another thing that might cause this problem is the way the light gun
reports movement to the mouse driver. Normally the mouse sends a stream
of location change data to the driver and it comes in at a fairly
constant rate with a minimal change in position in each message. The
light gun can only update its location once per frame, when the bright
spot of the electron beam sweeps through the part of the screen the bun
is pointed at. So, it could be sending short intense bursts of data
every frame and those bursts could overload some internal buffer and get
lost or the arithmetic in the mouse driver wrap around. I would consider
both of these to be low probability events.

It just occurred to me to ask, are you using the same monitor on the
Windows box and the Linux box? The curvature of the screen, the age of
the monitor, and the lighting in the room could interfere with the light
gun’s ability to detect the spot on the screen.

Because there is such a large amount of analog everything in what you
are doing makes the “fact” that it works perfectly on Windows a
distraction, not hard evidence.

	Bob PendletonOn Thu, 2003-06-26 at 20:43, Sean Fitzgibbon wrote:

On Thu, 2003-06-26 at 08:21, Sean Fitzgibbon wrote:

I am developing a game as part of a research project using the
Act-Labs USB PC Light Gun. The gun emulates a USB mouse. I have
written the game using SDL on win32 and it works well with really good
accuracy. However when I move across to Linux (Red Hat,Gnome, X11) I
get inconsistent accuracy. Accuracy in the centre of the screen is
good but gets worse towards the periphery. Does the mouse system
under linux differ appreciably from win32?

About the only things they have in common are the requirement to deliver
events to applications and to work with common off the shelf hardware.

Or should I be looking for the problem at a driver level (currently a
generic USB mouse driver)?

Please define what you mean by accuracy? Is it positioning accuracy,
timing accuracy, or both?
[Sean Fitzgibbon] Positioning accuracy.

Are you using the mouse directly through the mouse driver or are you
using it through X?
[Sean Fitzgibbon] I am accessing the mouse events using SDL events, as
such I presume that it is coming from X.

The delay between the time the X server gets input
from the mouse driver and the time it delivers it to you, while usually
not noticeable, can really be a problem where fine motion detection is
needed.
[Sean Fitzgibbon] Timing of the response is not important to the
software. It is logged via hardware for analysis later.

Also, look at the mouse handler code in your X server. Some
servers compress mouse motion events. That is, as the mouse moves they
just update the location of the mouse and deliver the accumulated motion
in one event. So, you only get one event for a huge movement of the
mouse. Of course, they have to create a new event every time a button is
pushed to maintain consistent click semantics and when ever a non-mouse
event is added to the queue to maintain time order semantics.
[Sean Fitzgibbon] This sounds as though it may be related to the
problem.

Why it would get worse at the edge of the screen is hard for me to
understand. It could be the result of motion event compression. But,
it could also be the result of miss-calibration of the light pen with
the refresh rate of the screen. If the light gun doesn’t have the
correct timing information it can’t really tell where it is pointing and
the error will accumulate as you get toward the left edge of the screen.
How does your light pen sync with the horizontal and vertical retrace
markers in the video signal?
[Sean Fitzgibbon] The light gun splices into the vga signal to the
monitor to sync with the retrace. It works perfectly with win32 so I
don’t think that it will be due to a failure to sync.

Any advice would be greatly appreciated.

Hope I helped.
Bob Pendleton

Cheers

Sean
–
±----------------------------------+

  • Bob Pendleton: independent writer +
  • and programmer. +
  • email: Bob at Pendleton.com +
    ±----------------------------------+
5

Have you had the same results when using the light gun as a mouse in another
environment?
How does it do in X? Does the same problem occur when using gpm services for
the console? if so then that might point to a driver issue, or a hardware
issue.

What aboot trying a differnt distro? try downloading knoppix and trying the
light gun and game program w/ that distro.

many options, more detail would be helpful (the meaning of ‘accuracy’ above is
some what unclear)On Thursday 26 June 2003 6:21 am, Sean Fitzgibbon wrote:

Hello

I am developing a game as part of a research project using the Act-Labs
USB PC Light Gun. The gun emulates a USB mouse. I have written the
game using SDL on win32 and it works well with really good accuracy.
However when I move across to Linux (Red Hat,Gnome, X11) I get
inconsistent accuracy. Accuracy in the centre of the screen is good but
gets worse towards the periphery. Does the mouse system under linux
differ appreciably from win32? Or should I be looking for the problem
at a driver level (currently a generic USB mouse driver)?

Any advice would be greatly appreciated.

Cheers

Sean

–
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety. "
–Benjamin Franklin