Gldefs – zdoom wiki

Default is 1.0 A size multiplier for attenuated dynamic lights. It affects a light’s size and secondary size. It applies to any attenuated light defined after it and is inherited by included sub-lumps, but it only lasts for the lump it is set in. This was added to mitigate a recently-discovered problem with attenuated lights getting reduced in size, even on OpenGL 3+. The intent of the shrinking was to account for higher brightness of non-attenuated lights on OpenGL 2 and was never meant to be active on more modern versions. To rectify light definitions which exhibit the broken behavior, the factor should be set as follows: lightsizefactor 0.667

Once dynamic lights are defined, they must be bound to actors. There are two possible methods to do so; the binding can be done directly in the actors’ DECORATE code, or in the GLDEFS lump.


The most important difference is that bindings made in DECORATE code are preserved through inheritance, whereas bindings made in GLDEFS are applied only to the actor itself and not its descendants. For the first method, see the actor states article. The GLDEFS method follows.

• LIGHTNAME: The name of a previously defined light (see above). It is possible to bind multiple lights to a single object, however only at most two lights will be used on a given frame: the one bound for this object to this frame in particular, and the one bound to the sprite. If several lights are bound for the same object to the same sprite or frame, only the last binding applies.

The GLDEFS lump can also be used to define skyboxes similar to those used in Quake II, made from a textured cube. The textures must be specially polarized so that the skybox will not appear to be a cube when seen in the game. A skybox is defined with the skybox line, and followed by a list of textures within bracket. The given name can then be used as a texture name for the sky in MAPINFO.

The bottom picture must be aligned with the north picture so that it fits right just under it. The top picture must likewise be aligned so that it fits right just above the north picture, but after that it must be mirrored horizontally and rotated 180°. Skyboxes made for other games may not fit these specifications unless you use the fliptop keyword.

Another feature of the GLDEFS lump is to define brightmaps that can be used to alter the brightness of given pixels within an otherwise static image. Brightmaps can be defined for sprites, flats and textures, but not for patches. This can be used, for example, to make back-lit computer screens, an enemy whose eyes glow in the dark, or to light up only the weapon part of an image when an enemy fires, rather than lighting the whole enemy.

To create a brightmap, first an image must be created that defines the base brightness of each pixel in the image. Black represents 0 brightness (no change) while white represents full-bright. Normal light is grayscaled, but it is possible to use color in order to tint the light. Note that this is the minimum light level the pixel will show at; if the area the monster is standing in is not completely pitch-black, the pixels will be lit to the ambient surrounding light level. Therefore, an enemy standing in an area with full brightness (such as a sector with a light level of 255) will be completely unaffected by his associated brightmap.

If the iwad keyword is present within the definition, then the brightmap will not be applied if the image is replaced by a loaded PWAD. This is useful so that if the user is loading a PWAD that replaces a given enemy, the brightmap doesn’t end up trying to apply itself to a graphic which no longer represents the same thing, possibly resulting in an incorrectly-lit enemy or decoration. In general, you don’t need to worry about adding this keyword if you’re creating brightmaps for your custom creations.

The thiswad keyword acts as the iwad keyword, but only for sprites contained in the same file as the definitions. It can be used if you expect your mod to have its custom graphics overridden by another mod; making it mostly useful for autoloaded sprite packs. If both iwad and thiswad are given to the same definition, it will be applied if the sprite is either from the iwad or from the wad.

The disablefullbright keyword causes the renderer to ignore the bright keyword applied to a frame within DECORATE. This can allow a user to override fullbright sprites that would otherwise nullify the effects of a brightmap. It’s useful for player modifications because you can create an enemy which uses bright frames for its attacks, which will be seen by players who do not opt to allow brightmaps, or whose hardware doesn’t support it. For everyone else, the brightmaps will override these bright frames.

Use a Flats block to define a list of flats that have to glow. The glow will use default settings: the glow height is 64, the color is averaged from the mapped picture, and the flat is set to be fullbright. Use a Walls block in the same way, but for textures. Despite the "walls" moniker, keep in mind that they do not work if actually set on a wall; only on floors and ceilings.

Use a Texture entry to define the parameters yourself. Contrarily to "Flats" and "Walls", "Texture" is not a block and only define the glow for a single texture. The color parameter must be either a RGB hex triplet, such as C010A8, or one of the recognized X11R6 color name, such as SlateGray1 or PowderBlue. Optionally, a glow height parameter can be given to set how high the glow goes, this must be an integer. Optionally as well, the definition can be finished with the fullbright keyword. If this keyword is not given, the affected texture will not be set to be fullbright.

The first step is to write a complying shader function. Each fragment shader requires a single function, Process, to be correctly defined. The function returns a vec4 that corresponds to the color your pixel should be. The function takes in a single vec4 parameter called color. This value has already had lighting and fog applied to it, and consequently should be multiplied in to your result.

[Type] is an optional and is one of either Flat, Sprite, Texture, or PostProcess (see below.) This is useful to prevent ambiguity if the same name is used by several graphics of different kinds. corresponds to the graphic to which it is applied. corresponds to the text lump containing your Process function. is a floating point value that defines a multiplier to be applied to the timer uniform.

In GLSL, there are three basic data input types: attribute, uniform, and varying. uniform and varying data types are the only types available to custom fragment shaders. uniform values are set by GZDoom or ZScript; while varying values are those that have been processed by the vertex shader. It is recommended that you do not use these unless you are experienced in GLSL.