Thus far, I've only seen one control scheme for touchscreen that was "ok" (Minecraft) but have some thoughts for improvement.

The difficulty of "getting it right" somehow increases the appeal to me. 

Mark V merely defaults always run on. Like what happens in the original Quake if you toggle it.

Gunter is arguing it should do more than that because turning on "Always run" in original Quake didn't also increase backspeed or sidespeed.

Which I didn't do in Mark V because in my opinion it should use the FitzQuake definition of always run.

So Gunter is arguing against the original Quake behavior, saying Mark V's "always run" should do more (ProQuake's always run sets all 3, for instance).

+speed - I myself have never found a scenario where I would want to walk instead of run in Quake. Not in any of hundreds of single player maps. Not in any of countless of multiplayer games/maps. But I can describe scenarios where changing it to Quake 2 style is a behavior change in original Quake.

I might be a bit of bad person in that I find both of the above kind of topics on the "boring side" of the spectrum. 

OK, I suspected that didn't come across as clearly as intended.

Just to summarize:

Quake has two run behaviours, and they're both different.

"Always run On" via the menus just bumps the values of cl_forwardspeed and cl_backspeed.

+speed applies the value of cl_movespeedkey uniformly to all axes of movement.

Quake II's behaviour is identical to +speed in Quake 1. Let's not get the idea that anybody is advocating for porting "Quake II movement" to Quake 1, because that's not happening.

What Gunter is arguing, and I am supporting him in this, is that the Quake behaviours should be consistent.

This is a simple matter of player expectation and principle of least surprise. If you have a "+speed" key, you expect it to have the same behaviour as "Always run On". 

I prefer the mark_v and fitz implementation of always run. I find quakespasm is too quick to judge when you strafe 

@fifth - Agreed. And because Mark V is intended to preserve the feel of FitzQuake. Modern ProQuake does what Gunter advocates and it doesn't feel exactly the same to me. So I stuck with the FitzQuake way.

@mh - The behavior of +speed is described here .... http://www.quakewiki.net/archives/console/commands/quake.html#c-+speed

Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?

My thought is this is already available to a user if they decided to do so. So it is not necessary to break defined and known Quake functionality like what, say, Quakespasm does. 

QuakeSpasm, Fitz and MarkV are all the exact same so far as strafing is concerned. No difference whatsoever in the code. 

Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?

Sigh.

That's not what I'm saying. That's a side effect, not the main thing. The main thing is an "Always run" option that's the same as +speed.

You don't have to have +speed slow you down. Just change the "^" to "||" in the one line of code and it won't.

Again: the main issue is that "Always run" and "+speed" behave differently. I am saying that they should behave the same. That is all. 

And incidentally, the Quake wiki is wrong. That's not what +speed does; all you have to do is look at the code to see that.

https://github.com/id-Software/Quake/blob/master/WinQuake/cl_input.c#L313

What +speed does, in the original Quake code, is adjust all 3 axes of the final movement. It doesn't modify cl_forwardspeed or cl_backspeed. What's described in the wiki is what "Always run" in the menus does (with the exception of the cl_movespeedkey part).

You see - two different behaviours. One modifies all 3 axes: forward/back, up/down, left/right; the other only modifies forward/back. One modified after the full movement is calculated; the other modifies before. One applies the value of cl_movespeedkey; the other just doubles. 

if that's the case why does QS feel a bit twitchier on the strafing than Mark v?

I feel like I hit strafe in QS and I feel I have less control cause I shoot off so fast.

I'm not trying to be an ass about it, genuinely feels different to me. 

I think I'm seeing where you are coming from now. Quake has a number of inconsistencies in that department.

Like how +jump is slower in water than +moveup.

Quake is crazy like that :( 

I almost inserted the word "allegedly" when describing the +speed entry.

(As an engine coder, I don't trust a non-engine coder's description of what something does because they didn't use the code as reference. Although that page was made pre-source code release). 

Here is the "fucked up" thing.

Client movement is "normalized" (vector math).

So if you mess with the sidespeed max, it affects your diagonal movement speed.

This is (probably) why that behavior in Quakespasm doesn't feel like FitzQuake, because I think Quakespasm uses the same increases "all of them" that modern ProQuake does.

Which to me doesn't feel like FitzQuake, which in turn is why I didn't do that in Mark V. 

And when I say "normalized" --- I mean that increasing the sidespeed max has the consequence of decreasing the effective forward speed max when moving diagonally.

So even slight diagonal movement feels different than original Quake/FitzQuake/Mark V in an engine that increases all the speeds like Quakespasm or modern ProQuake. 

I have used QS more frequently recently and that's due to the music not working again in mark v and also the twitch integration in one of the QS forks.

Currently using Mark V off-cam and QS on cam. So there's that I guess.

I also have a "pure" quake folder with winquake and various folders with pretty much each engine.

But I do have to re-adjust my thinking when playing in QS due to the strafe differences. It's probably not noticeable to most people but it's fairly jarring to me for some reason 

QS changed some stuff in 2013, I think it now behaves like you suggest (+speed and "always run" both affect forwardmove/sidemove/upmove, +speed with "always run" slows you back down to walking speed):
https://sourceforge.net/p/quakespasm/code/797/

(I don't understand why that "cmd->forwardmove /= cl_movespeedkey.value;" line was added though.)

Baker, I play with always run on and do use shift to walk sometimes (e.g. useful for navigating narrow ledges to get to secrets). But I can see where you're coming from regarding keeping winquake / Fitz behaviour identically.

I have a hard time noticing the difference between sidespeed 350 and 400. 

I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed.

FifthElephant, look on the old page ( http://www.celephais.net/board/view_thread.php?id=60831 ) at post #1154. That will explain why the strafing feels different in Quakespasm (or if you are using a +speed key instead of "always run"). I believe that's actually the correct behavior -- you SHOULD sidestep fast if you are running, so you can avoid rockets and stuff.


I really dislike my sidestep speed suffering when "always run" is on. I know Baker has resisted making an adjustment to this behavior (which I believe is a flaw or oversight in Quake's original coding -- and I would much prefer it to be consistent as mh suggests), but my plea in that case it to leave the menu option defaulted to OFF (as it was in original Quake). It ends up being more config settings for me to return to Quake default behavior:

cl_forwardspeed 200
cl_backspeed 200
+speed


And I actually have a key bound like this:

alias +slow -speed
alias -slow +speed
bind b +slow

because sometimes I do want to return to walking speed, like if I want to position myself carefully to take a screenshot, or to get just the right sniper position, or if I want to build up a massive fireball for the Mage in FvF (his Delayed Fireball attack travels at walking speed, so if you are moving forward and firing them, you get like 4 of 5 of them all piled on top of each other, heh, for a massive explosion when they hit something).


Touch-screen controls? Yikes. That would be tricky. If someone really wants to play Quake on their phone, I'd say, "get a bluetooth gamepad," heh. Like the Ipega 9055 that clamps around your device.... 

Yes, my bad, that was indeed changed.

It looks as though that line was added to prevent cl_movespeedkey from being applied twice, once from the menu code and once from the following block.

Quake II drops the side speed default to 200, then when always running it goes to 400.

I wonder how all of this behaves with values of cl_forwardspeed set in configs? 

I just checked and Quakespasm also modifies forwardspeed and backspeed. Now I'm even more confused. 

Hey, what about a sort of compromise where the "Always Run" menu option would have 3 possible values:

Off
Forward-Backward
All Directions 

Regardless, anyone who doesn't like autorun behaving exactly like +speed can just set some cvars instead of using the menu item. Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg.

A reminder:

cl_forwardspeed 400
cl_backspeed 400
cl_sidespeed 350
cl_upspeed 200

Those are the values for when autorun is toggled ON from the menu in the original game. If you want to be able to walk, set cl_movespeedkey to less than 1 and use +speed to slow down.

Though you might want to set cl_upspeed to around 400 if you don't want to swim like crap. 

 

Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg

When I first started engine coding I discovered "expert user bias". I was building modern ProQuake, I added a field-of-view slider that went from 90 to 110. Spirit said "I use 130 and the slider doesn't go that far".

I wasn't for or against anyone's particular settings but it didn't take long to realize that accommodating all preferences while keeping things simple for the average user.

Expert users can already do what they want.

There are engines that try to appeal to all possible settings.

ezQuake has a ridiculous settings menu with several pages and each of them scroll. Likewise, DarkPlaces has menus galore.

I think this flies in the face of the KISS rule --- "Keep it simple, stupid!"

"Keep it simple, stupid!" -- is why conservative engines rule and why advanced engines are frustrating. 

I probably shouldn't harp on this, but this is what I believe ...

Bad engine design expresses itself in the form of menus. 

Well, the thing is: an average user would probably prefer autorun to behave in a modern, convenient way. The problem here isn't even the fact that there are subtle movement angle differences. There are more jarring symptoms of hackery.

Like, turning the autorun ON doesn't invert it. In other words, you can't slow down anymore. I can't recall any game made in the last 20 years that would behave like that.

Another thing is that the strafing speed is locked at 350, which means that you can't strafe slowly at all.

Bad engine design expresses itself in the form of menus.

This I agree with. Doom source ports are a great example of what happens when you pile up engine modifications and try to be flexible about them. Though the game was always at a disadvantage when it came to extending the gameplay functionality. 

There are also certain mod concerns with how the menu always worked.

Malice is probably the only example, but I consider it fairly important. Toggling "always run" forces certain speed settings upon the player, which is fine in Quake, but what if the mod wants different values?

Having a separate variable would allow mods like Malice to have a (somewhat) working autorun toggler that wouldn't break anything.

Just my two cents. Since I'm aware of the problem, it doesn't really affect me.