Compile binary maps from UDMF

[Blastfrog]

Yet another silly idea thread from me.

 

So, id used a text based format when making the maps, and compiled them into binary to run it in the game. While these days it makes a lot more sense to edit in binary as usermade editors do (id's text format was... limited, no concept of sectors, just line properties, ugh), I think that the idea of compiling from a text based format is still valid.

 

 

The idea would be to make putting some effects in more easily, as long as it's something that could be done in binary, but is a pain to manually manage in complex and frequent usage. I can't think of any examples of that off the top of my head, however.

 

[Albertoni]

I can see no advantage coming from this. You're welcome to find an use for it, but until then...

[scifista42]

Well, binary format maps tend to be smaller in file size than UDMF maps, so this could be used simply to reduce file size of gonna-be-downloadable wads before uploading them.

[Edward850]

15 minutes ago, scifista42 said:

Well, binary format maps tend to be smaller in file size than UDMF maps, so this could be used simply to reduce file size of gonna-be-downloadable wads before uploading them.

You have reinvented the zip file.

[Remilia Scarlet]

The Doom engine is simple enough that I wouldn't think there would be much use to go to a binary format, at least from a speed point of view.  What sort of effects would be easier?

 

Plus as @Edward850 implied, smaller size can be accomplished simply by compressing it (pk3).  If size is the main concern, remember that the Zip file format supports more than just DEFLATE compression.

[Graf Zahl]

The main problem of a binary format is that you need to define its entire feature set up front. The motivation behind UDMF was to break that particular limit and have a format that can have new stuff added at will.

 

Raw data size nonwithstanding, having an external compiler provides no advantage over having the parser built into the engine.

 

If you want a binary map, don't start using UDMF. The entire point here is to get the extended features which the binary format does not supoirt.

So compiling a map would be a destructive process.

[scifista42]

1 hour ago, Graf Zahl said:

Raw data size nonwithstanding, having an external compiler provides no advantage over having the parser built into the engine.

How about lesser loading time, too? All players want it to be as short as possible, and compilation in general is not guaranteed to only take a negligible amount of time.

1 hour ago, Graf Zahl said:

If you want a binary map, don't start using UDMF. The entire point here is to get the extended features which the binary format does not supoirt.

So compiling a map would be a destructive process.

I disagree with this way of thinking. UDMF allows defining unlimited data structures, but many of the engines/parts-of-engines/programs (I will say just "programs" from now on) that read it do have limits and do expect the structures to follow certain rules in order to process them as they're supposed to. The reasons why the program couldn't parse UDMF itself can be various - high priority focus on time/memory/file size efficiency, being an old / now unmaintained program, issues with implementation, whatever. UDMF has a potential to accustomize to the needs of any such program - not necessarily by forcing the program to parse UDMF, but just by defining the structures, which would be processed by a compiler and the program will only process the result of the compilation. I see it as a good thing to have this possibility and to take advantage of it. Destructivity of the process can be prevented on the side of an editor, via configs enabling only certain features that the program can process in its own format - practically what we already have. Note that, as opposed to the target program, the editor could benefit from working with UDMF despite only working with limited features when editing files for a specific target program, also for various reasons - easily implemented support for multiple target programs with different limits, separated maintenance of the editor and the compiler.

[Graf Zahl]

2 minutes ago, scifista42 said:

How about lesser loading time, too? All players want it to be as short as possible, and compilation in general is not guaranteed to only take a negligible amount of time.

 

Are we living in 2017 or 1993? Sorry, but any computer having problems here will have far more problems with loading other stuff required to play the map.

Loading a UDMF map takes less than half a second on a modern system, loading the level's resources normally takes twice as long or more - and the initial screen wipe takes even more time than that.

 

 

 

 

2 minutes ago, scifista42 said:

I disagree with this way of thinking. UDMF allows defining unlimited data structures, but many of the engines/parts-of-engines/programs (I will say just "programs" from now on) that read it do have limits and do expect the structures to follow certain rules in order to process them as they're supposed to. 

 

Why would you even consider using UDMF then? It's clearly not suitable for the task at hand.

 

2 minutes ago, scifista42 said:

 

 

The reasons why the program couldn't parse UDMF itself can be various - high priority focus on time/memory/file size efficiency, being an old / now unmaintained program, issues with implementation, whatever. UDMF has a potential to accustomize to the needs of any such program - not necessarily by forcing the program to parse UDMF, but just by defining the structures, which would be processed by a compiler and the program will only process the result of the compilation.

 

 

Just two words: Screw it!

If that's the scenario it's not even worth thinking about using UDMF as an intermediate. Furthermore, it's purely academic, if this is about any Doom port its limits are the same as for any other, i.e. the ones of the original binary map format.

This is really something not worth thinking about at all.

 

 

 

2 minutes ago, scifista42 said:

 

 

 I see it as a good thing to have this possibility and to take advantage of it. Destructivity of the process can be prevented on the side of an editor, via configs enabling only certain features that the program can process in its own format - practically what we already have. Note that, as opposed to the target program, the editor could benefit from working with UDMF despite only working with limited features when editing files for a specific target program, also for various reasons - easily implemented support for multiple target programs with different limits, separated maintenance of the editor and the compiler.

 

Again: let's talk about something less far-fetched. No such engine exists, no such engine should ever exists, unless its maintainer is hell-bent on creating a problem, so it's all not worth thinking about. Any new engine wanting to support UDMF should support UDMF directly. All the considerations here go into the totally wrong direction.