Modding Birthright: Gorgon's Alliance Adventures

[kasrkraw]

Goblin Apocalypse at Bindier

https://imgur.com/ZmX3D1v

--------------------------------------------------------

So I noticed something peculiar when I extracted the 1.4 patch which gave me a great deal of excitement: the WADS folder.

https://imgur.com/CEpo6bq

If you thought the adventures in Birthright looked Doom-y, that's because they are! The two WAD files contained in the WADS folder are map files for Bindier and Lofton using the same data structure that mods use for the original doom games. This type of cross compatibility for the data files isn't unusual as plenty of older games were built off of the doom engine. The real question was if I can access the contents of the WADs.

As far as I know there hasn't been anything developed in the birthright community for editing the adventure maps, but Doom 1 and 2 have a whole suite of community generated tools for modding these days. In particular I wanted to see the structure of a WAD from Birthright.

Using SLADE I opened the WAD for Bindier.

https://imgur.com/MdOzDsI

Looking good so far, everything is in the same format as it would be for a doom WAD. See the "Map Marker" listed as "E1M1" there? E1M1 = Episode 1 Map 1 from Doom : P, but more importantly, we should be able to load up a map from Birthright in doom. All the necessary information is there, we'll just be missing assets.

Below is Lofton from Birthright loaded into Doom

https://imgur.com/3MfRD77

And below now is a level from a Doom WAD (Alien Vendetta) in Birthright

https://imgur.com/8Pm6Pmr

It's by luck that some of the ID's for things (objects that aren't the map geometry) in the Doom WAD corresponded to enemy ID's in Birthright and vice versa. Interestingly, a lot of them were for enemies I had never seen before, like "Dwarf Officer" or "Lord", so there are certainly some near finished but unused assets lying around.

Doom X Birthright shenanigans aside, what is going to be most relevant to the community here is that there are mapping tools available for Doom that can be used for Birthright. Using Doombuilder I copy and pasted the Goblin 'thing' to create the first image of this post. Here is what that scene looked like in Doombuilder.

https://imgur.com/E92j2fK

All those question marks are there because there isn't an asset reference file available. However, the ID's and facings of things can still be edited. Map geometry should be modifiable as well, but I haven't quite confirmed that.

So what maps are editable? Presumably all of them. What is likely happening is that the WAD's contained in the WADS folder are PWADs and override the core data files for the maps, so replacing another map would involve creating and inserting a WAD into the WADS folder with the same name as it. This is gist of what I did to insert a Doom WAD into birthright (renaming to BINDI_MW.wad and making sure the markers were set up correctly).

Without necessarily knowing what ID corresponds to what asset it seems entirely possible to manually increment through all possible ID's to determine what ID corresponds to what textures, what objects, etc. to allow creation of maps for Birthright: Gorgons Alliance. For the time being I'll keep exploring what the bounds of editing are in this manner, and maybe at some later date get back to the community with more technical information on this topic as well as use notes for the doom tools.

[Arjan]

nice work

can you also extract the character models? perhaps its fun to use them in the Birthright game i am currently making. they do need a bit of retexturing though

[AndrewTall]

Very impressive work, I had no idea of the Doom connection.

[Kami]

This is wonderful and makes me want to reinstall the game and do some modding! Thanks for sharing your findings.

[Sorontar]

Wow, good find. Thanks for telling us about this.

[kasrkraw]

I've taken some time to look into acquiring resources for use with the available tools from the doom community (notably SLADE and DOOMBUILDER) to make modification or maps/creation of new ones friendlier, and doing so seems to require cracking open the .RES files in the RESFILES folder.

Not being sure of what is necessarily in each .RES, I tried opening them and decompressing them with a variety of programs to no avail. I decided to take a looksie at the files using a hex editor. Mostly nonsense except that I spotted a filename and extension for an image (NAME.PCX) inside... repeatedly. Maybe we can get somewhere. The bytes inside around these file names don't seem to correspond to the .pcx file format which follows a predictable pattern with a 128 byte header (info on that here: http://bespin.org/~qz/pc-gpe/pcx.txt). NOTE - if you open one of the 'raw' .pcx files laying around on the .iso you can see the header format in action for yourself.

There must be some type of compression at play, but I have no idea what type. This is well outside of my realm of knowledge but undeterred I investigated the files some more to see what I could find. Within a given .RES file containing images, at the header of each .pcx file, immediately before the file name, are 4 bytes that repeat for each file depending on which .res you have open. In the TEXTURES.RES they are:

00 03 02 01

Screenshot for reference

This shall be dubbed the "Countdown sequence". Based on the fact that it isn't always null, 3, 2, 1 I don't think it's meant to be a countdown, I just happened to see the sequence in the textures file first. Maybe it has to do with how the game engine treats the files? In THINGPCX.RES it is also 00 03 02 01, but in MEDRTRES.RES the sequence is 00 00 02 02.

For each .pcx file, the string "RSRC" will also appear, starting 19 bytes prior to the Countdown Sequence. the RSRC may be preceded by null bytes. In the below example the leftmost two bytes are null, and the right four are RSRC:

00 00 52 53 52 43

Following the Filename there are usually three null bytes, though I have seen an occasional FF or 01. What occurs afterwards seems to have a pattern but it varies by .res file. In general, following the null bytes there seems to be about ~15 bytes of 'structured' bytes where the values frequently repeat for each .pcx. Following that there are no significant sets of matching bytes.

Based on the first file embedded in each .res, it seems that each file consistently starts with 12 bytes before the RSRC string, and contains a countdown sequence immediately prior to the filename. I can't make much useful info out from the 15 bytes between the RSRC string and the countdown sequence, but from looking at them across a few different files we get (2 sets per file):

FROM THINGPCX
3A 09 00 00 16 09 00 00 AC 09 00 00 F6 78 7E
38 0D 00 00 14 0D 00 00 06 0E 00 00 6E 63 7C

FROM TEXTURES
2E BA 00 00 0A BA 00 00 0A 00 01 00 79 B9 2B
FD C4 00 00 D9 C4 00 00 0A 00 01 00 E1 A2 29

FROM FONT
F3 54 00 00 CF 54 00 00 66 17 07 00 AE 9C 2A
A9 10 00 00 85 10 00 00 B4 66 00 00 2E 81 24

I see two sets of double null bytes occupying positions 3&4 and 7&8 in the set of 15. This seems to stay true for most of the files, but not all. In particular I saw that MAP.RES broke the trend. Curious to see if there are any patterns in the first 12 bytes of each file, here are another 3 sets of 2 sets:

FROM THINGPCX
00 04 00 00 9D F4 25 00 34 01 00 00
CE 2F 11 CC 00 00 25 28 00 00 00 00

FROM TEXTURES
B4 CC B6 CC CE B8 B6 B8 00 00 00 00
B3 CC B6 CC CE B8 B6 B8 00 00 00 00

FROM FONT
88 20 19 19 0F 18 00 00 00 00 00 00
00 00 87 34 13 44 01 28 00 00 00 00

From here, it looks like the last two bytes of this sequence might always be null? It does look there might be some sort of pattern within TEXTURES.RES at least.

This is about as deep as I want to delve into the .RES files though. I've beat my head against them for a while now but trying to glean the images from them seems to be beyond my capabilities. Maybe what I've found here can help someone else with more knowledge eventually extract the images and other files. For a direction, my wild guess is that the .pcx files embedded in the .RES files contain only critical header information and critical image data, along with whatever information is needed for the game engine to process them. Maybe it takes what is in the file and spits out .pcx files on the fly for use in the game or something.

I'm going to look into editing the scene files for each adventure next and see if it is possible to add new ones next.

[InVivoSomnium]

I know this thread is 3 years old, but I haven't seen anyone else working on this.

Some useful info I've found digging through the source files (available on archive.org), is that they used an application called RESUTIL.EXE (in the \Birthrt\RESUTIL folder) to compress and concatenate groups of files together. The process is described in the RESUTIL.H and RESUTIL.C files.

About the "RSRC" and "countdown sequence":

typedef struct sResourceHeader {
	ULONG	startcode;				// RSRC string for validity check
	ULONG	cbChunk;				// total size of this chunk
	ULONG	cbCompressedData;		// size of compressed data
	ULONG	cbUncompressedData;	// size of uncompressed data
	ULONG	hashValue;			// hash value of file name
	UBYTE	flags;				// [d4-03-97 JPC] new field
	UBYTE	compressionCode;		// 0 = none, 1 = RLE, 2 = LZSS
								// (note: RLE is not currently supported)
	UBYTE	fileExtension;			// index to file extension type
	char		szName[cMAX_RESNAME];	// 8.3 filename (no path)
} RESOURCE_HEADER;

I also found in another file (RESMANAG.C) a list of the .RES files and what is in them.

char *	gszBasicResFiles[] = {
	"UI.RES",					// everything from UI directory
	"TEXTURES.RES",			// wall and other textures for WADs
	"FONT.RES",				// Fonts
	"MAP.RES",				// The game map
	"LOWRES.RES",				// Ultra low res animations
	#if defined(_JUNEDEMO)
	"MEDSTRES.RES",			// Medium res stand frames.
	#else
	"MEDFTRES.RES",			// Medium res Fight animations
	"MEDRTRES.RES",			// Medium res (Rest of)animations
	"HIGHRES.RES",			// High res animations
	#endif
	"THINGPCX.RES",			// Thing PCX's
	"FINALE.RES",				// Finale PCX's
	""
};

Anyway, by using the RESUTIL.EXE application, there's a way to list the files it includes and a function to extract a single file. So for example: "resutil textures.res l" returns a list of 581 files (idk how to scroll back up in DosBox/DOS, so hopefully someone can supply a complete list from this for us). And by using the extract function, "resutil textures.res e ground01.pcx", a file named ground01.pcx gets spat out, but no image processing application can recognize it (GIMP, Photoshop, Paint.NET, etc.). And that's where I'm stuck. I don't know enough about the .PCX file format to check the hex code and verify the files, or what other method of processing is needed to get the files out in a readable format.

For anyone that wants to replicate my results, you'll need to move the .RES files and the DOS4GW.EXE from the Birthrt source code folder into the RESUTIL folder with the RESUTIL.EXE. Then you can use either a command shell or DosBox to navigate to the RESUTIL folder and run "resutil" to see the list of commands and syntax.

My guess is that the file that gets extracted is still compressed, and the .H file says they use LZSS (because RLE wasn't supported), but I have no idea how decompression is done.

[InVivoSomnium]

I know this thread is 3 years old, but I haven't seen anyone else working on this.

Some useful info I've found digging through the source files (available on archive.org), is that they used an application called RESUTIL.EXE (in the \Birthrt\RESUTIL folder) to compress and concatenate groups of files together. The process is described in the RESUTIL.H and RESUTIL.C files.

About the "RSRC" and "countdown sequence":

typedef struct sResourceHeader {
	ULONG	startcode;				// RSRC string for validity check
	ULONG	cbChunk;				// total size of this chunk
	ULONG	cbCompressedData;		// size of compressed data
	ULONG	cbUncompressedData;	// size of uncompressed data
	ULONG	hashValue;			// hash value of file name
	UBYTE	flags;				// [d4-03-97 JPC] new field
	UBYTE	compressionCode;		// 0 = none, 1 = RLE, 2 = LZSS
								// (note: RLE is not currently supported)
	UBYTE	fileExtension;			// index to file extension type
	char		szName[cMAX_RESNAME];	// 8.3 filename (no path)
} RESOURCE_HEADER;

I also found in another file (RESMANAG.C) a list of the .RES files and what is in them.

char *	gszBasicResFiles[] = {
	"UI.RES",					// everything from UI directory
	"TEXTURES.RES",			// wall and other textures for WADs
	"FONT.RES",				// Fonts
	"MAP.RES",				// The game map
	"LOWRES.RES",				// Ultra low res animations
	#if defined(_JUNEDEMO)
	"MEDSTRES.RES",			// Medium res stand frames.
	#else
	"MEDFTRES.RES",			// Medium res Fight animations
	"MEDRTRES.RES",			// Medium res (Rest of)animations
	"HIGHRES.RES",			// High res animations
	#endif
	"THINGPCX.RES",			// Thing PCX's
	"FINALE.RES",				// Finale PCX's
	""
};

Anyway, by using the RESUTIL.EXE application, there's a way to list the files it includes and a function to extract a single file. So for example: "resutil textures.res l" returns a list of 581 files (idk how to scroll back up in DosBox/DOS, so hopefully someone can supply a complete list from this for us). And by using the extract function, "resutil textures.res e ground01.pcx", a file named ground01.pcx gets spat out, but no image processing application can recognize it (GIMP, Photoshop, Paint.NET, etc.). And that's where I'm stuck. I don't know enough about the .PCX file format to check the hex code and verify the files, or what other method of processing is needed to get the files out in a readable format.

For anyone that wants to replicate my results, you'll need to move the .RES files and the DOS4GW.EXE from the Birthrt source code folder into the RESUTIL folder with the RESUTIL.EXE. Then you can use either a command shell or DosBox to navigate to the RESUTIL folder and run "resutil" to see the list of commands and syntax.

My guess is that the file that gets extracted is still compressed, and the .H file says they use LZSS (because RLE wasn't supported), but I have no idea how decompression is done.

[Kami]

Anyway, by using the RESUTIL.EXE application, there's a way to list the files it includes and a function to extract a single file. So for example: "resutil textures.res l" returns a list of 581 files (idk how to scroll back up in DosBox/DOS, so hopefully someone can supply a complete list from this for us). And by using the extract function, "resutil textures.res e ground01.pcx", a file named ground01.pcx gets spat out, but no image processing application can recognize it (GIMP, Photoshop, Paint.NET, etc.). And that's where I'm stuck. I don't know enough about the .PCX file format to check the hex code and verify the files, or what other method of processing is needed to get the files out in a readable format.

For anyone that wants to replicate my results, you'll need to move the .RES files and the DOS4GW.EXE from the Birthrt source code folder into the RESUTIL folder with the RESUTIL.EXE. Then you can use either a command shell or DosBox to navigate to the RESUTIL folder and run "resutil" to see the list of commands and syntax.

My guess is that the file that gets extracted is still compressed, and the .H file says they use LZSS (because RLE wasn't supported), but I have no idea how decompression is done.

I'm currently slowly working my way through rebuilding Birthright: The Gorgon's Alliance and saw your post while looking back at older discussions. I'm sad I didn't notice this earlier! I may detour and try to rebuild resutil first so we can at least maybe mod DOS/Win95 Birthright with new maps or textures.

[Kami]

I've just started work on a resutil.exe replacement for modern computers. Once it's more useful, I'll share it through the GitHub reporsitory. Currently, it only lists the files in a resource file with a bit of information about each one.

In case it's helpful, I've posted the output for all the .RES files from the CD and (hopefully helpful) context here: https://gist.github.com/Shiryou/68c4...27719c1cabf7fd

I'll post another update once the project is more functional and there's a download for people to use.


Regarding PCX files, I was able to open some of the files from the CD using GIMP, and Adobe claims that Photoshop or Illustrator should be able to handle them.

Here's one of the PCX files from the CD converted to PNG using GIMP:
KEEPPLAY.PNG

My next goal is to extract files, so I'll try opening the PCX files in there to see if I encounter the same issue.

Edit: I've managed to get extracting uncompressed files working, but the implementation of LZSS seems to be different from standard packages I'm finding. That covers about 125 files out of 9427 (1.3%). Sadly, my assembly language skills are a bit rusty, so it might take a while for me to figure out how to port the algorithm.