Scrolling Textures

[4LT]

I wanted gauge interest in a scrolling texture feature. This would allow applying a scrolling effect on either a per-material or per-entity basis.

Proposal 1: Materials similar to Source .vmt or Quake 3 shaders

Materials could be paired with textures to apply effects, such as scrolling

e.g.

{
    "texture" "lava1"
    "scrollv" "0 -100"
}

Pros: Extensible with other effects, consistently re-usable
Cons: Complicated

Proposal 2: Per-entity scrollv scroll velocity parameter

Scrolling is controlled via a key scrollv with a vector value (third component can be ignored)

Pros: Simple, ergonomic for mappers
Cons: Affects entire brush instead of single surface

[4LT]

I'm partial to the per-entity solution myself

[4LT]

@andrei-drexler is there any condition under which you would consider accepting a pull request for adding scrolling textures?

[4LT]

Looking at the alpha and scale code, seems that this would require changing the network protocol to get this to work. :/

[andrei-drexler]

Hey! I appreciate you wanting to help (especially since it's not the first time), and I do think that for a Quake engine also targeting stand-alone projects this would make a lot of sense, but I'm not sure there's a compelling use case for it here when the most popular source ports used to play Quake content (QS, KEX) don't have it. I see this as an alternative to the current practice of using animated textures to emulate the effect, but I don't think mappers would want their waterfalls and conveyor belts to scroll smoothly in IW and not at all in all other engines.

[4LT]

I think there's a perception that IronWail is the the spearhead for new features among many in the community, especially among the QM discord. (As a moderator of said discord, I'm biased, and I recognize that it does not represent the entirety of the Quake nor Quake mapping community). The recent release Dwell v2 recommends IronWail over other engines, and doesn't even mention Kex. Besides, I think if something takes root in IW, there's a good chance it may be backported to VkQuake and QS, e.g. lit water.

And no offense to the Kex port developers, but its had its days numbered since release. It played its part in bringing in new players and adding some cool new levels, but because it utilizes the Kex platform it's permanently locked out of the FOSS ecosystem, and it's not commercially viable to maintain it indefinitely.

Anyways, I don't have much skin in this game, just something I thought would be low-hanging fruit to implement, and it's the one feature Doom has over us Quake people ;) though I was spurred to create this discussion topic after reading a discussion bemoaning the slow speed of animated textures for about the 100th time.

[lavenderdotpet]

please please please add this in!

[perondeidad]

Proposal 1: Materials similar to Source .vmt or Quake 3 shaders

Dude, FTE already has this function since 2009

[lavenderdotpet]

Q3A can do this because Q3A is designed from the ground up for it. But retro-fitting it to a regular Q1 chassis is another matter.

this does make me wonder how retroquad does it

[mankrip]

Q3A can do this because Q3A is designed from the ground up for it. But retro-fitting it to a regular Q1 chassis is another matter.

this does make me wonder how retroquad does it

Retroquad uses a very flexible texture naming convention, but most of the downsides mentioned by mhQuake still applies. Even though Retroquad's naming convention supports direction and velocity (and turbulence, and animated frames all together), you need a different copy of the texture for each direction and velocity, which is a waste of RAM and storage.
I do have some plans for a more optimized and flexible scrolling texture system, but as mhQuake pointed out, such a thing requires a lot of work.

[TLWmarko]

The way which is probably the most flexible and simple that I can think of which also shouldn't require any protocol updates, is having settings be in a info_notnull entity. So it could have a _textureTarget field which is the name of the texture to be scrolled, and a vector for scroll speeds. The engine just finds an info_notnull which has this pattern of fields and thus classifys that texture as scrolling, and no QC required. Engines which don't support them simply have them standing still, which IMO is a fine fallback. QC can then also optionally be used for modifying speeds, and thus also turning it off, or even accelerating or what have you. If you want textures to start as not scrolling but eventually start scrolling via QC they would need a info_notnull with zeroes in the speed field, so the engine can pick up any potential changes being applied. If a mapper wants the same texture scroll in different directions/speeds they'd need to make a copy of that texture, which should be a reasonable workflow as it shouldn't be too common.

I collabed with mankrip on the spec used in RetroQuad, but having thought about it some more I think this approach is probably "perfect" unless I overlooked something. It still has the downside mhQuake mentions that it will require maintenance and can get in the way for other features, which is inevitable with new features for sure. The case I would make for scrolling textures being a good fit though, much like distance fog, .lit files and fence textures which are basically taken for granted now, is they all fit the retro sensibilities/style of Quake. Scrolling textures would imo bring that final retro-compatible feature into the mix.

[mhQuake]

The way which is probably the most flexible and simple that I can think of which also shouldn't require any protocol updates, is having settings be in a info_notnull entity. So it could have a _textureTarget field which is the name of the texture to be scrolled, and a vector for scroll speeds. The engine just finds an info_notnull which has this pattern of fields and thus classifys that texture as scrolling, and no QC required. Engines which don't support them simply have them standing still, which IMO is a fine fallback. QC can then also optionally be used for modifying speeds, and thus also turning it off, or even accelerating or what have you. If you want textures to start as not scrolling but eventually start scrolling via QC they would need a info_notnull with zeroes in the speed field, so the engine can pick up any potential changes being applied. If a mapper wants the same texture scroll in different directions/speeds they'd need to make a copy of that texture, which should be a reasonable workflow as it shouldn't be too common.

I collabed with mankrip on the spec used in RetroQuad, but having thought about it some more I think this approach is probably "perfect" unless I overlooked something. It still has the downside mhQuake mentions that it will require maintenance and can get in the way for other features, which is inevitable with new features for sure. The case I would make for scrolling textures being a good fit though, much like distance fog, .lit files and fence textures which are basically taken for granted now, is they all fit the retro sensibilities/style of Quake. Scrolling textures would imo bring that final retro-compatible feature into the mix.

I like the idea in principle, but the entity information would still need to be transmitted from the server to the client over the protocol. Otherwise you'd need to code up some kind of client-side entity parsing, which seems like it would take away a lot of the simplicity of the solution.

So unless we overload the behaviour of a regular entity type, we're back to some kind of protocol change.

[TLWmarko]

This is true, I forgot it doesn't transmit invisible entities, and only a select few fields. Either there's some neat hack or it's back to the drawing board. Bummer

[mhQuake]

While looking over something else, I see that the texinfo struct has a full 32-bit integer for flags, but only TEX_SPECIAL (value 1) is used in standard Quake (FitzQuake and derivatives added TEX_MISSING with a value of 2).

So we actually do have texture flags available in Quake 1, but they're on the parent texinfo struct, not on the texture itself, and these are potentially usable for anything, including scrolling. They would require tool as well as engine support though, but that's probably OK and the way it should be.

[mankrip]

While looking over something else, I see that the texinfo struct has a full 32-bit integer for flags, but only TEX_SPECIAL (value 1) is used in standard Quake (FitzQuake and derivatives added TEX_MISSING with a value of 2).

So we actually do have texture flags available in Quake 1, but they're on the parent texinfo struct, not on the texture itself, and these are potentially usable for anything, including scrolling. They would require tool as well as engine support though, but that's probably OK and the way it should be.

Good idea.

However, it would be good to have a way to specify velocity (speed and direction). Thinking about this, the first ideas that comes to mind are to store either angle and speed, or x and y velocity.

Some way to toggle conveyor belts on and off, change speed, etc through the gamecode would also be good. Supporting that in savegames would be tricky, though, because it could easily desync (think about a conveyor belt carrying objects placed on specific positions over it).

So, the most reliable way to store the scrolling data in savegames would be to store the scrolling offsets. This allows people to define an interpolation interval for the offsets instead of setting a velocity (and also allows them to update the offsets at custom timeframes, which is lighter on the network protocol than updating them every 0.1 seconds); also, modifying the offsets while keeping the interpolation interval at zero could be interesting for some effects, such as scrolling LED panels that scrolls a whole LED per step. And for surfaces that are always scrolling at the same speed, it's interesting to define the x and y size of each step, plus the frequency at which the steps are performed, this way the engine can automatically add a scrolling step to the scrolling offsets on every cycle of the frequency.

This leaves us with these values for the scrolling:

• Texture name (should also accept textures with animated frames, turbulent textures, alphamasked "fence" textures, and scrolling sky textures);
• X and Y offsets;
• X and Y step sizes (or a combination of step size and step angle);
• Step frequency;
• Interpolation interval.

Such offsets would have to be stored independently of the offsets that are already part of the BSP data, because the modder would want to affect all instances of the same scrolling texture by the same amount, regardless of their local positions on each surface of the entity.
And the texinfo flags you mentioned would be useful to make sure that only the surfaces matching both texturename and the texinfo flag would be affected (thus allowing mappers to reuse the same textures in non-scrolling surfaces of the same entity).

I suggest that the .texinfo flag for it be named something like TEXVFXSUBENT, which makes it clear that there's a subentity applying some texture effects on the surface linked to this texinfo.

Now, how to implement it on the gamecode?
The data needs to be stored in the savegames, so the best approach is to use subentities with the texture parameters defined as fields of those subentities. And since the pointers of the entities can be randomly assigned during map load, we need to assign those subentities using a scheme similar to the .target & .targetname scheme used for triggers.

Intuitive fields for the BSP entity would be:

• .entity texture1, texture2, etc and their corresponding
• .string texture1id, texture2id, etc.

And for the subentities, the values mentioned in the list of values way above, plus .string textureid (which should match .string texture1id, texture2id, etc on the BSP entity). I'd recommend using .string instead of .float for the texture IDs, this way mappers can write IDs that are easier to memorize.

To sum it all up, a fully-featured implementation of texture scrolling requires changes to:
Map data, and probably also the map format;
Network protocol, and qc gamecode;
Savegames, adding more data to them.

Some advantages of this approach:

• Scrolling skies in the world BSP can have their speed customized. The overlay can have its individual scrolling parameters defined in a subentity of the sky texture subentity.
• The same scrolling texture subentity can be shared with multiple BSP entities, making it easy for the mapper to reuse scrolling textures on different entities.
• In practice, it also allows modders to switch textures by changing the .texturename on the subentities, giving modders the power to create custom texture frame animations using any textures with flexible gamecode-programmable timing. Not only this is more flexible than the built-in automated frame animation system of vanilla Quake, it can also consume less RAM and storage memory because the same textures can be used in both animated and non-animated surfaces (which is a significant win when using HD textures). Such custom frame animations would need an additional parameter to define their interpolation interval, though. Maybe .positiontiming for the offsets' steps, and .frametiming for the custom frame animations.
• It covers all possible use cases, so there's no need to implement any other standards for scrolling textures in the future. So, while it can take a lot of work to be implemented at first, it will make the engine easier to maintain in the long run.
• The featureset of the subentities can be easily expanded to offer more features in the future, such as per-texture transparencies.

However, I'm afraid most people would not care enough about the flexibility of this approach and the possibilities that it offers, which is why I'm not putting effort into it yet. Most people would likely be happy enough with the inflexible approach from Quake 2. I'll only code my implementation when I'm actually creating a game using it.

[mankrip]

Speaking of conveyor belts, there must be a distinction between scrolling textures that are purely visual (like scrolling text displays) and scrolling textures that can move other entities around (like conveyor belts). This must be a part of a fully-featured standard, and included as a subentity field. I don't know the best words to describe such a feature in English though. "Grip"?