3DGE Wiki - User contributions [en]

MD2

2016-04-29T08:52:56Z

UsernameAK:

The MD2 model file format was introduced by id Software when releasing [[Quake 2]] in November 1997. It's a file format quite simple to use and understand. MD2 models' characteristics are these:

* Model's geometric data (triangles);
* Frame-by-frame animations;
* Structured data for drawing the model using GL_TRIANGLE_FAN and GL_TRIANGLE_STRIP primitives (called “OpenGL commands”).
* Model's texture is in a separate file. One MD2 model can have only one texture at the same time.

MD2 model file's extension is “md2”. A MD2 file is a binary file divided in two part: the header dans the data. The header contains all information needed to use and manipulate the data.

=Constants=

Here are some constant values defining maximal dimensions, so do not exceed these amounts, or 3DGE will fail to render the model:

* Maximum number of triangles: 4096
* Maximum number of vertices: 2048
* Maximum number of texture coordinates: 2048
* Maximum number of frames: 512
* Maximum number of skins: 32
* Number of precalculated normal vectors: 162

=Use in 3DGE=
Both ports can utilize MD2, but there are a few key additions that become helpful, as the engine supports higher-resolution/color textures,
==Features==
EDGE, and by extension, 3DGE, can load MD2s from either a LUMP in the wadfile, or externally as a plain file. While Quake 2 imposes harsh limits on the format, 3DGE enhances it beyond what was normally capable:

* Ability to use PNG, JPG, and TGA file formats for skins (original PCX is not supported)
* Able to define up to 9 skins-per-model and switch them out on-the-fly through DDF
* Able to use animations as either frame number or reference name, or both if desired
* Can control the bias, aspect, scale, and placement of the model, both for environment and HUD (weapons)

==Limitations==
While those features are handy, there are currently limitations of the format:

* No linear interpolation, so the "jelly-like" vertex animation carries over from Quake 2
* No internal shader system, so the models are lit uniformly, even in the presence of [[dynamic lights]]

==Explanation==
===Model===
Any state frame can specify a model by using the special '@123' or '@framename' syntax for the frame (instead of a letter). The number is the absolute frame number in the MD2 model, beginning at 1, or you can use the frame name.

Examples:
<TABLE WIDTH=95% BORDER=1 CELLSPACING=0 CELLPADDING=3 FRAME="box" BGCOLOR="#C2D6D6" >
<TR><TD>
<FONT SIZE=2>
STATES(IDLE)=TROO:@5:7:NORMAL:NOTHING; // the 5th frame

STATES(IDLE)=TROO:@run3:7:NORMAL:NOTHING; // frame called "run3"
</FONT>
</TD></TR>
</TABLE>
<div style="background: #f2e0ce; border: 2px solid #bfb1a3; padding: 0.6em; margin-top: 0.8em;">The model itself must be stored in a wad, and the lump name is the sprite base ("TROO") plus "MD2" on the end --> "TROOMD2".</div>

===Skins===
The skin of the model is the sprite base ("TROO") plus "SKN1" on the end --> "TROOSKN1". There should be a definition for it in IMAGES.DDF using the sprite namespace --> [spr:TROOSKN1].

Normal and specular maps can be applied to skins. The normal/spec map name id the sprite base ("TROO") plus "NRM" or "SPC" respectively on the end --> "TROONRM1" / "TROOSPC1".

<div style="background: #f2e0ce; border: 2px solid #bfb1a3; padding: 0.6em; margin-top: 0.8em;">Other skins can be used. The command "MODEL_SKIN=3" in a thing or weapon definition will use the third skin --> "TROOSKN3". Up to nine skins can currently be used (1 to 9). The skin can also be changed dynamically by using the SET_SKIN(##) action in the state frames.</div>

=USAGE=
Below describes the commands needed to manipulate and use the models in the game engine via DDF:

===THINGS.DDF===
{| border="1" cellpadding="2" BGCOLOR="#C8F4FF"
! COMMAND
! EXPLANATION
|-
| MODEL_SCALE
| Draw the model bigger, for example: MODEL_SCALE=1.5;
|-
| MODEL_ASPECT
| make the model fatter/skinnier: MODEL_ASPECT=0.7;
|-
| MODEL_BIAS
| add this to every z coordinate: MODEL_BIAS=24.0; Useful if you don't want to position from Quake 2's original 24 units in an external editor.
|}

===WEAPONS.DDF===

{| border="1" cellpadding="2" BGCOLOR="#C8F4FF"
! COMMAND
! EXPLANATION
|-
| MODEL_ASPECT
| make the weapon fatter/skinnier
|-
| MODEL_BIAS
| add this to every z coordinate
|-
| MODEL_FORWARD
| move the weapon forward/backward: MODEL_FORWARD=2.2;
|-
| MODEL_SIDE
| move the weapon right/left: MODEL_SIDE=-3.5;
|}

<div style="background: #f2e0ce; border: 2px solid #bfb1a3; padding: 0.6em; margin-top: 0.8em;">Note: there is no MODEL_SCALE command for WEAPONS.DDF (scaling has no effect because the model is drawn at the camera point). Changing MODEL_FORWARD, MODEL_SIDE and/or MODEL_BIAS can have a huge impact on the apparent size of the weapon.</div>

Also see [[MD3]] and [[MD5]].

Next version

2016-04-29T08:47:56Z

UsernameAK:

3DGE has tons of new features that are works-in-progress. Some of them have been listen elsewhere as completed or not: this is the definitive sheet.

'''Items marked in BOLD indicate in-progress or finished'''!

=2.0x codebase=
The following features will be completed before or at the end of the 2.0x lifecycle:

*: Completed Interpolation (heights, projectiles, etc)

*: MD5 support completed (skins, animation). '''FINISHED'''

*: DDF addition for weapons (Z_Aspect) ('''FINISHED'''), support for partial reloading

*: Splitscreen mode fully functional

*: MD2, MD3, MDL, and MD5 models support normal and specular maps.

=2.1 codebase=

Beginning with 2.1.0, 3DGE will get a massive rewrite:

*: OpenGL 2x rewrite (if extensions are detected, otherwise the engine will fall back to old 1.1 compliance). '''IN PROGRESS'''

*: Total Zone memory manager rewrite (more speed improvements). '''FINISHED'''

*: Textures will support normal, bump, and specular maps. '''IN PROGRESS'''

*: Heavily revamped Dynamic Lighting and Shadowing code (true directional light and true dynamic shadows)

*: Sky subsystem rewritten from Quake 3 for Q3 BSPs, normal sky code will remain for DOOM maps.

*: [http://opl3.cozendey.com/ OPL integration] for music; replaces fudged SYSTEM music player under Windows. '''FINISHED'''

*: SPLINE library replaces all camera code and new script files for them will be added.

*: Environment maps for surfaces (like Half-Life)

*: True Slopes using vertex height calculation

*: Polyobject support.

*: Inventory System

*: Better RTS functions (some adapted from FraggleScript)

*: FraggleScript support (limited*)

*: ROQ library for cinematics, and render-to-texture (skins, textures) '''IN PROGRESS'''

*: Quake 3 BSP Support (loading, rendering)

Next version

2016-04-29T08:47:22Z

UsernameAK:

3DGE has tons of new features that are works-in-progress. Some of them have been listen elsewhere as completed or not: this is the definitive sheet.

'''Items marked in BOLD indicate in-progress or finished'''!

=2.0x codebase=
The following features will be completed before or at the end of the 2.0x lifecycle:

*: Completed Interpolation (heights, projectiles, etc)

*: MD5 support completed (skins, animation). '''FINISHED'''

*: DDF addition for weapons (Z_Aspect) ('''FINISHED'''), support for partial reloading

*: Splitscreen mode fully functional

*: MD2, MD3, MDL, and MD5 models support normal and specular maps.

=2.1 codebase=

Beginning with 2.1.0, 3DGE will get a massive rewrite:

*: OpenGL 2x rewrite (if extensions are detected, otherwise the engine will fall back to old 1.1 compliance). '''IN PROGRESS'''
*: Total Zone memory manager rewrite (more speed improvements). '''FINISHED'''
*: Textures will support normal, bump, and specular maps. '''IN PROGRESS'''
*: Heavily revamped Dynamic Lighting and Shadowing code (true directional light and true dynamic shadows)
*: Sky subsystem rewritten from Quake 3 for Q3 BSPs, normal sky code will remain for DOOM maps.
*: [http://opl3.cozendey.com/ OPL integration] for music; replaces fudged SYSTEM music player under Windows. '''FINISHED'''
*: SPLINE library replaces all camera code and new script files for them will be added.
*: Environment maps for surfaces (like Half-Life)
*: True Slopes using vertex height calculation
*: Polyobject support.
*: Inventory System
*: Better RTS functions (some adapted from FraggleScript)
*: FraggleScript support (limited*)
*: ROQ library for cinematics, and render-to-texture (skins, textures) '''IN PROGRESS'''
*: Quake 3 BSP Support (loading, rendering)

Doom Definition File

2016-04-20T08:06:29Z

UsernameAK: Undo revision 400 by UsernameAK (talk)

'''DDF''' stands for '''Doom Definition File''', and is EDGE's answer to [[DehackEd]].
However, DDF is much easier to learn than DehackEd, and allows you to
do a number of unique things were simply not possible with DehackEd.

Indeed, DDF has more in common with the .CON files that enabled
users to modify the gameplay of Duke Nukem 3D. Unlike DehackEd, which
could be complex and not particularly intuitive, DDF uses fairly
simple, easily understood commands.

=Getting Started=
To get started, use the SIDEBAR to the left of this Wiki (click on DDF to expand each DDF entry).

=How DDF works=

A DDF file is a simple text file that describes an object.

''Comments: Anything after // are comments. They are
ignored by the parser.
<BR>eg // This is ignored.''

'''Spaces are ignored.''' So this means that calling your monster [EVIL
MONSTER] is exactly the same as calling it [EVILMONSTER] since the DDF
parser will ignore the space. ''The underscore '_' character is
converted to a space.'' So you'd use EVIL_MONSTER if you wanted the DDF
parser to recognise a monster called EVIL MONSTER.

Upper and lower case is ignored (so writing SHOTGUN is the same as
writing shotgun).

Anything between quotes '"' is parsed as is eg "MAP01: Containment
area". This means that spaces and upper and lower case characters will
be recognized. This is especially important for names of lumps or
textures, since any '_' characters would normally be converted to
spaces and 3DGE would complain about a missing lump/texture.

The main structure to define an object is<BR>
<BLOCKQUOTE><CODE>
[name]<BR>
param1=data1;<BR>
param2=data2;<BR>
</CODE></BLOCKQUOTE>

The name of the object is the name used to refer to it. Names should
be unique, since when there are two entries with the same the later
one will override the earlier one.
In some DDF files the names are ignored.
Param1 and data1 etc are dependent on what type of object you are
trying to define. Put a semicolon after each
define.
<BLOCKQUOTE><CODE>
param=data1,data2,data3;

''is the same as''

param=data1;
param=data2;
param=data3;
</CODE></BLOCKQUOTE>

=Datatypes=

<LI>'''Boolean''': can be 'true' or 'false'.</LI>
<LI>'''Integer''': any whole number.</LI>
<LI>'''Float''': any floating-point number, eg 123.45 or -0.017.</LI>
<LI>'''Time:''' a timing value in seconds. Can also be specified in tics,
there are 35 tics in a second.
To specify tics, put a 'T' after the number, eg 35T.
The special value 'MAXT' means an infinite delay. </LI>
<LI>'''Percentage''': an integer value following by %. Range is 0% to 100%.</LI>
<LI>'''Music''': an integer value that will be looked up in PLAYLIST.DDF</LI>
<LI>'''Sound''': a name that will be looked up in SOUNDS.DDF.
The wild card character '?' is handled specially, so 'PODTH?' will
match the PODTH1, PODTH2, and PODTH3 entries. When it is time to play
an SFX with a wild card, a matching SFX will be played at random.</LI>
<LI>'''String''': a string of characters eg "MAP01: Containment area"</LI>
<LI>LumpName: an eight letter string, referring to something stored in
the wad datafile.</LI>
<LI>'''Special''': a special format only used by that DDF file.</LI>
<LI>'''Flags''': a whole series of properties you can add.</LI>
<LI>'''States''': a series of sprites, eg the sequence of sprites to display
when something dies.</LI>
<LI>'''Language Ref''': a string that should be looked up in the language
DDF file to get the translation.</LI>

[[Category:DDF]]

Doom Definition File

2016-04-20T08:05:36Z

UsernameAK:

'''DDF''' stands for '''Doom Definition File''', and is EDGE's answer to [[DehackEd]].
However, DDF is much easier to learn than DehackEd, and allows you to
do a number of unique things were simply not possible with DehackEd.

Indeed, DDF has more in common with the .CON files that enabled
users to modify the gameplay of Duke Nukem 3D. Unlike DehackEd, which
could be complex and not particularly intuitive, DDF uses fairly
simple, easily understood commands.

=Getting Started=
To get started, use the SIDEBAR to the left of this Wiki (click on DDF to expand each DDF entry).

=How DDF works=

A DDF file is a simple text file that describes an object.

''Comments: Anything after // are comments. They are
ignored by the parser.
<BR>eg // This is ignored.''

'''Spaces are ignored.''' So this means that calling your monster `[EVIL
MONSTER]` is exactly the same as calling it `[EVILMONSTER]` since the DDF
parser will ignore the space. ''The underscore '_' character is
converted to a space.'' So you'd use EVIL_MONSTER if you wanted the DDF
parser to recognise a monster called EVIL MONSTER.

Upper and lower case is ignored (so writing SHOTGUN is the same as
writing shotgun).

Anything between quotes '"' is parsed as is eg "MAP01: Containment
area". This means that spaces and upper and lower case characters will
be recognized. This is especially important for names of lumps or
textures, since any '_' characters would normally be converted to
spaces and 3DGE would complain about a missing lump/texture.

The main structure to define an object is<BR>
<BLOCKQUOTE><CODE>
[name]<BR>
param1=data1;<BR>
param2=data2;<BR>
</CODE></BLOCKQUOTE>

The name of the object is the name used to refer to it. Names should
be unique, since when there are two entries with the same the later
one will override the earlier one.
In some DDF files the names are ignored.
Param1 and data1 etc are dependent on what type of object you are
trying to define. Put a semicolon after each
define.
<BLOCKQUOTE><CODE>
param=data1,data2,data3;

''is the same as''

param=data1;
param=data2;
param=data3;
</CODE></BLOCKQUOTE>

=Datatypes=

<LI>'''Boolean''': can be 'true' or 'false'.</LI>
<LI>'''Integer''': any whole number.</LI>
<LI>'''Float''': any floating-point number, eg 123.45 or -0.017.</LI>
<LI>'''Time:''' a timing value in seconds. Can also be specified in tics,
there are 35 tics in a second.
To specify tics, put a 'T' after the number, eg 35T.
The special value 'MAXT' means an infinite delay. </LI>
<LI>'''Percentage''': an integer value following by %. Range is 0% to 100%.</LI>
<LI>'''Music''': an integer value that will be looked up in PLAYLIST.DDF</LI>
<LI>'''Sound''': a name that will be looked up in SOUNDS.DDF.
The wild card character '?' is handled specially, so 'PODTH?' will
match the PODTH1, PODTH2, and PODTH3 entries. When it is time to play
an SFX with a wild card, a matching SFX will be played at random.</LI>
<LI>'''String''': a string of characters eg "MAP01: Containment area"</LI>
<LI>LumpName: an eight letter string, referring to something stored in
the wad datafile.</LI>
<LI>'''Special''': a special format only used by that DDF file.</LI>
<LI>'''Flags''': a whole series of properties you can add.</LI>
<LI>'''States''': a series of sprites, eg the sequence of sprites to display
when something dies.</LI>
<LI>'''Language Ref''': a string that should be looked up in the language
DDF file to get the translation.</LI>

[[Category:DDF]]

IWAD

2016-04-18T09:25:01Z

UsernameAK:

{{DoomWiki}}An IWAD - short for Internal WAD - is the main resource file for a Doom-engine game, containing all the game's original sounds, levels, and graphics.

=REQUIRED=
'''3DGE needs an IWAD file in order to play; without one the 3DGE engine has no game data to use.'''

3DGE needs an IWAD from either [[DOOM 1]], [[DOOM II]], [[FINAL DOOM]], [[HACX]], [[CHEX QUEST]], or [[HERETIC]] to function. 3DGE also works with [[FreeDoom]] (Freedoom1.wad and Freedoom2.wad).

Alternatively, you can set your own IWAD with the -IWAD switch.

==NOT SUPPORTED==
3DGE does not yet support the HEXEN IWAD, though it can read some graphics and level data from the game. It also does not support STRIFE.