Mouse controls

Have a question, suggestion, or comment about Aleph One's features and functionality (Lua, MML, the engine itself, etc)? Post such topics here.

Post Dec 4th '11, 01:21

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?
User avatar

Blastfrog

Post Dec 4th '11, 19:10

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.
Video Gamer Blog (With some articles by me!)

Look at Him Go, Weeee
User avatar

Zott
Earth

Post Dec 4th '11, 21:32

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.
User avatar

treellama
Pittsburgh

Post Dec 9th '11, 08:02

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

Post Dec 9th '11, 08:02

(oops, duplicate post)
Last edited by HunterZ on Dec 10th '11, 05:37, edited 1 time in total.
HunterZ

Post Dec 17th '11, 05:30

Treellama wrote: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.
User avatar

Blastfrog

Post Dec 17th '11, 08:42

ADJUST THE MOUSE SENSITIVITY

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

ukimalefu

Post Dec 17th '11, 09:21

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.
User avatar

Wrkncacnter

Post Dec 17th '11, 12:48

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 sampling
  • There 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 do
  • We 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 Windows
So 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.
Last edited by treellama on Dec 17th '11, 12:52, edited 1 time in total.
User avatar

treellama
Pittsburgh

Post Dec 17th '11, 13:27

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.
Last edited by goran on Dec 17th '11, 13:28, edited 1 time in total.
User avatar

goran

Post Dec 17th '11, 16:00

goran wrote: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.
Last edited by treellama on Dec 17th '11, 19:52, edited 1 time in total.
User avatar

treellama
Pittsburgh

Post Dec 17th '11, 16:13

Treellama wrote: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.
Last edited by goran on Dec 17th '11, 16:14, edited 1 time in total.
User avatar

goran

Post Dec 17th '11, 20:17

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.
Corrasion

Post Dec 17th '11, 20:46

Treellama wrote: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.
User avatar

Wrkncacnter

Post Dec 17th '11, 21:14

Corrasion wrote: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.
Last edited by treellama on Dec 17th '11, 21:16, edited 1 time in total.
User avatar

treellama
Pittsburgh

Post Dec 18th '11, 00:33

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.
Image
User avatar

gmanyo

Post Dec 18th '11, 01:53

Treellama wrote: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.
Image Image
User avatar

interion

Post Dec 18th '11, 02:08

Tim wrote: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.
Last edited by treellama on Dec 18th '11, 02:09, edited 1 time in total.
User avatar

treellama
Pittsburgh

Post Dec 18th '11, 02:26

gmanyo wrote: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.
User avatar

Crater Creator

Post Dec 18th '11, 04:05

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.

W wrote: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.
Last edited by Blastfrog on Mar 30th '13, 16:04, edited 1 time in total.
User avatar

Blastfrog

Post Dec 18th '11, 04:10

Sodaholic486 wrote: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.
Last edited by treellama on Dec 18th '11, 04:14, edited 1 time in total.
User avatar

treellama
Pittsburgh

Post Dec 18th '11, 04:39

Sodaholic486 wrote: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.
User avatar

Wrkncacnter

Post Dec 18th '11, 05:36

Treellama wrote: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.
Last edited by Blastfrog on Dec 18th '11, 05:39, edited 1 time in total.
User avatar

Blastfrog

Post Dec 19th '11, 01:34

Sodaholic486 wrote: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?
Last edited by treellama on Dec 19th '11, 01:41, edited 1 time in total.
User avatar

treellama
Pittsburgh

Post Dec 19th '11, 01:39

Treellama wrote: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.
Last edited by treellama on Dec 19th '11, 15:12, edited 1 time in total.
User avatar

treellama
Pittsburgh

Next

Return to Aleph One Discussion



Who is online

Users browsing this forum: No registered users