Subject: [Nel] small bug, bug unforgivable design flaw

From: Vincent Caron <[email-masked]>
Date: 30 Nov 2001 02:08:58 +0100

Many Linux users reported a very slow framerate. Actually, they should
notice that the initial framerate is good (100fps on my GeForce3) and
drops as soon as the mouse is moved. If you have a CPU monitor nearby (a
must for a serious Linux developer :)), you'll also notice that the
client spends most of the time in system calls.

NeL use the 'center warped mouse' trick to fetch relative mouse
coordinates. This need a call to XWarpPointer every time a mouse motion
event is read, to warp the pointer at the center. However this trigger
another mouse motion event (all X functions behave like user
interaction, here we have a gap with the win32 world) : you'll quickly
realize that you have the famous 'Larsen' effect (actually you're
filling the X queue faster than you're flushing it).

I made a _dirty_ hack to solve temporarily the pb : make the event
emitter ignore mouse events that report centered (0.5,0.5) mouse
coordinates (one-liner patch attached).

However, I'm a bit surprised by the display driver interface. The
'center warped mouse' trick is way deprecated. It's been a long time
since Windows (via DirectInput) and XFree (via DGA) support 'mickey'
mode. Reading mickeys give you the best mouse resolution, and moreover
bypass any filter (and Windows does smooth mouse motion).

What's more disappointing, is that the bad trick is actually coded right
into the client code (ie. in Snowballs2). So it's too late to switch
easily to proper mickey reading, since the driver didn't have the right
abstraction (two coordinates modes : absolute and relative).

I consider this as two errors : making the assumption that setMousePos()
has a portable behaviour (XWarpPointer() _will_ generate an event), and
imposing an old tweak on user to fetch relative coordinates. Remember
that at hardware level, mouse coordinates are relative... See SDL code
for ideas.

--

I should add a note on this. I'm actually just pointing out something
akward in a huge and amazing work I admire. Friends I trust swore the
real (hidden, except shots) demo just rules. The fact is, that I would
like the Linux version of NeL be of high quality, I mean at least at the
Windows development level. Something like pride, but also a simple
parity case :) (ek, I'm playing Q3 and a bunch of other FPS at the same
framerate of Windowsers ;)). That's maybe why I seem a little insistant
on the Linux side of NeL. I know you don't have enough ressource to
actively maintain the Linux port, so I never blame you for these pb.

Cross-platform programming, and especially win32/Linux comparative
design has become my speciality since the last 2 years. Now you
understand why I was so critic on this 'relative mouse coordinates' pb
:). The whole idea is, if you want to keep your promise of portability
for NeL, I suggest you consider this mouse driver interface pb. Then
we'll have no pb for future port (here I include Linux, BeOS and
MacOS9/X experience).

Index: unix_event_emitter.cpp
===================================================================
RCS file: /home/cvsroot/code/nel/src/3d/driver/opengl/unix_event_emitter.cpp,v
retrieving revision 1.4
diff -c -r1.4 unix_event_emitter.cpp
*** unix_event_emitter.cpp	11 Apr 2001 13:45:30 -0000	1.4
--- unix_event_emitter.cpp	30 Nov 2001 01:11:34 -0000
***************
*** 264,269 ****
--- 264,270 ----
  	XGetWindowAttributes (_dpy, _win, &xwa);
  	float fX = (float) event.xbutton.x / (float) xwa.width;
  	float fY = 1.0f - (float) event.xbutton.y / (float) xwa.height;
+   if ((fX == 0.5f) && (fY == 0.5f)) break;
  	TMouseButton button=getMouseButton (event.xbutton.state);
  	server.postEvent (new CEventMouseMove (fX, fY, button, this));
  	break;

---

From: "Cyril 'Hulud' Corvazier" <[email-masked]>
Date: Mon, 3 Dec 2001 11:21:54 +0100

Hi Vincent,

I would like to thank you for your help and your advises regarding the mouse
interface.

Yes you're right, the best mouse implementation should use the mickey mode.
A second implementation of the Events Emitter is planed in a near future.
This will introduce new messages for all the input interfaces including
mickey messages using Directinput and Dga.
After this work, the client side code could be modified to virtualise the
input regarding the user configuration.
For the time, the one we use is only based on win32 and xlib basic messages
so, it is not very smart. Sorry for this.

Be sure we want a NeL Gnu/Linux implementation as good as possible. :-)
Thanks again for your help.

Best regards,

Cyril Corvazier.

---

From: Cedric Valignat <[email-masked]>
Date: Thu, 13 Dec 2001 19:13:33 +0100

Hi Vincent,

I applied your patch.

Thanks a lot for the help,

Cedric.