Ladna
Junior Member
Posts: 234
Registered: 04-10 |
I don't have a definitive answer for you. Looking at the linuxdoom source, here's what happens to mouse input:
code:
event.data2 = (X_event.xmotion.x - lastmousex) << 2;
event.data3 = (lastmousey - X_event.xmotion.y) << 2;
It's likely that this is X-specific code. All it does is use relative mouse movement instead of absolute mouse position, and then multiplies the value by four. Chocolate Doom uses absolute mouse positions (warping back to 0,0 between measurements), and does no multiplying. EE uses relative mouse positions, and likewise does no multiplying. I can't tell you the effective difference between absolute & relative positions; it's an SDL thing and might affect different backends differently, that's all I know.
===
Separate from smooth mouse movement, both linuxdoom and Chocolate Doom do this to their mouse input:
code:
mousex = ev->data2*(mouseSensitivity+5)/10;
mousey = ev->data3*(mouseSensitivity+5)/10;
That's just handling a user's mouse sensitivity value, in a Doom-y way. EE will do this if you enable "vanilla_sensitivity".
===
Chocolate Doom also applies mouse acceleration, using the following code:
code:
static int AccelerateMouse(int val)
{
if (val < 0)
return -AccelerateMouse(-val);
if (val > mouse_threshold)
{
return (int)((val - mouse_threshold) * mouse_acceleration + mouse_threshold);
}
else
{
return val;
}
}
Again that's pretty self-explanatory. If you don't want mouse accel, just set it to zero and it works as expected. EE will do this if you set "mouse_accel" to "2".
===
EE supports additional mouse behavior. Here is "raw" mouse sensitivity:
code:
// SoM: this mimics the doom2 behavior better.
if(mouseSensitivity_vanilla)
{
mousex += (ev->data2 * (mouseSensitivity_horiz + 5.0) / 10.0);
mousey += (ev->data3 * (mouseSensitivity_vert + 5.0) / 10.0);
}
else
{
// [CG] 01/20/12: raw sensitivity
mousex += (ev->data2 * mouseSensitivity_horiz / 10.0);
mousey += (ev->data3 * mouseSensitivity_vert / 10.0);
}
(Wow, was that really a whole year ago? That's crazy.)
Of course, EE supports separate sensitivity values for horizontal and vertical mouse movement, as you can see here.
Here are disabled and "linear" accelerations:
code:
// SoM 1-20-04 Ok, use xrel/yrel for mouse movement because most
// people like it the most.
if(mouseAccel_type == 0)
{
mouseevent.data2 += event.motion.xrel;
mouseevent.data3 -= event.motion.yrel;
}
else if(mouseAccel_type == 1)
{
// Simple linear acceleration
// Evaluates to 1.25 * x. So Why don't I just do that? .... shut up
mouseevent.data2 += (event.motion.xrel +
(float)(event.motion.xrel * 0.25f));
mouseevent.data3 -= (event.motion.yrel +
(float)(event.motion.yrel * 0.25f));
}
(1-20 seems to be the date for mouse code changes, that's also crazy haha).
Here is EE's "custom" acceleration:
code:
static double CustomAccelerateMouse(int val)
{
if(val < 0)
return -CustomAccelerateMouse(-val);
if((mouseAccel_value != 1.0) && (val > mouseAccel_threshold))
return val * mouseAccel_value;
return val;
}
EE also supports "smooth turning" (an SMMU feature I assume), which basically averages your current mouse input with your mouse input from the previous TIC:
code:
// sf: smooth out the mouse movement
// change to use tmousex, y
// divide by the number of new tics so each gets an equal share
tmousex = mousex /* / newtics */;
tmousey = mousey /* / newtics */;
if(smooth_turning)
{
static double oldmousex=0.0, mousex2;
static double oldmousey=0.0, mousey2;
mousex2 = tmousex; mousey2 = tmousey;
tmousex = (tmousex + oldmousex) / 2.0; // average
oldmousex = mousex2;
tmousey = (tmousey + oldmousey) / 2.0; // average
oldmousey = mousey2;
}
So the answer to your question is, "I think so". I can't say if your mouse will behave identically between doom2.exe and Chocolate Doom if you configure them with identical mouse values, but it looks like they support essentially the same features. Of course, in line with its mission, EE supports these behaviors and then some.
===
As a side note, when upgrading EE's mouse code, I made it a point to do as many mouse calculations as possible using doubles. Theoretically this should improve precision, especially when using high DPI or high rate mice. In practice, SDL is such garbage it was probably a waste of time.
|
01-11-13 21:57 
