UDMF Support in Compat ports

[Sigvatr]

I've been doing some investigation into the UDMF format lately due to feedback I've been getting on my maps from forum users. Although I'm one of those purist elitist assholes, I have to say that I like the format. Even though you could consider it an "extension", it doesn't muck about with the end doom experience very much as far as I am concerned, so I'm not fussed.

However, it doesn't seem that many ports support it. I know a lot of people like using Choc/PrBoom etc... so I want to pitch the possibility of getting UDMF support implemented in more ports. I can probably implement it myself if I'm given a bit of directions in the source code, but I am for the most part unfamiliar with it. I've snooped around in it a few times but never tried to compile anything.

I know Chocolate Doom support is a big no no, although to be honest I have been toying around lately with the idea of starting my own port. I have very rough ideas for what I would like to do right now, but essentially I'm looking to fork from a current port that has wide platform support, OPL emulation support and hasn't enforced too many bug fixes to Vanilla Doom. Chocolate Doom looks like a likely candidate at the moment, although I'm not sure which platforms it supports and it still doesn't support OPL emulation yet.

Anyone have any ideas or recommendations?

[Csonicgo]

EE will have it. Soon.



Or else.

[DaniJ]

Given a port is vanilla-experience oriented what is the point in implementing UDMF if said port won't be using the namespacing to expose new modding features?

[andrewj]

DaniJ said:

Given a port is vanilla-experience oriented what is the point in implementing UDMF if said port won't be using the namespacing to expose new modding features?

To remove limits I guess.

[Graf Zahl]

Every port has some feature that may not be exposable through the binary map format but can be easily done in UDMF so implementing it with the base configuration does not sound like a worthwile undertaking.

Concerning limits, just have a look at Naturaltvventy's new map. If you can do that with the binary map format mere removal of limits is not really an issue - and it never was the focus of UDMF.

[Gez]

Graf Zahl said:

Concerning limits, just have a look at Naturaltvventy's new map. If you can do that with the binary map format mere removal of limits is not really an issue - and it never was the focus of UDMF.

NaturalTvventy said:

Hey gang,

Well bad news my friends. I've hit the maximum number of linedefs allowed for my industrial zone level and now DB2 won't let me draw any more.

Seems you actually can't do that with the binary map format.

[rpeter]

Are there UDMF maps out there with vanilla features only?
I presume there are some new ones for ZDoom/GZDoom, but that could be all.

[Graf Zahl]

No. There isn't even a DB config for the compatibility namespace available. What would be the point? Right now the only ports which support UDMF are ZDoom, its derivatives and Vavoom.

[bgraybr]

DaniJ said:

Given a port is vanilla-experience oriented what is the point in implementing UDMF if said port won't be using the namespacing to expose new modding features?

You could have a simple source port (based on Chocolate Doom or something similar) that utilizes all of the UDMF mapping features, such as colored lighting, but doesn't add any of the scripting or modding features of zdoom. Seems kind of pointless, but it might appeal to "purists" that want additional editing features/limit removal while still staying absolutely true to the original gameplay.

[Gez]

bgraybr said:

You could have a simple source port (based on Chocolate Doom or something similar) that utilizes all of the UDMF mapping features, such as colored lighting, but doesn't add any of the scripting or modding features of zdoom. Seems kind of pointless, but it might appeal to "purists" that want additional editing features/limit removal while still staying absolutely true to the original gameplay.

Sophistry. I could see PrBoom+ implementing the "vanilla" namespace to benefit from the limit removal aspect of UDMF; but additional modding features like colored lighting are modding features.

If you look at the specs, you'll see that colored lights are not part of the Doom namespace, by the way.

Finally, I don't see how avoiding ACS is being "absolutely true to the original gameplay" when nobody objects to voodoo doll scripting or Commander Keen hacks.

[Spleen]

Gez said:

Finally, I don't see how avoiding ACS is being "absolutely true to the original gameplay" when nobody objects to voodoo doll scripting or Commander Keen hacks.

Well, this is what 40oz thinks: http://img682.imageshack.us/img682/6215/chartt.png

Note that Eternity Engine is conveniently missing from that chart.

[Gez]

As are EDGE, Doomsday, etc.

[esselfortium]

I don't think it necessarily needs to include every existing source port to get his opinion across, though. You could mentally swap out any of the listed ports with another one of a comparable feature set.

[Sigvatr]

Gez said:

nobody objects to voodoo doll scripting or Commander Keen hacks

Actually, I do.

[Catoptromancy]

I would like to see this in pr+. It would just be awesome is all.

[fraggle]

Sigvatr said:

I'm looking to fork from a current port that has wide platform support, OPL emulation support and hasn't enforced too many bug fixes to Vanilla Doom. Chocolate Doom looks like a likely candidate at the moment, although I'm not sure which platforms it supports

Pretty much everything, basically.

and it still doesn't support OPL emulation yet.

Huh?

[Gez]

fraggle said:

Huh?

Well, it's still categorized there as a "future feature". ;)