is there a most compatible format to build in

[EClydeDeebo]

boom
doom
zdoom
gzdoom

all in doom 2

or has it gotten too specific?

Thanks

[GreyGhost]

That should be "doom", it's the base format that all others are derived from.

[EClydeDeebo]

I figured but....I never know.

Thanks !

Is there a page or post that you know off that addresses the differences?

[Chezza]

I was hoping to find you something that summarizes the difference in each format for you but no luck. But I can tell you this:

If you map with vanilla Doom, like Doom in Doom format then you should have a map that practically everyone can play with no issues whatsoever. The downside of it is the limitations of some more advanced features. No scripting, no 3D floors, no slopes and a variety of additional features like rotating polygons (someone correct me if I'm wrong).

However if you want more features and fancy scripts then mapping in UDMF format is ideal. It is the better choice than mapping in Hexen format if you want all the extras, unless you have particular reasons not to. The downside of using advanced features is how many popular sourceports won't support the format. Someone using vanilla doom or Boom etc can't use a UDMF map (again, correct me if I'm wrong).

UDMF maps can be played by ZDoom, GZDoom and Zandronum (Zandronum is popular for multuplayer as well) and probably a couple others. Meanwhile these sourceports should be able to run none UDMF maps as well.

Still, the safe bet is to map for Vanilla Doom.

[Gez]

EClydeDeebo said:

Is there a page or post that you know off that addresses the differences?

The differences are mostly in what fancy features you can add.

Plain old vanilla: you can add new textures and flats, and that's about all. Maps must be made in the Doom map format, there are limits on the number of sidedefs and other map elements you can use (the sidedef limit is normally the first to be reached), and the game will crash if you give it a scene too complex to render. (A simple way to cause a crash is to make a checkerboard pattern with sectors.)

Vanilla + dehacked: you can now also change the game behavior a bit, which can allow notably to sacrifice some existing objects to create new ones, replacing sprites is made easier.

Boom: You can have new animated textures and switches. Maps must still be made in the Doom map format, but you get a large number of new line and sector effects, and most limits have been removed or at least pushed back. New renderer effects allow you to change the color of ambient lighting in areas, to make some linedefs translucent (great for things such as windows and waterfalls), and if you're clever enough you can get a primitive sort of scripting through the use of conveyor belts: placing extra player starts on them will create a "voodoo doll" which can trigger line effects as it is moved by the belt.

ZDoom: Pretty much everything in the game can be redefined with no limit, or an entirely new game can be created. Maps can be made in Doom, Hexen, or UDMF/textmap formats. Real scripting is available through ACS, among others. Additional map editing features include notably polyobjects, 3D floors, portals, skyboxes, slopes and more.

GZDoom: like ZDoom, but with even more fancy effects available.



Each time you get more features, however, you lose on compatibility. Vanilla Doom is the baseline, you don't get much features but everyone will be able to play it with their engine of choice, whatever it is. Boom is still compatible with most ports, but some don't handle Boom effects. When you get to ZDoom, you'll have many people who just won't be interested because they don't want to use ZDoom.

[EClydeDeebo]

Thanks for the extensive and valuable replies.

I have not created a map since DOS when I used DCK. A worthy editor in it's day. Using GZDoombuilder (a great editor) I had been editing in Boom Doom format(simply because it was the first choice and I was ignorant). I noticed that if running my map in Risen3D everything worked as I had expected...things that weren't making sense I attributed to my skill level. On occasion I used DENG to test and noticed some switches were not working. Boom Doom has advanced switch options I used so that was the problem which I only discovered tonight. I switched to Doom Doom format and checked my switches. I noticed there were no advanced options so for now I am sticking to Doom Doom.

Lighting is another issue. In vanilla Doom, Z or GZDoom and Chocolate Doom my maps are very dark while in Risen3D or DENG lighting is as I want.

I am of the opinion....I played Doom the old way in the old days...I really like both Risen3D and DENG (though DENG is it's own pain in the ass in some respects).

I don't understand why my lighting is so dark in some ports while in others it is fine. Any thoughts beyond what has been outlined previously?

[GreyGhost]

EClydeDeebo said:

On occasion I used DENG to test and noticed some switches were not working. Boom Doom has advanced switch options I used so that was the problem which I only discovered tonight.

Doomsday Engine only partially supports Boom extensions, and offhand I couldn't say what's missing.

Lighting is another issue. In vanilla Doom, Z or GZDoom and Chocolate Doom my maps are very dark while in Risen3D or DENG lighting is as I want.

Sounds like you prefer hardware (OpenGL) rendering, GZDoom supports that but defaults to its "Dark" sector light mode. That particular setting is tucked away in Display Options/OpenGL Options/Preferences if you want to try the other lighting presets, I mainly use "Doom" mode.

There's a few source port comparison charts on this Wiki page which might be of interest to you.

[Gez]

EClydeDeebo said:

I don't understand why my lighting is so dark in some ports while in others it is fine. Any thoughts beyond what has been outlined previously?

Lighting in Doom is non-linear, anything below 96 will be very dark. A good example of that is that there are some actions that turn the light off in sectors (The Focus is a good example, with its corridor behind the blue door where you have a switch on one hand to turn the light on, and another on the other end to turn the light off) and before Doom's source code was released people just assumed the action was "set light level to 0", when in fact it actually is "set light level to 35". From observation in the game, there is no real difference between 0 and 35, both are just too dark to see anything.

This is because in Doom, light level depends on the COLORMAP table.



This is the COLORMAP. It has 32 light levels, then the invulnerability vision effect, then an unused row (because originally, the light amplification visor had their own colormap row too). Notice how the last few rows of light levels are basically all black or very dark gray.

Here's how it goes. Suppose the engine has to render a red pixel (index 176 on the palette), at a light level of 184. First, the 256 light levels are reduced to 32 possible values, because there are only 32 levels in the COLORMAP. 184/8=23. The darkest values are at the end, not the beginning, so flip it: 32-23=9, the color we'll want is on the ninth row of the color map. So, on column 176 of the ninth row, we find the value we want: 182. Our color was therefore changed from #FF0000 to #B30000, if you check the palette values.

When you write an OpenGL or DirectX renderer, this process is a bit complicated. It's simpler to use an algorithm that'll directly transform the color according to some formula instead of doing all these lookups; and in addition getting rid of the lookups allows you to have colors outside of the palette. But replicating the same effect is difficult. Furthermore, you run into issues of human perception vs. color value intensity: the Doom colormap was generated by linearly scaling the color channel values towards #000000, an approach that supposes that 127 is the perfect midpoint between 0 and 255, but this is not actually the case. See this post by Linguica if you're curious. Which means that the default formulas a coder might find in an OpenGL or DirectX tutorial for calculating light falloff are not what the Doom COLORMAP was generated with. It's why the "Standard" light mode in GZDoom is so different from software: it's an OpenGL standard formula, not the standard Doom formula.

Finally, you have to keep another thing into account, it's Doom's light diminishing. See, in Doom, the light level of something decreases as it moves away -- it's not realistic in the slightest (the Sun, after all, does not appear as a black hole just because we're so far away from it) but it's such a great part of Doom's atmosphere that it ends up just looking wrong if you remove the effect. This means that when you have a sector with light level 96, the actual light level in game will be lower than that -- only 80, or 64, or 48... -- unless the players moves close.

Which is why you should assume that any light level below 96 is going to be very, very dark, and even 128 will not seem half-bright but quite gloomy.

[EClydeDeebo]

More excellent information, Thanks.

I have found the GZDoom gl variables and I can now see my map. Doom mode works fine.

Great explanation on lights Gez...keep up the good work

[scifista42]

If you want to make your wad comfortable for players who don't use Risen3D and Doomsday Engine, you should do it the other way around, though - that is, test your wad in other (software-rendering) ports and manually accustomize light levels in your map to look OK in these ports.

[EClydeDeebo]

scifista42 said:

If you want to make your wad comfortable for players who don't use Risen3D and Doomsday Engine, you should do it the other way around, though - that is, test your wad in other (software-rendering) ports and manually accustomize light levels in your map to look OK in these ports.

Good Advice. Thank You