Raydium 3D Game Engine

Official forum for everything about Raydium, ManiaDrive, MeMak, ...
It is currently Fri Dec 14, 2018 1:06 pm

All times are UTC




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Tue Aug 25, 2009 9:15 pm 
Offline

Joined: Tue Jul 08, 2008 2:37 am
Posts: 181
Hi!

I have some trouble using the freemove and orbit camera under Mac OS X during some time now.
The first time this behavior occurred I thought it was a little lag of my system, because there were many other processes running.
But after the second and third time, where no other things were eating system resources, I checked my input devices and verified that everything is working correctly.
It feels that someone is shaking your mouse a bit while using the freemove and orbit camera.

I checked my local SVN to be sure that I haven't local changes. I updated step by step from R831, that's the current revision for the Raydium Apple SDKs, to R842 which seems to be the first revision with this problem on my system.

I'm able to reproduce this problem every time, from revision 842 to the latest, with willou.c. I can also reproduce it with simple.c, with and without simple.conf in the current revision R883.

It's reproducible at any screen resolution, never mind it's a window or in fullscreen mode.

I hopefully localized the problem, IMHO it must have something to do with Raydium revision 842: Correct handling of odd X/Y window sizes for freemove and orbit camera, using a 'box' model for mouse move detection, instead of a 'point' one.

Simplest way to reproduce it: Start the willou.c sample and slowly move your mouse to any direction, you can even fly with the arrow keys, but you don't have to, after some time your mouse position will warp (while you move your mouse) and it feels your input lags a bit (you are looking at some other direction as expected).

I haven't tried any other system yet, except the iMac, so perhaps this issue is system related.

Any suggestion?

Thank you very much.

Best regards,
st


Last edited by st on Wed Feb 15, 2012 6:39 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Aug 25, 2009 10:15 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Can't reproduce the trouble here (Linux and win32), so as you said, it's probably a target specific issue.

I've just added raydium_mouse_show() to the PHP API so you can see the new "box model" working. Just call this function using the in-game console.

The correct behavior is this one: the mouse can "freely" move inside a box. The distance done by the cursor from one frame to the next one defines the speed used by freemove/orbit/test6/... If the mouse leaves this box, the cursor is centered again. The size of this box is half the size of the window, on each axis. Showing the mouse cursor, you should the the move moving a bit and then jumping straight to the center of the screen. This is done by the new raydium_mouse_grab_delta() function, mouse.c file.

I'm pretty sure the trouble happens when you hit box borders, no ?
Perhaps a trouble in raydium_mouse_move() ?

I'll have a look on my side, since I've just seen that the behavior may have changed a little bit under win32 (sensitivity), so there's perhaps an ugly bug somewhere :)


Top
 Profile  
 
PostPosted: Tue Aug 25, 2009 11:24 pm 
Offline

Joined: Tue Jul 08, 2008 2:37 am
Posts: 181
Thanks for the quickly response.

On console raydium_mouse_show() is very useful for this. :D
This shows that on lower resolutions like 320x240 the border is more often reached than in a higher resolution like 1920x1200.
What is very confusing to me, is the fact, that not every "border hit" will produce a lagging warp. Only about every fifth will create a visible issue. So on lower resolutions the lags occur more often than on higher ones.

I've checked some things without success to find a way to fix the issue so far, including an advice from vicente via IRC.
vicente wrote:
maybe this? border = raydium_math_max(raydium_window_tx,raydium_window_ty) / 4; That's a division by an integer, change that 4 with a 4.0f and try
Next idea was to search on the Apple forums, yes there are some troubles with glutWarpPointer, but we have our own glutWarpPointer implemented in myglut-macosx.c and it has done it's job since R842. :)

Hmm, I think the next things I'll check are to guess the frame rate at warp time and checking all Mac related calls beginning from raydium_mouse_move().

- EDIT -
The frame rate is stable at mouse warp points. I haven't found out a solution to fix this lag issue yet.
BTW: Border is declared as an integer, so there should be no problem. ;)


Top
 Profile  
 
PostPosted: Wed Aug 26, 2009 12:48 am 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Found something interesting while testing with win32:
- The old "point" model was moving the cursor each frame (position? -> center -> position? -> center ...)
- The new "box" model is moving the cursor only when the mouse is out of the box (The box size is absolutely arbitrary ... I could have divided by 4.5, by 2 or used a fixed size box, it works the same) .. The idea behind this model is to do not harass the window manager with permanent glutWarpPointer() calls, and to deal with odd window sizes, since X11 can have a different answer for "get" and "set" mouse position in such cases (dunno if I'm clear on this last point).

But what I've just discovered may be interesting for your issue: the new box model makes Windows message queue doing ... wired things.
I've added raydium_log() traces for:
- get delta function
- message pump (a function used to request all messages to Windows since last call)
- mouse move callback (glutPassiveMotionFuncCB)

With the old model, when not moving the mouse, the result is: pump, callback, delta, pump, callback, delta, ...
Box model, not moving the mouse: pump, delta, pump, delta, ... (that's the point of this model)
Old point model, moving the mouse, off course, changes nothing, it's the usual pump, callback, delta chain
Box model, moving the mouse: pump, callback, delta, pump, callback, delta, ... It becomes like the old system. Everything is OK.

But sometimes (1 run on 5, perhaps ?), the new box models gives me, for instance:
pump, callback, callback, delta, pump, delta, ... (2 callbacks on 1 frame, 0 on the next one)

WM_MOUSEMOVE messages were desynchronized, sort of. It's very wired, since Windows is supposed to erase previous mouse move messages, not stack it ! (can't find anything on MSDN about this, but found various posts on random forums stating this)

It does not happen with the old model, since glutWarpPointer() seems force something in the Windows message queue, probably while firing its own WM_MOUSEMOVE ... Or perhaps the mouse is sending too much messages sometimes (tried at different speed in the driver: 125 Hz -> 1 KHz without noticable change about this issue) so the datadump can't read quickly enough with the box model ? ... Anyway, the fact is that it works OK with the old behavior.

In your case, making the test [line 108, mouse.c] always true resolv the issue ? In this case, we'll return back to the old let's-flood-the-WM point model, that were OK with win32 and OSX, fixing 2 bugs at once, and I'll try to fix the issue from the other end: X11 trouble with odd sized windows.


Top
 Profile  
 
PostPosted: Wed Aug 26, 2009 8:49 am 
Offline

Joined: Tue Jul 08, 2008 2:37 am
Posts: 181
Xfennec wrote:
In your case, making the test [line 108, mouse.c] always true resolv the issue ?
Commenting out lines 108 to 110 in mouse.c restores the old behavior. Without these lines everything works like usual and fixes the issue for me.

Perhaps we can simply #ifdef LINUX if(CONDITION) #endif this section. But I really want to know why it is not working here, I also would find it better to fire mouse move events only when really needed.

Thank you very much for the explanation and help! :D


Top
 Profile  
 
PostPosted: Wed Aug 26, 2009 1:39 pm 
Offline
User avatar

Joined: Sun Mar 16, 2003 2:53 am
Posts: 2590
Location: gnniiiii (Scrat)
Tried to fix the X11 strange behavior, without any success ... It's incredible how mouse management seems broken/unstable with most OS :)

X11 seems to use some sort of float rounding somewhere, and when I use XWarpPointer to move the cursor at a precise place, sometimes, with particular window sizes, the mouse is reported to be 1 pixel further on the right or on the top (or both). I tried to used fixed coordinates (100,100 instead of the screen center, for instance), I tried to find what sort of rounding was done, where it was done, how other libraries where dealing with mouse look (mostly with box model, it seems), ... nothing worked like I wanted.

So I've fixed that with conditional compilation. Not proud of it :) (rev 885)
Please report any trouble and strange behaviors you may encounter with mouse look.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group