Mouse controls

[Blastfrog]

Is there any way to get the mouse controls to feel like a standard FPS's mouse controls? I swear, the default mouse behavior is absolutely horrible, it's simply unplayable, and I have to revert to using the keyboard exclusively if I want to be able to play the game.

If there's no way to configure the mouse controls to feel more standard, would you guys be willing to code in some optional alternate mouse behavior?

[Zott]

Have you tried adjusting the mouse sensitivity under preferences -> Controls - > Mouse?

You mentioned in another thread that the vertical was slow in comparison to the horizontal, so you could definitely boost the vertical higher than the horizontal sensitivity.

[treellama]

Can you qualify what the problem is? "Absolutely horrible" isn't sufficiently descriptive to solve your problem. If it's sensitivity, inversion, or acceleration, there are controls in the preferences.

[HunterZ]

I feel the same way as the OP. I've messed with all the mouse-related controls, and I can't get anything that feels natural compared to mouselook in any other FPS. Setting a low-ish sensitivity with acceleration enabled is almost playable, but the mouselook seems to jump between too slow and too fast with nothing in between (and I hate acceleration anyways). Disabling acceleration results in what feels like jerky/jumpy movement.

It's also weird to be limited to looking up and down only slightly. The game has a setting whose name implies that it should turn off this limitation, but it doesn't.

In the end, I don't feel that the Aleph One engine really does offer mouselook in a usable form. All Doom ports that I've played get it right, so I'm not sure why Aleph One has such a weird mouselook implementation. I think I did have trouble with a Descent port's mouse controls, which is ironic since the controls in the original engine running in DOSBox are great.

[HunterZ]

(oops, duplicate post)

[Blastfrog]

Can you qualify what the problem is? "Absolutely horrible" isn't sufficiently descriptive to solve your problem. If it's sensitivity, inversion, or acceleration, there are controls in the preferences.

No matter what the settings are for the mouse, it's unplayably awkward to handle. Seriously, go play Quake or ZDoom with WASD+Mouse, then come back to Aleph One using WASD+Mouse, and tell me you can't see the huge difference in how it handles.

I really don't know how to convince the people that can't see the problem with mouse control that there is a problem. Let me put it this way, mouse control is completely functional, no problems there, the problem is that it just has awkward and downright shitty handling in how it feels when it's used.

All I ask is that there should be an option to have the mouse control feel identical to how it does in something like ZDoom or Quake. Aleph One uses very non-standard feel for it's acceleration, speed, and accuracy. There is no way that I or others that see a problem with it can possibly adjust to how the mouse control currently handles, there NEEDS to be an option to give the mouse control a different feel.


I really don't see how it's so difficult to see the problem. On a technical level, mouse control works just fine, from a gameplay perspective, it just handles horribly, and unlike any other FPS game's mouse controls.

[ukimalefu]

ADJUST THE MOUSE SENSITIVITY

In Aleph One, not your OS. I turn it down a bit and it makes a BIG difference for me.

[Wrkncacnter]

I honestly can't ever tell if you guys are joking, because the mouse support in alephone is beyond awful. I always assume the people that say "configure the sensitivity" are playing dumb on purpose, but then ukimalefu says it, and he's not smart enough to do anything on purpose.

[treellama]

One possibility for the future of this thread is for it to become a place to post "me too"s about how awful the mouse support is. Seems like it's on that track, so if that's all you want, feel free to continue.

An alternative route is to make specific, concrete suggestions on how it might be improved. So far there haven't been any; perhaps I need to ask more explicitly.

When making such suggestions, please keep in mind the following limitations, the removal of any of which is outside the scope of our current development resources:Event handling is locked to the render loop, so drops in frame rate below 30 fps will be accompanied by corresponding choppiness in mouse samplingThere are not enough bits available to have the mouse directly control where the player is looking; instead it controls the player's vertical and horizontal aim acceleration, like the keyboard and joystick doWe are limited to the mouse input APIs available in SDL, which do not provide a means of disabling the OS mouse acceleration in Mac OS X or WindowsSo with those in mind, what specific improvements can be made to mouse control? Saying nothing more than "it's awful" or "it's not like this other completely different thing" (go figure!) will result in the thread continuing along the first course I laid out, which may have some value in itself if you just want to vent.

[goran]

Making concrete suggestions is difficult without a proper understanding of programming. They know what is wrong, but lack the power to describe it.

Treellama, are you familiar with how mouse control is done in Zdoom? If you are, is this applicable to aleph one, or does the three limitations you provided above block it?

The way I see it, the only way to progress in this thread, is to find out how mouse control is done in the "better" games, and see if there's any part of it that can be mimiced in aleph one. If there's not, one might as well close this thread already.

[treellama]

Treellama, are you familiar with how mouse control is done in Zdoom? If you are, is this applicable to aleph one, or does the three limitations you provided above block it?

I'm not, but I assume it's been upgraded to work similar to the later Quake games, which are free of all three restrictions. The numerous Doom ports have had a ton more development due to Doom's popularity. You can, for instance, freely look up/down in ZDoom, which our renderers don't support.

So, saying "be like them" isn't going to help. Suggestions like "try to make the mouse sensitivity sliders more intuitive," which is on my list, might.

Combative hyperbole like "it's unplayable" when so many of use it just fine, is the opposite of helpful.

[goran]

Combative hyperbole like "it's unplayable" when so many of use it just fine, is the opposite of helpful.

Yeah that stuff is downright wrong. I played some solo today and kicked ass. Mouse, no problem.

[Corrasion]

In ZDoom, mouse works pretty much like in any other 2.5D game. In fact, most of the early shooters I know had decent mouse support, including vanilla Doom.

There are two main oddities with Marathon mouse: speed threshold and speed cap. Regardless of sensitivity and acceleration, you get imprecise aiming and inability to perform sharp turns. It looks more like hardcoded limitation actually.

But maybe acceleration slider would help a little bit, I dunno.

[Wrkncacnter]

Combative hyperbole like "it's unplayable" when so many of use it just fine, is the opposite of helpful.

While entirely unhelpful, it's not 100% untrue, and not everyone cares about being helpful. The mouse is only "playable" if you take the time to get used to it, and only people that are already Marathon fans are going to take the time to do that. For the record, I'd be pretty pissed off if the engine changed so much as to allow a good mouse implementation. I'm just glad you finally posted so we can point to your post whenever this topic comes up, and tell people to STFU. Apparently, my post wasn't informative enough.

[treellama]

Regardless of sensitivity and acceleration, you get imprecise aiming and inability to perform sharp turns.

The former is probably due to the limited (9-bit) angular precision in the engine. For the latter, the maximum angular velocity is a function of the physics model in use, not the engine itself.

[gmanyo]

Since the only game I've played extensively with mouse support is Marathon, I can't say that I've had a whole lot of problems with it, but I can agree with Corrasion that the imprecise aiming is annoying. I realize that there is a hardcoded problem with fixing this, but are there alternative ways to achieve at least pseudo-correct aiming? For example, would it be possible to have a very slight "auto-lock" feature? I guess things like this might be closer to hacks than to really fixing the problem, but at least they'd be something.

Alternatively, you could always just 4get.

[interion]

The former is probably due to the limited (9-bit) angular precision in the engine. For the latter, the maximum angular velocity is a function of the physics model in use, not the engine itself.

I've generally blamed the poor mouse control on the angular precision which is why I haven't been complaining, even though it is the reason why I've basically stopped playing online. As I get older it's become harder to tolerate the controls, especially at higher resolutions, but I know the limit is deeply ingrained in the engine.

However, I've always wondered if it's just the effort to maintain backwards compatibility that is keeping these engine limits in place. If you ripped out film support, rewrote the network protocol, updated the save file format and so on, would it be possible to make a more modern engine build optimized just for online multiplayer Infinity games? I mean, aside from the enormous amount of work it would take.

[treellama]

However, I've always wondered if it's just the effort to maintain backwards compatibility that is keeping these engine limits in place. If you ripped out film support, rewrote the network protocol, updated the save file format and so on, would it be possible to make a more modern engine build optimized just for online multiplayer Infinity games? I mean, aside from the enormous amount of work it would take.

Sure it's possible. That's essentially what Freeverse did, after all. It's even possible to do all that and preserve backward compatibility. It's really the enormous amount of work that's the obstacle to having everything. We prioritize things we think we have time to do.

[Crater Creator]

I realize that there is a hardcoded problem with fixing this, but are there alternative ways to achieve at least pseudo-correct aiming? For example, would it be possible to have a very slight "auto-lock" feature? I guess things like this might be closer to hacks than to really fixing the problem, but at least they'd be something.

When I wrote a hitscan projectiles lua script, it crossed my mind that it would arguably be reasonable for the game to register a hit if your target is within half a frogblast of where you're aiming (weapon inaccuracy withstanding). That is, when it's not possible to aim any more closely at the target due to that 9-bit precision on angles, the game gives the player the benefit of the doubt. I haven't figured out a way to do it in lua with any kind of efficiency yet, but as you say, it could be something.

[Blastfrog]

I really wish I could be helpful in solving the mouse issue, but I just don't know how to describe the problem in more detail, I just figured that it already intuitively obvious how broken it feels when actually playing.

I don't think the problem is the angle precision, I think it's more just how bizarrely it handles the speed threshold and the speed cap. As of right now, it feels more like joystick emulation than it does moving a mouse cursor. The solution is to make mouse aiming feel just like moving a mouse cursor, if that helps in setting some sort of goal for how it should feel when playing.

For the record, I'd be pretty pissed off if the engine changed so much as to allow a good mouse implementation.

Even if it was an option, and not the default behavior?

I fully support keeping the old controls in for those that like it better, and for film compatibility, but all I ask is that the players that cannot play with it how it is get an option to have more mainstream style mouse control.

[treellama]

As of right now, it feels more like joystick emulation than it does moving a mouse cursor.

Thanks for clarifying your issue with mouse control! Unfortunately all I can do is refer you to item two in my list of limitations we don't have the resources to fix right now.

[Wrkncacnter]

Even if it was an option, and not the default behavior?

Perhaps, but I don't have faith that some random coder sending in a mouse fix patch would do a very good job at maintaining the way the game currently feels. Please feel free to prove me wrong.

[Blastfrog]

Unfortunately all I can do is refer you to item two in my list of limitations we don't have the resources to fix right now.

Ah, I see how that particular limitation screws things up a little. Well, since the algorithm for how the view acceleration is handled is obviously known, perhaps a new form of mouse control could be added that takes this in mind and provides input to that acceleration system that when interpreted by it, could feel more like moving a mouse cursor? So it wouldn't truly be controlling the view directly, but the end result would be very close, if that makes any sense.

How about this implementation, from my very limited understanding of programming? How about every frame, center the mouse position on the screen, and just before resetting it again, compare how many pixels it moved from the center? (similar to how many FPS games appear to work if you have the cursor visible) Then, those results could be taken, and translated into an acceleration value that has equivalent results to as if the view direction were being directly manipulated?

Again, please tell me if this solution is unclear, I tried to make the concept of this solution as clear as possible.

[treellama]

How about this implementation, from my very limited understanding of programming? How about every frame, center the mouse position on the screen, and just before resetting it again, compare how many pixels it moved from the center? (similar to how many FPS games appear to work if you have the cursor visible) Then, those results could be taken, and translated into an acceleration value that has equivalent results to as if the view direction were being directly manipulated?

This is actually how it's implemented already--the difference in pixels from the center of the screen is translated into a fixed point number, which is scaled according to Aleph One's mouse sensitivity sliders. The resulting delta is then compressed into the misnamed absolute pitch or yaw bits in the action flags, which directly become the player's angular velocity for the next world update.

Translating to the appropriate angular velocity to match screen movement is just a function of getting your mouse sensitivity adjusted right (as ukimalefu tried to tell you). Perhaps it would help to adjust the numbers directly in the preferences file, as opposed to the fiddly onscreen sliders?

[treellama]

For the latter, the maximum angular velocity is a function of the physics model in use, not the engine itself.

I was wrong! Rereading this code (it's been a while!), the physics model maximum angular velocity is ignored when absolute yaw is used, so the inability to turn quickly is probably a result of the limited precision in the absolute yaw bits. There are only 7 bits available for that in the action flags, compared to the 9 bits angular precision, so it seems you're limited to turning 1/8 circle every 1/30 second.