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

UDMF v0.99 Specification Draft (aka TEXTMAP)

Recommended Posts

http://eternity.mancubus.net/text/udmf.txt

There are some unsolved technical issues:

* Conflict between BOOM and Hexen flags for mapthing gamemode presence. I have currently preferred BOOM's not* flags over Hexen's because they can be set on what few objects are typically not in various gamemodes, whereas Hexen's flags require setting on every object in the map in order to appear in a given gamemode. Other than this, neither has serious technical merit over the other.

* All possible SPAC flag combinations have not been documented.

* Reasonable default value for sector light level not clear.

* Semantics for Hexen player class flags possibly problematic for DOOM/Heretic/Strife games. Flags which must be set on every object really should be discouraged in the new format IMO. They are currently specified as class0-2 fields in the thing record.

Input is needed from all concerned parties to complete this draft as v1.0 of the specification.

Share this post


Link to post
esselfortium said:

giant skulltag forums smiley

You know, I'm the one that initially resized that smiley to be huge. I'm surprised people still use it. That's the first time I've seen it with the four extra hearts in the background, though.

Share this post


Link to post

A) This format doesn't have to be compatible with older games. It cannot be, because older games are not going to be able to read this anyway. So I don't see your problem with the flag names and such. Just say "these are the flags we use in UDMF, period".

B) In the 'sector' structure, change the 'floorpic' and 'ceilingpic' to 'texturefloor' and 'textureceiling'. Also change 'floorheight' and 'ceilingheight' to 'heightfloor' and 'heightceiling'. You did this right for the sidedef (see 'texture*') I think you should document these naming conventions.

Share this post


Link to post
Quasar said:

http://eternity.mancubus.net/text/udmf.txt

There are some unsolved technical issues:

* Conflict between BOOM and Hexen flags for mapthing gamemode presence. I have currently preferred BOOM's not* flags over Hexen's because they can be set on what few objects are typically not in various gamemodes, whereas Hexen's flags require setting on every object in the map in order to appear in a given gamemode. Other than this, neither has serious technical merit over the other.


This is more an editor problem than anything else. As long as these options are presented properly to the mapper it really shouldn't matter how it is implemented.

* All possible SPAC flag combinations have not been documented.


As long as it is a bit mask every combination should be allowed and checked for - even if it is redundant.

* Reasonable default value for sector light level not clear.


128 is probably too dark. A reasonable value would be 160.

* Semantics for Hexen player class flags possibly problematic for DOOM/Heretic/Strife games. Flags which must be set on every object really should be discouraged in the new format IMO. They are currently specified as class0-2 fields in the thing record.


ZDoom uses a player class property to handle this. As long as the player class in use doesn't specify any filtering these flags will be ignored. This way there is no conflict with Doom, Heretic and Strife (unless a mod defines its own player classes that allow filtering.)
This, however, requires positive flags to work as intended so if these get switched around I would have a problem doing a consistent implementation because having no limits on available flags I'd make this so that new flags can be added by the mapper if needed to support more player classes.

Other suggestions:

- This was discussed before: Vertex coordinates should be float or fixed point. I have been in a situation where the lack of precision became a problem with a map because intersecting diagonal lines had their intersection on a non-integer coordinate so the end result didn't look correct.

- The Boom sector type bit masks should be taken out of the special field. This would make handling (especially editing them) a lot easier.

- Limitations imposed by the Doom map format should not be kept for convenience. This includes the merging of skill flags for the easy and hard skills (with a new map format each skill can easily have its own flag with little additional work in the port.) or the line tag with the line ID. The line tag as originally used by Doom is just an argument to the special and should be treated as such. Again, this shouldn't be too hard to implement (ZDoom already has it separated so for me this is just an artificial limitation without any purpose.)

Share this post


Link to post
Graf Zahl said:

- This was discussed before: Vertex coordinates should be float or fixed point. I have been in a situation where the lack of precision became a problem with a map because intersecting diagonal lines had their intersection on a non-integer coordinate so the end result didn't look correct.

I mentioned this to Quasar on IRC as a suggested extension, and if I remember correctly he said that it should be a part of the base specs.

Share this post


Link to post

There's one important thing the specs don't say:

How is floating point precision handled? If repeated loading and saving causes incremental imprecisions in floating point values we have a problem. I think it has to be clear that any editor saving the format must ensure that any saved value must be written back unchanged if it isn't being edited.

Share this post


Link to post

I still don't understand anything to this. Will this allow new
features like 3D floors in software.

And will it implies console doom port map spécifications:
http://www.doomworld.com/vb/wads-mods/38608-the-console-doom-hacking-project-console-specs/

like doom 64 lighting system for example

Sector_0:
Floor Color: 44
CeilingColor: 15
SpriteColor: 16
CeilingShade: 15
FloorShade: 43
Sector_1:
Floor Color: 98
CeilingColor: 97
SpriteColor: 99
CeilingShade: 100
FloorShade: 101
Sector_2:
Floor Color: 93
CeilingColor: 92
SpriteColor: 94
CeilingShade: 95
FloorShade: 96

This just a question

Share this post


Link to post
DoomKn1ght said:

I still don't understand anything to this. Will this allow new
features like 3D floors in software.

And will it implies console doom port map spécifications:
http://www.doomworld.com/vb/wads-mods/38608-the-console-doom-hacking-project-console-specs/

like doom 64 lighting system for example

Sector_0:
Floor Color: 44
CeilingColor: 15
SpriteColor: 16
CeilingShade: 15
FloorShade: 43
Sector_1:
Floor Color: 98
CeilingColor: 97
SpriteColor: 99
CeilingShade: 100
FloorShade: 101
Sector_2:
Floor Color: 93
CeilingColor: 92
SpriteColor: 94
CeilingShade: 95
FloorShade: 96

This just a question



No, of course not. All it does is a more flexible way to define map data so that it is easier to add new things that have to be defined in the map. Imagine several of ZDoom's features that need to be defined in an OPEN script. With this they can be defined where they should.

Share this post


Link to post

Ralphis said:
udmf on top

Finally, the Unidoom Map Format!

Share this post


Link to post
CodeImp said:

A) This format doesn't have to be compatible with older games. It cannot be, because older games are not going to be able to read this anyway. So I don't see your problem with the flag names and such. Just say "these are the flags we use in UDMF, period".

B) In the 'sector' structure, change the 'floorpic' and 'ceilingpic' to 'texturefloor' and 'textureceiling'. Also change 'floorheight' and 'ceilingheight' to 'heightfloor' and 'heightceiling'. You did this right for the sidedef (see 'texture*') I think you should document these naming conventions.


Most of the field names were taken directly from the structures in the Doom source code, including all of the ones you have singled out - flats, sector heights, and sidedef texture names. Check doomdata.h in the Doom source code if you don't believe me ;) Of course there is no reason we HAVE to follow that.

Graf Zahl said:

- This was discussed before: Vertex coordinates should be float or fixed point. I have been in a situation where the lack of precision became a problem with a map because intersecting diagonal lines had their intersection on a non-integer coordinate so the end result didn't look correct.

- The Boom sector type bit masks should be taken out of the special field. This would make handling (especially editing them) a lot easier.

- Limitations imposed by the Doom map format should not be kept for convenience. This includes the merging of skill flags for the easy and hard skills (with a new map format each skill can easily have its own flag with little additional work in the port.) or the line tag with the line ID. The line tag as originally used by Doom is just an argument to the special and should be treated as such. Again, this shouldn't be too hard to implement (ZDoom already has it separated so for me this is just an artificial limitation without any purpose.)


1. Don't know that Doom Builder can handle a real-number grid rather than an integer one. CodeImp is going to have to give feedback on this before I can add it to the specification. It would already be possible to provide xf/yf vertex members for vertices created by the BSP, whether or not CodeImp can support them in his editor.

2. Sounds like an implementation-specific concern to me. UDMF is not set on dictating anything in respect to line or sector specials. This is what we decided upon earlier AFAIK. This is also why I didn't address the issue you raised earlier of "not allowing" line ids to be set by line specials. That's the implementing source port's business only and is outside the scope of this standard.

3. Again, implementation specific concern. If ZDoom wants to support separate skill level flags for all skills, why not add them as a port-specific feature. And then, if support becomes widespread, they could be standardized in a later v2.0 draft. If the specification is used to dictate new features that have to be supported, then support for it will dwindle.

The primary guiding principle I used when designing the fields supported by v0.99 was to stick to what will be necessary to represent any translated Doom and Hexen maps. This is why there are no fancy port features in there, even ones that we might agree upon immediately. I wanted the spec to be as broad and unrestrictive to implementation as possible.

Share this post


Link to post
Quasar said:

The primary guiding principle I used when designing the fields supported by v0.99 was to stick to what will be necessary to represent any translated Doom and Hexen maps. This is why there are no fancy port features in there, even ones that we might agree upon immediately. I wanted the spec to be as broad and unrestrictive to implementation as possible.



Ok, it's not a big issue as it can easily be expanded. The only one I'm having real issues with is:

- The Boom sector type bit masks should be taken out of the special field. This would make handling (especially editing them) a lot easier.


because this is effectively crippling the sector special field forever if the mixed use is allowed in the new format - and as I said, this is not editing friendly.
After all it is bit fields and like flags in linedefs and things they should be treated the same here for consistency.

Share this post


Link to post

On the BOOM thing flags: As we discussed over IRC, I vote to use Hexen's additive type of flags. Makes more sense to tell what the thing is for than to tell what it is not for. Defaults are not to worry about. They are documented and the editor should set the default automatically when creating a new thing.

Quasar said:

Most of the field names were taken directly from the structures in the Doom source code, including all of the ones you have singled out - flats, sector heights, and sidedef texture names. Check doomdata.h in the Doom source code if you don't believe me ;) Of course there is no reason we HAVE to follow that.

I would rather have the naming convention to be like my example here. I could live with my suggestions I gave above, but not with this in v0.99. Also: document it!

Quasar said:

1. Don't know that Doom Builder can handle a real-number grid rather than an integer one. CodeImp is going to have to give feedback on this before I can add it to the specification. It would already be possible to provide xf/yf vertex members for vertices created by the BSP, whether or not CodeImp can support them in his editor.

Doom Builder is not a nodebuilder and I don't intend to write one. This map format could be extended to include nodes information, but I don't see the need for that (sourceports today can build nodes automatically). The only real reason I see for floating point vertices are for nodebuilder output, not for mappers, because such a level of detail is not needed IMO.

However, in light of extendability, I think it is not a bad idea to use floats in the map format. Though, Doom Builder will now only write integral values, I could change this later maybe.

Quasar said:

3. Again, implementation specific concern. If ZDoom wants to support separate skill level flags for all skills, why not add them as a port-specific feature. And then, if support becomes widespread, they could be standardized in a later v2.0 draft. If the specification is used to dictate new features that have to be supported, then support for it will dwindle.

The primary guiding principle I used when designing the fields supported by v0.99 was to stick to what will be necessary to represent any translated Doom and Hexen maps. This is why there are no fancy port features in there, even ones that we might agree upon immediately. I wanted the spec to be as broad and unrestrictive to implementation as possible.

Agreed, but please don't be afraid to document extensions. The sooner you document them, the better other sourceports can support the same field names for the same purpose!

Share this post


Link to post

After further discussion in IRC CodeImp and I have come up with the following ideas:

1. For sector specials, it would not be appropriate to *forbid* the use of the value in this field as a BOOM extended sector special by implementing ports, but it would nevertheless be prudent to provide access to BOOM's sector bits as separate fields, and such representation should be preferred for obvious reasons.

2. For skill flags, easy/medium/hard ought to retain their current meanings. Additive skill0 through skill4 flags would control presence for individual skill levels when asserted. For example, a thing that sets "easy = true" and "skill4 = true" would appear in ITYTD, HNTR, and NM skills. There's no reason that existing semantics cannot be balanced with extensions, even if it results in a small amount of redundancy.

3. I have agreed that the additive gamemode flags are probably better due only to being consistent with skill and player class specification.

Share this post


Link to post
CodeImp said:

Doom Builder is not a nodebuilder and I don't intend to write one. This map format could be extended to include nodes information, but I don't see the need for that (sourceports today can build nodes automatically). The only real reason I see for floating point vertices are for nodebuilder output, not for mappers, because such a level of detail is not needed IMO.



I disagree with this. I have been there with KDiZD and know what the lack of precision can mean to a map.

CodeImp said:

Agreed, but please don't be afraid to document extensions. The sooner you document them, the better other sourceports can support the same field names for the same purpose!


As soon as v1.00 of this spec is finalized I will implement it in ZDoom and define all additional options I think are useful.

Share this post


Link to post

I disagree as well. It doesn't have to do with more detail, but more precision. I've run into problems with intersecting diagonal lines as well.

Share this post


Link to post

Very well, then floating point vertices it is. I will make Doom Builder 2 capable of working with this.

Share this post


Link to post
CodeImp said:

Very well, then floating point vertices it is. I will make Doom Builder 2 capable of working with this.

Awesome :O. I'm pretty much the same as essel when it comes to splitting weird angled lines, so that'll be a neat thing to have.

Share this post


Link to post
Quasar said:

1. For sector specials, it would not be appropriate to *forbid* the use of the value in this field as a BOOM extended sector special by implementing ports, but it would nevertheless be prudent to provide access to BOOM's sector bits as separate fields, and such representation should be preferred for obvious reasons.

Wouldn't allowing Boom's extended specials in the main field make it an annoying thing to have to work around, though? It seems like it'd just make more sense to use multiple fields for them, maybe even the Hexen argument fields, so that they're only using a few line specials instead of however many hundred or thousand they have to use in the Doom format. I mean, I suppose that with this you'd be able to add new line specials with whatever high numbers you need, but it just seems kind of strange to keep them implemented that way, when they could be replaced with just a few specials that use arguments.

Share this post


Link to post

In general, yes. However, this would force any port that doesn't implement Hexen specials to completely change its implementation to work. And even though Eternity does implement some of them it still keeps all the original Doom types instead of using translation tables like ZDoom.

Of course the translation tables make this a non-issue for me. It's easily converted.

Share this post


Link to post

Aren't the Hexen args and stuff already part of the standard, though? So any port that wants to comply with the base standard would have to have those anyway.

Alternately, how about a compromise where you have a few specials (or I suppose you could even do just one) for the boom extended specials, and a boom-special field that would have the full Boom special number? I guess that could be kind of weird, but it'd keep the 8 billion numbers out of the main specials field while allowing ports to read it without having to support args. Actually, forget that. Probably a dumb idea. :p

Share this post


Link to post

We were talking about *sector* specials, not line specials. There's no problem with the BOOM line specials because they use outrageously high and difficult to remember numbers that will never be needed anyway. The problem with sectors, on the other hand, was BOOM team's decision to make them kick in starting at 32. This leaves scant few free specials below that number. Hexen already uses some that are not compatible due to being numbered higher than that.

I won't put language in the spec forbidding the use of such sector specials, but I will certainly be looking at a different way of supporting them in UDMF. I was already considering this for ExtraData sectors anyway.

Share this post


Link to post
esselfortium said:

Alternately, how about a compromise where you have a few specials (or I suppose you could even do just one) for the boom extended specials, and a boom-special field that would have the full Boom special number? I guess that could be kind of weird, but it'd keep the 8 billion numbers out of the main specials field while allowing ports to read it without having to support args. Actually, forget that. Probably a dumb idea. :p


Any port that feels the need to do this can implement ZDoom's Generic_*** specials and all is fine.

Quasar said:

We were talking about *sector* specials, not line specials. There's no problem with the BOOM line specials because they use outrageously high and difficult to remember numbers that will never be needed anyway. The problem with sectors, on the other hand, was BOOM team's decision to make them kick in starting at 32. This leaves scant few free specials below that number. Hexen already uses some that are not compatible due to being numbered higher than that.


... and that's why ZDoom shifts the Boom bit fields by 3 bits to get enough free types for Hexen map format. A bigger problem is Heretic which uses slightly less than 60 types which renders the lower damage bit unusable.

Share this post


Link to post
CodeImp said:

Very well, then floating point vertices it is. I will make Doom Builder 2 capable of working with this.

The format document should specify a precision for them, and I suggest two digits after the '.' would be the best compromise between precision and information clutter in the editor UI.

Share this post


Link to post

I'd say 3 digits - and the editor must ensure that reading and writing back a value does not change the last digit.

Share this post


Link to post

2 digits just might work I think, but I think with 3 digits you get into accuracy problems when using 32bit floating points (a vertex could be placed at a 32000 coordinate where you lose a lot of accuracy). I could use doubles which is slow or fixed point which is troublesome to code.

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
×