DMU — A Glowing Concern?
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Engine, Games.</i>
In versions prior to 1.9.0 glowing surfaces (eg wall glows) have been managed internally with the textures/flats themselves having the "glowing" property. This property is declared using the <strong>RENDER_GLOWFLATS/TEXTURES </strong>text string definitions.
In 1.9.0 the property "glowing" is assigned to the surface when the texture/flat on that surface is changed. Currently this is handled by polling for changes in UpdatePlanes() but since we no longer need to do the costly polling, thanks to DMU, we can inform the relevant subsystems (ie the renderer) directly when a flat/texture change occurs.
Properties such as "glowing" should be assigned to the surface as it allows for more dynamic manipulation. For example the height, colour etc of plane glows could be changed via XG.
Glowing textures in 1.9.0 will be defined using the Decoration{} definitions in DED.
<ul>
<li>First of all - should we still support the <strong>RENDER_GLOWFLATS/TEXTURE</strong> text strings?</li>
</ul>
The point I wish to raise is:
As we will be informing the renderer directly when a flat/texture change occurs via DMU, it is at this point that we will be making the decision of what happens when a surface that was perviously using a "glowing" flat/texture, is now not. During the course of its life the surface may have had it's "glowing" properties changed while the texture on that surface has stayed the same.
The question is how do we decide if the "glowing" propeties of that surface should persist when a texture change occurs?
Currently the games will use DMU eg:
<strong>P_SetIntp(DMU_SECTOR, sector, DMU_FLOOR_TEXTURE, 37)</strong>
to make the change. The problem is that this change requires addtional information to make the decision on what to do with the "glowing" properties.
It would be simpler if the "glowing" properties of a surface were not influenced by the texture/flat used on that surface and instead could be manipulated as seperate properties eg:
<strong>P_SetInp(DMU_SECTOR, sector, DMU_FLOOR_GLOW_HEIGHT, 30)</strong>
In versions prior to 1.9.0 glowing surfaces (eg wall glows) have been managed internally with the textures/flats themselves having the "glowing" property. This property is declared using the <strong>RENDER_GLOWFLATS/TEXTURES </strong>text string definitions.
In 1.9.0 the property "glowing" is assigned to the surface when the texture/flat on that surface is changed. Currently this is handled by polling for changes in UpdatePlanes() but since we no longer need to do the costly polling, thanks to DMU, we can inform the relevant subsystems (ie the renderer) directly when a flat/texture change occurs.
Properties such as "glowing" should be assigned to the surface as it allows for more dynamic manipulation. For example the height, colour etc of plane glows could be changed via XG.
Glowing textures in 1.9.0 will be defined using the Decoration{} definitions in DED.
<ul>
<li>First of all - should we still support the <strong>RENDER_GLOWFLATS/TEXTURE</strong> text strings?</li>
</ul>
The point I wish to raise is:
As we will be informing the renderer directly when a flat/texture change occurs via DMU, it is at this point that we will be making the decision of what happens when a surface that was perviously using a "glowing" flat/texture, is now not. During the course of its life the surface may have had it's "glowing" properties changed while the texture on that surface has stayed the same.
The question is how do we decide if the "glowing" propeties of that surface should persist when a texture change occurs?
Currently the games will use DMU eg:
<strong>P_SetIntp(DMU_SECTOR, sector, DMU_FLOOR_TEXTURE, 37)</strong>
to make the change. The problem is that this change requires addtional information to make the decision on what to do with the "glowing" properties.
It would be simpler if the "glowing" properties of a surface were not influenced by the texture/flat used on that surface and instead could be manipulated as seperate properties eg:
<strong>P_SetInp(DMU_SECTOR, sector, DMU_FLOOR_GLOW_HEIGHT, 30)</strong>
Comments
<blockquote>First of all - should we still support the RENDER_GLOWFLATS/TEXTURE text strings?</blockquote> The reason why this mechanism exists is to mark certain flats/textures as being light-emitting. If the feature were introduced now, it would most certainly be a new DED entry in a Flat {} and Texture {} definition. However, there is no reason to drop this support. We still need a way to say that certain flats (e.g., lava) are always glowing. Furthermore, we should add a way to define the glowing parametes (height, color) someway, preferably in a DED, per flat/texture.
Now, do we also need to be able to control the glowing properties per surface (plane/wall)? It could be useful, but it is a feature that can only be utilized by actual program code in the game lib. (DEDs and GLOWFLATS/TEXTURES can easily be defined by map authors.) As such, it is less important in my opinion. It would also complicate the renderer's task since it would have to make the decision whether to use the common glowing properties of the flat/texture or the properties specific to the plane/wall.
I agree it will complicate matters. However, dynamic control of plane glows is a feature that map authors have requested (most prominent is the D64TC) and is one that wouldn't take much more work to implement. Height and color is now handled internally on a per surface basis.
To clarify - there wouldn't be two sets of glow parameters. A texture change would (optionaly) set the surface glow properties.
<blockquote>It could be useful, but it is a feature that can only be utilized by actual program code in the game lib.</blockquote>
I'm thinking via XG yes.
Perhaps I don't fully understand what you're saying, but to me there are indeed two sets of glowing parameters:<ul><li>The ones defined globally for a specific name of flat/texture, e.g., all lava flats. These currently have the glowing/not-glowing property, a height controlled by a cvar, and an automatically determined color. When the renderer notices that a plane is using one of these flats, it uses the globally defined glow parameters. If you change one of the global parameters even at runtime, say, the glow height, all the planes where the flat is used are instantly affected since they all are rendered using the same glow height variable. <li>Then there would be the per-surface parameters, which presumably have no relation to the flat/texture used on the surface. To change these, someone has to modify the parameters specific to the surface individually.</ul>
Thats a relief
<blockquote>I'm just saying that the old system of GLOWFLATS/TEXTURES exists for a reason and is still useful. In the scenario where you want to say that certain flats/textures should glow, without making any changes to the map itself, you can just define the flats/textures as glowing.</blockquote>
Ok. I had already re-implemented support for the old system, intergrated with the per-surface parameters so it will work either way. I was wondering if once we have DED access to the glow properties (for the flats/textures, not surface glows) if we would still require the old text string support.
When you get a chance - have a look at the implementation. Although there are two scenarios they effect the same glow properties (the surfaces).
All that is needed is a mechanism to say <strong>if</strong> Doomsday should apply the glow properties from the texture when the texture change occurs. Plus a facility to manipulate the glow properties of the surface (via DMU).
Nothing has been changed with how the old system of GLOWFLATS/TEXTURES functions, though it is handled differently internally.
I would think that if someone has manually set the glow properties of a surface (plane/wall), they should remain in effect no matter what happens.
In the default case, where no one has specially set a surface's glow properties, the glow properties should follow the global parameters defined for the flat/texture in use by the surface.
I'll take a look at the current implementation...
I thought it strange at the time I implemented it but for some reason I got the impression that it had to be done per-subsector...
The updating in <tt>UpdatePlanes{}</tt> was only a quick first attempt (I didn't put much thought into it as it would be replaced anyway when we remove the polling).
What are the other issues?
I'll make the necessary changes.
What if the glow of a surface was determined like this, whenever the surface needs to be drawn:
<ol>
<li>Check if surface has the "manual glow" flag set.
<li>If yes, use the manual settings (glow strength, color, height, etc.). Done.
<li>There was no manual glow set (the default case). Check if the currently used flat/texture has glowing parameters.
<li>If yes, use them. Done.
<li>There is no glow.
</ol>
The "manual glow" flag and other glow parameters would be the properties of a sector's floor/ceiling and lines, accessible through DMU.
Using the above logic it'll be possible to determine the new glow values once when any are modified without the need for polling.
I'll implement it so that no decisions have to be made beyond the time that a change occurs, setting the surface glow properties. We shouldn't need to make the decision each time the surface is rendered (I'm thinking about the future plans to dynamically freeze sections of the render lists).