About UDMF again...

[milasudril]

Thank god I don't have to work with you. You absolutely don't get it, do you? I wouldn't want to work with such a messy format - ever!

I don't like you either.

[milasudril]

I'd rather optimize for maximum usability

How do you define "usability"

[Gez]

No, the old one use the old header. The newer file format uses the new header. The header solves the problem. An mathematical analogy

So now your map is made of several files, which use several different headers. "map01.001 contains sectors 0 to 547; map01.002 contains sectors 548 to 619 and 820 to 1200, map01.003 contains sectors 620 to 819..."

This would be extremely dumb.

If there were more than one way to represent the same kind of data, I would have used file format plug-ins.

Sounds needlessly complicated. Now you've got to define a metaformat that defines the format for extending the format.

This would be extremely dumb.

And perhaps I will sink that ship...

Good luck! I won't be waiting...

[milasudril]

UDMF is 1.3 - 1.5 times the size of the binary format. To me that's a non issue compared to the gain in flexibility.

What is the largest number in UDMF? In the engine? If it is the same as in a regular WAD, that is a lot. If it removes the limitation of 16-bit integers it is not.

[Graf Zahl]

I'd rather optimize for maximum usability

How do you define "usability"

In terms of a data storage format I define usability as the capability to add arbitrary values to a definition without having to change the format or some metadata describing the format and not having to change data entries unrelated to the one I want to change.

UDMF satisfies all of these, as do other common formats like XML. The reason UDMF is not XML was simply that XML parsers are too complex for what's needed here.

[milasudril]

No, the old one use the old header. The newer file format uses the new header. The header solves the problem. An mathematical analogy

So now your map is made of several files, which use several different headers. "map01.001 contains sectors 0 to 547; map01.002 contains sectors 548 to 619 and 820 to 1200, map01.003 contains sectors 620 to 819..."

As I said, I think the BMP file header is a really good example for how you can store data. CVS is not as good as binary formats...

If there were more than one way to represent the same kind of data, I would have used file format plug-ins.

Sounds needlessly complicated. Now you've got to define a metaformat that defines the format for extending the format.

This would be extremely dumb.

Ideally it should not be needed, but when we speak about Doom and all derived games, it is probably better to think of the engine as a kind of media player. You can say that it is a WAD player. The best way to implement the differences in the different games are to use plug-ins for file formats, game logic etc. On windows you would have

doomII.dll
heretic.dll
hexen.dll
strife.dll
yourgame.dll

for game logic

doomwad.dll
hexenwad.dll
udmf.dll
yourformat.dll

for map file formats

now the engine has been reduced to draw the map and play the sounds and stuff. If you want to make new mod that needs new game logic you can write a new mygame.dll and bid far well acs . Isolating game logic, file formats and rendering engine you would probably end up making an engine capable to play Q3 too. (If it can draw all things it needs).

And perhaps I will sink that ship...
Good luck! I won't be waiting...

That is what I am waiting for.

[milasudril]

The reason UDMF is not XML was simply that XML parsers are too complex for what's needed here.

Yes it is!

[Gez]

Ideally it should not be needed, but when we speak about Doom and all derived games, it is probably better to think of the engine as a kind of media player. You can say that it is a WAD player. The best way to implement the differences in the different games are to use plug-ins for file formats, game logic etc. On windows you would have

heretic.dll
hexen.dll
strife.dll
yourgame.dll

for game logic

doomwad.dll
hexenwad.dll
udmf.dll
yourformat.dll

for map file formats

What you describe is the Doomsday approach. ZDoom supports all features and formats of all games for all games, so what you're talking about would be a huge step backward in usability.

Also, I don't see how having to write new dlls would somehow be more practical for the end-user wishing to use a new field than just clicking on the "custom" tab in DB2 and typing the field's name and value.

[milasudril]

I'd rather optimize for maximum usability

How do you define "usability"

In terms of a data storage format I define usability as the capability to add arbitrary values to a definition without having to change the format or some metadata describing the format and not having to change data entries unrelated to the one I want to change.

UDMF satisfies all of these, as do other common formats like XML. The reason UDMF is not XML was simply that XML parsers are too complex for what's needed here.

Now we are off topic but note that XML also could be more "binary"

Code: Select all

<foo bla="..."> </foo>

use

Code: Select all

struct Tag
{
unsigned int ID;
unsigned int numberOfAttributes;

struct Attribute
{
unsigned int ID;
unsigned int type; 
void* data; /<**allocated when reading the attribute*/
}

Attribute* attributes;/<**allocated when reading tag*/

}

[milasudril]

What you describe is the Doomsday approach. ZDoom supports all features and formats of all games for all games, so what you're talking about would be a huge step backward in usability.

But it is a huge step in extensibility. You can actually make it to use whatever you want including an own menu system.

[Gez]

But it is a huge step in extensibility.

No.

Not being able to use ACS in Doom is not a huge step in extensibility. Not being able to use conversations in Heretic is not a huge step in extensibility. Cutting the game into little pieces results in having to maintain several ports at once, and in duplicating all features you want to be common to them. Since that's all of them...

Example: Doomsday jDoom supports voodoo dolls, but Doomsday jHeretic doesn't. As a result, Kristus' mod Curse of D'Sparil is broken on two maps which use voodoo doll scripting if using that port. Works flawlessly in GZDoom and ZDoom, though.


What you're talking about with menus and dlls and so on is going on wiiiiiiild tangent that has nothing to do with map format anymore.

[Graf Zahl]

You know, I find it rather funny how milasudril has argued himself in a corner out of which there is no escape but he tries anyway by cooking up overcomplicated and harebrained schemes to add some sort of flexibility to his idea without ever realizing that UDMF doesn't need any of that because extensibility is a natural feature of its format specification,

Dude, it's time to realize that Doom's source port and editor programmers are no idiots. We know what we are doing and UDMF was designed the way it is because it's the most convenient means of getting what we needed. Your convoluted mess is not.

[Deathlike2]

I'm not even sure why this is an internet argument.

milas, you fail to understand the obvious.

1) For a map maker, a format that is bound to a particular version of a port (or to a specific port) is massive fail. No matter what structure you create, if you have to have a new revision # or anything that breaks future compatibility with the WAD (other than bugs) is the worst case scenario for every map being developed. If you have to use a binary structure, the people developing the ports will have to waste additional time trying to add compatibility, instead of adding new features. This is a wasted effort on both map developers and the ports.

2) ZDoom treats every WAD as a resource. Each resource provides the sounds+visuals and whatnot to the game. If a custom WAD wants to use resources from a different game (like Strife actors in a Doom-environment) they can do so. The resources in Doomsday are treated to their specific games, which have their peculiar behavior. You can't transition a particular behavior to another w/o lots of unnecessary duplication. In many ways, ZDoom is simply "the universal Doom engine"... so it does not need a special dataset... they are all treated equally under the same "engine".

[milasudril]

What you're talking about with menus and dlls and so on is going on wiiiiiiild tangent that has nothing to do with map format anymore.

It was you that complained about the most flexible solution of different file formats.

[milasudril]

Back to file formats.

We can make six different type of file formats. I list where you can put the field information. All of these formats can either be text not binary.

No field information (Meta-info):
All doom formats are Binary No field information

Meta-info at beginning of the list:
This is efficient AND extensible. The first record contains a list of which order different fields appear.

Meta-info at every record:
Here comes UDMF and XML.

Clearly Gez, UDMF use meta-info in every record. I can post a complete proof that the second approach is exactly as extensible as the third provided that all records have their fields in the same order (which they probably have): They contain the same information that's it.