ModdingWiki - Recent changes [en-gb]

DAT Format (Shadowcaster)

Diema — Thu, 06 Aug 2026 14:50:54 GMT

Initial draft

New page

== Overview ==
[[Shadowcaster]] contains two forms of DAT archive. This page is about the game's WAD-like game data archives. Another page details the [[Cutscene Format (Shadowcaster)|cutscene DAT format]].

A Shadowcaster game-data archive has the following general structure:
<syntaxhighlight lang="cpp">
uint16_t NumRecords; // the number of sub-files contained in this archive.
uint32_t Directory; // an offset from the start of this file to the beginning of the record list.

uint8_t DataRegion[...]; // raw sub-file data. there can be hidden sections here; a sub-file's start does not have to begin right after the end of the previous.

// within each sub-file record is the following format:
uint32_t Offset; // offset to the start of the data, from the beginning of the file.
uint32_t Size; // the sub-file's size in bytes.
uint16_t NameOfs; // a pointer from the beginning of the directory to a null-terminated string. this can be zero.
uint16_t Flags; // in the floppy version, this is always zero. in the CD version, a value of 1 indicates RLE compression.
</syntaxhighlight>

=== Record Names ===
In this format, sub-file records do not have to have a name.

The underlying logic of this is that the game will often request a specific named lump, then refer to unnamed records using an ID offset from that. For example, if the lump named "view" is lump #0, then the game can refer to "view+5" to refer to lump #5, and therefore, lump #5 does not have to store its name. In such a case, <code>NameOfs = 0</code>.

By convention, SLADE and MapCaster notate the names of these lumps as ID offsets from the last named entry found.

== Reading a DAT Archive ==
Adapted from MapCaster GML:
<syntaxhighlight lang="cpp">
NumRecords = buffer_read(buf, buffer_u16);
Directory = buffer_read(buf, buffer_u32);

buffer_seek(buf, buffer_seek_start, Directory);
for(z = 0; z < NumRecords; z++) {
Records[z] = ds_map_create();

r = Records[z];
r[? "Offset"] = buffer_read(buf, buffer_u32);
r[? "Size"] = buffer_read(buf, buffer_u32);
r[? "NameOffset"] = buffer_read(buf, buffer_u16);
r[? "Flags"] = buffer_read(buf, buffer_u16);

// name all lumps
if(r[? "NameOffset"] != 0) {
last_name = 0;
prev_ofs = buffer_tell(buf);

// seek to the name table
buffer_seek(buf, buffer_seek_start, Directory + r[? "NameOffset"]);

r[? "Name"] = ReadString(...); // read until 0x00 is encountered

// go back to where we were before in reading the directory
buffer_seek(buf, buffer_seek_start, prev_ofs);
}
else { // if the lump has no name, treat it as being
// named as an offset from the previous named lump
last_name++;
l = Records[z - last_name];
r[? "Name"] = l[? "Name"] + "+" + string(last_name);
}
}
</syntaxhighlight>

Shadowcaster

Diema — Thu, 06 Aug 2026 14:39:13 GMT

Update to also put DAT format spec in, acknowledge a difference between ravdata and cutscene DATs

← Older revision		Revision as of 14:39, 6 August 2026
(One intermediate revision by the same user not shown)
Line 32:		Line 32:
	\| Name = [https://www.doomworld.com/forum/topic/155625-mapcaster-level-editor-for-shadowcaster/ MapCaster]		\| Name = [https://www.doomworld.com/forum/topic/155625-mapcaster-level-editor-for-shadowcaster/ MapCaster]
	\| Platform = Windows		\| Platform = Windows
	\| grp = No		\| grp = Edit
	\| map = Edit		\| map = Edit
	\| gfx = No		\| gfx = No
Line 67:		Line 67:
	\| KnownFormat = Yes		\| KnownFormat = Yes
	\| Desc = Sound effects		\| Desc = Sound effects
			}}
			{{GameFile
			\| Name = ravdata.dat
			\| Format = [[DAT Format (Shadowcaster)]]
			\| KnownFormat = Yes
			\| Desc = Data archive
			}}
			{{GameFile
			\| Name = *.dat
			\| Format = [[Cutscene Format (Shadowcaster)]]
			\| KnownFormat = No
			\| Desc = Cutscenes
	}}		}}
	{{GameFile		{{GameFile

OJT Format (Shadowcaster)

Diema — Thu, 06 Aug 2026 14:27:18 GMT

Initial draft

New page

== Overview ==
[[Shadowcaster]] OJT files describe a list of static objects present in a given level. These files are a linear list of 57-byte records with no header.
<syntaxhighlight lang="cpp">
uint32_t Tag; // does not have to necessarily be unique.
uint32_t Ptr_Prev; // typically if there is a previous OJT record before this one, this is set to sizeof(ojt_record) (57).
uint32_t Ptr_Next; // same as above, but forwards in the file.
uint8_t Collision; // typically zero for a non-solid object, or 1 for a solid one.
uint8_t Gravity; // a bitfield describing the object's relationship to gravity.
// some known values: 0 = no gravity; 1 = hangs from ceiling; 3 = spawn on ceiling, subject to gravity.
char DisplayName[20]; // not used by the game. a string that usually contains the name of the sprite used. seems to be an editor leftover?
uint32_t Pic; // a literal lump number from RAVDATA.DAT. This is the graphic the object will use in the 3D view.
uint32_t Width; // the object's width (or "radius" if you prefer), represented in frac-units (0-63 within a tile).
uint32_t Height; // same as the above, but the object's height along Z+.
uint32_t Unknown;
uint8_t TileX;
uint8_t TileY; // the object's coarse tile X/Y coordinates (0-31 are valid).
uint8_t Sides; // the number of sides the sprite has. for example: 0 = one-sided sprite, 8 = eight-sided sprite (like Doom).
uint16_t SubTileX;
uint16_t SubTileY; // the object's sub-tile X/Y fractional values (0-63 are valid).
</syntaxhighlight>

== Reading an OJT file ==
Adapted from MapCaster GML:
<syntaxhighlight lang="cpp">
for(i = 0; i < NumOjtsInFile; i++) {
ojt.Tag = buffer_read(ojt_file, buffer_u32);
ojt.Ptr_Prev = buffer_read(ojt_file, buffer_u32);
ojt.Ptr_Next = buffer_read(ojt_file, buffer_u32);
ojt.Collision = buffer_read(ojt_file, buffer_u8);
ojt.Gravity = buffer_read(ojt_file, buffer_u8)
ojt.DisplayName = ReadString(20);
ojt.Pic = buffer_read(ojt_file, buffer_u32);
ojt.Width = buffer_read(ojt_file, buffer_u32);
ojt.Height = buffer_read(ojt_file, buffer_u32);
ojt.Unknown = buffer_read(ojt_file, buffer_u32);
ojt.x = buffer_read(ojt_file, buffer_u8) * TILESIZE; // TILESIZE = 64 in Shadowcaster
ojt.y = buffer_read(ojt_file, buffer_u8) * TILESIZE; // TILESIZE = 64 in Shadowcaster
ojt.Sides = buffer_read(ojt_file, buffer_u8);
ojt.x += buffer_read(ojt_file, buffer_u16);
ojt.y += buffer_read(ojt_file, buffer_u16);
}
</syntaxhighlight>

LIB Format (Shadowcaster)

Diema — Thu, 06 Aug 2026 13:23:17 GMT

Initial draft

New page

== Overview ==

[[Shadowcaster]] .lib archives can be considered the "ancestor" of the Doom WAD format. They are mostly similar, realistically only differing in how you are expected to find the sub-file directory.

At the high level, .lib archives consist of a data region, the directory region, and finally the number of records stored at the very end of the file.

=== Data Region ===

The data region is simply every file's contents, concatenated end-to-end. There can possibly be "hidden" sections; one file does not necessarily need to exactly start at the end of the previous, or itself end at the start of the next.

In the case of .lib files, mostly level data and music are stored; graphics are stored in [[DAT Format (Shadowcaster)|DAT files]].

=== Directory ===

The directory immediately precedes the record count, and consists of a number of 21-byte entries with the following format:
<syntaxhighlight lang="cpp">
uint32_t Size;
uint32_t Offset; // from beginning of file
char RecordName[13];
</syntaxhighlight>

=== Record Count ===

Determining how many records are stored in the directory is done by seeking to the end of the file and reading the final uint16_t found there.

== Reading a lib file ==

Adapted from MapCaster GML:
<syntaxhighlight lang="cpp">
// first, we get the number of records and construct a pointer to the start of the directory
buffer_seek(Lib, buffer_seek_start, filesize - 2);
NumRecords = buffer_read(Lib, buffer_u16);
// offset to the start of the directory:
Directory = filesize - 2 - (NumRecords * 21);

// seek to the start of the directory
buffer_seek(Lib, buffer_seek_start, Directory);

// Read all entries until the end
for(i = 0; i < NumRecords; i++) {
Records[i] = ds_map_create();
r = Records[i];
r[? "Size"] = buffer_read(Lib, buffer_u32);
r[? "Offset"] = buffer_read(Lib, buffer_u32);

// read the name string
r[? "Name"] = ReadString(13); // directory subfile names are always exactly 13 bytes and follow 8.3 DOS filename convention, and are null-terminated

}</syntaxhighlight>

SCR Format (Shadowcaster)

Diema — Sat, 25 Jul 2026 04:35:17 GMT

Show changes

ITM Format (Shadowcaster)

Diema — Sat, 25 Jul 2026 03:47:16 GMT

(The struct definition was originally copied from an ImHex pattern, I accidentally left two #includes at the top that aren't important)

← Older revision		Revision as of 03:47, 25 July 2026
Line 4:		Line 4:

	<syntaxhighlight lang="cpp">		<syntaxhighlight lang="cpp">
	~~#include <std/mem.pat>~~
	~~#include <std/io.pat>~~

	typedef struct {		typedef struct {
	int32_t tag;		int32_t tag;

SCR Format (Shadowcaster)

Diema — Sat, 25 Jul 2026 03:45:42 GMT

Added a note about terminator bytes

← Older revision		Revision as of 03:45, 25 July 2026
Line 23:		Line 23:
	For example, <code>0F80 01 0D000000</code> -- function call 15, one argument (0x0D). This plays song ID 13 immediately upon satisfying its preceding condition list.		For example, <code>0F80 01 0D000000</code> -- function call 15, one argument (0x0D). This plays song ID 13 immediately upon satisfying its preceding condition list.

	A function list is finished specifying calls when the game encounters a ~~0xFF~~ terminator byte outside of an argument list. If no more condition/function lists proceed after this terminator byte, the script file is finished.		A function list is finished specifying calls when the game encounters a terminator byte outside of an argument list. A terminator can be 0xFF for single-fire scripts that are "deleted" after they are run, or 0x00 in some cases for repeatable effects. If no more condition/function lists proceed after this terminator byte, the script file is finished.

ITM Format (Shadowcaster)

Diema — Sat, 25 Jul 2026 03:44:21 GMT

Initial draft

New page

ITM files are found within SHADOW.LIB and contains a list of 42-byte records, each describing one item in the level. An "item" is distinguished from an "[[OJT Format (Shadowcaster)|object]]" in that items can be picked up and placed in the inventory, and typically have some effect when the player interacts with them (or uses them on scripted static objects in the level).

The following structure describes any individual ITM record.

<syntaxhighlight lang="cpp">
#include <std/mem.pat>
#include <std/io.pat>

typedef struct {
int32_t tag;
int32_t unknown1;
int32_t unknown2;
int32_t tilex;
int32_t tiley;
int32_t unknown3;
int32_t itemtype;
int32_t stacksize;
int32_t charge;
int16_t tilesubx;
int16_t tilesuby;
int16_t unknown4;
} item_t;
</syntaxhighlight>

=== tag ===
An identifier that scripts can use to address this item. This identifier does not have to be unique.

If the item is referenced in a [[SCR Format (Shadowcaster)|script]], then all items with the referenced tag will be acted upon (such as deleting a group of items at once).

=== tilex, tiley ===
Defines the "integer" component of the item's coordinates, in terms of coarse tile coordinates (0-31). X+ is eastward, and Y+ is southward.

=== itemtype ===
The record ID within [[NFO Format (Shadowcaster)|itemtype.nfo]] that specifies most of this item's properties, such as what spell to cast when a wand is used and what graphics to display.

=== stacksize ===
The game technically supports "stacks" of items, but not very well.

You can use this field to specify if this itm contains multiple of the same (for example, a stack of 5 healing potions). In effect, this acts like a multiplier for the "charge" property.

=== charge ===
How much "mana" or "power" this item contains at spawn. This value is also treated as the maximum mana the item can hold when recharged in a mana pool.

Note however that all effects that an item can use appear to have a fixed amount of mana they require, so it is possible to create "illegal" items that can never store enough mana to execute their effect (you will see "ITEM OUT OF POWER" in the message bar in-game).

=== tilesubx, tilesuby ===
These form the "fractional" component of the item's spawn position. Valid values are 0-63, using the same coordinate system as coarse tilex/tiley. This means that storing 0 in these fields will spawn an item at the northwest most corner of its tile.

SCR Format (Shadowcaster)

Diema — Fri, 24 Jul 2026 04:13:56 GMT

Initial draft -- TODO: properly format known conditions and function call IDs; provide a complete, simple example script

New page

[[Shadowcaster]] level scripts (*.SCR) control many special effects and level-flow modifications at runtime. Such effects include changing the level environment values (which sky is drawn if any, colored lighting, fog, and darkness), teleporting the player either to a different level (or within the same one), deleting and spawning static objects or items, locking or unlocking doors, and granting metaforms or experience points. These scripts are based on the concept of conditional lists -- that is, in order for an action to take place, a (series of) condition(s) must be satisfied.

There is no header. Script code begins immediately at the start of the file. A single script block consists of a list of conditions followed immediately by a list of function calls, and finally, a terminator. A script may not begin with a function call; this is explicitly treated as invalid data by the game. Conditions always have the following form:

<code>int16_t condition_id;

uint8_t evaluation_type;

uint32_t value;</code>

There is a list of 100 hard-coded conditions the game executable recognizes, many of which are exclusively script-controlled and are not modified directly by the game. In most circumstances, <code>evaluation_type</code> is set to <code>0x83</code> to mean "equal to"; other values are not yet fully known. This is followed by an immediate value to compare against. Scripts contain no explicit flow control and rely entirely on these condition evaluations.

For example, <code>0000 83 05000000</code> will be satisfied if condition #0 is equal to 5.

A single script block may contain many such condition formulations. The function list is only executed if all such conditions are satisfied. The condition list is finished specifying conditions upon encountering a condition with its highest bit set (0x8000). These are function calls. The game contains a list of 41 hard-coded functions that level scripts may call by ID. A function call follows this format:

<code>int16_t function_id;

uint8_t numargs;

uint32_t args[...];</code>

For example, <code>0F80 01 0D000000</code> -- function call 15, one argument (0x0D). This plays song ID 13 immediately upon satisfying its preceding condition list.

A function list is finished specifying calls when the game encounters a 0xFF terminator byte outside of an argument list. If no more condition/function lists proceed after this terminator byte, the script file is finished.

File:Mod-Shadowcaster.png

Diema — Fri, 24 Jul 2026 03:46:17 GMT

Diema uploaded File:Mod-Shadowcaster.png

New page

MAP Format (Shadowcaster)

Diema — Fri, 24 Jul 2026 03:42:10 GMT

(to conform witih the trend set that formats like Rise of the Triad's RTL format is "2D tile-based", therefore, so must this be.)

← Older revision		Revision as of 03:42, 24 July 2026
Line 1:		Line 1:
	{{Map Infobox		{{Map Infobox
	\| Type = 3D tile-based		\| Type = 2D tile-based
	\| Layers = 9		\| Layers = 9
	\| Games =		\| Games =

Shadowcaster

Diema — Fri, 24 Jul 2026 03:39:42 GMT

← Older revision		Revision as of 03:39, 24 July 2026
Line 1:		Line 1:
	{{Stub}}		{{Stub}}
	{{Game Infobox		{{Game Infobox
	\| Levels = No		\| Levels = Edit
	\| Tiles = No		\| Tiles = No
	\| Sprites = No		\| Sprites = No

File:MAP Format (Shadowcaster).png

Diema — Fri, 24 Jul 2026 03:36:27 GMT

Diema uploaded File:MAP Format (Shadowcaster).png A custom Shadowcaster-format MAP built with MapCaster for demonstration purposes.

New page

== Summary ==
A custom Shadowcaster-format MAP built with MapCaster for demonstration purposes.

MAP Format (Shadowcaster)

Diema — Fri, 24 Jul 2026 03:35:26 GMT

Initial draft

New page

{{Map Infobox
| Type = 3D tile-based
| Layers = 9
| Games =
{{Game|Shadowcaster}}
}}

[[Shadowcaster]] contains several different file formats used for storing level data. MAP files contain the tile geometry. They are conceptually similar to [[Wolfenstein 3D]] levels, where like data is stored sequentially and different kinds of data are clearly separated into "layers". However, there is an expanded feature-set.

MAP files all follow the same format and are the same size:

<code>
uint16_t floorpic[32*32];

uint8_t floorheight[32*32];

uint16_t ceilingpic[32*32];

uint8_t ceilingheight[32*32];

uint16_t northwallpic[32*32];

uint8_t northwallheight[32*32];

uint16_t westwallpic[32*32];

uint8_t westwallheight[32*32];

uint8_t unused[32*32];
</code>

Any <code>*wallpic</code> element being set to zero will not be rendered and will not have collision. Floors and ceilings may also be set to zero, but result in rendering garbage. Height values are expressed as growing upwards relative to the player's perspective (so Z=64 is visibly closer to the floor than Z=128 in first person).

For floor/ceiling elements, the height value describes that of the northwestern-most vertex of that tile; the surrounding tiles (north, northwest, and west) will slope to meet that point. However, this feature is unfinished and results in a Doom-like texture bleeding effect that is usually undesirable.

For wall elements, textures "grow upwards" in the Z+ direction, and the height value in the MAP determines the starting/bottom Z of the texture. Walls will render upwards until either there is no more texture to draw (the texture does not tile), or a ceiling is encountered. The inverse is also true if the texture's start height is set below the floor.

The game uses a 1D occlusion array to determine wall visibility and clipping, so if there is a gap above or below the wall because of the way its height value is set, no geometry will be rendered behind it (you cannot see into other parts of the level through such a gap). If the level's environment is set to permit a sky, then sky will be drawn; otherwise, it will be filled with black.

Shadowcaster

Diema — Fri, 24 Jul 2026 03:24:09 GMT

@@ Line 25: / Line 25: @@
 | mus = Edit
 | sfx = Edit
 | txt = No
 | sav = No
@@ Line 43: / Line 67: @@
   | KnownFormat = Yes
   | Desc = Sound effects
 }}
 {{EndGameFileList}}

User:Diema

Malvineous — Fri, 24 Jul 2026 01:07:04 GMT

Creating user page for new user.

New page

I'm an oldschool Doom level author, and the proprietor of the Windowcaster project (a port of Shadowcaster to modern OSes). As such, my primary focus is on the Shadowcaster modding page.

I've previously written MapCaster, a partially-capable level editor for that same game.

User:Diema

Malvineous — Fri, 24 Jul 2026 01:07:00 GMT

User account Diema was created by Malvineous and password was sent by email

Raptor

Alexbeav — Wed, 15 Jul 2026 20:06:56 GMT

Adding info about GLB files

Show changes

User:Alexbeav

Malvineous — Wed, 15 Jul 2026 01:21:08 GMT

Creating user page for new user.

New page

I'm a hobbyist game developer and longtime fan of early-'90s DOS shooters, currently studying Raptor: Call of the Shadows by reverse-engineering its data files. Working from the game's released DOS source and the open-source engine port, I documented and byte-for-byte validated Raptor's level format, including the enemy-placement (actor) fields that the current Raptor Level Format page still lists as needing investigation, along with the sprite library, the tile-property (FLATS) records, and how it all sits inside the GLB archives. I'd like to contribute this to complete the Raptor Level
Format page, and I'm happy to help keep the Raptor pages up to date. As part of the same work I also built a free browser-based Raptor level editor.

User:Alexbeav

Malvineous — Wed, 15 Jul 2026 01:21:05 GMT

User account Alexbeav was created by Malvineous and password was sent by email