DEV DIARY THREE – MAP UPDATE & ISSUES WE’VE FACED
If you missed them, check out the previous two Dev Diaries for Eviternity: First dev diary / Second dev diary
In this, the third Dev Diary instalment, I wanted to cover some of the more technical side – ongoing issues, resolved issues, how parts of how the map were made, etc. To start off with though, let me introduce you to the two newest additions to the Eviternity map set:
MAP03: DRAIN
Following on from the ending of MAP02: Subterranean, we have Drain – a strange medieval fortification which houses a “secret” exit passage, accessible only by lowering the central walkway! This map provides a gentle nudge up in terms of difficulty, with a few mid tier enemies making an appearance. Drain was made mostly on-stream, in the space of only 3 days!
MAP06: RECONNECT
Reconnect’s objective is true to its name – you need to activate the eight technological panels throughout the tech base, reconnecting the power throughout and lighting up the map as you go! This map serves as a strong welcome to the second episode, with difficulty on par to the next two maps, and a play-time to rival their length too!
COMPLICATIONS AND TECHNICAL ISSUES
Let’s touch on the main issue that’s affecting OTEX, and subsequently, Eviternity – PrBoom+’s incorrect implementation of TEXTURE1 / TEXTURE2. Rather than type up ‘my version’ of it, let’s have an expert provide a comprehensive explanation. Take it away, Ukiro!
TEXTURE1 VS TEXTURE2
In the original Shareware DOOM, textures were defined in a list called TEXTURE1. Since this was just episode 1 with a smaller set of textures, the full game instead uses a lump called TEXTURE2. For DOOM II there was no shareware version so it only uses TEXTURE1 and practically all projects that supply custom textures in a WAD include a TEXTURE1 lump with definitions for all the DOOM II textures plus their own additions.
But the game engine still recognizes TEXTURE2 as a valid texture definition lump if it’s present. Furthermore, it seems all implementations of the engine can read both TEXTURE1 and TEXTURE2 at once. This should in theory make it possible to define all the OTEX textures in TEXTURE2, so that as a standalone resource WAD it’s compatible with all DOOM IWAD’s as well as other texture sets as long as they use TEXTURE1.
Unfortunately, this doesn’t work in PrBoomPlus. To explain why, we need to dive a bit deeper.
In DOOM, textures are made out of patches. For example, switches are usually a switch patch placed over a patch of the base material. In a DOOM WAD file, textures are thus not a bunch of images, but instead a list of references to patches and their placement. Unfortunately each item in this list points to patches via their order of appearance in a lump called PNAMES. So a texture actually has 3 components:
- The graphics data itself, a lump in DOOM’s picture format
- An entry in PNAMES referencing the graphics lump
- An entry in TEXTUREn referencing the index # of the graphics lump’s appearance in PNAMES
While the engine can load both TEXTURE1 and TEXTURE2, each of them will reference indexes in PNAMES. But it seems most engines, with the exception of the GZDoom family, merges all loaded PNAMES in memory. But then we have entries in both TEXTUREn lumps referencing the same PNAMES number expecting different things. The result in PrBoomPlus is that TEXTURE1 ends up getting patches from the PWAD, breaking all vanilla textures.
The right thing for the engine to do seems clear when reading the DoomWiki entry:
At startup time (to be precise, during “R_Init: Init DOOM refresh daemon”), the patches inside the WAD are read and combined into Wall Textures, or how the source code refers to, “map textures”.
If it’d just do this for TEXTURE1 and TEXTURE2 separately before merging the PNAMES lists, this should work, and it seems difficult to imagine a scenario where this would break some other expected behavior.
There is a potential solution for PrBoomPlus: By including references to all IWAD textures in TEXTURE2. But this still won’t make it compatible with additional resource WAD’s using TEXTURE1, and since the reasonable choice is to use DOOM II, it’d exclude Final DOOM IWAD’s from OTEX compatibility.
So until this is solved in PrBoomPlus and other engines, OTEX needs to be used as the only texture resource for your maps, or you can use GZDOOM.
Ola "Ukiro" Björling
Author of OTEX, Guest Mapper for Eviternity
A huge thanks to Ukiro for taking the time to explain the issue as clearly as they can! So as you can see this causes a bit of an issue when working on Eviternity, as it means the custom extra textures I compose for specific uses, such as the structure pictured adjacent to this paragraph, have to either be merged on a custom local copy of OTEX, or the map has to be tested in GZDoom, which is bad practice when making Boom format maps – you should always test in the intended source port first, after all!
Moving forward, in future dev diaries I’ll cover the new maps that are created, and I’ll be sure to go into detail about some of the other struggles I’ve overcome during the development of Eviternity, or perhaps any techniques I’m learning along the way!
If you want to see Eviternity being actively developed, be sure to tune into my Twitch livestreams, every Wednesday!
