Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sigvatr

UDMF Support in Compat ports

Recommended Posts

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?

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post
fraggle said:

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×