UDMF support for "simple" ports

[Blastfrog]

UDMF can be useful for traditional style mapping as well, not just going crazy with advanced port features in a more convenient and flexible way.

 

I think it'd fit right at home in ports like PrBoom+. Yeah, sure, it's not the Doom map format, but it'd be a waste of the UDMF spec not to do simpler things in it too, for simpler ports.

 

Thoughts?

[RjY]

I've often thought about a trivial extension to the binary wad format that doubles the width of half a dozen fields. This is all I think that's needed for traditional mapping. Sidedef and vertex numbers in linedefs and sector numbers in sidedefs are doubled in width to increase maximums from 64K to 4G (although you'd hit the limit on the size of a lump before you reached them). Might as well change vertexes from integers to 16.16 fixed coordinates while you're at it. Then you stick a magic number on the start of the lump to signify it has these extended width fields and use basically the same existing wad loading code you already have, just with a few more conditionals in it. It'd probably add maybe 100 lines of C code tops. This is much easier to justify adding to a source port than a whole separate text parser.

[Quasar]

UDMF was born out of my own proposal for an extended binary map format.

[Graf Zahl]

Implementing the base UDMF spec wouldn't be too hard. Aside from the parser there's really only two things that need addressing: Spawn flags for all skills and linedef tag/id separation, which are separate fields in UDMF.

 

Extending the binary format is far from  'trivial'. In order to make that work you need all relevant ports being on board, you need editor support and you need tool support. I think I am on the safe side when I say that this is very unlikely - it's far easier to implement UDMF instead which already has all the support it needs.

 

[kb1]

UDMF support is planned for the Boom+ spec, in Phase n, where "n > 1", along with thing and frame defs, and hopefully some other things.

 

UDMF (and thing/framedefs) are stand-alone specs that could be implemented without the Boom+ standard, but I am hoping that, thinking about them as a single unit will allow a smooth transition from phase to phase, and provide a clear upgrade path to the developer. The entire spec is being built with this eventual progression in mind.

[Graf Zahl]

Since UDMF can run on the same parser as UMAPINFO the biggest part is already done, i.e. having a working tokenizer. The rest is just taking some code from ZDoom and remove the engine specific parts, plus two minor alterations of the internal data structures.

 

[kb1]

That's great. Let me ask: Is your parser self-contained, like in one module without dependencies? In other words, could I just drop a module into, say PrBoom+, and run with it, or do I need a bunch of modules/libraries as well? (I haven't researched it yet.) Self-contained would, of course, be the best scenario for wide adoption.

[Graf Zahl]

The tokenizer is one single file, written in C++, it has no external dependencies aside from the basic C runtime library.