Here's a more complex one --- fullbright colors in water texture + software renderer

That didn't even occur to me, but yeah - a GL/D3D engine can just not draw a fullbright, but software doesn't even have the option.

Rather than remapping I think if it was me I'd probably do an extra colormap.

Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage

Not a problem. Most of the work is actually changing various cases of "if (surf->flags & SURF_DRAWTURB)" to "if ((surf->flags & SURF_DRAWTURB) && !litwater)" at runtime, so load time is fine.

Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined.

I think the don't know case was me being nitpicky more than anything else. It is possible but the probabiility is so low that I don't think you'd ever actually see it.

What would be more worrying is bad tools setting surf->samples for a drawturb surface in a map that shouldn't have lightmapped water, because that's really the only way you have of checking, but I don't know if such bad tools even exist. Either way, providing an r_lightmappedwater cvar that the user can set to 0 can help with that. 

Water with garbage fullbright pixels is a texture pack problem, as it always was with garbage fullbright pixels. I don't think it should be solved engine-side. That would only complicate things. 

Although not an official texture, *tele teleporter textures should probably be fullbright (not lit). Both Mark V and Quakespasm treat *tele textures differently.

dwere: Water with garbage fullbright pixels is a texture pack problem ... I don't think it should be solved engine-side

Sounds logical. 

tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group. 

Personally, I've had enough of having to do that with _phong 1 on all my func_details... 

The idea isn't to annoy the mapper by making him manually set the rules up on each func_group - I assume there would be default liquid lighting settings that are used if nothing is specified, but...if you want custom light behaviour on a certain liquid body then you can func_group the liquid and set some options...

Beats having hardcoded arbitrary rules for teleport textures and whatnot imo. 

Do it like surface lights - have an entity whose sole purpose is to specify the light properties (aka override the defaults) of a particular texture, which then applies to all instances of that texture in the map. No need to use func_groups.

I only thought of this because with custom liquid textures used for random things like teleporters or energy fields, the texture names can be unpredictable (I think Knave has a *starfluid texture or something) 

I think the special entity could work, although I don't think it's ever been done before - with surface lights, it's a single key that specifies that the light it's on should be duplicated and spread across all instances of that texture. It's not specifically a custom entity that does anything different to a normal light.

This is quite offtopic, anyway... 

I'm slightly tempted to add an (optional) auto-jump feature where a player at an edge will automatically jump *only* if they can make the jump at the current speed *and* they are running.

If they can't make the jump and are running, the option would work like "edgefriction 999999" (if you don't know what it is, you might try it) and make it very difficult to fall off an edge.

And perhaps have the option have an "automatic jump up" if forward progress requires a upwards jump that can be made.

(Because pressing "jump" seems to be an annoying burden if you aren't using a mouse + keyboard). 

But is it similar to quake 3's awesome stair clipping. I hate q1's momentum loss around short floor variances 

I can understand that this might seem attractive on accessibility grounds, but (and unless I'm seriously missing something) wouldn't it totally fuck with your game if you were playing with "always run" enabled? 

rebind the jump button to +run 

I don't fully get it, but it sounds like a terrible idea.

Why don't you just make it a full bot so the player doesn't have to press "attack" in addition to not having to press "jump?" Because "aiming" is an annoying burden if you aren't using mouse + keyboard... or, you know, if you just suck at Quake :p heh. I know you're probably thinking about Gamepad controls, but still, meh.


mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]). 

I know you're probably thinking about Gamepad controls, but still, meh.

I think he's talking about things like phones and tablets. Gamepad users don't have a problem with jumping. 

Touch screens is exactly what I thought it was too, where you might have left thumb to move, right thumb to look, tap to shoot, and ideally you'd like to be able to jump while moving and shoot while jumping but you're out of options for how to handle it. 

mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]).

I'm not sure about the details of how MarkV implements this.

I like the Quake 2 method which maintains a separate cl_run cvar and just multiplies the speeds by 2 if it's set. Seems less messy to me that Quake's faffing around with cl_forwardspeed. Any reasons why that hasn't been adopted (aside from "iiiiit's nottttt Quaaaaaakkkkkkkke", that is)? 

@Gunter - found your discussion of "always run" in the other thread; repeating here for info:

This is not a good setting to default ON. It's weird. It doesn't actually do what you'd think (make it like you're holding down the +speed run button) -- it just messes with your normal "walking" forward and back speed, but not your sidestepping speed, exactly. So you end up being able to run forward fast, BUT when doing so you sidestep slowly... EVEN AFTER you press the run button or use +speed in the console. Always Run must be switched off to get proper sidestep speed when running, even when using the +speed option (unless you make other settings, I guess?). Please default it back to off. A better fix would be to change the "Always Run" menu option to actually lock +speed on instead of whatever weird thing it currently does.

This is basically what Quake II does.

It's "always run" option, via the cl_run cvar, is exactly the same behaviour as the +speed key. In addition it has the following nice behaviour.

If "always run" is off, pressing the +speed key will speed you up.

If "always run" is on, pressing the +speed key will slow you down.

Even nicer, it's basically (aside from cvar declarations and removing the old cl_forwardspeed behaviour) a one-liner: https://github.com/id-Software/Quake-2/blob/master/client/cl_input.c#L304

I'm coming more and more strongly in favour of this being something that should be standardized across Quake engines. 

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.