How to guess the game engine a WAD was made for?

[leto]

Hello DoomWorld!

 

I am currently working on improving https://github.com/jmickle66666666/wad-js to let you guys view and edit WADs in your browser (crazy idea, right? thank JavaScript for that!).

 

I've been very successful with my experiments so far, but as I am trying to figure out the best way to parse ceiling/floor lumps (because they're not always 64x64 pixels, unfortunately), I came across a question where your insight would be greatly appreciated.

 

Here is my problem: What do you think is the best way to guess the game engine a WAD was made for? In other words: How do I know if this WAD was created for vanilla Doom, Doom II, Heretic, Hexen, or a specific port?

 

It does not look like this information is explicitly stored in WADs, so how would you go about this? Look for specific lumps? If so, then, which ones should I target? Is there a way to be 100% sure? Or should I simply ask the user when they upload their file to wadJS?

 

Let me know!

[The Nate]

Shouldn't it say so in the text file WADs usually come with?

[leto]

Not a bad idea. However, I am trying to programmatically guess the engine. In other words: I have a script that reads the WAD file and parses it in order to display the resources within the file. If I could find the information about the intended game engine without having to parse the text file, I think that it would be simpler. Also, if no text file is provided, then it won't work at all.

[SaladBadger]

You can detect hexen format specifically by looking for the BEHAVIOR lump, all hexen/zdoom in hexen format maps must have it even if they don't have any scripts (in that case the lump is empty). Beyond that, there's not much you can do. Some heuristics on the editor numbers and line specials in the maps maybe?

 

In practice, every editor produced that supports multiple games has required the user to fill in information about what game it's for, since guessing is too much effort and won't always work, especially when you consider EE or ZDoom maps that can have any number of new objects with editor numbers that might conflict with these other games (in EE's case, this is less of a problem since they define a "safe" range of user-supported editor numbers)

[leto]

@SaladBadger That's what I thought. I wanted to avoid asking for user input but it seems too risky to guess from the WAD data itself. Thank you for your help!

Maybe I can push my luck and ask a follow up question related to my original post:

Flat lumps contain only an array of bytes where each byte is the index of a color within the WAD palettes. There's no indication of the height or width of the flat. It's probably okay 99% of the time, since it's going to be 64x64 (which is 4096 bytes). However, if the flat is 4160 bytes (Heretic scrolling flats), or 8192 bytes (some Hexen flats), for example, can I safely assume that they're meant to be rendered as 65x64 and 64x128 images, or could there be pitfalls I am not aware of?

[WadArchive]

Guessing which WAD or engine isn't the simplest thing to do. I currently use a modified version of https://github.com/BlackRookSoftware/Doom to help with this but I am in the process of writing something else to do the guessing.

 

As others have mention you can look at things like engine specific lumps to try and rule out engines/games it won't work on. eg:

 

BEHAVIOR lump will likely mean Hexen

SCP_DEFN lump for Risen3D

TEXTMAP lump would mean that it isn't vanilla compatible. You can look at the namespace of the TEXTMAP lump to find out the IWAD needed

 

If ZMAPINFO or EMAPINFO exist then you know it should work on ZDoom and Eternity (but may not rule out other engines)

 

PK3 rules out all the vanilla engines. If it is a PK3 you can look at the folder structure. Doomsday has a different structure compared to other ports that support PK3.

 

If you like you can also look further into the lumps themselves, like thing numbers or does a map use textures only found in a specific game?

[Kappes Buur]

3 hours ago, Gerkhin said:

@SaladBadger That's what I thought. I wanted to avoid asking for user input but it seems too risky to guess from the WAD data itself. Thank you for your help!

Maybe I can push my luck and ask a follow up question related to my original post:

Flat lumps contain only an array of bytes where each byte is the index of a color within the WAD palettes. There's no indication of the height or width of the flat. It's probably okay 99% of the time, since it's going to be 64x64 (which is 4096 bytes). However, if the flat is 4160 bytes (Heretic scrolling flats), or 8192 bytes (some Hexen flats), for example, can I safely assume that they're meant to be rendered as 65x64 and 64x128 images, or could there be pitfalls I am not aware of?

 

Using a simple map as test,

A 64x128 image

 

1. the image between F_ markers

2. the image between TX_ markers

 

reveals that in either case the floor will be drawn with the 64x128 image

and not resized to 64x64

 

for GZDoom UDMF in either DOOM2 or Heretic

 

[leto]

3 hours ago, WadArchive said:

BEHAVIOR lump will likely mean Hexen

SCP_DEFN lump for Risen3D

TEXTMAP lump would mean that it isn't vanilla compatible. You can look at the namespace of the TEXTMAP lump to find out the IWAD needed

 

If ZMAPINFO or EMAPINFO exist then you know it should work on ZDoom and Eternity (but may not rule out other engines)

 

PK3 rules out all the vanilla engines. If it is a PK3 you can look at the folder structure. Doomsday has a different structure compared to other ports that support PK3.

 

@WadArchive Thank you for the information. It's super helpful! Did you know all of this off the top of your head? I think that, from a user interface standpoint, the user will have the final word on what the target engine of a WAD is. However, the interface will provide hints as to what it "thinks" the target engine is, based on the lumps within the WAD.

 

@Kappes Buur I'm glad you confirmed that GZDoom will display the flat correctly. However, what I'm concerned about is how ports, game engines, and even map editors parse these flats. The flat lumps are simple arrays of bytes without any concept of width of height in them. So, if there are 8192 bytes, how come that it shows as 64x128 and not 128x64 or 32x256? Are game engines able to handle any weird size like 35x49? Having your insight on this would be great!

[Dark Pulse]

Some Doomed standard numbers may help you narrow things down as well.

 

Perhaps based on those (and some other rules) you can narrow things down.

 

Strife (on the damn rare chance you come across a custom level for Strife) will have its conversations stored in SCRIPTxy lumps - one corresponding to each map slot, as well as SCRIPT00 for a global.

 

Note that it's not a guarantee to be there, but it'd be pretty silly to have a Strife map with no conversations...

[WadArchive]

On 3/15/2019 at 5:48 PM, Gerkhin said:

 

@WadArchive Thank you for the information. It's super helpful! Did you know all of this off the top of your head? I think that, from a user interface standpoint, the user will have the final word on what the target engine of a WAD is. However, the interface will provide hints as to what it "thinks" the target engine is, based on the lumps within the WAD.

 

Not all off the top of my head. I just start to notice it as I am reading up on the different lumps/formats etc.. or when I come across a lump I am not sure about I look on the various wikis to see what it is

[kb1]

It's not easy. For map lumps, you can divide the size of the THINGS and the LINEDEFS by the size of 1 THING/LINEDEF for Doom/Heretic, and if there's a remainder, try the same process for Hexen. Also, the presence of the BEHAVIOR lump is a good indicator.

 

You can go even further, and check for Boom/MBF/Eternity/DoomLegacy/ZDoom linedef special types/sector types, thingdef types, etc.

 

Non-standard Flats can be tricky. However, you can check the first few bytes: If it's a texture patch, the first few bytes contain the dimensions. You can check for crazy/invalid dimensions, and if so, it may be a flat. Also, most flats should be divisible by 4096. For special cases, you can have some hard-coded flat names known to have goofy dimensions (65x64).

 

Of course, marker lumps (P_START, etc.) can help weed out lump types, if they've been added properly.

 

For some lumps, you have to have a list of hard-coded lump names and properties, cause there's no way for software to properly identify the lump.

 

It's a messy ordeal. I've been working on a program: WADExplorer, for years, slowly adding ways to try to properly identify all the lumps in WADs. It works pretty well for most all WADs, but occasionally it mis-identifies lumps. That's why I allow the user to right-click on the lump, and change its properties.

 

I have been trying to work on a universal compatibility spec for WADs, but I've been overwhelmed with work. Anyway, part of that spec included having an indicator for the intended engine. It's something that's sorely needed. Without something like that, you have to dig through all of the above, and more, for map identification. It can be done, but it's a lot of work. Good luck!