What sourceport should one test their maps with?

[CheeseBaron]

Hello, im a new user so sorry if this is in the wrong place or if the question is dumb.

Ive been making a few semi-vanilla (as in, not using any of the fancy scripting n all that stuff GZDooM provides) maps but always testing them in GZDooM, which i heard isnt quite the best idea as it may potentiall lead to the map being broken with other sourceports. I havent found any proper info about this so im asking here.
What sourceport should one test their map with to ensure decent compatibility with most ports? Is chocolate doom too far or just right? Does it even matter that much?

(If curious, the only map i uploaded is "killfac.wad" on the idgames archive, tested with GZDooM but not requiring anything from it)

[DrowzyBomber13]

I've always used zdoom. I feel its general enough to work with just about everything but vanilla source ports. If you're shooting for a map that can run on older source ports, I'd suggest Boom.

[Pseudonaut]

I don't see any reason not to test a map in multiple ports. Chocolate Doom isn't strictly necessary if you're not aiming for vanilla compatibility, but limit-removing ports like Crispy Doom or DSDA-Doom (complevel 2) should be fine. 

[RataUnderground]

If you want vanilla compatibility - > Chocolate Doom
Limit Removing -> Crispy Doom
Boom compatibility -> DSDA or Woof
UDMF - > GzDoom

These are my fav sourceports for each case.

[leveste]

3 hours ago, CheeseBaron said:

always testing them in GZDooM, which i heard isnt quite the best idea as it may potentiall lead to the map being broken with other sourceports

This is true. Even when setting compatibility to "strict", Gzdoom still fixes bugs behind the scenes. The problem is that other popular ports like DSDA, Woof or Crispy-Doom emulate the original right down to the bugs. What happens is that you might make a mapping error that is unoticeable in Gzdoom, but an issue in the others(Tag 0 being one that really breaks the map).

 

As for which port, here's my recommendations:

Pure vanilla: Original exe in Dosbox or Chocolate Doom

Limit removing: Crispy Doom, Woof or DSDA-Doom; for Woof and DSDA, depending which IWAD you use, you'll have to use complevels 2, 3 and 4, which correspond to Doom 2, Ultimate Doom and Final Doom(Plutonia and TNT), respectively

Boom, Mbf, Mbf21: Woof or DSDA; complevels 9, 11 and 21 respectively

UDMF: Gzdoom

 

Alternatively, you can just stick to Gzdoom and make a note that the map wasn't tested in other ports, so there might be game-breaking stuff in other ports. Nothing wrong with that either, as long as you're clear about it.

[prfunky]

Quote

What sourceport should one test their maps with?

Answer:

ALL of them!

I pretty much look at Doom ports to Doom as internet browsers to web pages as

far as testing goes. It doesn't hurt to try your mod in any port you can get your

hands on. Even better; it allows you to familiarize yourself to more than one way

of doing Doom. You might find an engine whose capabilities you prefer to where

you were already.

 

I'm lucky enough to have started mapping when there wasn't too much out yet.

There were specific rules and limits to how one was able to map then. Many of

the source ports have loosened up these restrictions, which I'm grateful for, but

I still think in vanilla Doom because that's what I mapped for from the beginning.

Of course, with me, that's no longer true as I now primarily map for Zandronum.

Speaking of which, you should try to ascertain what your targeted audience will

be. In my case, I map for deathmatch-mode of play. Therefore, I should concentrate

on Zandronum, ZDaemon and Odamex since those are the ports which have good

client-server networking capabilities. But if your target audience is speedrunning,

you'd want to be gearing towards DSDA-Doom. Similarly, if your target audience

wants fabulous OpenGL rendered worlds, then you'd stick with the GzDoom.

 

There are still even more ports than all those mentioned. I would recommend you

make informed choices about what you want to do by reading this Wiki entry:

https://en.wikipedia.org/wiki/List_of_Doom_ports

 

Edited May 9, 2023 by prfunky
spelling/typo

[CheeseBaron]

Okie people, thanks for all the replies!

[BedrockCastle]

Well, what's the map format? If you're making a pure vanilla map, use Chocolate Doom. Limit-removing maps are best tested in Crispy Doom, or a similar limit-removing port. I always use DSDA-Doom for Boom-compatible maps, but PrBoom+ is a fine choice as well.

 

Generally, though, you should test in multiple ports whenever possible.

[DRON12261]

[A really important topic, so I decided to write a mini memo here. I'm not an English speaker and might have made some mistakes, so don't kick me too much)]

When testing your map, you should first of all look at the map format, game mode of map, and certain standards & features that you use in your wad.
 

Of course, if you made a map for Boom and say that it was tested only on GZDoom - then you didn't do any testing of your map at all.
 

If we talk about the format of the map, there are several of the main ones:
1) Vanilla - directly the original format of the maps themselves Doom.
2) Limit-Removing - vanilla with greatly expanded limits (but still with the limits, and different ports may have different ceiling. Yes, these limits are hard to reach usually, but more than possible).
3) Boom - map standard, which appeared with the same name source-port, in fact is a significant expansion of the vanilla format.
4) MBF21 - like a Boom, but a more recent format and is also another "expanding" step.
5) Hexen - generally more used today for multiplayer maps for multiplayer ports.
6) UDMF - ZDoom, and different versions have their own different set of features, mapping for ZDoom 2.8.1, for Zandronum and for GZDoom can differ significantly.
7) Eternity (UDMF and BOOM) - special format exclusive to the Eternity Engine port, since it uses a huge number of unique features specific to this port.

To test on the ports themselves (in fact, we should test on all possible ports, so I will write only the ports for which this format is the ceiling and which will be especially critical for the presence of any bugs and errors):
1) Vanilla - necessarily on one of the following - the original on DOSBOX, Chocolate Doom or Chocorenderlimits. + ports below.
2) Limit-Removing - Crispy Doom, Rude doom (in fact limit-removing version of Chocolate Doom). + ports below.
3) Boom - necessarily PrBoom+ & Doom Retro & Woof! & DSDA, as well as their forks like Nugget Doom and From Doom with Love (although the expectation is that if it works on the base port, it should work on the fork as well). + ports below.
4) MBF21 - necessarily Doom Retro & Woof! & DSDA. The list of ports that support this format is smaller. For example the same Zandronum or ZDaemon are out of the list.
5) Hexen - ZDaemon & Odamex & Zandronum & Skulltag multiplayer ports.
6) UDMF - This is the ZDoom format, but we have several versions of it: ZDoom 2.8.1 (hence ZDoom LE, RZDoom, etc.), Skulltag, Zandronum & Q-Zandronum, LZDoom and GZDoom. The udmf limitation goes by which features you will be using, as some ports may have their own features for UDMF that won't work on other ZDoom ports.
7) Eternity (UDMF and BOOM) - well, here it's much easier, because the format is exclusive to Eternity Engine port.
 

Besides the map format itself, you have to look at the features that you use, like UMAPINFO, or DEHEXTRA and stuff like that. There's also a certain list of ports there that support all of that.
 

And yes, do not forget about compatibility level (-complevel) when testing maps, especially when you additionally test an older format on a more advanced port.
 

And in principle try to test on as many ports as possible your maps, then you really can guarantee to your players stability of your project.
 

Additionally I left a list of the ports I always have at hand for testing (but I strongly recommend to get acquainted with the whole list of possibilities of each port):
- DOSBOX (Vanilla, Original)
- Chocolate Doom (Vanilla)
- Chocorenderlimits (Vanilla)
- Crispy Doom (Limit-Removing)
- Rude Doom (Limit-Removing)
- PrBoom+ (Boom)
- Doom Retro (Boom, MBF21)
- DSDA (Boom, MBF21)
- Woof! (Boom, MBF21)
- Odamex (Boom, MBF21, Hexen)
- Skulltag (Boom, Hexen, old UDMF)
- ZDaemon (Boom, Hexen, old UDMF)
- ZDoom 2.8.1 (Boom, Hexen, old UDMF)
- RZDoom (Boom, Hexen, old UDMF)
- LZDoom (Boom, Hexen, UDMF)
- GZDoom (Boom, MBF21, Hexen, UDMF)
- Zandronum (Boom, Hexen, UDMF)
- Q-Zandronum (Boom, Hexen, UDMF)
- Eternity Engine (Boom, MBF21, custom UDMF)
 

Also it is worth to read about these standards (actually there are more, but these are the base ones):
- Different versions of MAPINFO (but today the most important are UMAPINFO, ZMAPINFO, EMAPINFO and Hexen MAPINFO)
- DeHacked
- DEHEXTRA
- Decorate
- ACS
- ZScript
- I should also add that all ports supporting either UMAPINFO, ZMAPINFO or EMAPINFO support music in .ogg or .mp3 format 99% of the time.

Edited June 8, 2023 by DRON12261

[RastaManGames]

@DRON12261 This is base.

[RataUnderground]

It is worthy of being pinned in the section!

[Ravendesk]

1 hour ago, DRON12261 said:

...

I don't necessarily see why one should test limit removing wads with Crispy. Dsda-doom and woof offer full demo-compatible support for limit-removing cl2 wads. Don't think you really should be worried about getting Crispy as long as you specify complevel correctly. It wouldn't hurt though, of course.

 

And I think you can safely replace "&" with "or" in most of the sections. Testing with several source ports is nice but most of the time not really needed.

 

Good post otherwise.

[Horus]

It’s better to test vanilla maps in chocorenderlimits, because it gives you proper guidance on where your maps fail vanilla limits.

 

I would advise always testing your maps in GZDoom because it is the most popular source port and therefore likely what a lot of the players of your map will use (unless your map is one of the few that don’t work on that source port).

 

DSDA-Doom is the second most popular source port and I would recommend using it to test maps that it works with (i.e. not UDMF).

 

Otherwise an additional source port would be warranted where you are targeting something specific, e.g. Eternity for Eternity UDMF, chocorenderlimits for Vanilla, Zandronum/ZDaemon/Odamex for multiplayer maps, etc. So I wouldn’t burden yourself by unnecessarily testing your map in loads of different source ports, more focus on the important ones to what it is you are trying to do.

 

 

[DRON12261]

1 hour ago, Ravendesk said:

I don't necessarily see why one should test limit removing wads with Crispy. Dsda-doom and woof offer full demo-compatible support for limit-removing cl2 wads. Don't think you really should be worried about getting Crispy as long as you specify complevel correctly. It wouldn't hurt though, of course.

 

And I think you can safely replace "&" with "or" in most of the sections. Testing with several source ports is nice but most of the time not really needed.

 

Good post otherwise.

 

All in all, it will be enough for a quick test. But all the ports are implemented differently, in the same DSDA may be conditionally involve some fixes that will not be in Crispy Doom and sometimes the behavior may be slightly different. On the same Rude Doom, very unexpected things can come up, for example with improperly assembled TEXTUREx.
 

As for replacing "&" with "or", I disagree. These ports are the most popular and most used today. And their behavior can also differ from each other, and even here sometimes to a large extent than limit-removing source-port and corresponding -complevel. This can start from some minor differences in technical implementation and end up with completely different custom features of these ports. So I insist that these ports "bundle" are always tested if you really want to say that your map can claim to be "polished". Maybe nothing will happen on very simple and boxed maps, but the larger and more technically complex the map is, the more pitfalls there can be. Especially if you use any "mapping hacks" and non-standard mapping tricks. And this also applies to different Node Builders, somewhere in one port can be "slime trails" in some places, in another port they can sometimes suddenly appear in other places. 
 

And I guess I forgot to add. You should also test your maps at -complevel higher than the original target value. This is often due to the fact that many will not pay attention to the request to play with a certain -complevel, and if you make sure that everything works at higher -complevel, then you yourself will be quieter, and the players less information in the README. Of course, except for those moments when your map will principally only work on one particular -complevel.

Edited May 10, 2023 by DRON12261

[Biodegradable]

On 5/9/2023 at 5:12 AM, CheeseBaron said:

What sourceport should one test their map with to ensure decent compatibility with most ports?

 

Cross-port compatibility testing is time-consuming, but it's certainly worth it as more people will play your WADs. Given the billions of Doom ports, you'll drive yourself batty testing for ALL of them, but here's a good list of the most popular ones people in the community play with most of the time from my observations:

• GZDoom
• PrBoom+
• DSDA-Doom
• Chocolate Doom
• Crispy Doom
• Doom Retro
• Woof
• Eternity Engine

You'll cover most of your bases if you can get your work to run in these particular ports in terms of general compatibility to the largest pool of regular Doomers.

Edited May 10, 2023 by Biodegradable

[Ravendesk]

11 minutes ago, DRON12261 said:

As for replacing "&" with "or", I disagree. These ports are the most popular and most used today. And their behavior can also differ from each other, and even here sometimes to a large extent than limit-removing source-port and corresponding -complevel. This can start from some minor differences in technical implementation and end up with completely different custom features of these ports.

Hm, I don't think that's correct. If these ports claim to be demo-compatible, then the map should behave exactly the same of all of them with correct complevel specified. Otherwise that would mean there is a bug in one of the source-ports.

 

I agree, however that there might be rendering differences, but as long as you test your map in software rendeder, you should be safe as it should behave the same way across sourceports.

[DRON12261]

3 minutes ago, Ravendesk said:

Hm, I don't think that's correct. If these ports claim to be demo-compatible, then the map should behave exactly the same of all of them with correct complevel specified. Otherwise that would mean there is a bug in one of the source-ports.

 

I agree, however that there might be rendering differences, but as long as you test your map in software rendeder, you should be safe as it should behave the same way across sourceports.

The demo compatibility is right on point. But I was just talking about the peculiarities of rendering, especially it concerns errors like slime trails. So it's better to test them on all such available ports. If you put a lot of investment in the visual component of the level, and then notice that it looks on someone else port is not how it should work in theory, agree, you will feel a little failure and frustration as an author) Plus the gameplay itself due to some additional features port can be different and sometimes not in the direction that you need. For example Doom Retro has a custom implementation of blood, and on the bloody scenery, it is also involved there. If let's say you put a huge number of such scenery in one place, it can cause some lag. Yes, this is on the port side, but you can affect this as a mapper and prevent all such roughness. Another good example is when Woof! treats animated floor textures as liquids, while you might have some kind of fan there. It would be weird to see a floating fan (I've had that happen))