[quake2] CVS: Mouse still a bit bad

Thomas J Fogal tfogal at pascal.unh.edu
Mon Sep 27 14:32:42 EDT 2004

 <20040927092808.1435.qmail at taiga.com>arny at taiga.com writes:

> > Could someone tell me which file(s) I should look at to compare 
> > the quake2forge to icculus-quake2 glx mouse code?

As far as I can tell (read: I just did a quick look) icculus-quake2
GLX mouse handling is done in linux/gl_glx.c. Of course, this is only
linux mouse handling, which is consistent with Vincent's reports that
solaris GLX has been impeccable.
I am not very familiar with the quake2forge source tree. Sorry.

> I got the feeling another 'thread' was stopping a mouse handling
> 'thread' and a sound handling 'thread' from running for a split
> second from time to time.  If that was the case the problem would
> be in the thread scheduling code.
> Note I don't know _anything_ about quake 2, it might not even
> work that way (i.e. splitting mouse and sound into different
> threads).  Alternatively I could have explained what I meant
> conceptually in terms of interrupts being unserviced.

quake2 does not use threads. Anything linked against SDL must be linked
against pthreads, but this is probably only because SDL provides higher
level abstractions for threading. I could be wrong though -- it is
entirely possible that SDL will create internal threads for handling
sound && input.
At least for now =). If I ever get the time I'd kind of like to fiddle
with separating the 'server' and 'client' modes into seperate



More information about the quake2 mailing list