vera/nuclide
4
0
Fork 0
Code Issues 32 Pull requests Projects Releases Packages Activity

Overhaul of the entire documentation.

Browse source
This commit is contained in:
Marco Cawthorne 2022-10-02 17:10:54 -07:00
parent 41fb4d9ae7
commit 2a8081b042
Signed by: eukara
GPG key ID: CE2032F0A2882A22
80 changed files with 3097 additions and 221 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.gitignore vendored
View file

@ -1,4 +1,5 @@
*~
Documentation/html/
darkstar/
noffice/
pvk/

58
Documentation/Building.md Normal file
View file

@ -0,0 +1,58 @@
# Building
## Building the Engine {#engine}
The **build_engine.sh** will do that for you. It will still ask you to have at least
a certain amount of dependencies installed (such as the **GCC**, **GNU make** and the **X11/SDL**
headers for your platform.
### Dependencies
* subversion
* gmake
* gcc
* mesa-libGL-devel
* libgnutls-devel
* libopenal-devel
* libX11-devel
* libXcursor-devel
* libXrandr-devel
* libSDL2-devel (only if you pass BUILD_SDL2=1 in build.cfg)
## Building the Level Editor {#editor}
Handled by **build_editor.sh**.
### Dependencies
* gcc-c++
* gtk2-devel
* gtkglext-devel
* libxml2-devel
* libjpeg8-devel
* minizip-devel
## Building Game-Logic {#game}
You can build the game source tree with **build_game.sh**.
The script also takes a parameter. If you specify:
`./build_game.sh valve`
then it will only build the game-logic for the `valve` directory.
Otherwise, it will iterate through all of the game directories, look for a Makefile and build its default target.
It'll try use the **fteqcc** binary that's in the *./bin/* directory.
So make sure to build run **build_engine.sh** first.
Some distributions may carry the **fteqcc** compiler, but it usually is a very ancient version
that's probably not going to build any of this.
## Custom Configuration {#config}
There's a **build.cfg** file with which you can tweak build parameters of the various **build_** scripts.
For example, this is where you select between X11 and SDL2 builds. There you can specify which engine revision
you want to build and also which plugins you want to build along with it.
It's well commented, so I encourage you to check it out. However on some platforms, changing those settings
might introduce additional setup/dependency steps.
## Additional Information {#notes}
The game-logic is written in QuakeC, it is thus platform and architecture independent.
You do not need to rebuild the logic for each and every platform.
The results will be identical.

36
Documentation/Contributing.md Normal file
View file

@ -0,0 +1,36 @@
# Contributing
If you'd like to contribute code: Awesome.
There's just 2 very short requirements.
## Rule #1
The code must be yours.
It's simple:
* Do not take code that is by anyone else that is not you.
## Rule #2
No submission or decompilation of third-party code. This is important if you want to recreate behaviour from another game.
* We do not decompile - we reverse-engineer by trial and error.
This is generally referred to as 'clean-room engineering'.
Most of the behaviour is rather predictable, other is not.
This is why some of the parts of Nuclide, which emulate entities/frameworks
from other games may feel a bit off. It's because it's all implemented by eye.
# Other notes
Game specific features need to be put into game-specific directories.
Unless other games benefit from this, keep it seperate to one of the game
sub-directories. This usually means it'll be part of another git repository too.
That's about it!
# Saying Thanks
If you want to solely say thanks, the main developer of Nuclide **loves** receiving E-Mail. You can contact him at <mailto:marco@vera-visions.com> and let him know your thoughts.
If you'd like to donate to him via [PayPal](https://paypal.me/eukara) or [Patreon](https://www.patreon.com/eukara) you can do that too. That money pays for a lot of free services he provides that come with both [FTEQW](https://www.fteqw.org/) and **Nuclide**.

69
Documentation/Filesystem.md Normal file
View file

@ -0,0 +1,69 @@
# Filesystem
## Launching
The `nuclide` shell script is the launcher.
It sets **$PATH** to include the directory `bin/` which contains the engine that
you've built with `build_engine.sh`.
When nuclide is run and executes the engine, it'll first read `default.fmf` which
is a manifest file the engine reads. It is updated occasionally.
It defines which directories to mount in the virtual filesystem of the engine
and has a document entirely dedicated to itself. For that please read:
```
src/engine/specs/fte_manifests.txt
```
## Loading Games
On its own, Nuclide launches the game directory `base/`, unless you tell it otherwise:
```
./nuclide -game mygame
```
Will load `mygame/` instead of `base/`.
You can also load multiple additional directories in a specific order by specifying
multiple `-game` command-line arguments.
It will still load the other `BASEGAME` entries listed in the default.fmf.
You can even load your own manifest file over default.fmf, by passing
```
./nuclide -manifest mymanifest.fmf
```
## Virtual-Filesystem
When a game is mounted, we're either looking for **loose files** (loaded last), or
**archives** the engine supports.
The Quake .pak archive format, or zip archives with the pk3 and pk4 extensions are supported.
Upon initializing the filesystem they are enumerated alphabetically and then loaded in order.
Directories with the .pk3dir extensions are treated as if they were .pk3 archives.
The editor also supports .pk3dir directories.
Once the game has loaded a game directory, it'll load the persistent menu.dat into our QuakeC
virtual machine.
It' always running, you can make your own by modifying `src/menu-fn/`, `src/menu-vgui/`
or writing your own module.
## Archives
Protected archives always start have the prefix **pak**[...] and cannot be downloaded by connecting
to a server that has them.
**Use this for any copyrighted data.**
When you spawn a map, you create a server which will distribute its own client-side game-logic.
It's advised that you do not pack **csprogs.dat** and **progs.dat** into a protected archive.
## Nuclide specific formats
Nuclide contains many custom definition files that are not engine specific.
`.efx`, `.font`, `.sndshd` and `.way` to name a few.
The game-logic mostly handles them and can thus be, in theory, extended by you.

2
doc/history → Documentation/History.md
View file

@ -1,4 +1,4 @@
NUCLIDE PROJECT HISTORY
# History
In November 2016 eukara started work on 'OpenCS', a project which focused
solely on creating a clean-room implementation of Counter-Strike 1.5 in QuakeC

68
Documentation/Main.md Normal file
View file

@ -0,0 +1,68 @@
# Overview
Welcome to the documentation for Nuclide.
This is a software development kit and development environment created by [Vera Visions, L.L.C.](https://www.vera-visions.com/)
## What this project is {#what}
The Nuclide project produces a freely available game-logic component and
development platform on top of FTEQW; which is the engine we happen to use.
The goal is to create a modern research base for new advancements, as well
as to have a stable base with a decent API for making games.
- Client-side predicted movement and inputs for things like weapons-systems
- Lots of well documented objects to use in level formats supported by FTEQW
- Reference implementations for a lot of features exlusive to FTEQW compared
to other idTech engines
- Designed to be familar to developers who're used to GoldSrc and Source engine
projects
### 1. Why might I want to use it? {#why}
You want to develop a game using a lot of complex and well-tested objects
which might be tedious to implement on your own.
You want to run or make modifications for a game using Nuclide and need full
control over what you can do.
### 2. How free is Nuclide? {#license}
Everything in Nuclide is **free software**. The copyright terms for the game-logic are
very permitting. Nuclide does not use the GPL as a point of reference, it
instead uses a ISC-like license. This means you can use, copy, modify and
distribute the code and work resulting from it for any purpose.
Please read the very short 'LICENSE' document for details.
### 3. What are the alternatives? {#alternatives}
Implementing systems such as prediction, complex map objects and entities on
your own or licensing another engine such as [Source](https://partner.steamgames.com/doc/sdk/uploading/distributing_source_engine) that ships with its own **Source SDK Base**.
## Getting started {#prerequisites}
First of all, you want to be sure this is what you want to get into.
If you do posess a basic knowledge of the following:
- The C programming language
- Debugging a native application
- Makefiles
- Compiling your own binaries
- Concept of public and private APIs
Then you will have a good time.
We strive to keep the codebase portable and conform to open standards wherever possible.
This means that if you develop on Windows, you probably want to install something like [Cygwin](https://www.cygwin.com/) to make this bearable.
Please don't ask us how to learn UNIX/Cygwin.
**This is a development kit and a development environment. This is not a game.**
## Actually getting started {#how}
You clone the Nuclide git repository first. There's multiple places to get it, one such place may be GitHub:
`git clone https://github.com/veravisions/nuclide`
And then you can [get started on building the engine and the rest of the toolchain](Building.md).

4
Documentation/Materials/MatCommands.md Normal file
View file

@ -0,0 +1,4 @@
# Materials: Commands {#mat_commands}
These are all the important material commands that affect the renderer in some shape or form.
[For material commands that affect the compiling process, look over here.](MatVMap.md)

258
Documentation/Materials/MatGoldSrc.md Normal file
View file

@ -0,0 +1,258 @@
# Materials: GoldSrc
Material definitions handle what footsteps and what impact effects are played against each texture in the game-world.
So when you walk on dirt, you can hear the difference; or when you shoot wood with a gun it will have splinters spawn instead of black bits and smoke.
*Note:* While Nuclide supports this for legacy BSP files, you are encouraged to define the material of a texture via the [surfaceparm](MatCommands.md) command in a **Material** instead.
## Details
Usually, a game in the GoldSrc engine would provide a `sound/materials.txt` file, where each line defines the properties for a single (or a series of) textures.
For example:
```
C CONCRETEWALL
```
Will make any surface **concrete** that starts with the name `CONCRETEWALL`. In vanilla Half-Life, the second argument (name) can only be 12 characters long.
It will also only compare the length of characters of the name above. So for example if you were to define:
```
C CONC
```
Then `CONCRETEWALL` would still be marked as concrete, and any other texture that starts with `CONC[...]`.
## Community Changes and Additions
In stock GoldSrc, the **materials.txt** can be overwritten by a modification, and users could customize the file on the client-side only for themselves. This means there was no map specific materials, and mods could not inherit Half-Life's materials, so mods would always have to manage a nearly duplicate file if they desired custom texture sounds.
A few mods tried to remedy this problem, the following below is methods
documented so far:
* maps/MAPNAME.mat
> Introduced in The Wastes (2003)
* maps/MAPNAME_materials.txt
> Convention by Andrew Lucas, creator of Trinity SDK, modeled after
> MAPNAME_details.txt
* materials_file `PATH/FILE.txt` via the `worldspawn` entity
> Introduced in Sven Co-op 5.0
All these methods are supported by Nuclide, as one goal is to implement
conventions by not only Valve but the community as well.
In addition Nuclide has also implemented a way of giving modifications
their own inheritable materials file:
```
sounds/materials_UNIQUENAME.txt
```
The idea here is that any mod or even map pack can include ONLY the textures
used, and no longer will anyone have to manage a near-clone of materials.txt
For repackaging or modding purposes, if you desire to give your map custom
sound definitions, we recommend **The Wastes** its method for individual maps, while
the Nuclide method should be used for Mods or Map Packs. We find these to be
the most clean and efficient way.
**NOTE**: We recommend only using materials text files for GoldSrc related modding
purposes. It is inefficient for modern projects as there are much better
standards already supported in Nuclide. Keep in mind, it takes memory to load
big text files, and lots of text files adds up over play sessions.
# Material List
In Nuclide, this is the currently supported list of material IDs:
| Material ID | Material Name |
|-------------|---------------|
| B | Bloody Flesh |
| C | Concrete |
| D | Dirt |
| F | Flesh |
| G | Grate |
| H | Alien |
| K | Snow |
| M | Metal |
| N | Sand |
| O | Foliage |
| P | Computer |
| S | Slosh |
| T | Tile |
| V | Vent |
| W | Wood |
| Y | Glass |
## Game differences
Listed below are definitions for various games and mods. Only the changes and additions are listed since the rest are identical.
The * indicates these definitions are not implemented in Nuclide
## GoldSrc
### Arrangement
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| B | Blue Texture |
| N | Snow |
| R | Red Texture |
| U | Slime |
| X | Yellow Texture |
| Z | Black Texture |
### Counter-Strike
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| N | Snow |
| X | Grass |
*Afraid of Monsters: DC, Natural Selection, and Snow War uses the same definitions.*
### Cry of Fear
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| B | Random Twig Snap |
| H | Paper |
| I | Mud |
| O | Sand |
| P | Snow |
| R | Gravel |
| U | Grass |
| Y | Broken Glass |
| Z | Carpet |
### Gunman Chronicles
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| G | Wood |
| T | Rock |
| V | Sand |
| W | Unknown/Unused? |
### Firearms
| **Material ID** | **Material Name** |
|-------------------|-----------------------------------------|
| B | Sandbag |
| N | Snow |
| U | No impact or decals, just smoke effects |
### Heart of Evil
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| U | Mud |
### Hostile Intent
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| A | Sand |
| E | Foliage |
| N | Snow |
| R | Carpet |
| U | Mud |
| Z | Grass |
### Household DEATH!
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| H | Wood (Creaky) |
| I | Grass |
### Night at the Office
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| T | Carpet |
### Opposing Force
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| O | Snow |
*Science and Industry uses the same definitions as Opposing Force.*
### Poke646
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| M | Metal/Grate |
| T | Wood/Tile |
| G | Carpet/Grass |
### Wasteland Half-Life
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| B | Barrel |
| I | Sand |
| N | Tinroof |
| R | Rust |
| U | Drywall |
*The Wastes uses the same definitions.*
## Source
While Source has materials describing a surface with its **$surfaceprop** command, the GoldSrc way of describing materials with a 1-character symbol is still used to define which impact effect to use.
So be aware that a Source engine game may actually have more surface materials than this, these are solely the IDs associated with impact effects.
### Alien Swarm
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| 11 | Steam Pipe |
Alien Swarm: Reactive Drop uses the same definitions.
### Counter-Strike: Global Offensive
| **Material ID** | **Material Name** |
|-------------------|---------------------------|
| 11 | Mud |
| 12 | Sand Barrel |
| 13 | Sand Barrel (Penetration) |
| 14 | Metal Shield |
### Half-Life 2
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| A | Antlion |
| B | Flesh (Bloody) |
| H | Flesh (Antlion) |
| K | Snow |
| L | Plastic |
| N | Sand |
| I | Clip |
| O | Foliage |
| X | Fake |
| - | No Decal |
### Half-Life 2: Episode 2
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| E | Antlion Egg Sacks |
| Z | Adviser Shield |
### Insurgency
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| A | Fruit |
*Day of Infamy uses the same definitions.*
### Left 4 Dead
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| J | Grass |
| K | Mud |
| Q | Asphalt |
| R | Brick |
| U | Cardboard |
| 1 | Clay |
| 2 | Plaster |
| 3 | Rock |
| 4 | Rubber |
| 5 | Sheetrock |
| 6 | Cloth |
| 7 | Carpet |
| 8 | Paper |
| 9 | Upholstery |
| 10 | Puddle |
### Portal 2
| **Material ID** | **Material Name** |
|-------------------|---------------------|
| R | Reflective |

80
Documentation/Materials/MatOverview.md Normal file
View file

@ -0,0 +1,80 @@
# Materials
**Materials**, also formerly known **Q3 shaders** or wrongly referred to as just **shaders** are scripts that define texture and surface properties.
## History
In the idTech series of engines, **id Tech 3/Quake III Arena** was the first to introduce such a system, wrongly referred to back then as **shaders**. This was before vertex and fragment shaders were commonplace in the video-game asset pipeline.
They effectively merged the Quake texture-prefix hacks and Quake II .wal surface flags into one plain text format.
Starting with **id Tech 4/Doom III** in 2004, the name of **shader** was changed to **material** to avoid confusion with proper GPU oriented vertex and fragment shaders.
FTE has since coupled the old 'shader' syntax with proper GPU shaders using the [program](MatCommands.md) material command.
## What is a Material?
Materials are short text scripts that define the properties of a surface as it appears and functions in a game world (or compatible editing tool). By convention, the documents that contain these scripts usually has the same name as the texture set which contains the textures being modified (e.g; base, hell, castle, etc,). Several specific materials have also been created to handle special cases, like liquids, sky and special effects.
## Usage
When the engine looks for a texture, it will look for a material file in the file-tree first, then attempt to 'make one up' if only an image file is present. A rendereable surface will **always** have a material. The question is whether you provide it, or if the engine has to automatically generate one internally.
The file extension for materials in Nuclide is .mat. There are two ways of defining materials:
* A large .shader script file containing multiple materials inside the **./scripts/** folder (not recommended)
* One small .mat file with the same path as the texture. E.g: **models/weapons/handcannon/w_handcannon/w_handcannon.mat** handles **models/weapons/handcannon/w_handcannon/w_handcannon.tga**
A material file consists of a series of surface attributes (global scope) and rendering instructions formatted within braces ("{" and "}"). Below you can see a simple example of syntax and format for a single process, including the VMAP keywords or 'Surface Parameters', which follow the first bracket and a single bracketed 'stage':
```
// Vera Visions Material
{
diffusemap textures/common/lava.tga
vmap_tessSize 64
{
program unlit
blendFunc add
}
}
```
The first line is a simple comment. All the official textures are marked that way.
`diffusemap` defines a texture sampler to associate with the material, it'll also be used by the real-time lights to render an impacted surface, hence why it's defined at a global scope. Other materials may need to be aware of it. The compiler also uses it to compute radiosity.
`vmap_tessSize` will tell the BSP compiler to tesselate the surface in a specific way. This affects the entire surface and not just a single rendering stage, hence why it's defined at a global scope.
We then follow into the territory of defining specific rendering instructions within braces ("{" and "}"), most of the time that's not needed if we're defining a simple, opaque material. However in this case we want to make sure that we have 1 rendering stage that blends additively. Things such as real-time lights and the BSP compiler ignore these additional stages entirely.
`program unlit` will tell it not to be affected by lighting and just use a simple fullbright shader.
`blendFunc add` will now tell the renderer that this surface is no longer opaque and will be blended with whatever equation will result in an additive blend.
[You can read more about those commands in detail right here.](MatCommands.md)
## Engine generated materials
If no material definition for a surface is present, the engine will create an internal one.
It's generally a primitive material using the internal **defaultwall** shader if it's a world texture, the **defaultskin** texture if it's a model, or a **default2d** if it's a HUD element.
## Legacy materials
You can support old-style Q3A materials alongside modern shader oriented ones.
```
{
if $programs
program vertexlit
diffusemap "models/weapons/handcannon/w_handcannon.dds"
normalmap "models/weapons/handcannon/w_handcannon_normal.dds"
else
{
map "models/weapons/handcannon/w_handcannon.tga"
rgbGen lightingDiffuse
}
endif
}
```
Here everything inside the **if $programs** block will only ever load if it's capable of handling the GLSL.
So if you have a card only performing well under the GL 1.X pipeline, the **else** path will take priority.
This means less graphical fidelity, but generally better performance on those old chipsets.
All of Quake III's shading language is supported in the else block.

55
Documentation/Materials/MatShaders.md Normal file
View file

@ -0,0 +1,55 @@
# Materials: Shaders
Shaders are referring to GPU-oriented pieces of a program, performing shading and rendering related functions instead of letting the engine handle it.
In **FTEQW** you can specify a custom GLSL or HLSL shader using the [program](MatCommands.md) command inside a [Material](MatOverview.md).
## Example Shader
This is a primitive shader file. It includes the vertex and fragment program.
It will respond to the [diffusemap](MatCommands.md) only, which is loaded
into the **d_f** variable. It can be modified from that point onwards.
The commented out line will turn all of the output red.
Give it a try, or something!
```
//======= Copyright (c) 2015-2020 Vera Visions LLC. All rights reserved. =======
//
// Purpose:
//
// Example surface
//==============================================================================
!!ver 110
!!samps diffuse
#include "sys/defs.h"
varying vec2 tex_c;
#ifdef VERTEX_SHADER
void main ()
{
tex_c = v_texcoord; /* get our texture coordinates, which we'll use for the texture2D command */
gl_Position = ftetransform(); /* place vertex into the place FTE wants us to put them at */
}
#endif
#ifdef FRAGMENT_SHADER
void main ()
{
vec4 d_f = texture2D(s_diffuse, tex_c); /* load the fragment from our diffusemap sample */
// d_f.rgb = vec3(1.0, 0.0, 0.0); /* turns out fragment (aka pixel) red */
gl_FragColor = d_f; /* final pixel output is that of d_f */
}
#endif
```
## Dissecting GLSL shaders
When we pass `program <shadername>` in our [Material](MatOverview.md), the engine will load `glsl/<shadername>.glsl` to handle the material for us.
The shader in question needs to define a `main` function for both a vertex and a fragment shader. That's what the **ifdef**s are for in the above example.
You can not have separate files handle vertex/fragment programs, unlike in **id Tech 4/Doom III**.
At some point in the `main` function, we do have to set `gl_Position` and `gl_FragColor` respectively. Those can not be undefined.

4
Documentation/Materials/MatVMap.md Normal file
View file

@ -0,0 +1,4 @@
# Materials: VMap Commands {#mat_vmap}
The following commands are alter specific behaviour during the **BSP** compilation process.
These are not respected by the engine, the renderer or the game-logic.

30
Documentation/Materials/commands/alphafunc.md Normal file
View file

@ -0,0 +1,30 @@
# Materials: Commands {#mat_commands}
## alphafunc
### Syntax {#syntax}
**alphaFunc <func>**
### Overview {#overview}
Determines the alpha test function used when rendering this surface.
Valid values are **GT0**, **LT128**, and **GE128**. These correspond to
**"GREATER THAN 0"**, **"LESS THAN 128"**, and **"GREATER THAN OR EQUAL
TO 128"**.
This function is used when determining if a pixel should be written to
the frame-buffer. For example, if **GT0** is specified, the only the
portions of the texture map with corresponding alpha values greater than
zero will be written to the framebuffer. **By default alpha testing is
disabled.**
Both alpha testing and normal [alpha
blending](blendFunc) can be used to get
textures that have see-through parts. The difference is that
**alphaFunc** is an all-or-nothing test, while blending smoothly blends
between opaque and translucent at pixel edges.
Alpha test can also be used with
[depthWrite](depthWrite), allowing other
effects to be conditionally layered on top of just the opaque pixels by
setting [depthFunc](depthFunc) to equal.

23
Documentation/Materials/commands/alphagen.md Normal file
View file

@ -0,0 +1,23 @@
# Materials: Commands {#mat_commands}
## alphagen
### Syntax {#syntax}
**alphaGen <func>**
### Overview {#overview}
The alpha channel can be specified like the [rgb
channels](rgbGen). If not specified, it
defaults to 1.0.
### Functions {#functions}
#### portal {#portal}
This rendering stage keyword is used in conjunction with the
[surfaceparm](surfaceparm) keyword
portal. The function accomplishes the "fade" that causes the scene in
the portal to fade from view. Specifically, it means "Generate alpha
values based on the distance from the viewer to the portal."
Use `alphaGen portal` on the last rendering pass.

142
Documentation/Materials/commands/blendfunc.md Normal file
View file

@ -0,0 +1,142 @@
# Materials: Commands {#mat_commands}
## blendfunc
![OpenGL blending cheat-sheet](gl_blendmodes.jpg "from zanir.wz.cz/?p=60")
### Syntax {#syntax}
**blendFunc <simplefunc>**
**blendFunc <srcBlend> <destBlend>**
### Overview {#overview}
Blend functions are the keyword commands that tell the renderer how
graphic layers are to be mixed together.
### Usage {#usage}
#### Simplified blend functions {#simplified_blend_functions}
The most common blend functions are set up here as simple commands, and
should be used unless you really know what you are doing.
##### add {#add}
This is a shorthand command for `blendFunc GL_ONE GL_ONE`. Effects like
fire and energy are additive.
##### filter {#filter}
This is a shorthand command that can be substituted for either
`blendFunc GL_DST_COLOR GL_ZERO` or `blendFunc GL_ZERO GL_SRC_COLOR`. A
filter will always result in darker pixels than what is behind it, but
it can also remove color selectively. Lightmaps are filters.
##### blend {#blend}
Shorthand for `blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA`. This is
conventional transparency, where part of the background is mixed with
part of the texture.
#### Explicit blend functions {#explicit_blend_functions}
Getting a handle on this concept is absolutely key to understanding all
shader manipulation of graphics.
BlendFunc or "Blend Function" is the equation at the core of processing
shader graphics. The formula reads as follows:
` [Source *`<srcBlend>`] + [Destination * `<dstBlend>`]`
**Source** is usually the RGB color data in a texture file.
**Destination** is the color data currently existing in the frame
buffer.
Rather than think of the entire texture as a whole, it maybe easier to
think of the number values that correspond to a single pixel, because
that is essentially what the computer is processing: One pixel of the
bitmap at a time.
The process for calculating the final look of a texture in place in the
game world begins with the pre-calculated lightmap for the area where
the texture will be located. This data is in the frame buffer. That is
to say, it is the initial data in the Destination. In an unmanipulated
texture (i.e. one without a special shader script), color information
from the texture is combined with the lightmap. In a shader-modified
texture, the $lightmap stage must be present for the lightmap to be
included in the calculation of the final texture appearance.
Each pass or "stage" of blending is combined (in a cumulative manner)
with the color data passed onto it by the previous stage. How that data
combines together depends on the values chosen for the Source Blends and
Destination Blends at each stage. Remember it's numbers that are being
mathematically combined together that are ultimately interpreted as
colors.
A general rule is that any Source Blend other than **GL_ONE** (or
**GL_SRC_ALPHA** where the alpha channel is entirely white) will cause
the Source to become darker.
##### Source Blend <srcBlend> {#source_blend}
The following values are valid for the Source Blend part of the
equation.
- **GL_ONE** This is the value 1. When multiplied by the Source, the
value stays the same the value of the color information does not
change.
- **GL_ZERO** This is the value 0. When multiplied by the Source, all
RGB data in the Source becomes Zero (essentially black).
- **GL_DST_COLOR** This is the value of color data currently in the
Destination (frame buffer). The value of that information depends on
the information supplied by previous stages.
- **GL_ONE_MINUS_DST_COLOR** This is nearly the same as
**GL_DST_COLOR** except that the value for each component color is
inverted by subtracting it from one. (,i.e. R = 1.0 - DST.R, G =
1.0 - DST.G, B = 1.0 - DST.B, etc.)
- **GL_SRC_ALPHA** The TGA file being used for the Source data must
have an alpha channel in addition to its RGB channels (for a total
of four channels). The alpha channel is an 8-bit black and white
only channel. An entirely white alpha channel will not darken the
Source.
- **GL_ONE_MINUS_SRC_ALPHA** This is the same as **GL_SRC_ALPHA**
except that the value in the alpha channel is inverted by
subtracting it from one.(i.e. A=1.0 - SRC.A)
##### Destination Blend <dstBlend> {#destination_blend}
The following values are valid for the Destination Blend part of the
equation.
- **GL_ONE** This is the value 1. When multiplied by the Destination,
the value stays the same the value of the color information does not
change.
- **GL_ZERO** This is the value 0. When multiplied by the Destination,
all RGB data in the Destination becomes Zero (essentially black).
- **GL_SRC_COLOR** This is the value of color data currently in the
Source (which is the texture being manipulated here).
- **GL_ONE_MINUS_SRC_COLOR** This is the value of color data currently
in Source, but subtracted from one(i.e. inverted).
- **GL_SRC_ALPHA The TGA** file being used for the Source data must
have an alpha channel in addition to its RGB channels (four a total
of four channels). The alpha channel is an 8-bit black and white
only channel. An entirely white alpha channel will not darken the
Source.
- **GL_ONE_MINUS_SRC_ALPHA** This is the same as **GL_SRC_ALPHA**
except that the value in the alpha channel is inverted by
subtracting it from one. (i.e. A=1.0 - SRC.A).
##### Doing the Math: The Final Result {#doing_the_math_the_final_result}
The product of the Source side of the equation is added to the product
of the Destination side of the equation. The sum is then placed into the
frame buffer to become the Destination information for the next stage.
Ultimately, the equation creates a modified color value that is used by
other functions to define what happens in the texture when it is
displayed in the game world.
#### Default Blend Function {#default_blend_function}
If no blendFunc is specified then no blending will take place. That's
just a fact of life.

45
Documentation/Materials/commands/cull.md Normal file
View file

@ -0,0 +1,45 @@
# Materials: Commands {#mat_commands}
## cull
### Syntax {#syntax}
**cull <side>**
### Overview {#overview}
Every surface of a polygon has two sides, a front and a back. Typically,
we only see the front or "out" side. For example, a solid block you only
show the front side. In many applications we see both. For example, in
water, you can see both front and a back. The same is true for things
like grates and screens.
To "cull" means to remove. The value parameter determines the type of
face culling to apply. The default value is cull front if this keyword
is not specified. However for items that should be inverted then the
value back should be used. To disable culling, the value disable or none
should be used. Only one cull instruction can be set for the material.
### Sides {#sides}
#### front {#front}
**This is the default value.** The front or "outside" of the polygon is
not drawn in the world. It is used if the keyword `"cull "` appears in
the content instructions without a <side> value or if the keyword cull
does not appear at all in the shader.
#### back {#back}
Cull back removes the back or "inside" of a polygon from being drawn in
the world.
#### none {#none}
Neither side of the polygon is removed. Both sides are drawn in the
game. Very useful for making panels or barriers that have no depth, such
as grates, screens, metal wire fences and so on and for liquid volumes
that the player can see from within. Also used for energy fields,
sprites, and weapon effects (e.g. plasma).
**Design Notes:** For things like grates and screens, put the texture
with the cull none property on one face only. On the other faces, use a
non-drawing texture.

140
Documentation/Materials/commands/deformvertexes.md Normal file
View file

@ -0,0 +1,140 @@
# Materials: Commands {#mat_commands}
## deformvertexes
### Syntax {#syntax}
**deformVertexes <func>**
### Overview {#overview}
This command performs a general deformation on the surface's vertexes,
changing the actual shape of the surface before drawing the shader
passes. You can stack multiple deformVertexes commands to modify
positions in more complex ways, making an object move in two dimensions,
for instance.
### Functions {#functions}
#### wave <siv> <func> <base> <amplitude> <phase> <freq> {#wave}
Designed for water surfaces, modifying the values differently at each
point.
It accepts the standard **wave** functions of the type: **sin**,
**triangle**, **square**, **sawtooth** or **inversesawtooth**.
The "div" parameter is used to control the wave "spread" - a value equal
to the [tessSize](vmap_tessSize) of the
surface is a good default value.
#### normal <siv> <func> <base> &lt;amplitude ~0.1-~0.5&gt; &lt;frequency ~1.0-~4.0&gt; {#normal_amplitude_0.1_0.5_frequency_1.0_4.0}
This deformation affects the normals of a vertex without actually moving
it, which will effect later material options like lighting and
especially environment mapping. If the material stages don't use normals
in any of their calculations, there will be no visible effect.
**Design Notes:** Putting values of 0.1 to 0.5 in Amplitude and 1.0 to
4.0 in the Frequency can produce some satisfying results. Some things
that have been done with it: A small fluttering bat, falling leaves,
rain, flags.
#### bulge <bulgeWidth> <bulgeHeight> <bulgeSpeed> {#bulge}
This forces a bulge to move along the given s and t directions. Designed
for use on curved pipes.
#### move<x> <y> <z> <func> <base> <amplitude> <phase> <freq> {#move}
This keyword is used to make a brush, curve patch or model appear to
move together as a unit. The **<x>** **<y>** and **<z>** values are the
distance and direction in game units the object appears to move relative
to it's point of origin in the map.
The **<func> <base> <amplitude> <phase>** and **<freq>** values are the
same as found in other wave form manipulations.
The product of the function modifies the values x, y, and z.Therefore,
if you have an amplitude of 5 and an x value of 2, the object will
travel 10 units from its point of origin along the x axis. This results
in a total of 20 units of motion along the x axis, since the amplitude
is the variation both above and below the base.
It must be noted that an object made with this material does not
actually change position, it only appears to.
**Design Note**: If an object is made up of surfaces with different
materials, all must have matching deformVertexes move values or **the
object will appear to tear itself apart!**
#### autosprite {#autosprite}
This function can be used to make any given triangle quad (pair of
triangles that form a square rectangle) automatically behave like a
sprite without having to make it a separate entity.
This means that the "sprite" on which the texture is placed will rotate
to always appear at right angles to the player's view as a sprite would.
Any four-sided brush side, flat patch, or pair of triangles in a model
can have the autosprite effect on it. The brush face containing a
texture with this material keyword must be square.
**Design Note**: This is best used on objects that would appear the same
regardless of viewing angle. An example might be a glowing light flare.
#### autosprite2 {#autosprite2}
Is a slightly modified "sprite" that only rotates around the middle of
its longest axis.
This allows you to make a pillar of fire that you can walk around, or an
energy beam stretched across the room.
### Notes {#notes}
Specific parameter definitions for deform keywords:
#### <siv> {#section}
This is roughly defined as the size of the waves that occur. It is
measured in game units. Smaller values create agreater density of
smaller wave forms occurring in a given area. Larger values create a
lesser density of waves, or otherwise put, the appearance of larger
waves. To look correct this value should closely correspond to the value
(in pixels) set for
[tessSize](vmap_tessSize) of the texture.
A value of 100.0 is a good default value (which means your
[tessSize](vmap_tessSize) should be close
to that for things tolook "wavelike").
#### <func> {#section_1}
This is the type of wave form being created. **sin** stands for sine
wave, a regular smoothly flowing wave. **triangle** is a wave with a
sharp ascent and a sharp decay. It will make a choppy looking wave
forms. A **square** wave is simply on or off for the period of the
frequency with no in between. The **sawtooth** wave has the ascent of a
triangle wave, but has the decay cut off sharply like a square wave. An
**inversesawtooth** wave reverses this.
#### <base> {#section_2}
This is the distance, in game units that the apparent surface of the
texture is displaced from the actual surface of the brush as placed in
the editor. A positive value appears above the brush surface. A negative
value appears below the brush surface.
#### <amplitude> {#section_3}
The distance that the deformation moves away from the base value. See
Wave Forms in the introduction for a description of amplitude. <phase>
SeeWave Forms in the introduction for a description of phase)
#### <frequency> {#section_4}
See Wave Forms in the introduction for a description of frequency)
Design Note: The siv and amplitude parameters, when used in conjunction
with liquid volumes like water should take into consideration how much
the water will be moving. A large ocean area would have have massive
swells (big siv values) that rose and fell dramatically (big amplitude
values). While a small, quiet pool may move very little.

15
Documentation/Materials/commands/depthfunc.md Normal file
View file

@ -0,0 +1,15 @@
# Materials: Commands {#mat_commands}
## depthfunc
### Syntax {#syntax}
**depthFunc <func>**
### Overview {#overview}
This controls the depth comparison function used while rendering.
The default is **lequal** (Less than or equal to) where any surface that
is at the same depth or closer of an existing surface is drawn. This is
used for textures with transparency or translucency. Under some
circumstances you may wish to use **equal**, e.g. for light-mapped
grates that are alpha tested (it is also used for mirrors).

13
Documentation/Materials/commands/depthwrite.md Normal file
View file

@ -0,0 +1,13 @@
# Materials: Commands {#mat_commands}
## depthwrite
### Syntax {#syntax}
**depthWrite**
### Overview {#overview}
By default, writes to the depth buffer when
[depthFunc](depthFunc) passes will happen
for opaque surfaces and not for translucent surfaces.
Blended surfaces can have the depth writes forced with this function.

24
Documentation/Materials/commands/diffusemap.md Normal file
View file

@ -0,0 +1,24 @@
# Materials: Commands {#mat_commands}
## diffusemap
### Syntax {#syntax}
**diffusemap <texturepath/texturename>**
### Overview {#overview}
Specifies the default texture asset to use on the diffuse/albedo pass of
the material. This is the base texture in most cases. Some special
materials used for special effects and the like might not have one.
However surfaces such as floors, walls etc. certainly do. It will affect
which texture is used to get color information from for lighting passes,
etc.
### See also {#see_also}
- [normalmap](normalmap)
- [specularmap](specularmap)
- [fullbrightmap](fullbrightmap)
- [uppermap](uppermap)
- [lowermap](lowermap)
- [reflectmask](reflectmask)
- [reflectcube](reflectcube)

42
Documentation/Materials/commands/fogparms.md Normal file
View file

@ -0,0 +1,42 @@
# Materials: Commands {#mat_commands}
## fogparms
### Syntax {#syntax}
**fogParms <red value> <green value> <blue value> <distance to opaque>**
### Overview {#overview}
**Note**: you must also specify "surfaceparm fog" to cause
[vmap](vmap) to identify the surfaces inside the volume.
Fogparms only describes how to render the fog on the surfaces.
**<red value> <green value> <blue value>** These are normalized values.
To obtain the values that define fog color divide the desired color's
Red, Green and Blue values by 255 to obtain three normalized numbers
within the 0.0 to 1.0 range.
**<distance toopaque>** This is the distance, in game units, until the
fog becomes totally opaque, as measured from the point of view of the
observer. By making the height of the fog brush shorter than the
distance to opaque, the apparent density of the fog can be reduced
(because it never reaches the depth at which full opacity occurs).
### Notes {#notes}
- The fog volume can only have one surface visible (from outside the
fog).
- Fog must be made of one brush. It cannot be made of adjacent
brushes.
- Fog brushes must be axial. This means that only square or
rectangular brushes may contain fog, and those must have their edges
drawn along the axes of the map grid (all 90 degree angles).
**Design Notes:**
- If a water texture contains a fog parameter, it must be treated as
if it were a fog texture when in use.
- If a room is to be filled completely with a fog volume,it can only
be entered through one surface (and still have the fog function
correctly).
- Additional shader passes may be placed on a fog brush, as with other
brushes.

13
Documentation/Materials/commands/fte_clutter.md Normal file
View file

@ -0,0 +1,13 @@
# Materials: Commands {#mat_commands}
## fte_clutter
### Syntax {#syntax}
**fte_clutter <model> <spacing> <scale min> <scale max> <z offset>
<angle min> <angle max>**
### Overview {#overview}
Similar to [vmap_surfaceModel (Material
Command)](vmap_surfaceModel), however
it'll place models at runtime. The density can be controlled via the
cvar `r_clutter_density`.

25
Documentation/Materials/commands/fullbrightmap.md Normal file
View file

@ -0,0 +1,25 @@
# Materials: Commands {#mat_commands}
## fullbrightmap
### Syntax {#syntax}
**fullbrightmap <texturepath/texturename>**
### Overview {#overview}
The texture is essentially a fullbright overlay on top of the
diffuse/albedomap.
Not all [Shaders](Shaders) support them. In some, like the
[unlit](unlit_(Shader)) shader, the
[diffusemap](diffusemap) is always
fullbright.
### See also {#see_also}
- [diffusemap](diffusemap)
- [normalmap](normalmap)
- [specularmap](specularmap)
- [uppermap](uppermap)
- [lowermap](lowermap)
- [reflectmask](reflectmask)
- [reflectcube](reflectcube)

BIN
Documentation/Materials/commands/gl_blendmodes.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 73 KiB

15
Documentation/Materials/commands/nomipmaps.md Normal file
View file

@ -0,0 +1,15 @@
# Materials: Commands {#mat_commands}
## nomipmaps
### Syntax {#syntax}
**noMipmaps**
### Overview {#overview}
This implies [noPicMip](noPicMip), but
also prevents the generation of any lower resolution mipmaps for use by
the 3d card. This will cause the texture to alias when it gets smaller,
but there are some cases where you would rather have this than a blurry
image. Sometimes thin slivers of triangles force things to very low
mipmap levels, which leave a few constant pixels on otherwise scrolling
special effects.

12
Documentation/Materials/commands/nopicmip.md Normal file
View file

@ -0,0 +1,12 @@
# Materials: Commands {#mat_commands}
## nopicmip
### Syntax {#syntax}
**noPicMip**
### Overview {#overview}
This causes the texture to ignore user-set values for the gl_picmip cvar
command. The image will always be high resolution. Example: Used to keep
images and text in the heads up display from blurring when user
optimizes the game graphics.

27
Documentation/Materials/commands/normalmap.md Normal file
View file

@ -0,0 +1,27 @@
# Materials: Commands {#mat_commands}
## normalmap
### Syntax {#syntax}
**normalmap <texturepath/texturename>**
### Overview {#overview}
Specifies the default texture to use for any normalmap operations. This
depends heavily on which [GLSL program](Shaders) is used
inside the later stages. The dynamic lights will use this to determine
height information for light and shadows. So sometimes you want to skip
setting this.
### Creating normal maps to use with this command {#creating_normal_maps_to_use_with_this_command}
Check out our [Normal mapping guide](Normal_mapping_guide).
### See also {#see_also}
- [diffusemap](diffusemap)
- [specularmap](specularmap)
- [fullbrightmap](fullbrightmap)
- [uppermap](uppermap)
- [lowermap](lowermap)
- [reflectmask](reflectmask)
- [reflectcube](reflectcube)

15
Documentation/Materials/commands/polygonoffset.md Normal file
View file

@ -0,0 +1,15 @@
# Materials: Commands {#mat_commands}
## polygonoffset
### Syntax {#syntax}
**polygonOffset <value>**
### Overview {#overview}
Surfaces rendered with the polygonOffset keyword are rendered slightly
off the polygon's surface. This is typically used for wall markings and
"decals." The distance between the offset and the polygon is variable.
If no value is supplied a distance of 1 is assumed, however this is
meant for backwards compatibility. Being explicit will help grepping
values later in case you need to find all surfaces with just a
polygonOffset of 1.

12
Documentation/Materials/commands/portal.md Normal file
View file

@ -0,0 +1,12 @@
# Materials: Commands {#mat_commands}
## portal
### Syntax {#syntax}
**portal**
### Overview {#overview}
Specifies that this texture is the surface for a portal or mirror. In
the game map, a portal entity must be placed directly in front of the
texture (within 64 game units). All this does is set "sort portal", so
it isn't needed if you specify that explicitly.

14
Documentation/Materials/commands/program.md Normal file
View file

@ -0,0 +1,14 @@
# Materials: Commands {#mat_commands}
## program
**program** defines which GLSL/HLSL shader to load for a defined
material. It also accepts arguments that will recompile a shader with
certain permutations. This is kinda ugly,
Starting in [The Wastes](The_Wastes) 1.2, there are the
following shader programs available to you:
- program [unlit](unlit_(Shader))
- program [lightmapped](lightmapped_(Shader))
- program [vertexlit](vertexlit_(Shader))
- program [water](water_(Shader))
- program [refract](refract_(Shader))

20
Documentation/Materials/commands/reflectcube.md Normal file
View file

@ -0,0 +1,20 @@
# Materials: Commands {#mat_commands}
## reflectcube
### Syntax {#syntax}
**reflectcube <texturepath/cubemapname>**
### Overview {#overview}
Specifies which cubemap to use on this material. By default, the engine
will pass the nearest in-world cubemap instead.
### See also {#see_also}
- [diffusemap](diffusemap)
- [normalmap](normalmap)
- [specularmap](specularmap)
- [fullbrightmap](fullbrightmap)
- [uppermap](uppermap)
- [lowermap](lowermap)
- [reflectmask](reflectmask)

25
Documentation/Materials/commands/reflectmask.md Normal file
View file

@ -0,0 +1,25 @@
# Materials: Commands {#mat_commands}
## reflectmask
### Syntax {#syntax}
**reflectmask <texturepath/texturename>**
### Overview {#overview}
Defines a texture that specifies which parts of a material will reveal a
reflective material, such as a
[cubemap](reflectcube). This applies to
standard FTEQW. In Nuclide the reflectmask is currently unused with the
included shaders. If you want to apply reflectivity to your materials,
use the alpha channel of your
[normalmap](normalmap) instead.
### See also {#see_also}
- [diffusemap](diffusemap)
- [normalmap](normalmap)
- [specularmap](specularmap)
- [fullbrightmap](fullbrightmap)
- [uppermap](uppermap)
- [lowermap](lowermap)
- [reflectcube](reflectcube)

117
Documentation/Materials/commands/rgbgen.md Normal file
View file

@ -0,0 +1,117 @@
# Materials: Commands {#mat_commands}
## rgbgen
### Syntax {#syntax}
**rgbGen <func>**
**rgbGen wave <func> <base> <amp><phase> <freq>**
### Overview {#overview}
Defines what vertex colors are set to for any given surface.
If no rgbGen is specified, either "identityLighting" or"identity" will
be selected, depending on which blend modes are used.
Valid <func> parameters are const, wave, identity, identityLighting,
entity, oneMinusEntity, fromVertex, and lightingDiffuse.
### Functions {#functions}
#### const {#const}
Follow this up with a vector of the color that you'd like the vertex
colors to be set as. An example for green would be:
` rgbGen const 0.0 1.0 0.0`
#### identityLighting {#identitylighting}
Colors will be (1.0,1.0,1.0) if running without overbright bits (NT,
linux, windowed modes), or (0.5, 0.5, 0.5) if running with overbright.
Overbright allows a greater color range at the expense of a loss of
precision. Additive and blended stages will get this by default.
#### identity {#identity}
Colors are assumed to be all white (1.0,1.0,1.0). All filters stages
(lightmaps, etc) will get this by default.
#### entity {#entity}
Colors are grabbed from the entity's .colormod field.
#### oneMinusEntity {#oneminusentity}
Colors are grabbed from 1.0 minus the entity's .colormod field.
#### entityLighting {#entitylighting}
Introduced by [FTE](FTE), same as entity, but will receive
lighting similar to identityLighting on top of it.
#### vertex {#vertex}
Colors are filled in directly by the data from the map or model files.
This is used for blending brushes and patches. It was used at one point
to store primitive lighting, in case the lightmapped rendering path was
to expensive (this is no longer available).
#### oneMinusVertex {#oneminusvertex}
As rgbGen vertex, but inverted.
Design Note: This keyword would probably not be used by a level designer
#### lightingDiffuse {#lightingdiffuse}
Colors are computed using a standard diffuse lighting equation. It uses
the vertex normals to illuminate the object correctly.
Design Note: -rgbGen lightingDiffuse is used when you want the RGB
values to be computed for a dynamic model (i.e. non-map object) in the
world using regular in-game lighting. For example, you would specify on
materials for items, characters, weapons, etc.
#### wave <func> <base> <amp><phase> <freq> {#wave}
Colors are generated using the specified waveform. An affected texture
with become darker and lighter, but will not change hue. Hue stays
constant. Note that the rgb values for color will not go below 0 (black)
or above 1 (white). Valid waveforms are **sin**, **triangle**,
**square**, **sawtooth** and **inversesawtooth**.
##### <func> {#section}
- **Sin**: color flows smoothly through changes.
- **Triangle**: color changes at a constant rate and spends no
appreciable time at peaks and valleys.
- **Square**: color alternates instantly between its peak and valley
values.
- **Sawtooth**: With a positive frequency value, the color changes at
a constant rate to the peak then instantly drops to its valley
value.
- **Inversesawtooth**: An inverse sawtooth wave will reverse this,
making the ascent immediate (like a square wave) and the decay fall
off like a triangle wave.
##### <base> {#section_1}
Baseline value. The initial RGB formula of a color (normalized).
##### <amp> {#section_2}
Amplitude. This is the degree of change from the baseline value. In some
cases you will want values outside the 0.0 to 1.0 range, but it will
induce clamping (holding at the maximum or minimum value for a time
period) instead of continuous change.
##### <phase> {#section_3}
See the explanation for phase under the waveforms heading of Key
Concepts.
##### <freq> {#section_4}
Frequency. This is a value (NOT normalized) that indicates peaks per
second.

52
Documentation/Materials/commands/skyparms.md Normal file
View file

@ -0,0 +1,52 @@
# Materials: Commands {#mat_commands}
## skyparms
### Overview {#overview}
**skyParms <farbox> <cloudheight> <nearbox>**
Specifies how to use the surface as a sky, including an optional far box
(stars, moon, etc), optional cloud layers with any shader attributes,
and an optional near box (mountains in front of the clouds, etc). Some
of the VMAP specific commands use this as a reference as to what skybox
to use for color, intensity etc.
The renderer will take it into account only if you do not supply any
Stages in the material.
**<farbox>** Specifies a set of files to use as an environment box
behind all cloudlayers. Specify "-" for no farbox, or a file base name.
A base name of "env/test" would look for files "env/test_rt.tga",
"env/test_lf.tga", "env/test_ft.tga", "env/test_bk.tga",
"env/test_up.tga", "env/test_dn.tga" to use as the right / left / front
/ back / up / down sides.
**<cloudheight>** controls apparent curvature of the cloud layers -
lower numbers mean more curvature (and thus more distortion at the
horizons). Higher height values create "flatter" skies with less horizon
distortion. Think of height as the radius of a sphere on which the
clouds are mapped. Good ranges are 64 to 256. The default value is 128.
**<nearbox>** Specified as farbox, to be alpha blended ontop of the
clouds. This has not be tested in a long time, so it probably doesn't
actually work. Set to "-" to ignore.
### Example Sky Material {#example_sky_material}
`   // Vera Visions Material`
`   {`
`       qer_editorImage textures/skies/dune.tga`
`       skyParms textures/skies/dune/bg 256 -`
`       noPicMip`
`       noMipmaps`
`       `
`       surfaceParm sky`
`       surfaceParm noimpact`
`       surfaceParm nolightmap`
`       surfaceParm nodlight`
`       {`
`           program skybox`
`           map $cube:textures/skies/dune/bg`
`           map textures/skies/clouds/dunecloud.tga`
`           map textures/skies/clouds/dunecloud_layer.tga`
`       }`
`   }`

53
Documentation/Materials/commands/sort.md Normal file
View file

@ -0,0 +1,53 @@
# Materials: Commands {#mat_commands}
## sort
### Syntax {#syntax}
**sort <value>**
### Overview {#overview}
Use this keyword to fine-tune the depth sorting of materials as they are
compared against other materials in the game world. The basic concept is
that if there is a question or a problem with materials drawing in the
wrong order against each other, this allows the designer to create a
hierarchy of which materials draws in what order.
The default behavior is to put all blended materials in sort "additive"
and all other materials in sort "opaque", so you only need to specify
this when you are trying to work around a sorting problem with multiple
transparent surfaces in a scene.
### Values {#values}
The value here can be either a numerical value or one of the keywords in
the following list (listed in order of mostly ascending priority):
- **ripple**: Meant for surfaces blending below water surfaces I
guess.
- **eferredlight**: Blend at the same order as deferred lighting. So
before diffuse mapping usually takes place.
- **portal**: This surface is a portal, it draws over every other
shader seen inside the portal, but before anything in the main view.
- **sky**: Typically, the sky is the farthest surface in the game
world. Drawing this after other opaque surfaces can be an
optimization on some cards. This currently has the wrong value for
this purpose, so it doesn't do much of anything.
- **opaque**: This surface is opaque (rarely needed since this is the
default with noblendfunc)
- **decal**: Blend it like a decal. Ones affected by light, or
something.
- **seethrough**: Not sure what to call this, beyond repeating its
name and it being between decal and unlitdecal.
- **unlitdecal**: Blend it like an unlit decal, this most commonly is
bullet impacts.
- **banner**: Transparent, but very close to walls.
- **underwater**: Draw behind normal transparent surfaces.
- **blend**: Draw like a blendFunc blend transparent surface.
- **additive**: normal transparent surface (default for shaders with
blendfuncs)
- **nearest**: this shader should always sort closest to the viewer,
e.g. muzzle flashes and blend blobs
It is generally recommended you stick to the keywords. The engine may
introduce new ones and you will benefit from internal sorting parameters
not clashing with yours whenever the engine may update them.

22
Documentation/Materials/commands/specularmap.md Normal file
View file

@ -0,0 +1,22 @@
# Materials: Commands {#mat_commands}
## specularmap
### Syntax {#syntax}
**specularmap <texturepath/texturename>**
### Overview {#overview}
Can set the specularity of the surface in relation to dlights.
Specularity is the intensity of the light reflecting off the surface. In
special cases some [GLSL programs](Shaders) might use the
texture it for other purposes, too.
### See also {#see_also}
- [diffusemap](diffusemap)
- [normalmap](normalmap)
- [fullbrightmap](fullbrightmap)
- [uppermap](uppermap)
- [lowermap](lowermap)
- [reflectmask](reflectmask)
- [reflectcube](reflectcube)

296
Documentation/Materials/commands/surfaceparm.md Normal file
View file

@ -0,0 +1,296 @@
# Materials: Commands {#mat_commands}
## surfaceparm
### Overview {#overview}
The surfaceparm keyword is not only read by the VMAP compiler, but also
by the renderer. A few keywords will only apply to any one of them.
All surfaceparm keywords are preceded by the word surfaceparm as
follows:
:
: surfaceparm **fog**
### Behaviour Keywords {#behaviour_keywords}
Commands that affect core functionality of a surface, or could impact
the entire room or the gameplay surrounding it.
#### areaportal {#areaportal}
A brush marked with this keyword functions as an area portal, a break in
the VMAP tree. It is typically placed on a very thin brush placed inside
a door entity (but is not a part of that entity). The intent is to block
the game from processing surface triangles located behind it when the
door is closed. It is also used by the BSPC (bot area file creation
compiler) in the same manner as a clusterportal. The brush must touch
all the structural brushes surrounding the areaportal.
#### clusterportal {#clusterportal}
A brush marked with this keyword function creates a subdivision of the
area file (.aas) used by the bots for navigation. It is typically placed
in locations that are natural breaks in a map, such a sentrances to
halls, doors, tunnels, etc. The intent is keep the bot from having to
process the entire map at once. As with the the areaportal parameter,
the affected brush must touch all the structural brushes surrounding the
areaportal.
#### donotenter {#donotenter}
Read as "do not enter." Like clusterportal, this is a bot-only property.
A brush marked with donotenter will not affect non-bot players, but bots
will not enter it. It should be used only when bots appear to have
difficulty navigating around some map features.
#### lava {#lava}
Assigns to the texture the game properties set for lava. This affects
both the surface and the content of a brush.
#### nodamage {#nodamage}
The player takes no damage if he falls onto a texture with this
surfaceparm
#### nosteps {#nosteps}
The player makes no sound when walking on this texture.
#### nonsolid {#nonsolid}
This attribute indicates a brush, which does not block the movement of
entities in the game world. It applied to triggers, hint brushes and
similar brushes. This affects the content of a brush.
#### origin {#origin}
Used on the "origin" texture. Rotating entities need to contain an
origin brush in their construction. The brush must be rectangular (or
square). The origin point is the exact center of the origin brush.
#### playerclip {#playerclip}
Blocks player movement through a nonsolid texture. Other game world
entities can pass through a brush marked playerclip. The intended use
for this is to block the player but not block projectiles like rockets.
#### slick {#slick}
This surfaceparm included in a texture should give it significantly
reduced friction.
#### slime {#slime}
Assigns to the texture the game properties for slime. This affects both
the surface and the content of a brush.
#### structural {#structural}
This surface attribute causes a brush to be seen by the VMAP process as
a possible break-point in a BSP tree. It is used as a part of the
material for the "hint" texture. Generally speaking, any opaque texture
not marked as "detail" is, by default, structural, so you shouldn't need
to specify this.
#### water {#water}
Assigns to the texture the game properties for water.
#### climb {#climb}
Marks the desired surface as a climbable surface. This currently affects
the entire volume.
#### vehicleclip {#vehicleclip}
Blocks all movement of vehicle entities through this surface.
#### leakssteam {#leakssteam}
When this surface is impacted, steam will leak out temporarily. Specific
to The Wastes 1.3.
#### leakswater {#leakswater}
When this surface is impacted, water will leak out temporarily. Specific
to The Wastes 1.3.
#### fl_r1 {#fl_r1}
Reserved for custom games. This can be anything.
#### fl_r2 {#fl_r2}
Reserved for custom games. This can be anything.
#### fl_r3 {#fl_r3}
Reserved for custom games. This can be anything.
#### fl_r4 {#fl_r4}
Reserved for custom games. This can be anything.
#### fl_r5 {#fl_r5}
Reserved for custom games. This can be anything.
#### fl_r6 {#fl_r6}
Reserved for custom games. This can be anything.
#### fl_r7 {#fl_r7}
Reserved for custom games. This can be anything.
### Rendering Keywords {#rendering_keywords}
Commands that affect rendering of a surface, or the how surfaces are
made to look by the compiler. These do not affect gameplay function.
#### alphashadow {#alphashadow}
This keyword applied to a texture on a brush, patch or model will cause
the lighting phase of the VMAP process to use the texture's alpha
channel as a mask for casting static shadows in the game world.
Design Note: Alphashadow does not work well with fine line detail on a
texture. Fine lines may not cast acceptable shadows. It appears to work
best with well-defined silhouettes and wider lines within the texture.
Most of our tattered banners use this to cast tattered shadows.
#### fog {#fog}
Fog defines the brush as being a "fog" brush. This is a VMAP function
that chops and identifies all geometry inside the brush. The General
material keyword fogparms must also be specified to tell how to draw the
fog.
#### lightfilter {#lightfilter}
Causes the VMAP light stage to use the texture's RGB and alpha channels
to generate colored alpha shadows in the lightmap. For example, this can
be used to create the colored light effect cast by stained glass
windows. This can be used with surfaceparm alphashadow if an alpha is to
be respected.
#### nodlight {#nodlight}
Read as "No DeeLight". A texture containing this parameter will not be
affected or lit by dynamic lights, such as weapon effects. The VMAP
compiler doesn't really care about this, but the renderer does.
#### nodraw {#nodraw}
A texture marked with nodraw will not visually appear in the game world.
Most often used for triggers, clip brushes, origin brushes, and so on.
Light will pass through it, therefore beware of bleeding issues when
using nodraw/caulk textures with this.
#### nodraw2 {#nodraw2}
Same as nodraw, but the engine won't draw it, whereas the VMAP compiler
will react to the surface. So unlike nodraw, light will not pass through
these surfaces.
#### noimpact {#noimpact}
World entities will not impact on this texture. No explosions occur when
projectiles strike this surface and no marks will be left on it. Sky
textures are usually marked with this texture so those projectiles will
not hit the sky and leave marks.
#### nomarks {#nomarks}
Projectiles will explode upon contact with this surface, but will not
leave marks. Blood will also not mark this surface. This is useful to
keep lights from being temporarily obscured by battle damage.
Blob shadows (aka **r_shadows 1**) also counts as a mark. So any surface
that you don't want to see affected by shadows should receive this
surfaceparm.
#### nolightmap {#nolightmap}
This texture does not have a lightmap phase. It is not affected by the
ambient lighting of the world around it. It does not require the
addition of an rgbGen identity keyword in that stage.
#### trans {#trans}
Light will pass through this surface, but only if either alphashadow or
lightfilter are applied. Tells VMAP that pre-computed visibility should
not be blocked by this surface. Generally, any materials that have
blendfuncs should be marked as surfaceparm trans.
### Material Related Keywords {#material_related_keywords}
Specifies which impact effects and footstep sounds are played when
interacting with a given surface. Only one of them can be given at once:
#### alien {#alien}
Defines that the surface is of an 'alien' material. Affects impact sound
and effects.
#### flesh {#flesh}
Defines that the surface is of flesh. Affects impact sound and effects.
#### foliage {#foliage}
Defines that the surface is foliage. Affects impact sound and effects.
#### computer {#computer}
Defines that the surface is of computer parts. Affects impact sound and
effects.
#### dirt {#dirt}
Defines that the surface is of dirt. Affects impact sound and effects.
#### vent {#vent}
Defines that the surface is a vent. Affects impact sound and effects.
#### grate {#grate}
Defines that the surface is a grate. Affects impact sound and effects.
#### metal {#metal}
Defines that the surface is of metal. Affects impact sound and effects.
#### glass {#glass}
Defines that the surface is of glass. Affects impact sound and effects.
#### sand {#sand}
Defines that the surface is of sand. Affects impact sound and effects.
#### slosh {#slosh}
Defines that the surface is of a liquid. Affects impact sound and
effects.
#### snow {#snow}
Defines that the surface is of snow. Affects impact sound and effects.
#### tile {#tile}
Defines that the surface is of kitchen/bathroom tiles. Affects impact
sound and effects.
#### wood {#wood}
Defines that the surface is of wood. Affects impact sound and effects.
#### concrete {#concrete}
Defines that the surface is of concrete. Affects impact sound and
effects.

24
Documentation/Materials/commands/tcgen.md Normal file
View file

@ -0,0 +1,24 @@
# Materials: Commands {#mat_commands}
## tcgen
### Syntax {#syntax}
**tcGen <coordinate source>**
### Overview {#overview}
Specifies how texture coordinates are generated and where they come
from. Valid functions are **base**, **lightmap** and **environment**.
### Sources {#sources}
#### base {#base}
Base texture coordinates from the original art.
#### lightmap {#lightmap}
Lightmap texture coordinates.
#### environment {#environment}
Make this object environment mapped.

132
Documentation/Materials/commands/tcmod.md Normal file
View file

@ -0,0 +1,132 @@
# Materials: Commands {#mat_commands}
## tcmod
### Syntax {#syntax}
**tcMod <func> &lt;…&gt;**
### Overview {#overview}
Specifies how texture coordinates are modified after they are generated.
The valid functions for tcMod are **rotate**, **scale**, **scroll**,
**stretch** and **transform**.
**Transform** is a function generally reserved for use by programmers
who suggest that designers leave it alone.
When using multiple **tcMod** functions during a stage, place the scroll
command last in order, because it performs a mod operation to save
precision, and that can disturb other operations.
Texture coordinates are modified in the order in which **tcMods** are
specified. In otherwords, if you see:
` tcMod scale 0.5 0.5`
` tcMod scroll 1 1`
Then the texture coordinates will be **scaled then**scrolled'''.
### Functions {#functions}
#### rotate <degrees per per second> {#rotate}
This keyword causes the texture coordinates to rotate. The value is
expressed in degrees rotated each second. A positive value means
clockwise rotation. A negative value means counterclockwise rotation.
For example "tcMod rotate 5" would rotate texture coordinates 5 degrees
each second in a clockwise direction. The texture rotates around the
center point of the texture map, so you are rotating a texture with a
single repetition, be careful to center it on the brush (unless
off-center rotation is desired).
#### scale <sScale> <tScale> {#scale}
Resizes (enlarges or shrinks) the texture coordinates by multiplying
them against the given factors of <sScale> and &lt;tScale). The values
"s" and "t" conform to the "x" and "y" values (respectively) as they are
found in the original texture. The values for sScale and tScale are
**NOT** normalized. This means that a value greater than 1.0 will
increase the size of the texture. A positive value less than one will
reduce the texture to a fraction of its size and cause it to repeat
within the same area as the original texture (Note: see
[clampmap](clampmap) for ways to control
this).
Example: `tcMod scale 0.5 2` would cause the texture to repeat twice
along its width, but expand to twice its height (in which case half of
the texture would be seen in the same area as the original)
#### scroll <sSpeed> <tSpeed> {#scroll}
Scrolls the texture coordinates with the given speeds. The values "s"
and "t" conform to the "x" and "y" values (respectively) as they are
found in the original texture. The scroll speed is measured in
"textures" per second. A "texture" is the dimension of the texture being
modified and includes any previous material modifications to the
original texture). A negative s value would scroll the texture to the
left. A negative t value would scroll the texture down.
Example: tcMod scroll 0.5 -0.5 moves the texture down and right
(relative to the texture's original coordinates) at the rate of a half
texture each second of travel.
**This should be the LAST tcMod in a stage.** Otherwise there maybe
popping or snapping visual effects in some materials.
#### stretch <func> <base> <amplitude> <phase> <frequency> {#stretch}
Stretches the texture coordinates with the given function. Stretching is
defined as stretching the texture coordinate away from the center of the
polygon and then compressing it towards the center of the polygon.
**<base>**: A base value of one is the original dimension of the texture
when it reaches the stretch stage. Inserting other '''values positive or
negative in this variable will produce unknown effects.
**<amplitude>**: This is the measurement of distance the texture will
stretch from the base size. It is measured, like scroll, in textures. A
value of 1 here will double the size of the texture at its peak.
**<phase>**: See the explanation for phase under the deform vertexes
keyword.
**<frequency>**: this is wave peaks per second.
**<func>**:
- **Sin**: the texture expands smoothly to its peak dimension and then
shrinks smoothly to its valley dimension in a flowing manner.
- **Triangle**: The textures stretch at a constant rate and spend no
appreciable time at the peak or valley points.
- **Square**: The texture is shown at its peak for the duration of the
frequency and then at its valley for the duration of the frequency.
- **Sawtooth**: the texture stretches like a triangle wave until it
reaches a peak, then instantly drops to the valley, as in a square
wave.
- **Inversesawtooth**: this is the reverse of the sawtooth wave.
#### transform <m00> <m01> <m10> <m11> <t0> <t1> {#transform}
Transforms each texture coordinate as follows:
S' = s \* m00 + t \* m10 + t0 T' = s \* m01 + t \* m11 + t1
This is for use by programmers.
#### turb <base> <amplitude> <phase> <freq> {#turb}
Applies turbulence to the texture coordinate. Turbulence is a back and
forth churning and swirling effect on the texture.
The parameters for this are defined as follows:
- **<base>**: Currently undefined.
- **<amplitude>**: This is essentially the intensity of the
disturbance or twisting and squiggling of the texture.
- **<phase>**: See the explanation for phase under the
[deformvertexes](DeformVertexes)
keyword.
- **<freq>**: Frequency. This value is expressed as repetitions or
cycles of the wave per second. A value of one would cycle once per
second. A value of 10 would cycle 10 times per second. A value of
0.1 would cycle once every 10 seconds.

21
Documentation/Materials/commands/vmap_backmaterial.md Normal file
View file

@ -0,0 +1,21 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_backmaterial
### Syntax {#syntax}
**vmap_backMaterial <material>**
### Overview {#overview}
This allows a brush surface to use a different material when you are
inside it looking out.
By way of example, this would allow a water brush (or other) surfaces to
have a different sort order or appearance when seen from the inside.
**vmap_backMaterial** only works on brush faces. For this reason, it is
often deprecated in favor of using
[vmap_cloneMaterial](vmap_cloneMaterial)
where the target material contains
[vmap_invert](vmap_invert).
It can still be useful as a kind of shorthand.

16
Documentation/Materials/commands/vmap_backsplash.md Normal file
View file

@ -0,0 +1,16 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_backsplash
### Syntax {#syntax}
**vmap_backsplash <percent> <distance>**
### Overview {#overview}
Controls the percentage of [surface
light](vmap_surfaceLight) backsplash (how
much light the emitting surface hits), as well as the distant away from
the surface of which it is cast. This is really tricky to get right in
tight areas, so put time aside to experiment.
**The default backsplash amount is 5%, and the default distance is about
16 units.**

14
Documentation/Materials/commands/vmap_basematerial.md Normal file
View file

@ -0,0 +1,14 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_basematerial
### Syntax {#syntax}
**vmap_baseMaterial <material>**
### Overview {#overview}
Copies the vmap_/surfaceparm commands from the specified material into
this one.
However, if you want to copy the appearance and only specify
compiler-specific modifications, use
[vmap_remapMaterial](vmap_remapMaterial).

10
Documentation/Materials/commands/vmap_bounce.md Normal file
View file

@ -0,0 +1,10 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_bounce
### Syntax {#syntax}
**vmap_bounce <scale>**
### Overview {#overview}
Specifies the fraction of light to re-emit during a bounce pass on this
surface.

12
Documentation/Materials/commands/vmap_clonematerial.md Normal file
View file

@ -0,0 +1,12 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_clonematerial
### Syntax {#syntax}
**vmap_cloneMaterial <material>**
### Overview {#overview}
A material with this directive will inherit the target material's
properties and appearance. **Be careful, this can lead to an infinite
loop if a cloning material references another cloning material or
itself.**

15
Documentation/Materials/commands/vmap_invert.md Normal file
View file

@ -0,0 +1,15 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_invert
### Syntax {#syntax}
**vmap_invert**
### Overview {#overview}
Inverts a surface normal. Works on brush faces, models and patches. Used
in celshading to achieve the inverted backfacing hull.
Can be used with a material that is targeted by
[vmap_cloneMaterial](vmap_cloneMaterial)
for something similar to
[vmap_backMaterial](vmap_backMaterial).

16
Documentation/Materials/commands/vmap_lightimage.md Normal file
View file

@ -0,0 +1,16 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightimage
### Syntax {#syntax}
**vmap_lightImage <texturepath>**
### Overview {#overview}
By default, surface lights use the average color of the source image to
generate the color of the light. vmap_lightImage specifies an alternate
image to be used for light color emission, radiosity color emission,
light filtering and alpha shadows. You can even use a light image with a
different alpha channel for blurrier alpha shadows. The light color is
averaged from the referenced texture. The texture must be the same size
as the base image map. vmap_lightImage should appear before
qer_editorImage.

33
Documentation/Materials/commands/vmap_lightmapfilterradius.md Normal file
View file

@ -0,0 +1,33 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightmapfilterradius
### Syntax {#syntax}
**vmap_lightmapFilterRadius <lightmap filter radius>
<light filter radius>**
### Overview {#overview}
This is usually used on [light emitting
materials](vmap_surfaceLight) to
approximate finer subdivided lighting. It adds a gaussian blur effect to
the lightmaps of either the material itself, or the surfaces affected by
the material, or both. The values for **<lightmap filter radius>** and
**<light filter radius>** are measured in world units of filtering
(blurring) of lightmap data cast by any light sources.
**<lightmap filter radius>** Amount of blur set for the material itself
to approximate for the [surface
light's](vmap_surfaceLight) finer
subdivided lighting. It should be set to 0 for sky materials since they
don't have lightmaps.
**<light filter radius>**: Amount of blur set for other surfaces
affected by this material's emitted light. It should be set just high
enough to eliminate the "stadium shadow" effect sometimes produced by
[light_environment](light_environment) or to smooth out the
lighting on [surface
lights](vmap_surfaceLight).
[vmap_lightmapFilterRadius](vmap_lightmapFilterRadius)
should be placed before any light related material directives that you
want it to affect.

14
Documentation/Materials/commands/vmap_lightmapmergable.md Normal file
View file

@ -0,0 +1,14 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightmapmergable
### Syntax {#syntax}
**vmap_lightmapMergable**
### Overview {#overview}
When specified, the compiler will attempt to merge all surfaces using
this material together onto lightmap sheets. This can drastically reduce
the artifacts occuring on surfaces like terrain where precision issues
might get you black spots along the lightmap seams. Definitely use this
across large collections of surfaces on which you expect smooth
transitions.

13
Documentation/Materials/commands/vmap_lightmapsampleoffset.md Normal file
View file

@ -0,0 +1,13 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightmapsampleoffset
### Syntax {#syntax}
**vmap_lightmapSampleOffset <float>**
### Overview {#overview}
Takes a single parameter, defaulting to 1.0, which specifies how many
units off a surface should the compiler sample lighting from. Use larger
values (2.0-8.0) if you're getting ugly splotches on lightmapped
terrain. Try to use filtering to solve splotches if possible, leaving
vmap_lightmapSampleOffset as a last resort.

15
Documentation/Materials/commands/vmap_lightmapsamplesize.md Normal file
View file

@ -0,0 +1,15 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightmapsamplesize
### Syntax {#syntax}
**vmap_lightmapSampleSize <int>**
### Overview {#overview}
Surfaces using a material with this option will have the pixel size of
the lightmaps set to N world grid units. This option can be used to
produce high-resolution shadows on certain surfaces. In addition, it can
be used to reduce the size of lightmap data, where high-resolution
shadows are not required, gaining memory and performance benefits. The
default sample size is 8, smaller numbers increases lightmap resolution.
In general, you should stick with power of 2 values.

12
Documentation/Materials/commands/vmap_lightrgb.md Normal file
View file

@ -0,0 +1,12 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightrgb
### Syntax {#syntax}
**vmap_lightRGB <red color> <green color> <blue color>**
### Overview {#overview}
Alternative to [vmap_lightImage (Material
Command)](vmap_lightImage) and the
automatic way of figuring out which light color a specified surface
emits.

15
Documentation/Materials/commands/vmap_lightsubdivide.md Normal file
View file

@ -0,0 +1,15 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_lightsubdivide
### Syntax {#syntax}
**q3map_lightSubdivide <units>**
### Overview {#overview}
Used on surface lights (see [vmap_surfaceLight (Material
Command)](vmap_surfaceLight)). Controls
the distance between surface generated light sources for uniform
lighting. It defaults to 120 game units, but can be made larger or
smaller as needed (for light surfaces at the bottom of cracks, for
example). This can be a dominant factor in processing time for lightmap
generation.

10
Documentation/Materials/commands/vmap_nodirty.md Normal file
View file

@ -0,0 +1,10 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_nodirty
### Syntax {#syntax}
**vmap_nodirty**
### Overview {#overview}
This surface is not affected by dirt-mapping. The compiler baked variant
of ambient occlusion.

11
Documentation/Materials/commands/vmap_offset.md Normal file
View file

@ -0,0 +1,11 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_offset
### Syntax {#syntax}
**vmap_offset <float>**
### Overview {#overview}
Offsets a surface along the vertex normals by N.N units. Used in
celshading for those black edges. This is the sort-of the compiler
version of [polygonOffset](polygonOffset)

20
Documentation/Materials/commands/vmap_remapmaterial.md Normal file
View file

@ -0,0 +1,20 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_remapmaterial
### Syntax {#syntax}
**vmap_remapMaterial <material>**
### Overview {#overview}
Allows the material to later become known as the specified material.
These materials should not contain anything but compiler-specific
keywords.
For example, if you want a material that is **exactly like'' the
specified**vmap_remapMaterial**in appearance, but with a
specific**vmap_''' or surfaceparm characteristics, use this command.
However, if you want want just a material's vmap_/surfaceparm
properties, use
[vmap_baseMaterial](vmap_baseMaterial).

11
Documentation/Materials/commands/vmap_shadeangle.md Normal file
View file

@ -0,0 +1,11 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_shadeangle
### Syntax {#syntax}
**vmap_shadeAngle <degrees>**
### Overview {#overview}
In short: At which angle the phong shading on a material breaks. If you
set it to 0, basically no phong shading will ever be performed. The
default shade angle in [VMAP](VMAP) is 40 degrees.

24
Documentation/Materials/commands/vmap_surfacelight.md Normal file
View file

@ -0,0 +1,24 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_surfacelight
### Syntax {#syntax}
**vmap_surfacelight <intensity>**
### Overview {#overview}
The texture gives off light equal to the value set for it. The relative
surface area of the texture in the world affects the actual amount of
light that appears to be radiated.
To give off what appears to be the same amount of light, a smaller
texture must be significantly brighter than a larger texture.
Unless the
[vmap_lightImage](vmap_lightImage) or
[vmap_lightRGB](vmap_lightRGB) directive
is used to select a different source for the texture's light color
information, the color of the light will be the averaged color of the
texture.
If you want to change the distance/range of the surfacelight, use
[vmap_surfacelightDistance](vmap_surfaceLightDistance).

13
Documentation/Materials/commands/vmap_surfacelightdistance.md Normal file
View file

@ -0,0 +1,13 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_surfacelightdistance
### Syntax {#syntax}
**vmap_surfaceLightDistance <scale>**
### Overview {#overview}
Increases the range of a surfacelight. This is different from increasing
the [vmap_surfaceLight (Material
Command)](vmap_surfaceLight) value, as
it'll travel much wider without affecting the total intensity of the
light.

16
Documentation/Materials/commands/vmap_surfacemodel.md Normal file
View file

@ -0,0 +1,16 @@
# Materials: VMap Commands {#mat_vmap}
## vmap_surfacemodel
### Syntax {#syntax}
**vmap_surfaceModel <modelpath> <density> <odds> <minscale> <maxscale>
<minangle> <maxangle> <oriented>**
### Overview {#overview}
A surface with vmap_surfaceModel in its shader will randomly place a
specified model across it's face. This is designed to place grass or
tree models over terrain.
This will bake the models into the .bsp itself, creating an
unnecessarily inflated map. Use [fte_clutter (Material
Command)](fte_clutter) instead.

25
Documentation/Materials/commands/vmap_tesssize.md Normal file
View file

@ -0,0 +1,25 @@
# Materials: Compiler Commands {#mat_vmap}
## vmap_tesssize
### Syntax {#syntax}
**vmap_tessSize <amount>**
### Overview {#overview}
Formely known as just **tessSize**.
The command controls the tessellation size (how finely a surface is
chopped up in to triangles), in game units, of the surface.
This is only applicable to solid brushes, not curves, and is generally
only used on surfaces that are flagged with the
[deformVertexes](deformVertexes) keyword.
Abuse of this can create a huge number of triangles. This happens during
BSP processing, so maps must be reprocessed for changes to take effect.
### Note {#note}
It can also be used on tesselating surfaces to make sure that
tesselations are large, and thus, less costly in terms of triangles
created.

79
Documentation/Models/VVM.md Normal file
View file

@ -0,0 +1,79 @@
# Models: VVM
**Vera Visions Model**, also known as **VVM** or **IQM-FTE** is the main
skeletal model format.
## Features {#features}
Features that the original IQM exporter (by Lee Salzman) did not offer:
- Support for external configuration files for IQM generation (ala
studiomdl)
- Pre-processor for rotating single or all input files
- Pre-processor for translating/repositioning single or all input
files
- Pre-processor for renaming bones inside a single or all input files
- Pre-processor for material prefixes inside a single or all input
files
Some features that our extended specification (VVM) has to offer:
- Support for hitmeshes for faster, content-aware collision detection
- Automatic hitmesh generation
- Submodels that allow showing/hiding specific groups of the model via
the game-logic
- Support for frame triggered events that can be read by the
game-logic (model-events)
- Level-of-detail range flag for references/sub-models
- User-defined surface and contentflags per reference/sub-model
**NOTE: Using any of the VVM features is not supported in any engine
other than FTEQW**
The tool's output will let you know if you're outputting an IQM
compatible file or not.
It also has a re-engineered exporter that takes control files as input,
rather than a giant command-line string. This was done because some
models have hundreds of model parameters in The Wastes.
## History {#history}
In 2016 when we had our first prototype of The Wastes, we started out
using DPM for tool-chain related reasons and quickly migrated to IQM.
However we needed a better system for handling reproducible output
files. The original tool only handled compilation via plain command-line
parameters which was not good enough.
The input command file (.qc) syntax is obviously inspired by qdata and
other tools such as studiomdl. So if you're familiar with those tools
you know exactly what to expect.
We then went on and designed extensions that we needed to make the game
work, for example a generic model-events system that'd call events in
the game-logic when a certain key-frame in the model is displayed.
More complicated things were hit-meshes, for more accurate hit detection
of body parts as well as sub-models that made the action of shooting
body-parts off possible.
We developed this together with David of FTEQW, since this had to be
developed in conjunction with the FTEQW built-ins that'd later be
exposed to the game-logic.
However, the initial extensions to the IQM format in FTE were designed
by us; and this is the exporter that was used to make our game.
## Viewing VVM Models {#viewing_vvm_models}
You can grab a binary build of FTE [1](https://www.fteqw.org/)
(basically a generic, non The Wastes specific version) and use the
'modelviewer' command in the console. The console can be opened via
Shift+ESC.
If you want to see for example the Winston viewmodel, type *modelviewer
models/weapons/v_winchester.vvm*
## External links {#external_links}
[<https://github.com/VeraVisions/vvmtool> vvmtool on
GitHub](https://github.com/VeraVisions/vvmtool)

150
Documentation/Models/VVM_Tutorial.md Normal file
View file

@ -0,0 +1,150 @@
# Models: VVM Tutorial
## Introduction {#introduction}
As you already know, the VVM exporter (vvmtool) takes inspiration from
Valve's **studiomdl** in terms of usage. There are *slight* syntax
differences, primarily because the way some features are implemented
differ **drastically**.
For example, **model events** can be stacked and applied to many
animation sequences at once. *There is no way to do so with studiomdl.*
## Input files {#input_files}
Any .vvm consists of multiple input files. These can come in the
following formats:
- SMD (GoldSrc & Source)
- MD5MESH and MD5ANIM (idTech 4)
- FBX
- IQE
- OBJ (no animations)
Make sure that when you use animated files, that the bone naming and
bone order is consistent among them.
## Control File {#control_file}
This file is the head of the format. It specifies how the input files
are loaded in, with additional useful commands on how to manipulate the
input data. Many of these features would **not be possible** with an
internal, modeling program specific exporter for VVM.
Here's an EXCERPT of a control file from **The Wastes*:
output tommygun.vvm
materialprefix models/weapons/tommygun/
bone "Bone55" rename "Muzzleflash"
scene ref/tommygun.smd
rotate 0 -90 0
scene seq/idle.smd fps 20.0
scene seq/idle_empty.smd fps 20.0
event 0 1004 "weapons/tommygun/draw.wav 1"
scene seq/draw.smd fps 25.0
event reset
event 0 1004 "weapons/tommygun/draw.wav 1"
scene seq/draw_empty.smd fps 25.0
event reset
event 0 1004 "weapons/tommygun/holster.wav 1"
scene seq/holster.smd fps 30.0
event reset
event 0 1004 "weapons/tommygun/holster.wav 1"
scene seq/holster_empty.smd fps 30.0
origin 0 -32 0
event reset
event 14 1004 "weapons/tommygun/clipout.wav 1"
event 48 1004 "weapons/tommygun/clipin.wav 1"
scene seq/reload_not_empty.smd fps 22.0
event 64 1004 "weapons/tommygun/bolt.wav 1"
scene seq/reload.smd fps 22.0
origin 0 0 0
event reset
event 0 1001 "33 models/effects/muzzleflash/muzzleflash2.vvm"
event 0 1002 "3 40 0 70"
event 0 1005 "33 1"
scene seq/shoot.smd fps 30.0
scene seq/shoot_last.smd fps 30.0
...
That's a really complicated control file, but it highlights a few
things:
- You can specify as many events as you like...
- and apply them to as many scenes as you want.
- Creating an interface for a dedicated, in-modeling-program exporter
would be unfeasible.
- You can run commands to fix existing model input files after the
fact, like bone renaming...
- ... and even rotation, scaling and origin re-adjusting (on a
per-input-file basis!)
- The **origin** command is absolute, so set it to '0 0 0' to reset
However, a model control file doesn't need to be this complicated:
output terminal01.vvm
materialprefix models/props/computers/
rotate 0 -90 0
scene ref/terminal01.smd
This is `models/props/computers/terminal01.qc` from The Wastes.
What each line means:
`output` specifies the resulting final output file name and location
relative to the control file.
`materialprefix` just appends this string to any referenced material.
Ideally it's the location where the .vvm itself is stored in your game
filesystem.
`rotate` Simply rotates all input files by 90 degrees on the Y/Yaw axis
upon importing.
`scene` Tells it to load one input file, which is a reference. If it was
an animation it'd specify a framerate via the 'fps X' parameter.
## Compiling {#compiling}
You grab your copy of **vvmtool** and you either drag
and drop your control file onto it, or run it via command-line:
`vvmtool.exe foobar.qc`
It should be as simple as that!
## Notes {#notes}
Some helpful tips for your content creation journey.
### vid_reload {#vid_reload}
I recommend getting a single reference, plus the animations into your
game first, then adding events and other necessary commands on top.
You can use the console command `vid_reload` to force the engine to
flush the model/texture cache and to reload an updated model from disk.
Really useful when iterating over model exports.
### Blender users {#blender_users}
If you're using the Blender Source Model tools, as of 2021, it still
doesn't down-mix certain animation features into the .smd format.
**This is a problem with the Blender exporter, not vvmtool (as it also
won't work in studiomdl).**
So if your bones seem completely messed up, try .fbx instead.
If you absolutely need to use .smd, export it as .fbx in Blender, import
said output back into Blender and then export as .fbx.

23
doc/mods → Documentation/Mods.md
View file

@ -1,5 +1,4 @@
Mod loading and setting up games
================================
# Mod/Game Setup
For mods to show up in the "Custom Game" menu, we have to either find a manifest
file, or a liblist.gam, or a gameinfo.txt inside the respective mod directory.
@ -11,10 +10,12 @@ restricting that.
A liblist.gam file can look something like this:
game "My Cool Mod"
version "1.0"
startmap "e1m1"
trainingmap "traininglevel"
```
game "My Cool Mod"
version "1.0"
startmap "e1m1"
trainingmap "traininglevel"
```
But more definitions are available.
Check src/menu-fn/m_customgame.qc's customgame_liblist_parse() function to stay
@ -31,10 +32,12 @@ If you need more control, you can use manifest files. Similar to the default.fmf
that's in the root Nuclide source tree. You can set liblist entries like this
inside of them:
-set gameinfo_game "My Cool Mod"
-set gameinfo_version "1.0"
-set gameinfo_startmap "e1m1"
-set gameinfo_trainingmap "traininglevel"
```
-set gameinfo_game "My Cool Mod"
-set gameinfo_version "1.0"
-set gameinfo_startmap "e1m1"
-set gameinfo_trainingmap "traininglevel"
```
Please name the manifest the same as the mod/game dir. For example if your game
its directory is named "foobar" name your manifest "foobar.fmf".

12
Documentation/Sound/EAX.md Normal file
View file

@ -0,0 +1,12 @@
# Sound: EAX
Creative Technology's **Environmental Audio Extensions**, also known as **EAX**, attempted to create more ambiance within video games by more accurately simulating a real-world audio environment.
Due to the release of Windows Vista which deprecated the DirectSound3D API EAX was based on in 2007, Creative discouraged EAX implementation in favor of its [OpenAL](OpenAL.md)-based EFX equivalent.
EFX is fully supported in **FTEQW** and exposed via user-friendly entities and scripting language in **Nuclide**.
## See also
* [EFX](EFX.md)
* [OpenAL](OpenAL.md)

87
Documentation/Sound/EFX.md Normal file
View file

@ -0,0 +1,87 @@
# Sound: EFX
EFX is a system in [OpenAL](OpenAL.md) that delivers high quality sound reverberation. It is the successor to Creative's [Environmental Audio Extensions](EAX.md).
**Nuclide** offers abstraction for new and old entities relying on **digital signal processing**.
## Entities
**env_sound** is most commonly used to change the environmental sound processing of a room/area.
In GoldSrc, it'll specify which enumeration of DSP preset to use for audio playback, in Nuclide however we just map it to a file in the filesystem.
## EFX files
Entities that specify a EFX type, usually want to load one from a file.
Here's an example one, `efx/city.efx`:
```
density "1.000000"
diffusion "0.500000"
gain "0.316200"
gain_hf "0.398100"
gain_lf "1.000000"
decay_time "1.490000"
decay_hf_ratio "0.670000"
decay_lf_ratio "1.000000"
reflections_gain "0.073000"
reflections_delay "0.007000"
reflections_pan "0 0 0"
late_reverb_gain "0.142700"
late_reverb_delay "0.011000"
late_reverb_pan "0 0 0"
echo_time "0.250000"
echo_depth "0.000000"
modulation_time "0.250000"
modulation_depth "0.000000"
air_absorbtion_hf "0.994300"
hf_reference "5000.000000"
lf_reference "250.000000"
room_rolloff_factor "0.000000"
decay_limit "1"
```
Most of the parameters are self explanatory.
## Debug cvars
With the cvar `>s_al_debug` you'll get an overlay of information about which EFX file is currently being used, as well as what every single parameter is set to.
You can refresh EFX definitions with a simple map restart.
## Legacy translation table
Here you can see which **.efx file** is responsible for handling a legacy **env_sound** room-type.
**roomtype ID**|**EFX file**
:-----:|:-----:
0|efx/default.efx
1|efx/gs\_generic.efx
2|efx/gs\_metal\_s.efx
3|efx/gs\_metal\_m.efx
4|efx/gs\_metal\_l.efx
5|efx/gs\_tunnel\_s.efx
6|efx/gs\_tunnel\_m.efx
7|efx/gs\_tunnel\_l.efx
8|efx/gs\_chamber\_s.efx
9|efx/gs\_chamber\_m.efx
10|efx/gs\_chamber\_l.efx
11|efx/gs\_bright\_s.efx
12|efx/gs\_bright\_m.efx
13|efx/gs\_bright\_l.efx
14|efx/gs\_water1.efx
15|efx/gs\_water2.efx
16|efx/gs\_water3.efx
17|efx/gs\_concrete\_s.efx
18|efx/gs\_concrete\_m.efx
19|efx/gs\_concrete\_l.efx
20|efx/gs\_big1.efx
21|efx/gs\_big2.efx
22|efx/gs\_big3.efx
23|efx/gs\_cavern\_s.efx
24|efx/gs\_cavern\_m.efx
25|efx/gs\_cavern\_l.efx
26|efx/gs\_weirdo1.efx
27|efx/gs\_weirdo2.efx
28|efx/gs\_weirdo3.efx

86
Documentation/Sound/SoundDefs.md Normal file
View file

@ -0,0 +1,86 @@
# Sound: soundDef
Nuclide mimics the sound defintion spec from **idTech 4** somewhat, albeit
with some changes/enhancements. We call them **soundDefs**.
**The elevator pitch**: To allow for more control over the sounds than what was previously
allowed in idTech engines we also allow designers to drop sounds into
the game without having to set some common parameters every time.
Instead of directly calling which .wav or .ogg file to play, we tell it
to play the single name of a sound def. For example:
*c1_sentry_loader_in* which can be located in **any** text file ending
with the **.sndshd** file extension inside the `sound/` directory.
```
c1_sentry_loader_in
{
dist_min 10
dist_max 25
no_occlusion
volume 0.25
sample sound/movers/comm1/sentry_loader_in.wav
}
```
![Attenuation Visualisation](sounds_attenuation.png "Attenuation")
- dist_min / dist_max sets the radius where the sound fades out. The
sound is at maximum volume inside 'dist_min' radius, and it
completely silent after 'dist_max' radius.
- The no_occlusion key tells the engine not to take level geometry in
to account when calculating volume.
- 'volume' is the volume inside the inner radius of the sound.
- The last line sets the actual sound file to play.
Let's take a look at another one:
```
emetal_impacts
{
dist_min 5
dist_max 45
volume 0.5
sample sound/impact/ambient_impacts/emetal_01.wav
sample sound/impact/ambient_impacts/emetal_02.wav
sample sound/impact/ambient_impacts/emetal_03.wav
sample sound/impact/ambient_impacts/emetal_04.wav
sample sound/impact/ambient_impacts/emetal_05.wav
}
```
This one has multiple sound files specified, which means that **Nuclide** will randomly choose one to play.
## Commands {#commands}
| | | |
|-----------------|-------------------------|-------------------------------------------------------------------------------------------------------------|
| **Key** | **Value** | **Description** |
| attenuation | idle/static/none/normal | Changes the sound's attenuation, aka playback radius/distance. This essentially just changes **dist_max**. |
| dist_min | <float> | Sets the minimum playback distance in quake units. |
| dist_max | <float> | Sets the maximum playback distance in quake units. |
| volume | <float> | Sets the playback volume. 0.0 - 1.0 range. |
| shakes | <float> | Will shake the screen with an intensity specified. Play around with this, 256 is a good starting value. |
| pitch | <float> | Will set a specific pitch change. 0.0 - 2.0 range most commonly, but there's wiggle room. |
| pitch_min | <float> | Will set a minimum pitch instead of an exact one. This means it'll play a random pitch between min and max. |
| pitch_max | <float> | Will set a maximum pitch instead of an exact one. This means it'll play a random pitch between min and max. |
| offset | <float> | Sound sample offset in seconds. |
| looping | none | Sound set to force loop, regardless of sound markers in file. |
| nodups | none | Don't play duplicate samples in sequence. |
| global | none | Play samples everywhere. |
| private | none | Play samples privately onto the entity that it gets played on. |
| no_reverb | none | Disable any [EAX](/EAX "wikilink") on samples in this def. |
| omnidirectional | none | Samples won't play from any particular direction. |
| follow | none | Samples will move alongside the entity it's being played on |
| footstep | none | Determines sample volume based upon the speed of the entity. |
| distshader | <string> | Which sound def to play to everyone who is out of playback reach of this one. |
| sample | <string> | Adds a sample to play to the list. Will only play one at a time. |
## Power to the developer {#power_to_the_developer}
Unlike the implementation in **idTech 4**, all of the sound defs handling
is done in the game-logic and is therefore exposed to all developers.
Some mods may want to hook AI callbacks into the system, or create
visual effects when commands are called by a sound def. The
possibilities are endless!

BIN
Documentation/Sound/sounds_attenuation.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 25 KiB

18
Documentation/Support.md Normal file
View file

@ -0,0 +1,18 @@
# Support
If you require assistance that involves the internals of Nuclide itself (as in, you have already gotten it running) and need someone to talk to about it - there's a few places where we all gather and talk about this project as well as sub-projects and related projects.
## Matrix
This is the default for us. [You can find a dedicated **Space** right here.](https://matrix.to/#/#nuclide:matrix.org)
## Internet Relay Chat
This is our fallback. It is also bridged with the general room on Matrix.
You can connect to irc.libera.chat and join #nuclide.
## Commercial Support
While the code is free - both in price and in license, our time is not.
If you require support that involves more than what the documentation here offers, reach out over at <mailto:biz@vera-visions.com>.
While we are a tiny team, and need to be compensated, keep your expectations reasonable as to the level of support we can provide - especially with only one programmer.

0
doc/fte.svg → Documentation/fte.svg
View file

Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

0
doc/idtech.svg → Documentation/idtech.svg
View file

Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.7 KiB

After

Width:  |  Height:  |  Size: 3.7 KiB

85
Documentation/openal.svg Normal file
View file

@ -0,0 +1,85 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
version="1.1"
width="400"
height="215"
id="svg3078"
xml:space="preserve"
sodipodi:docname="openal.svg"
inkscape:version="1.0.2 (e86c870879, 2021-01-15)">
<style>
@media (prefers-color-scheme: dark) {
path {
fill: white;
}
g {
fill: white;
}
}
@media (prefers-color-scheme: light) {
path {
fill: black;
}
g {
fill: black;
}
}
</style><sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1525"
inkscape:window-height="1019"
id="namedview72"
showgrid="false"
inkscape:zoom="2.86"
inkscape:cx="254.36914"
inkscape:cy="107.5"
inkscape:window-x="0"
inkscape:window-y="0"
inkscape:window-maximized="0"
inkscape:current-layer="g3142" /><metadata
id="metadata3084"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs
id="defs3082" /><g
transform="matrix(1.25,0,0,-1.25,0,215)"
id="g3086"><g
transform="matrix(0.61991192,0,0,0.61991192,7.5079443,3.7376882)"
id="g3142"><path
d="m 386.09375,721.875 c -19.36375,0 -35.0625,15.7 -35.0625,35.0625 l 0,92.65625 -7.5,0 0,7.5 7.5,0 0,100.15625 c 0,19.36275 15.69875,35.0625 35.0625,35.0625 19.3625,0 35.0625,-15.69975 35.0625,-35.0625 l 0,-100.15625 7.53125,0 0,-7.5 -7.53125,0 0,-92.65625 c 0,-19.3625 -15.7,-35.0625 -35.0625,-35.0625 z m 0,16.28125 0,111.4375 -21.28125,0 0,-90.15625 c 0,-11.75625 9.525,-21.28125 21.28125,-21.28125 z m -52.59375,13.75 -44.65625,0.9375 36.6875,23.96875 0.8125,-0.25 0,0.375 z m -7.15625,25.03125 -0.0937,0.34375 -0.71875,-0.46875 -41.875,12.9375 41.875,12.96875 0.71875,-0.46875 0.0937,0.3125 z m 0,25.625 0,0.40625 -0.8125,-0.25 -36.6875,23.96875 44.65625,0.90625 z m 112.34375,-50.65625 7.1875,25.0625 0,-0.40625 0.8125,0.25 36.65625,-23.96875 z m 8,24.90625 -0.71875,0.46875 -0.0937,-0.3125 0,25.59375 0.0937,-0.3125 0.71875,0.46875 41.84375,-12.96875 z m 0,25.90625 -0.8125,0.25 0,-0.40625 -7.1875,25.03125 44.65625,-0.90625 z m -71.21875,-25.75 c -4.14875,0 -7.53125,3.35125 -7.53125,7.5 0,4.15 3.3825,7.53125 7.53125,7.53125 4.14875,0 7.5,-3.38125 7.5,-7.53125 0,-4.14875 -3.35125,-7.5 -7.5,-7.5 z m 21.28125,0 c 4.15,0 7.5,3.35125 7.5,7.5 0,4.15 -3.35,7.53125 -7.5,7.53125 -4.14875,0 -7.53125,-3.38125 -7.53125,-7.53125 0,-4.14875 3.3825,-7.5 7.53125,-7.5 z M 375.46875,797 c -4.14875,0 -7.53125,3.35125 -7.53125,7.5 0,4.14875 3.3825,7.53125 7.53125,7.53125 4.14875,0 7.5,-3.3825 7.5,-7.53125 0,-4.14875 -3.35125,-7.5 -7.5,-7.5 z m 21.28125,0 c 4.15,0 7.5,3.35125 7.5,7.5 0,4.14875 -3.35,7.53125 -7.5,7.53125 -4.14875,0 -7.53125,-3.3825 -7.53125,-7.53125 0,-4.14875 3.3825,-7.5 7.53125,-7.5 z m -21.28125,20.03125 c -4.14875,0 -7.53125,3.35125 -7.53125,7.5 0,0.22241 0.0118,0.46419 0.0312,0.6875 9.3e-4,0.0102 -9.7e-4,0.021 0,0.0312 0.36318,3.8117 3.59421,6.8125 7.5,6.8125 3.91625,0 7.12,-2.9925 7.46875,-6.8125 l 0,-0.0312 c 0.02,-0.2275 0.0312,-0.455 0.0312,-0.6875 0,-4.14875 -3.35125,-7.5 -7.5,-7.5 z m 21.28125,0 c 4.15,0 7.5,3.35125 7.5,7.5 0,0.22241 -0.0129,0.46419 -0.0312,0.6875 -9.3e-4,0.0102 9.7e-4,0.021 0,0.0312 -0.36301,3.8117 -3.56172,6.8125 -7.46875,6.8125 -3.91625,0 -7.1525,-2.9925 -7.5,-6.8125 l 0,-0.0312 c -0.0213,-0.2275 -0.0312,-0.455 -0.0312,-0.6875 0,-4.14875 3.3825,-7.5 7.53125,-7.5 z m -69.5,32.5625 0,108.90625 c 0,32.5 26.34375,58.875 58.84375,58.875 32.5,0 58.84375,-26.375 58.84375,-58.875 l 0,-108.90625 -7.5,0 0,108.90625 c 0,28.353 -22.99125,51.3438 -51.34375,51.3438 -28.35375,0 -51.3125,-22.9908 -51.3125,-51.3438 l 0,-108.90625 z m 58.84375,7.5 21.28125,0 0,74.9375 -0.125,0 0.125,0.1875 0,21.28125 -0.28125,3.40625 -21,-24.875 21.15625,0 -21.15625,-24.96875 21.1875,0 -21.1875,-25 21.25,0 z m 21,99.84375 c -0.005,0.0313 0.005,0.0625 0,0.0937 -0.86,5.1655 -3.56875,9.71087 -7.4375,12.90625 l -13.5625,-12.90625 z m -52.28125,74.4063 0,20.0312 62.59375,0 0,-20.0312 z"
transform="matrix(0.8,0,0,-0.8,0,842)"
id="path3090"
style="fill-opacity:1;fill-rule:evenodd;stroke:none" /><path
d="m 199.125,849.59375 c -19.3625,0 -35.0625,15.7 -35.0625,35.0625 l 0,37.3125 c 0,19.36312 15.7,35.0625 35.0625,35.0625 19.3625,0 35.0625,-15.69938 35.0625,-35.0625 l -20.03125,0 c 0,8.29763 -6.73375,15.03125 -15.03125,15.03125 -8.2975,0 -15.03125,-6.73362 -15.03125,-15.03125 l 0,-8.65625 30.0625,0 0,-20.03125 -30.0625,0 0,-8.625 c 0,-8.2975 6.73375,-15.03125 15.03125,-15.03125 8.2975,0 15.03125,6.73375 15.03125,15.03125 l 20.03125,0 c 0,-19.3625 -15.7,-35.0625 -35.0625,-35.0625 z"
transform="matrix(0.8,0,0,-0.8,0,842)"
id="path3096"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 251.8,76.3785 -16.073,0 0,57.9085 c 0,6.638 -5.381,12.019 -12.018,12.019 -6.638,0 -12.02,-5.381 -12.02,-12.019 0,0 0,-57.9085 0.045,-57.9085 l -16.073,0 0,57.9085 c 0,15.49 12.557,28.047 28.048,28.047 15.49,0 28.047,-12.557 28.047,-28.047 0,0 0,-57.9085 0.044,-57.9085"
id="path3098"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 56.8887,134.287 0,-29.861 c 0,-15.4905 -12.5571,-28.0475 -28.0473,-28.0475 -15.4906,0 -28.04765,12.557 -28.04765,28.0475 l 0,29.861 c 0,15.49 12.55705,28.047 28.04765,28.047 15.4902,0 28.0473,-12.557 28.0473,-28.047 z m -16.0285,0 c 0,6.638 -5.3809,12.019 -12.0188,12.019 -6.6383,0 -12.0191,-5.381 -12.0191,-12.019 l 0,-29.861 c 0,-6.6381 5.3808,-12.019 12.0191,-12.019 6.6379,0 12.0188,5.3809 12.0188,12.019 l 0,29.861"
id="path3100"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 122.564,134.287 0,-29.861 c 0,-15.4905 -12.557,-28.0475 -28.0472,-28.0475 -4.3012,0 -8.3762,0.968 -12.0191,2.6985 l 0,-27.9254 -16.0286,0 0,105.1724 c 0,0 6.5579,-0.509 10.6989,0 7.1066,0.874 7.3422,6.01 17.3488,6.01 15.4902,0 28.0472,-12.557 28.0472,-28.047 z m -16.028,0 c 0,6.638 -5.381,12.019 -12.0192,12.019 -6.6379,0 -12.0191,-5.381 -12.0191,-12.019 l 0,-29.861 c 0,-6.6381 5.3812,-12.019 12.0191,-12.019 6.6382,0 12.0192,5.3809 12.0192,12.019 l 0,29.861"
id="path3102"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 493.78125,849.59375 c -19.3625,0 -35.0625,15.7 -35.0625,35.0625 l 0,72.375 20.09375,0 c -0.0319,0 -0.0548,-21.49816 -0.0625,-41.9375 l 30.0625,0 0,41.9375 20.09375,0 c -0.0319,0 -0.0548,-21.49816 -0.0625,-41.9375 -0.004,-9.76276 8.3e-4,-15.0992 0,-20.03125 -4.3e-4,-2.56221 0,-10.40625 0,-10.40625 0,-19.3625 -15.69875,-35.0625 -35.0625,-35.0625 z m 0,20.03125 c 8.29875,0 15.03125,6.73375 15.03125,15.03125 l 0,10.40625 -30.0625,0 c -4.3e-4,-2.56221 0,-10.40625 0,-10.40625 0,-8.2975 6.735,-15.03125 15.03125,-15.03125 z"
transform="matrix(0.8,0,0,-0.8,0,842)"
id="path3106"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 451.119,92.407 12.019,0 c 6.638,0 12.019,5.3809 12.019,12.019 l 16.029,0 c 0,-15.4905 -12.557,-28.0475 -28.048,-28.0475 l -28.047,0 0,85.9555 16.028,0 0,-69.927"
id="path3110"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /></g></g></svg>
Side by side

After

Width:  |  Height:  |  Size: 7.6 KiB

85
Documentation/opengl.svg Normal file
View file

@ -0,0 +1,85 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
version="1.1"
width="1357.35"
height="562.5"
id="svg2"
xml:space="preserve"
sodipodi:docname="OpenGL_logo_(Nov14).svg"
inkscape:version="1.0.2 (e86c870879, 2021-01-15)">
<style>
@media (prefers-color-scheme: dark) {
path {
fill: white;
}
g {
fill: white;
}
}
@media (prefers-color-scheme: light) {
path {
fill: black;
}
g {
fill: black;
}
}
</style><sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1920"
inkscape:window-height="1019"
id="namedview15"
showgrid="false"
inkscape:zoom="0.82071685"
inkscape:cx="678.67499"
inkscape:cy="281.25"
inkscape:window-x="0"
inkscape:window-y="0"
inkscape:window-maximized="1"
inkscape:current-layer="g12" /><metadata
id="metadata8"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><defs
id="defs6" /><g
transform="matrix(1.25,0,0,-1.25,0,562.5)"
id="g10"><g
transform="scale(0.1,0.1)"
id="g12"><path
d="m 1475.08,1979.84 c 25.13,-91.65 64.58,-174.12 118.42,-247.41 53.79,-73.32 122.84,-132.22 207.18,-176.77 84.27,-44.52 184.7,-66.72 301.35,-66.72 116.59,0 217.02,22.2 301.36,66.72 84.27,44.55 153.32,103.45 207.17,176.77 53.78,73.29 93.23,155.76 118.36,247.41 25.11,91.66 37.68,184.61 37.68,278.86 0,94.25 -12.57,187.13 -37.68,278.79 -25.13,91.66 -64.58,174.12 -118.36,247.47 -53.85,73.27 -122.9,132.17 -207.17,176.71 -84.34,44.53 -184.77,66.8 -301.36,66.8 -116.65,0 -217.08,-22.27 -301.35,-66.8 -84.34,-44.54 -153.39,-103.44 -207.18,-176.71 -53.84,-73.35 -93.29,-155.81 -118.42,-247.47 -25.12,-91.66 -37.62,-184.54 -37.62,-278.79 0,-94.25 12.5,-187.2 37.62,-278.86 z m -234.38,647.03 c 38.51,117.69 96.33,221.92 173.34,312.59 77.01,90.67 172.9,163.09 287.53,217.11 114.64,54.04 248.14,81.12 400.46,81.12 152.25,0 285.76,-27.08 400.4,-81.12 114.63,-54.02 210.52,-126.44 287.53,-217.11 77.01,-90.67 134.83,-194.9 173.33,-312.59 38.51,-117.69 57.82,-240.19 57.82,-367.5 0,-127.3 -19.31,-249.86 -57.82,-367.53 -38.5,-117.69 -96.32,-221.93 -173.33,-312.61 -77.01,-90.67 -172.9,-162.64 -287.53,-215.81 -114.64,-53.12 -248.15,-79.76 -400.4,-79.76 -152.32,0 -285.82,26.64 -400.46,79.76 -114.63,53.17 -210.52,125.14 -287.53,215.81 -77.01,90.68 -134.83,194.92 -173.34,312.61 -38.5,117.67 -57.76,240.23 -57.76,367.53 0,127.31 19.26,249.81 57.76,367.5"
id="path14"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 4116.68,2091.86 c -14.9,52.92 -37.55,100.1 -68.11,141.56 -30.56,41.44 -69.75,74.44 -117.54,98.98 -47.85,24.55 -103.83,36.83 -168.03,36.83 -67.42,0 -124.61,-13.08 -171.57,-39.16 -47.04,-26.1 -85.4,-60.21 -115.2,-102.39 -29.8,-42.19 -51.33,-90.18 -64.64,-143.91 -13.32,-53.71 -19.95,-108.18 -19.95,-163.38 0,-58.35 7,-114.74 21.15,-169.19 14.07,-54.54 36.41,-102.45 66.98,-143.91 30.54,-41.44 70.06,-74.81 118.66,-100.11 48.61,-25.33 107.38,-37.98 176.31,-37.98 68.93,0 126.5,13.01 172.7,39.1 46.21,26.09 83.46,60.63 111.67,103.62 28.16,42.93 48.54,92.03 61.1,147.29 12.5,55.27 18.81,112.02 18.81,170.36 0,55.22 -7.44,109.3 -22.34,162.29 z m -716.96,423.36 0,-161.35 4.03,0 c 32.96,66.06 84.78,114.11 155.48,144.09 70.7,29.97 148.4,44.96 233.25,44.96 94.18,0 176.24,-16.89 246.18,-50.7 69.88,-33.8 127.95,-79.45 174.28,-136.99 46.34,-57.6 81.24,-123.98 104.85,-199.18 23.55,-75.23 35.35,-155.05 35.35,-239.49 0,-84.44 -11.42,-164.26 -34.15,-239.51 -22.79,-75.23 -57.31,-140.87 -103.65,-196.87 -46.33,-56.01 -104.47,-100.17 -174.34,-132.37 -69.95,-32.2 -151.19,-48.35 -243.85,-48.35 -29.86,0 -63.25,3.07 -100.12,9.19 -36.92,6.21 -73.41,16.14 -109.52,29.96 -36.1,13.82 -70.32,32.71 -102.51,56.51 -32.19,23.81 -59.27,53.35 -81.25,88.76 l -4.03,0 0,-614.708 -202.01,0 0,1646.048 202.01,0"
id="path16"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 5334.47,2164.7 c -18.02,41.33 -42.34,76.98 -72.89,106.83 -30.62,29.85 -66.72,53.6 -108.26,71.24 -41.6,17.64 -87.49,26.46 -137.68,26.46 -51.76,0 -98.47,-8.82 -140.01,-26.46 -41.59,-17.64 -77.26,-41.76 -107.05,-72.35 -29.8,-30.65 -53.34,-66.31 -70.58,-106.89 -17.29,-40.59 -27.46,-83.88 -30.61,-129.84 l 698.92,0 c -3.17,45.96 -13.77,89.63 -31.84,131.01 z m 48.95,-764.03 c -91.29,-67.48 -206.11,-101.21 -344.61,-101.21 -97.59,0 -182.24,15.34 -253.82,46 -71.65,30.71 -131.86,73.71 -180.66,128.98 -48.79,55.27 -85.4,121.25 -109.77,198.04 -24.37,76.75 -38.13,160.45 -41.29,250.99 0,90.54 14.14,173.43 42.55,248.7 28.34,75.24 68.11,140.5 119.3,195.76 51.19,55.27 111.85,98.2 181.93,128.92 70.06,30.71 146.89,46.07 230.4,46.07 108.7,0 198.84,-21.95 270.54,-65.75 71.72,-43.85 129.22,-99.61 172.52,-167.28 43.31,-67.72 73.29,-141.55 89.83,-221.48 16.54,-80 23.23,-156.12 20.08,-228.41 l -913.03,0 c -1.58,-52.12 4.67,-101.53 18.81,-148.28 14.14,-46.75 36.87,-88.14 68.3,-124.17 31.44,-36.01 71.46,-64.69 120.19,-86.15 48.66,-21.48 105.98,-32.2 171.95,-32.2 84.77,0 154.28,19.17 208.44,57.61 54.16,38.42 89.88,96.82 107.18,175.29 l 198.21,0 c -26.77,-133.48 -85.78,-233.95 -177.05,-301.43"
id="path18"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 5904.18,2515.22 0,-189.05 3.79,0 c 83.69,144.46 216.44,216.75 398.18,216.75 80.55,0 147.7,-10.79 201.49,-32.31 53.71,-21.54 97.15,-51.51 130.35,-89.94 33.2,-38.42 56.5,-84.13 69.94,-137.17 13.38,-53.05 20.14,-111.84 20.14,-176.41 l 0,-783.95 -202,0 0,806.46 c 0,73.71 -22.11,132.06 -66.23,175.11 -44.18,43 -104.84,64.52 -182.05,64.52 -61.46,0 -114.68,-9.25 -159.63,-27.69 -44.94,-18.45 -82.38,-44.53 -112.3,-78.34 -29.9,-33.8 -52.38,-73.34 -67.34,-118.61 -15.02,-45.33 -22.48,-94.86 -22.48,-148.65 l 0,-672.8 -202,0 0,1192.08 190.14,0"
id="path20"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 8124.43,1336.09 c -91.21,-37.56 -183.32,-56.38 -276.23,-56.38 -146.7,0 -278.57,25 -395.72,74.83 -117.17,49.89 -215.94,118.6 -296.43,206.19 -80.48,87.52 -142.16,190.4 -185.09,308.59 -42.91,118.17 -64.38,245.6 -64.38,382.16 0,140.01 21.41,270.04 64.2,390 42.81,119.92 104.34,224.52 184.63,313.83 80.31,89.32 178.97,159.32 296.05,210.15 117.09,50.76 248.97,76.17 395.67,76.17 98.34,0 193.53,-14.49 285.62,-43.43 92.11,-28.98 175.26,-71.53 249.5,-127.67 74.21,-56.13 135.45,-125.33 183.73,-207.55 48.3,-82.28 77.85,-176.65 88.57,-283.23 l -402.34,0 c -25.06,104.79 -73.36,183.43 -144.89,235.86 -71.58,52.43 -158.3,78.64 -260.19,78.64 -94.81,0 -175.29,-17.94 -241.45,-53.84 -66.15,-35.9 -119.82,-84.08 -160.97,-144.46 -41.16,-60.45 -71.08,-129.15 -89.81,-206.19 -18.83,-77.05 -28.16,-156.67 -28.16,-238.96 0,-78.83 9.39,-155.43 28.2,-229.82 18.83,-74.38 48.81,-141.36 89.96,-200.89 41.15,-59.51 94.89,-107.19 161.15,-143.09 66.24,-35.9 146.82,-53.85 241.78,-53.85 139.63,0 247.44,34.41 323.56,103.26 76.13,68.82 120.45,168.63 133,299.38 l -423.8,0 0,307.91 803.57,0 0,-1011.99 -267.38,0 -42.82,212.3 c -75.11,-94.36 -158.32,-160.36 -249.53,-197.92"
id="path22"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 9367.09,3194.26 0,-1523.74 933.51,0 0,-347.38 -1353.67,0 0,1871.12 420.16,0"
id="path24"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="M 7380.08,1090.55 C 6737.23,708.5 5774.39,491.039 4700.12,491.039 c -1935.48,0 -3504.5,787.501 -3504.5,1758.961 0,971.46 1569.02,1758.98 3504.5,1758.98 1078.22,0 2044.96,-221.49 2687.83,-605.93 C 6686.25,4047.18 5428.11,4499.79 3989.58,4500 1786.4,4500.35 0.191406,3493.25 0,2250.62 -0.1875,1008.01 1785.68,0.300781 3988.87,0 5421.68,-0.238281 6676.56,450.922 7380.08,1090.55"
id="path26"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /><path
d="m 10650.3,1509.99 20.3,0 c 13.4,0 22.9,2.18 28.5,6.54 5.5,4.38 8.2,10 8.2,16.9 0,6.89 -2.6,12.53 -7.9,16.89 -5.3,4.37 -14.3,6.55 -27,6.55 l -22.1,0 0,-46.88 z m -46.6,79.51 83.9,0 c 23.7,0 40.9,-4.78 51.6,-14.36 10.6,-9.57 15.9,-22.41 15.9,-38.5 0,-12.56 -4,-23.44 -12.1,-32.64 -8.2,-9.19 -21,-15.86 -38.4,-19.99 7.2,-2.76 12.5,-5.67 15.8,-8.73 4.8,-4.29 9.8,-10.65 15,-19.08 0.3,-0.61 10.4,-18.7 30.3,-54.24 l -55.2,0 c -17.9,35.7 -29.9,57.04 -36,64.02 -6.2,6.96 -12.3,10.46 -18.4,10.46 -1.4,0 -3.3,-0.24 -5.8,-0.7 l 0,-73.78 -46.6,0 0,187.54 z m 221.1,-93.77 c 0,39.07 -13.9,72.44 -41.5,100.1 -27.7,27.66 -61,41.48 -100.1,41.48 -39.1,0 -72.4,-13.82 -100.1,-41.48 -27.7,-27.66 -41.5,-61.03 -41.5,-100.1 0,-39.07 13.8,-72.43 41.5,-100.09 27.7,-27.65 61,-41.48 100.1,-41.48 39.1,0 72.4,13.83 100.1,41.48 27.6,27.66 41.5,61.02 41.5,100.09 z m 34,0 c 0,-31.4 -7.9,-60.67 -23.6,-87.79 -15.7,-27.12 -37.1,-48.5 -64.2,-64.12 -27.1,-15.64 -56.4,-23.45 -87.8,-23.45 -31.3,0 -60.4,7.81 -87.6,23.45 -27.1,15.62 -48.5,37 -64.2,64.12 -15.7,27.12 -23.6,56.39 -23.6,87.79 0,31.26 7.9,60.48 23.6,87.69 15.7,27.2 37.1,48.6 64.2,64.24 27.2,15.62 56.3,23.43 87.6,23.43 31.4,0 60.7,-7.81 87.8,-23.43 27.1,-15.64 48.5,-37.04 64.2,-64.24 15.7,-27.21 23.6,-56.43 23.6,-87.69"
id="path28"
style="fill-opacity:1;fill-rule:nonzero;stroke:none" /></g></g></svg>
Side by side

After

Width:  |  Height:  |  Size: 9.6 KiB

2
doc/release-readme → Documentation/release-readme.txt
View file

@ -19,7 +19,7 @@ Make sure you're running the latest version of FTEQW.
If your entire engine/binary crashes to desktop or whatever, it's an FTE bug.
Contact #fte at irc.quakenet.org
If you crash to console, contact #freecs at irc.freenode.net
If you crash to console, contact #freecs at irc.libera.chat
Notes
=======================================

116
Documentation/vulkan.svg Normal file
View file

@ -0,0 +1,116 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
version="1.1"
id="Vulkan"
x="0px"
y="0px"
width="1300px"
height="500px"
viewBox="0 0 1300 500"
xml:space="preserve"
sodipodi:docname="Vulkan_RGB_Dec16.svg"
inkscape:version="1.0.2 (e86c870879, 2021-01-15)">
<style>
@media (prefers-color-scheme: dark) {
path {
fill: white;
}
g {
fill: white;
}
}
@media (prefers-color-scheme: light) {
path {
fill: black;
}
g {
fill: black;
}
}
</style><metadata
id="metadata37"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><defs
id="defs35" /><sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1920"
inkscape:window-height="1019"
id="namedview33"
showgrid="false"
inkscape:zoom="0.85692308"
inkscape:cx="650"
inkscape:cy="250"
inkscape:window-x="0"
inkscape:window-y="0"
inkscape:window-maximized="1"
inkscape:current-layer="Vulkan" />
<g
id="g26">
<path
d="M724.1,385.06h-40.57c0,0,0-98.97,0-129.66c12.96,7.22,30.09,20.54,40.57,33.32V385.06z"
id="path2"
style="fill-opacity:1" />
<g
id="g8">
<path
d="M381.75,385.06h-50.58l-66.01-204.03h46.01l45.44,143.45h0.57l46-143.45h46.29L381.75,385.06z"
id="path4"
style="fill-opacity:1" />
<path
d="M585.51,385.06h-38.58v-20.57h-0.85c-5.15,8.58-11.81,14.77-20.01,18.58c-8.19,3.81-16.57,5.71-25.15,5.71 c-10.86,0-19.76-1.43-26.72-4.28c-6.95-2.85-12.43-6.91-16.43-12.14c-4.01-5.24-6.82-11.62-8.44-19.15 c-1.61-7.52-2.42-15.86-2.42-25v-90.88h40.58v83.44c0,12.19,1.91,21.29,5.72,27.29c3.81,6.01,10.57,9,20.29,9 c11.05,0,19.05-3.28,24-9.86c4.96-6.58,7.43-17.39,7.43-32.44v-77.44h40.59V385.06z"
id="path6"
style="fill-opacity:1" />
</g>
<polygon
points="730.84,296.19 730.74,290.47 781.89,237.33 829.91,237.33 774.18,291.62 836.19,385.06 787.04,385.06 "
id="polygon10"
style="fill-opacity:1" />
<path
d="M843.62,282.76c0.57-9.52,2.96-17.43,7.15-23.72c4.19-6.29,9.52-11.33,16-15.14 c6.48-3.81,13.77-6.53,21.87-8.14c8.09-1.62,16.24-2.43,24.43-2.43c7.43,0,14.95,0.52,22.57,1.57c7.63,1.05,14.57,3.1,20.86,6.15 c6.28,3.05,11.43,7.29,15.44,12.71c4,5.43,6,12.62,6,21.58v76.87c0,6.67,0.38,13.06,1.14,19.15c0.76,6.1,2.1,10.67,4.01,13.72 h-41.15c-0.76-2.28-1.38-4.62-1.86-7c-0.47-2.38-0.81-4.8-1-7.29c-6.48,6.68-14.11,11.34-22.87,14.01c-8.76,2.66-17.72,4-26.86,4 c-7.05,0-13.63-0.86-19.71-2.57c-6.1-1.71-11.44-4.38-16-8c-4.58-3.62-8.16-8.19-10.72-13.72c-2.57-5.52-3.86-12.09-3.86-19.71 c0-8.38,1.48-15.29,4.43-20.72c2.96-5.43,6.76-9.76,11.44-13c4.67-3.24,10-5.67,16-7.29c6-1.62,12.05-2.91,18.14-3.86 c6.1-0.94,12.1-1.71,18.01-2.28c5.91-0.57,11.14-1.43,15.71-2.57c4.58-1.15,8.19-2.81,10.86-5.01c2.67-2.19,3.91-5.38,3.72-9.57 c0-4.38-0.72-7.86-2.15-10.43c-1.43-2.57-3.33-4.57-5.71-6c-2.38-1.43-5.14-2.38-8.29-2.86c-3.15-0.48-6.52-0.72-10.14-0.72 c-8,0-14.29,1.71-18.86,5.15c-4.57,3.43-7.24,9.14-8,17.15H843.62z M937.35,312.77c-1.72,1.53-3.86,2.71-6.43,3.57 c-2.57,0.87-5.33,1.58-8.29,2.15c-2.95,0.57-6.05,1.05-9.28,1.43c-3.24,0.38-6.48,0.85-9.72,1.43c-3.05,0.57-6.05,1.34-9,2.28 c-2.95,0.96-5.53,2.24-7.72,3.86c-2.19,1.62-3.95,3.67-5.29,6.14c-1.33,2.48-2,5.62-2,9.43c0,3.62,0.67,6.67,2,9.14 c1.34,2.48,3.15,4.43,5.43,5.86c2.29,1.43,4.95,2.43,8,3c3.05,0.57,6.19,0.85,9.43,0.85c8,0,14.2-1.33,18.58-3.99 c4.38-2.67,7.63-5.86,9.71-9.58c2.09-3.71,3.39-7.47,3.85-11.28c0.48-3.81,0.71-6.86,0.72-9.14V312.77z"
id="path12"
style="fill-opacity:1" />
<path
d="M1004.21,237.33h38.59v20.57h0.85c5.14-8.57,11.81-14.81,20-18.71c8.19-3.91,16.58-5.86,25.14-5.86 c10.87,0,19.77,1.48,26.73,4.43c6.95,2.96,12.42,7.05,16.43,12.29c4,5.24,6.81,11.62,8.43,19.14c1.62,7.53,2.43,15.86,2.43,25.01 v90.87h-40.57v-83.44c0-12.2-1.91-21.29-5.71-27.29c-3.82-6-10.58-9-20.3-9c-11.05,0-19.04,3.29-24,9.86 c-4.96,6.56-7.43,17.38-7.43,32.43v77.44h-40.58V237.33z"
id="path14"
style="fill-opacity:1" />
<g
id="g18">
<path
d="M612.37,211.84v173.23h40.58V234.21C639.93,226.23,626.36,218.74,612.37,211.84z"
id="path16"
style="fill-opacity:1" />
</g>
<path
d="M198.43,219.21c23.52-68.89,164.15-94.16,314.15-56.43c89.97,22.62,163.49,66.5,211.51,109.89 c-21.79-57.55-127.44-139.59-272.91-167.71c-164.48-31.8-326.71-3.85-346.79,69.14c-14.5,52.73,49.18,114.5,147.66,156.74 C207.81,295.02,186.29,254.78,198.43,219.21z"
id="path20"
style="fill-opacity:1" />
<g
id="g24">
<path
d="M724.16,247.62v-66.59h-40.59v20.22C700.88,216.71,714.61,232.45,724.16,247.62z"
id="path22"
style="fill-opacity:1" />
</g>
</g>
<g
id="g30">
<path
d="M1214.98,363.43c0,12.26-9.63,21.89-22.15,21.89c-12.4,0-22.29-9.63-22.29-21.89 c0-12,9.89-21.63,22.29-21.63C1205.35,341.8,1214.98,351.43,1214.98,363.43z M1176.08,363.43c0,9.63,7.12,17.27,16.88,17.27 c9.49,0,16.48-7.65,16.48-17.14c0-9.63-6.99-17.41-16.62-17.41C1183.2,346.16,1176.08,353.94,1176.08,363.43z M1189.39,374.77 h-5.01v-21.63c1.98-0.4,4.75-0.66,8.31-0.66c4.09,0,5.93,0.66,7.52,1.58c1.19,0.92,2.11,2.64,2.11,4.75c0,2.37-1.85,4.22-4.48,5.01 v0.26c2.11,0.79,3.3,2.37,3.96,5.27c0.66,3.3,1.05,4.62,1.58,5.41h-5.41c-0.66-0.79-1.05-2.77-1.71-5.27 c-0.4-2.37-1.71-3.43-4.48-3.43h-2.37V374.77z M1189.53,362.51h2.37c2.77,0,5.01-0.92,5.01-3.17c0-1.98-1.45-3.3-4.62-3.3 c-1.32,0-2.24,0.13-2.77,0.26V362.51z"
id="path28"
style="fill-opacity:1" />
</g>
</svg>
Side by side

After

Width:  |  Height:  |  Size: 5.9 KiB

60
Doxyfile
View file

@ -32,7 +32,7 @@ DOXYFILE_ENCODING = UTF-8
# title of most generated pages and in a few other places.
# The default value is: My Project.
PROJECT_NAME = "Nuclide"
PROJECT_NAME = Nuclide
# The PROJECT_NUMBER tag can be used to enter a project or revision number. This
# could be handy for archiving the generated documentation or if some version
@ -44,7 +44,7 @@ PROJECT_NUMBER =
# for a project that appears at the top of each page and should give viewer a
# quick idea about the purpose of the project. Keep the description short.
PROJECT_BRIEF =
PROJECT_BRIEF = "Software Development Kit for id Tech"
# With the PROJECT_LOGO tag one can specify a logo or an icon that is included
# in the documentation. The maximum height of the logo should not exceed 55
@ -58,7 +58,7 @@ PROJECT_LOGO =
# entered, it will be relative to the location where doxygen was started. If
# left blank the current directory will be used.
OUTPUT_DIRECTORY = ./doc
OUTPUT_DIRECTORY = ./Documentation
# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
# directories (in 2 levels) under the output directory of each output format and
@ -68,7 +68,7 @@ OUTPUT_DIRECTORY = ./doc
# performance problems for the file system.
# The default value is: NO.
CREATE_SUBDIRS = NO
CREATE_SUBDIRS = YES
# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
# characters to appear in the names of generated files. If set to NO, non-ASCII
@ -244,7 +244,7 @@ SEPARATE_MEMBER_PAGES = NO
# uses this value to replace tabs by spaces in code fragments.
# Minimum value: 1, maximum value: 16, default value: 4.
TAB_SIZE = 4
TAB_SIZE = 8
# This tag can be used to specify a number of aliases that act as commands in
# the documentation. An alias has the form:
@ -463,7 +463,7 @@ LOOKUP_CACHE_SIZE = 0
# DOT_NUM_THREADS setting.
# Minimum value: 0, maximum value: 32, default value: 1.
NUM_PROC_THREADS = 1
NUM_PROC_THREADS = 4
#---------------------------------------------------------------------------
# Build related configuration options
@ -489,7 +489,7 @@ EXTRACT_PRIVATE = YES
# methods of a class will be included in the documentation.
# The default value is: NO.
EXTRACT_PRIV_VIRTUAL = NO
EXTRACT_PRIV_VIRTUAL = YES
# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal
# scope will be included in the documentation.
@ -874,7 +874,22 @@ WARN_LOGFILE =
# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
# Note: If this tag is empty the current directory is searched.
INPUT = src/
INPUT = src/ \
Documentation/Main.md \
Documentation/Building.md \
Documentation/Filesystem.md \
Documentation/Mods.md \
Documentation/Materials/mat_overview.md \
Documentation/Materials/mat_commands.md \
Documentation/Materials/mat_vmap.md \
Documentation/Materials/commands/ \
Documentation/Materials/mat_shaders.md \
Documentation/Materials/mat_legacy.md \
Documentation/Sound/ \
Documentation/Models/ \
Documentation/History.md \
Documentation/Contributing.md \
Documentation/Support.md
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
@ -903,7 +918,9 @@ INPUT_ENCODING = UTF-8
# comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, *.f18, *.f, *.for, *.vhd,
# *.vhdl, *.ucf, *.qsf and *.ice.
FILE_PATTERNS = *.qc *.h
FILE_PATTERNS = *.qc \
*.h \
*.md
# The RECURSIVE tag can be used to specify whether or not subdirectories should
# be searched for input files as well.
@ -918,7 +935,12 @@ RECURSIVE = YES
# Note that relative paths are relative to the directory from which doxygen is
# run.
EXCLUDE = src/engine src/worldspawn src/vvmtool
EXCLUDE = src/engine \
src/worldspawn \
src/vvmtool \
src/menu-vgui \
src/menu-fn \
src/plugins
# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
# directories that are symbolic links (a Unix file system feature) are excluded
@ -934,7 +956,12 @@ EXCLUDE_SYMLINKS = NO
# Note that the wildcards are matched against the file with absolute path, so to
# exclude all test directories for example use the pattern */test/*
EXCLUDE_PATTERNS = */src/engine/* */src/worldspawn/* */src/vvmtool/*
EXCLUDE_PATTERNS = */src/engine/* \
*/src/worldspawn/* \
*/src/vvmtool/* \
*/src/menu-fn/* \
*/src/menu-vgui/* \
*/src/plugins/*
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the
@ -971,7 +998,8 @@ EXAMPLE_RECURSIVE = NO
# that contain images that are to be included in the documentation (see the
# \image command).
IMAGE_PATH =
IMAGE_PATH = Documentation/Materials/ \
Documentation/Sound/ \
# The INPUT_FILTER tag can be used to specify a program that doxygen should
# invoke to filter for each input file. Doxygen will invoke the filter program
@ -1027,7 +1055,7 @@ FILTER_SOURCE_PATTERNS =
# (index.html). This can be useful if you have a project on for instance GitHub
# and want to reuse the introduction page also for the doxygen output.
USE_MDFILE_AS_MAINPAGE =
USE_MDFILE_AS_MAINPAGE = Main.md
#---------------------------------------------------------------------------
# Configuration options related to source browsing
@ -1521,7 +1549,7 @@ DISABLE_INDEX = NO
# The default value is: NO.
# This tag requires that the tag GENERATE_HTML is set to YES.
GENERATE_TREEVIEW = NO
GENERATE_TREEVIEW = YES
# When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the
# FULL_SIDEBAR option determines if the side bar is limited to only the treeview
@ -2240,7 +2268,9 @@ INCLUDE_FILE_PATTERNS =
# recursively expanded use the := operator instead of the = operator.
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
PREDEFINED = SERVER CLIENT MENU
PREDEFINED = SERVER \
CLIENT \
MENU
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
# tag can be used to specify a list of macro names that should be expanded. The

4
README.md
View file

@ -1,4 +1,4 @@
# ![FTE Logo](doc/fte.svg) Nuclide - Software Development Kit
# ![FTE Logo](Documentation/fte.svg) Nuclide - Software Development Kit
Software Development Kit, built around idTech with focus on advanced features and
clean-room implementations of true-and-tested game-logic frameworks.
@ -101,7 +101,7 @@ David Walton for **FTEQW** and the **FTEQCC** compiler, which is the brain of th
Timothee Besset and the **GtkRadiant** contributors, as well as the NetRadiant team for giving us a base for our editor **WorldSpawn**.
![idTech Logo](doc/idtech.svg)
![idTech Logo](Documentation/idtech.svg)
## License
Copyright (c) 2016-2022 Vera Visions L.L.C.

34
doc/about
View file

@ -1,34 +0,0 @@
About Nuclide
The Nuclide project produces a freely available game-logic component and
development platform on top of FTEQW; which is the engine we use.
Our goals is to create a modern research base for new advancements, as well
as to have a stable base with a good API for games.
- Client-side predicted movement and inputs for things like weapons-systems
- Lots of well documented objects to use in level formats supported by FTEQW
- Reference implementations for a lot of features exlusive to FTEQW compared
to other idTech engines
- Designed to be familar to developers who're used to GoldSrc and Source engine
projects
1. Why might I want to use it?
You want to develop a game using a lot of complex and well-tested objects
which might be tedious to implement on your own.
You want to run or make modifications for a game using Nuclide and need full
control over what you can do.
2. How free is Nuclide?
Everything in Nuclide is free. The copyright terms for the game-logic are
very permitting. Nuclide does not use the GPL as a point of reference, it
instead uses a ISC-like license. This means you can use, copy, modify and
distribute the code and work resulting from it for any purpose.
Please read the very short 'license' document for details.
3. What are the alternatives?
Implementing systems such as prediction, complex map objects and entities on
your own or licensing another engine such as Source that ships with its own
Source SDK Base.

48
doc/building
View file

@ -1,48 +0,0 @@
Building the engine and toolchain:
The build_engine.sh will do that for you. It will still ask you to have at least
a certain amount of dependencies installed (such as the GCC, make and the X/SDL
headers for your operating system.
Building the editor:
Handled by build_editor.sh.
GTK2, Pango, GTKGLEXT and MiniZip are one of a few other main dependencies.
Building the game-logic:
Once build_engine.sh has been executed, you can now build the source tree with
build_game.sh. It'll use the fteqcc binary that's in the ./bin/ directory.
Old, manual build instructions:
================================================================================
1. Building all of the game-logic
To build the game-logic for all games, issue 'make' inside the src/
directory of the repository. This requires you to have the latest
fteqcc installed.
2. Building a specific game or mod
For that you'll have to navigate into the client and server directory
of the game you want to compile. For example if you're only wanting to
build the Half-Life game-logic, navigate into src/client/valve, issue
'make' there, then do the same inside src/server/valve.
3. Building the engine
The engine is not part of this project.
However, as of this writing, building the engine is simple.
Checkout/Clone the FTEQW engine repository, then navigate into the
engine/ sub-directory and issue 'make m-rel' there.
This will generate a 'fteqw' binary for your platform in the sub-directory
titled 'release'.
3. Building fteqcc
Issue 'make qcc-rel' in the FTEQW repository folder 'engine', like in 3.
It will generate an fteqcc binary inside the sub-directory 'release'.
4. Misc notes
To those not in the know, the game-logic is written in QuakeC, it is thus
platform and architecture independent. You do not need to rebuild the logic
for each and every platform. The result will be identical.

17
doc/contributing
View file

@ -1,17 +0,0 @@
NUCLIDE CODEBASE CONTRIBUTING RULES
1. The code must be yours.
It's simple: Do not take GPL code. Do not take Half-Life SDK code.
We do not decompile, we reverse-engineer by trial and error.
Also referred to as 'clean-room engineering'.
Most of the behaviour is rather predictable, other is not.
2. Game specific features need to be put into game-specific directories.
Unless other games benefit from this, keep it seperate to one of the game
sub-directories.
That's about it.
Join us on #nuclide at irc.libera.chat

36
doc/filesystem
View file

@ -1,36 +0,0 @@
NUCLIDE FILESYSTEM DOCUMENTATION
The 'nuclide' shell script is the launcher.
It sets PATH to include the directory 'bin' which contains the engine that
you've built with build_engine.sh.
When nuclide is run and executes the engine, it'll first read default.fmf which
is a manifest file the engine reads. It is updated occasionally.
It defines which folders to mount in the virtual filesystem of the engine
and has a document entirely dedicated to itself. For that please read:
src/engine/specs/fte_manifests.txt
On its own, Nuclide launches the game 'base', unless you tell it otherwise:
./nuclide -game mygame
You can also load multiple additional folders in a specific order by specifying
multiple '-game' arguments.
Will load 'mygame' instead of base.
It will still load the other 'BASEGAME' entries listed in the default.fmf.
You can even load your own manifest file over default.fmf, by passing
./nuclide -manifest mymanifest.fmf
Once the game has loaded, it'll load the persistent menu.dat into our QuakeC
progs VM.
It' always running, you can make your own by forking src/menu-fn, src/menu-vgui
or write something from scratch.
When a game is mounted, we're either looking for loose files (loaded last), or
pak archives the engine supports. Plain .pak, or zip archives with the pk3 or
pk4 extensions are supported.
Folders with the .pk3dir extensions are treated as if they were .pk3 files.
The editor also supports .pk3dir folders.
Nuclide contains many custom definition files that are not engine specific.
.efx, .font, .sndshd and .way to name a few.
The engine doesn't really read them, the game-logic mostly handles them.

57
doc/hlmaterials
View file

@ -1,57 +0,0 @@
hlmaterials - Nuclide Documentation
Written by Gethyn ThomasQuail, 6th April 2021
This document gives a general overview of what the materials.txt files is,
and how it's used in Nuclide, and why the decisions were chosen for the
current implementation. It is not an in-depth explanation of the format
itself.
The materials.txt is how the GoldSrc engine defined sounds for various
textures throughout the game. For example, crates make "wood" sounds,
vents produce metallic feedback, etc. It is an analogue to surfaceparms
for those familiar with idTech engines, this was just Valve Software's
way of doing it before adopting standards.
In stock Half-Life, this file is located at:
sounds/materials.txt
It is allowed to be overwritten by a modification, and users could customize
the file on the client-side only for themselves. This means there was no
map specific materials, and mods could not inherit HL's materials, so
mods would always have to manage a nearly duplicate file if they desired
custom texture sounds.
A few mods tried to remedy this problem, the following below is methods
documented so far:
- maps/MAPNAME.mat
Introduced in The Wastes.
- maps/MAPNAME_materials.txt
Convention by Andrew Lucas, creator of Trinity SDK, modeled after
MAPNAME_details.txt
- materials_file "PATH/FILE.txt" via "worldspawn" entity
Introduced in Sven Co-op 5.0
All these methods are supported by Nuclide, as one goal is to implement
conventions by not only Valve but the community as well.
In addition Nuclide has also implemented a way of giving modifications
their own inheritable materials file:
sounds/materials_UNIQUENAME.txt
The idea here is that any mod or even map pack can include ONLY the textures
used, and no longer will anyone have to manage a near-clone of materials.txt
For repackaging or modding purposes, if you desire to give your map custom
sound definitions, we recommend The Wastes method for individual maps, while
the Nuclide method should be used for Mods or Map Packs. We find these to be
the most clean and efficient way.
NOTE: We recommend only using materials text files for GoldSrc related modding
purposes. It is inefficient for modern projects as there are much better
standards already supported in Nuclide. Keep in mind, it takes memory to load
big text files, and lots of text files adds up over play sessions.