Why don't people just use UDMF format?

[leodoom85]

If people wants to start mapping in UDMF skipping the basic features of Doom format, so be it. Let them do it. In my case, I started doing my first release-able map in UDMF and I can also do maps in Doom/Boom format. 

[Graf Zahl]

1 hour ago, Myst.Haruko said:

I'm wondering if new boom format is still being in development, because strange silence rises some questions. 

 

The main issue with Boom is that PrBoom+ doesn't appear to show even the slightest sign of still being developed, aside from some minor fixes every now and then. I had been hoping that my UMAPINFO work would eventually be picked up, but sadly it didn't happen. I do not have the time to maintain it myself, unfortunately. Even GZDoom is too much right now in addition to a full time programming job.

 

[Koko Ricky]

I've been using Doom 2 format for years and would like to eventually create maps that have slopes, skyboxes, colored lighting and less restrictions on actions and texturing. The goal is to create visually immersive but also mechanically complex gameplay. What format would be best for this? I've experimented briefly with UDMF and it seemed to be exactly what I was looking for, but is there a better option?

[Nine Inch Heels]

6 hours ago, anotak said:

can you elaborate on the performance issues? there are some unfortunate (but not tremendous) increases in save / load time of UDMF maps with some software, notably the doombuilder family of editors, but it shouldn't affect anything ingame as far as I know? did i miss something.

I'm not referring to performance issues when using builders, I'm talking more about performance issues when playing. As has been pointed out by Xaser, UDMF-format maps have (G)ZDoom as their targeted source ports in virtually every case imaginable, and the ZDoom derivatives usually have a hard time dealing with quantities when it comes to both monster count and projectile count (projectiles also have hitboxes).

[Urthar]

Yeah, it was unfortunate to see the UMAPINFO/BOOM+ project peter out after all the initial enthusiasm.

 

I like UDMF, and the next project I work on will certainly use it. If it has a major drawback (other than being limited to those ports which support it,)  it's that it can get a bit fiddly and time consuming. It could perhaps benefit from additional abstraction in terms of editor support. For example,  you can manipulate a 3D Floor object quite initutively once it's been set up, but ideally it should be an entity in it's own right and the mapper shouldn't even have to think about dummy sectors, line actions and tag numbers.

 

 

Edited November 12, 2017 by Urthar

[scifista42]

@GoatLord

4 hours ago, Graf Zahl said:

Use Doom format if you want to target a broader range of ports, use UDMF for ZDoom to actually have access to all the features of the engine.

And since your vision involves features that aren't compatible with a broader range of ports...

[Graf Zahl]

23 minutes ago, Nine Inch Heels said:

I'm not referring to performance issues when using builders, I'm talking more about performance issues when playing. As has been pointed out by Xaser, UDMF-format maps have (G)ZDoom as their targeted source ports in virtually every case imaginable, and the ZDoom derivatives usually have a hard time dealing with quantities when it comes to both monster count and projectile count (projectiles also have hitboxes).

 

Under normal circumstances there are no performance issues. Even a huge map like ZDCMP2 can easily run at 60 fps for most of the time.

The only real problem case is Nuts-style maps with several thousands of monsters being active all at once but hands up who considers them reference material!

 

[Cruduxy Pegg]

I thought it was because people wanted to use demos in prboom but looks like it isn't the case.

[Nine Inch Heels]

17 minutes ago, Graf Zahl said:

but hands up who considers them reference material!

raises hand

 

In the context of this topic, I'd say that reference material actually matters (even if only for a select few people), because no format does large scale slaughter better than boom.

[Graf Zahl]

It's still not relevant because you need more than 'large scale slaughter' to get actual slowdowns.

The last time someone tested Sunder it still performed ok - a little below PrBoom+ but not that much.

 

No, Nuts is not reference material because there are no realistic maps where more than 10000 sprites need to be rendered.

 

[Juza]

Well, the reason I like Doom is because of its simplicity. For me, UDMF  is throwing all that simplicity in the trash bin and trying to make Doom just like any other modern FPS game, but with bad graphics... Like, it even allows the creation of cutscenes.

[Altazimuth]

I assure you, there were cutscenes before in Doom mods long before UDMF. ACS is what lets you do that. See: Void, Super Sonic Doom, Imp Encounter, etc.

 

EDIT: Forgot about SMMU, which let you do stuff like this via FraggleScript, and it didn't even have Hexen format.

 

[Benjogami]

39 minutes ago, Graf Zahl said:

No, Nuts is not reference material because there are no realistic maps where more than 10000 sprites need to be rendered.

 

I'm not quite sure what a "realistic" map is, but maybe this qualifies:

 

It's too bad that it doesn't perform well in GZDoom because the extra sight range for the cyberdemons makes things pretty spicy.

[Da Werecat]

I'm pretty sure you can do simplicity just fine with UDMF modern engines. No one is forcing you to add cutscenes. Advanced features can help in more subtle ways - by helping you shape the experience in any way you want without complicated hacks and compromises.

 

On a side note, I find nothing wrong with complex designs. Doom is a tool. Making more of the same is an option, not a requirement.

[Nine Inch Heels]

1 hour ago, Graf Zahl said:

The last time someone tested Sunder it still performed ok - a little below PrBoom+ but not that much.

 

No, Nuts is not reference material because there are no realistic maps where more than 10000 sprites need to be rendered.

What map in Sunder was the reference? Because there's a lot of different ones in it, and I seriously doubt GZDoom will perform just fine with all of the maps in that set. Besides, if there's framerate issues then it does not perfom "ok", because there's framerate issues that point towards performance, or rather a lack thereof.

 

You were the one who who brought nuts into this, not me. And it's not about the sprites that need to be rendered, it's about all the background checks that ZDoom derivatives do that don't happen in PrBoom+.

 

Also there are no "realistic" maps in doom anyway, that's the point of it.

 

29 minutes ago, AsianMammoth said:

Well, the reason I like Doom is because of its simplicity. For me, UDMF  is throwing all that simplicity in the trash bin and trying to make Doom just like any other modern FPS game, but with bad graphics... Like, it even allows the creation of cutscenes.

First you ask why people don't transition to UDMF because it does "amazing" stuff, now you say you don't like those fancy things because Doom is about simplicity. You make no sense at all.

 

Anyway, seems like you have your answer.

[Juza]

3 minutes ago, Nine Inch Heels said:

First you ask why people don't transition to UDMF because it does "amazing" stuff, now you say you don't like those fancy things because Doom is about simplicity. You make no sense at all.

 

Anyway, seems like you have your answer.

I'm just another one in the very small crowd of people that care about the old-school way of playing Doom, as it seems like everyone else wants to make Doom 'something it isn't' (not that it's a bad thing, I guess). That's just my view.

[snapshot]

I Like to think of Realistic maps as maps that don't have unnecessary amount of Monsters ( =/= nuts.wad ).

[Benjogami]

23 minutes ago, dmg_64 said:

I Like to think of Realistic maps as maps that don't have unnecessary amount of Monsters ( =/= nuts.wad ).

nuts.wad has the necessary amount of monsters for it to be nuts.wad. That will always be the case, and for every other map as well.

 

It could use more ammo though.

[Nine Inch Heels]

15 minutes ago, AsianMammoth said:

I'm just another one in the very small crowd of people that care about the old-school way of playing Doom, as it seems like everyone else wants to make Doom 'something it isn't' (not that it's a bad thing, I guess). That's just my view.

It still makes no sense. If what you want is "oldschool doom", you wouldn't "advocate" formats like UDMF, because that format is primarily (+90% of cases these days) used to make doom "something it wasn't" in the first place. That's why arguments made by certain people ("You can script, but you don't have to") miss the point entirely. There's no actual reason to employ a format that limits the choice of sourceports for supposed players, if none of said format's features are being used to begin with (because there's no benefit in limiting people's choices for no reason for the mapper or the player). Besides, most, if not all, of those who map in hexen or UDMF do so because they want it for the scripting, which directly undermines their arguments wrt to scripting not being "required" from my POV.

 

If you want oldschool, then either map in vanilla format or boom (which I consider "enhanced vanilla"), because that's as close as it gets.

[Graf Zahl]

57 minutes ago, Nine Inch Heels said:

What map in Sunder was the reference? Because there's a lot of different ones in it, and I seriously doubt GZDoom will perform just fine with all of the maps in that set. Besides, if there's framerate issues then it does not perfom "ok", because there's framerate issues that point towards performance, or rather a lack thereof.

You cannot expect to have a map with 5000 monsters run at 60fps constantly when the same map is massively detailed. For me it occasionally dipped down to 40 but not lower. Most of the issues with this mod were render-induced and not caused by the playsim, though.

The main reason why PrBoom+ runs faster here is that Entryway compiled it with the Intel C++ compiler (which costs lots of $$$) A self compiled version with MSVC was only marginally faster.

 

 

57 minutes ago, Nine Inch Heels said:

 

You were the one who who brought nuts into this, not me. And it's not about the sprites that need to be rendered, it's about all the background checks that ZDoom derivatives do that don't happen in PrBoom+.

 

Depends on the mod. Even with Nuts it's more the renderer than the playsim which costs performance. Rendering 10000 objects doesn't come for free, and this ultimately depends on the graphics driver and little else.

 

 

57 minutes ago, Nine Inch Heels said:

 

Also there are no "realistic" maps in doom anyway, that's the point of it.

 

Are we twisting words here? I did not mean realistic in terms of replicating the visuals of the real world but something that was made for realistic playing where you play to beat the map and get to the exit. Nuts is a proof of concept, but entirely unplayable without cheating.

 

 

 

[Killer5]

Correct me if there are innaccuracies in my post because I really want to start using eternity more if I can.

 

My reason for not using udmf is probably different than most:

- I once started using eternity for a bit (I actually really liked the eternity engine for a while). I noticed that there are behavioral differences in cyberdemon infight behavior. I was streaming stardate 20x7 map02 using eternity and noticed in the purple key fight the cyberdemon focused on me exclusively even though it was getting hit by all the other demons. I was told later that mbf format changes monster behavior (cybs in particular). So I no longer use it for this reason since I prefer the cyb behavior when I play using cl9 in prboom+. If there is a way that already exists to make eternity behave like prboom+ cl9 I'll probably switch to eternity tbh.

- The fps issues in gzdoom are a huge deal for me. Especially when there are some projects in the works that completely tank in zdoom based ports (these maps are nothing like nuts).

 

My stance on demo recording has changed since I started making maps. I like making things I enjoy playing rather than making things targeted for demo recording. If people make demos then it is a bonus.. but I can't be bothered either way. I'm weird in this aspect though that I still like recording demos for wads that are already designed for cl9.

 

I think there are a lot of really fun setups to be made with portals and 3d floors. I haven't really decided that I need those features yet however to make maps I find fun. But I think about them a lot. I have been playing around with taking boom bridges to extremes in order to get some interesting puzzles working which occur above parts of my maps but I would gladly supplement 3d floors in these instances instead of boom bridges in order to realize my designs (they would look much better imo and give me more creative freedoms).

 

So yeah. I guess my preference of the way monsters behave in prboom+ cl9 is preventing me from using udmf and the eternity engine. Since I still want to make demos for cl9 wads it also doesn't make sense for me to switch to a source port that doesn't support that functionality either.

[Nine Inch Heels]

7 minutes ago, Graf Zahl said:

You cannot expect to have a map with 5000 monsters run at 60fps constantly when the same map is massively detailed.

If you mean "the foundry", that map causes issues for people on both GZDoom and ZDoom, to varying extent depending on their machine, but there's problems nonetheless.

 

10 minutes ago, Graf Zahl said:

Are we twisting words here? I did not mean realistic in terms of replicating the visuals of the real world but something that was made for realistic playing where you play to beat the map and get to the exit. Nuts is a proof of concept, but entirely unplayable without cheating.

Neither did I mean realistic visuals. Correct me if I'm wrong, but people beat nuts and got to the exit, so by that token it would qualify as realistic, if we talk about being "realistically beatable". Case in point, I've seen many a player to deem a map not realistically beatable, only to eventually stumble upon a demo that does this supposedly impossible thing.

[Remilia Scarlet]

12 minutes ago, Graf Zahl said:

The main reason why PrBoom+ runs faster here is that Entryway compiled it with the Intel C++ compiler (which costs lots of $$$) A self compiled version with MSVC was only marginally faster.

Just curious, has there ever been some benchmarks with PrBoom against various compilers?  I'm curious how the Intel C++ Entryway paid money for stacks up against GCC in this particular case, for instance.

 

Also, do you load the entire UDMF into memory at load?  Would map format even matter once it's loaded into RAM?

[Koko Ricky]

1 hour ago, AsianMammoth said:

I'm just another one in the very small crowd of people that care about the old-school way of playing Doom, as it seems like everyone else wants to make Doom 'something it isn't' (not that it's a bad thing, I guess). That's just my view.

This sounds pretty inaccurate to me. The community did go through a "Wow, look what Doom can do!" period in the early 2000s as ZDoom and other source ports introduced a myriad of new, often Build-like features, but these days it's a mix of old and new. I'm not anywhere near caught up on current releases, but it seems plenty of people are still interested in focusing on more vanilla or "traditional" style mapping.

[GarrettChan]

55 minutes ago, Nine Inch Heels said:

makes no sense

Well, probably someone begins with h stole his account to post this or something ;P

[Linguica]

23 minutes ago, Graf Zahl said:

The main reason why PrBoom+ runs faster here is that Entryway compiled it with the Intel C++ compiler (which costs lots of $$$) A self compiled version with MSVC was only marginally faster.

How does LLVM / Clang stack up?

[Mordeth]

2 hours ago, AsianMammoth said:

Well, the reason I like Doom is because of its simplicity. For me, UDMF  is throwing all that simplicity in the trash bin and trying to make Doom just like any other modern FPS game, but with bad graphics... Like, it even allows the creation of cutscenes.

UDMF, the map format, doesn't do anything. It's up to the supporting engines to add new features.

 

Before UDMF, new features often had to rely on crutches in order to implement them because the map format did not allow for some stuff. Eg. Eternity needs ExtraData to add info to things / linedefs that are not possible to add in your normal editor under normal Doom format. Changing from Doom to UDMF format simply allows the modder to skip those extra steps and WAD lumps and add this information to the map itself. The player will not know the difference.

 

For example, if I want to open an door after a specific group of monsters die, I'll need to use CLED to assign a dummy flag to their specific editor sequence number which ExtraData can pick up and use to add a TID to that group. A script can then monitor that group and open the door if they are all dead. With UDMF, I can add that TID directly without the need for CLED or ExtraData.

 

So what you are really complaining about, is the fact that source port keep adding advanced features that, in your own opinion, don't match Doom. And that's a completely different discussion.

[Decay]

12 hours ago, Nine Inch Heels said:

-Boom yields faster results

lol

 

"i'm used to mapping in a particular format therefore its objectively faster." Seriously, this is one of the lamest arguments you could bring up for advocating for boom/fossil format mapping. Same with "its simpler." Are you saying the average boom mapper is pretty much like this?

 

[obnoxious meme image re-removed]

 

Anyway, UDMF's interface in GZDoom builder is a complete mess, looks like trash, unnecessarily difficult to navigate. DB2's UDMF is more or less the same as Doom in Hexen format, with isn't that far off from boom. Main reason people map in boom format is for compatibility of many ports/speedrunning/demo bullshit though, so even though as a UDMF mapper myself I totally see why people love to stunt themselves.

[stonedbaroness]

I always try to go for Zandronum multiplayer compatibility, So whenever I use UDMF I have to make sure A certain feature or command I use isn't GZDoom exclusive (Doom 64 style lighting, activate once sector actions). I never use player dummy sectors or even Fake bridges in Boom format (Unless it for like somewhat realistic water) because I've found those things not to work very well in Zandro multiplayer. Quite a shame, though I find work arounds. Fake bridges are only usable if I know the player isnt going to interact with them in any other angle besides the entrance and exit of it. I have an issue with this because Players will most likely move straight up and down constantly if many players try to cross at different moments. For me, Its only good if it works in multiplayer.

[Nine Inch Heels]

1 minute ago, Decay said:

"i'm used to mapping in a particular format therefore its objectively faster." Seriously, this is one of the lamest arguments you could bring up for advocating for boom/fossil format mapping. Same with "its simpler." Are you saying the average boom mapper is pretty much like this?

Way to build a strawman. As has been mentioned by Xaser, UDMF is more complex than boom, hence poeple usually spend more time on a single map, which is especially true for new mappers who still need find out how to "do stuff", let alone identify what method is most suitable for which purpose. The point that new mappers have serious problems with this complexity stands firm. If you want evidence, have a look around in the JOM discord. It's not like people would recommend vanilla or boom for starters just because. Keep in mind that most maps aren't deathmatch maps, not to mention that it looks like DM is pretty much a niche these days, if the quantity of available maps is in any way indicative. That said, I can see why UDMF is a better choice for DM, but DM maps are different.

 

...Also gotta wonder why so many speedmapping sessions go for boom. Maybe it's because the format yields faster results due to its simplicity... It's certainly possible.