DRD Team

Graf Zahl wrote: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!

Graf Zahl wrote:I'd rather optimize for maximum usability

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

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

And perhaps I will sink that ship...

Graf Zahl wrote: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.

milasudril wrote:

Graf Zahl wrote:I'd rather optimize for maximum usability

How do you define "usability"

Gez wrote:

milasudril wrote: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..."

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...

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

milasudril wrote: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

Graf Zahl wrote:

milasudril wrote:

Graf Zahl wrote: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.

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

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*/

}

Gez wrote:
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.

milasudril wrote:But it is a huge step in extensibility.

Gez wrote: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.