Fog & Scrolling Texture Improvements (Patreon)

A new cvar called r_fog_alphacurve was implemented, which helps to make fog in Retroquad look closer to the fog in other engines. There are more details and many comparisons in this Twitter thread.

So far, the only map where r_fog_alphacurve looked actually worse was "Teh Ratz in the Walls" (see the screenshot in Quaddicted for a comparison). I suspect that's because the fog in that map is too desaturated and the color quantization used for fog prioritizes saturated colors in order to get more faithful hues.

The "fog" command has also been overhauled, and now it supports a "modifier" mode where you can modify a single parameter of the current fog while preserving the others. This makes it easier to do experiments with the fog.

In other news, a guy named Polo contacted me about creating a standard for scrolling textures. We had some talks, and here's my thought process, which resulted in the standard we have agreed to implement.

Me:

I couldn't decide on what minimum and maximum values would be good. If the minimum speed is too small, the maximum speed may be too slow. And if the maximum speed is too high, the minimum speed will be too fast.

Texture names only have 15 characters, so a fast diagonal movement with speed over 100 per axis would consume 8 characters (e.g. "]512]128"). Other texture naming effects such as warping and animated frames could easily consume another 4 characters ( "*" for liquids, and "+16" for animations). This would leave only 2 or 3 characters for the unique texture name, but specific liquid types can consume up to another 6 characters (e.g. "portal").  The water texture in this video combines all texture naming effects (liquid turbulency, specific "water" liquid type, animated frames, and scrolling), and has 19 frames of animation.

An ideal solution is to keep the speed values at a maximum of 2 characters, but this makes it hard to achieve a wide range of speeds. A way to specify a wide range of values with only 2 characters is to use alphanumeric notation, but this would confuse Retroquad's current name parsing code, which in turn would force us to only accept scrolling values at the end of the name (e.g. "waterb]2]4" instead of "water]2]4b"). This is an acceptable restriction.

With alphanumeric values in base 33 (0123456789abcdefghijklmnopqrstuvw), we could specify absolutely any speed from zero to 1024 using only 2 digits (ww = 1024). This is a good range, but people would bet very confused on how to set values encoded this way.

Base64 encoding is a popular format that could make adoption easier, and would allow us to specify any values from zero to 3969, which is an even better range. But the last two characters in Base64 ( "+" and "/" ) are an issue because the "+" character should be exclusive for animated frames, and "/" shouldn't be used in filenames (and we must ensure filename compliance for external textures - the conversion from "*" to "#" is bad enough).

At this point, we could use a modified Base64 that replaces the last two characters. But if we go a little further, creating a custom encoding in base 65, we can extend the range enough to specify any value from zero to 4096. To create this custom Base65 encoding, I propose we make the values from 0 to 9 use the characters "0" to "9" (to make the slowest speeds straightforward to specify), with the next values going from "A" to "Z", "a" to "z", and to keep the entire encoding (sort of) alphanumeric, I'd like to use the circumflex accentuated characters "â", "ê" and "ô". Parsing accentuated characters may be a bit of a hassle though, so I'm open for suggestions.

My point is that by making sure that the maximum value is a power-of-2, the textures at maximum speed will be able to scroll back exactly to the same position in 1 second, making synchronization easier to do.

Polo's comments:

I do quite like the first suggestion, the base 33 one, since it's least confusing and thus also easier to implement. If it can also still support more characters than 2, you could have even higher speeds.

Me:

Yeah, let's do the base 33 with up to 3 characters per value. There's even a calculator online to help people.

Base 33 also has the advantage of uppercase and lowercase having the same values, which eliminates casing issues with filenames.

We also discussed further about tools support.

Polo:

One detail also which I'm not sure if you saw is I realized the map compiler could also be used to modify a texture's name. So one could have a func_scrolling, which creates copies of the texture attached if the same texture is used somewhere else non-scrolling in the map, and replace the ending characters with [ and so on.

So with a compiler feature like that, people don't necessarily even need to use a calculator like that, or mess with their wads. But that's an extra feature, outside of the engine really.

Me:

An entity-based approach could use something similar to my other idea. There's no need to create an entire entity class for this, the BSP compiler could simply read the settings from custom field values in the same way that "_phong" does. That's up for EricW, though. I'm not sure if he'd like to implement it.

Polo:

Yeah it is up to ericw, but same goes with QuakeSpasm which I'm doing now. I just kinda wanna make sure this is well thought through and I make a good patch for them as possible so it's difficult for them to dismiss, especially if i get some mappers to feel excited about the feature. Then it's possible to make a patch for EricW's compiling tools as well, but that's secondary. I have already got some mappers excited.

Me:

I'd suggest using a field called "_scroll" with the values containing the name of the texture followed by the x and y speeds. Maybe multiple textures could be defined this way.

Example: "_scroll" "metal1 +16 -128 wood3 -8 +64"
The compiler would convert - and + to [ and ], as well as the speed values to base 33.

Maybe using multiple fields for multiple textures would keep things more organized:
"_scroll1" "metal1 +16 -128"
"_scroll2" "wood3 -8 +64"
"_scroll3" "rocky5 -4 +32"
// ... and so on

The only issue is that I don't remember if spaces are allowed in texture names. Spaces would corrupt the field value tokenization.

Polo:

Nice, yeah something like that!

I'll generally advocate for anything that feels the most natural for mappers, since if they don't care it's wasted effort. I can test if spaces are allowed in texture names.

Ok so, spaces are supported by everything except EricW compiler! So, in practice not supported.

Me:

Hmm, does the map editors (TrenchBroom and JACK) add quotes to texture names? I'll check Jack's maps.

Yeah, Jack doesn't quote the texture names. Perfect then!

Polo:

When I put quotes on the texture name TrenchBroom freaks out instead.

I guess that makes it safe to assume it's not supposed to be supported, even if TexMex and the WAD format does.

Then we also talked about gamecode support.

Me:

I guess that covers pretty much everything, except dynamic changes through quakec code.

QuakeC's bad support for string manipulation wouldn't let us read the speed values from such strings, and updating the string would require trimming it and concatenating the new values back into it; a lot of work.

I guess I'll eventually implement it through multiple fields:

// texture 1
.string scroll1 = "metal1";
.float scroll1speed_x = 16;
.float scroll1speed_y = 8;

// texture 2
.string scroll2 = "metal1";
.vector scroll2speed = '32 64 0';
// can also be set this way, but wastes an extra value since _z isn't used.

// texture 3... and so on.

The good point about using the fields this way is that people can use vector math directly.

Enumerated fields can take some more work to implement, but I don't see a better solution.

By the way, personally I'd use .string scrolltexture1 instead of .string scroll1 because this would eliminate the chances of conflicts with old mods that could've used such a field name for other stuff. But I guess that most mappers and modders wouldn't like such a long field name. Like, scrolltexture1speed_x is quite long indeed.

The QuakeC stuff will be more complicated indeed. There's a few more things to consider in it.

Polo is coding support for this naming standard in QuakeSpasm, and I'll adjust the necessary parts in Retroquad to make it compliant. This is quite an exciting development since it's possibly going to be implemented on multiple engines going forward.

The gamecode support will be more complex to implement because the game will have to keep track of the timing and positional offsets to ensure that every time the speed is changed, the texture will continue the scrolling from the previous scroll position.

Exposing the positional offsets to the gamecode will also allows modders to implement custom scrolling algorithms in the gamecode (e.g. scrolling by X integer units at a time to simulate oldschool LED matrix panels).

Gamecode support for scrolling textures will also require some changes to the network protocol.

I'm working on the gamecode method alone, but if the texture naming + QBSP compiler method gets accepted by mappers, Polo may also implement the gamecode method in QuakeSpasm.

In real life news, my financial situation keeps getting worse and I've been having panic attacks non-stop for the last couple months. I've spent weeks getting the documentation to try to renegotiate my biggest loan, and this Tuesday I should go to the bank to try to renegotiate. This biggest loan has been consuming over 30% (right now, 48%) of my salary for the last 3 years, which is illegal, so if the bank refuses to renegotiate, I'll have to sue the bank — which would be a painful process. But if the bank accepts to renegotiate, this should stabilize my financial condition and I should be able to pay my late bills (including this month's credit card bill, which I just defaulted) in a few months.