Well regarding the relative coordinates mouse problem, it seem like XInput is a viable (depends on what you consider viable) solution. If you add an InputDevice section in your XF86Config file identical to you core pointer section but with a different name (say “Extended Mouse”) and without the “CorePointer” option and add it to your “ServerLayout” section as well then you can access your mouse as an extended input device. Among others this gives you relative coordinates. I haven’t acually tried it but xinput detects and uses it so I’m pretty sure it works.
As the only alternative is the XWarpPointer trick you get cleaner (and potentially faster) code and there might also be other benefits (better resolution etc. for example Q3A does have a dga codepath for the mouse. There must be a reason for it and XInput and dga should be equivalent) but I’m not sure, if anyone is let me know.
I’m not sure whether it would be ok to force the user to change his X configuration just to play your game (esp. if this user doesn’t know much about hacking the XF86Config-4 file) so I’m not going to use this for now (although I plan to try it at least) but I’m posting this here in the hope that other people who are interested will use it (esp. in commercial games) so that it will become more standard.
Feel free to post any comments, ideas, etc.
you’re right, it would be good if the core input devices can also be manipulated through the XInput extension; their forced exclusion from XInput looks pretty pointless and artificial to me too. If they were available through XInput, that extension could serve analogical purpose under X as does the DirectInput under windows.
I think it’s too much for a game to ask for XF86Config modifications. So currently I don’t see this as a viable solution.
How about suggesting that idea in the XFree86 mailing lists? (I meant the idea for inclusion of the core input devices in the XInput)
How about suggesting that idea in the XFree86 mailing lists? (I meant the idea for inclusion of the core input devices in the XInput)
Well I doubt it’ll be any use, they don’t design the specs (the X consortium does I think) they just implement them. I could ask them to ‘bend’ the specs a little but even if they would do it I wouldn’t like it.
hi,
when you talk about the XWarpPointer trick, is it the fact of always putting the mouse in the center each time it is moved?
i tried that way but i had a flickering image when moving mouse (not when moving camera with keyboard). is it the problem you talk about? i guess it’s because it generates an event as a user’s move does, rigth?
i’ve seen in quake 2 source this way and also the dga way (not yet tried).
if the dga (a xf86 ext) way is correct, why are you looking for another way (still in xf86)?
bye
[This message has been edited by dephenomia (edited 02-18-2004).]
when you talk about the XWarpPointer trick, is it the fact of always putting the mouse in the center each time it is moved?
Yep.
i tried that way but i had a flickering image when moving mouse (not when moving camera with keyboard). is it the problem you talk about? i guess it’s because it generates an event as a user’s move does, rigth?
Nope. Your problem is most likely caused by not scaling the relative motion you get from your mouse. If for example you get a relative motion of (3, 5) from the mouse and you just rotate by that then you rotate by 3 and 5 degrees in the y and z (or whatever) axes respectively, which might be too much (depending on your gl-to-world scale). No scale these by say .1 to get (.3, .5) and you might get much smoother motion (this should be what the sensitivity cvar does in q2/3). Regarding the thing about XWarpPointer creating motion events, this is true and it must be taken care of or else you’re going to flood your event queue, which is not good™.
if the dga (a xf86 ext) way is correct, why are you looking for another way (still in xf86)?
Well q2 and q3 uses DGA 1.1 which is deprecated by DGA 2 and hence will not be available in the future. DGA 2 still supports relative motion events but you generally can’t use it with opengl anymore. See my previous post about relative coordinates for more info.
If you’re not XSync:ing or XFlush:ing properly, you’re into problems with XWarpPointer etc. I had that happening in GLFW (my motion events and XWarpPointer calls we not in sync, so effectively a lot of motion events got lost).
so marcus, have you found any usable alternatives by any chance?
[This message has been edited by zen (edited 02-20-2004).]
Originally posted by zen:
so marcus, have you found any usable alternatives by any chance?
Well, I use XWarpPointer + XFlush/XSync in GLFW , and it works very well. Of course, I use XGrabPointer too. To be on the safe side, and to minimize XWarpPointer calls, I use a movement threshold (i.e. I only re-center the pointer if it leaves a rectangular area in the center of the window). All in all, it works very well. You can check/rip the GLFW code if you wish.
By the way: mouse-based view rotation tends to be very jerky, regardless of scaling. You should add some simple filter function to the mouse coordinates to fix this. I suppose x_rot = (x_this_frame+x_previous_frame)/2 is sufficient (depends on your application and framerate).
well i do rescale the mouse values and i have flickering. so i guess i agree with marcus
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.