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

UDMF v1.0 RFC

Recommended Posts

The id should be used to identify this line, and arg0 should be used to
identify the line or sector that this line is to affect or otherwise
reference, if the implementing port is capable of making such a semantic
distinction.


I'm sorry but that's still too many unknowns. If this behavior is not unambiguously defined in the map format this may cause incompatibilities.

Unlike options like line translucency which will merely produce visual anomalies if not supported this one is a crucial feature of the engine and if the base spec allows for incompatibilities in the compatibility namespaces it is a major issue.

In any case, this distinction is so trivial to implement for ports newly supporting the UDMF format that if it is part of the base spec it must not be subject to any kind of interpretation, it has to be 100% clear with no deviation allowed.

Here's my take for the blurb at the end:

Unlike traditional Doom maps UDMF makes a clear distinction between a line's ID and the parameter which identifies the object the line's special is supposed to affect.

The id will be used to identify this line, and arg0 will be used to identify the line or sector that this line is to affect or otherwise reference, i.e. it is effectively a parameter to the line's special.

Boom used the linedef's tag for both due to lack of other options so in order to ensure compatibility any map converter converting maps for the Doom/Heretic/Strife namespaces must store the linedef's tag field as both the id and as arg0 in each line. The default value of the id field under these namespaces is defined as 0 rather than -1.


The important difference to your wording is that there are no conditional semantics in the wording which IMO is very important.

The same kind of wishy-washy wording was used in many parts of the J2ME spec, particularly the sound interface. As a result, if you design a sound playing application for a Java enabled Nokia phone it won't play on a Motorola phone and vice versa. Although both implemented the same API their use of it is totally incompatible because they interpreted crucial parts differently.

Share this post


Link to post

I can change it, but I still cannot force ports with no Hexen support to support the id/arg0 differing from each other. Feature dictation is outside the scope of the standard. In that case it isn't totally clear what they should do, since in those standard namespaces, the numbers really should not ever differ (making it accordingly irrelevant, in those namespaces, which is used as what's going into that port's line->tag field at map init).

Share this post


Link to post

Isn't Hexen support kind of required for ports that want to support UDMF, though, since it's a part of the base spec? o_O

Share this post


Link to post
Quasar said:

I can change it, but I still cannot force ports with no Hexen support to support the id/arg0 differing from each other. Feature dictation is outside the scope of the standard. In that case it isn't totally clear what they should do, since in those standard namespaces, the numbers really should not ever differ (making it accordingly irrelevant, in those namespaces, which is used as what's going into that port's line->tag field at map init).

Well, in that case, such a port should simply refuse to load the map, shouldn't it ?

Share this post


Link to post

If you are more concerned with ports that might not want to implement such a simple thing it's be better to remove the id/arg0 distinction from the spec for the Doom namespace.

However, since the feature addition is utterly trivial I really see no point to weaken the spec in such a crucial area to save eventual port developers from investing 5-10 minutes of work (as in adding one variable to the line_t structure, adding savegame support for it, changing the initialization loop for translucent lines in P_LoadLineDefs2 and changing P_FindLineByLineTag. That's all the work that is needed. I checked. That's all a Boom-based ports needs.)

esselfortium said:

Isn't Hexen support kind of required for ports that want to support UDMF, though, since it's a part of the base spec? o_O



No. The Doom namespace doesn't make any use of the Hexen specific fields. It's still a non-issue in my opinion. We are defining a major addition to the engine here. What's a minor additional requirement in relation? If you ask me, not a problem.

Share this post


Link to post

Alright then, as long as it is understood that this isn't establishing a precedent for the future in requiring larger restructuring of port internals to support UDMF. Requiring a change this minor, which has no compatibility ramifications, is tolerable. I'll adopt Graf's wording more or less exactly since it does the job.

Share this post


Link to post
Quasar said:

Alright then, as long as it is understood that this isn't establishing a precedent for the future in requiring larger restructuring of port internals to support UDMF.


That's what port specific namespaces are there for, aren't they? Don't worry, I have no intention to force any new features into the base spec. Right now it covers everything that has to be covered while addressing a handful of trivially implementable and reasonable improvements.
But this issue was far too important to be left to interpretation. I don't think anyone would have liked to see Doom-namespace maps that work with port A but not with port B because they chose to implement this differently while both adhering to the wording of the spec (see my cell phone example above.)


Requiring a change this minor, which has no compatibility ramifications, is tolerable.


If that hadn't been the case here I would have advocated to leave it out anyway.

Share this post


Link to post
Creaphis said:

Graf, you need to get a job that involves something other than cell phone java.


Why? I don't program in Java myself - but that doesn't mean I'm not aware of the issues involved.

Share this post


Link to post
Quasar said:

I can change it, but I still cannot force ports with no Hexen support to support the id/arg0 differing from each other.

YES YOU CAN!

Don't muck up the spec by making the Doom namespace work differently.

EDGE is a no-Hexen port. If I were to implement this spec in EDGE I'd probably take the easy way out and do this:

if (spec->arg0 > 0)
  line->tag = spec->arg0
else
  line->tag = spec->id
Of course that won't work for linedefs which have both a special and are referenced by another line (for translucency or whatever). However in practice such a situation will be rare, so this solution would be good enough for me.

@Quasar, please remove my name from the spec, as I haven't made any significant contribution to it.

Share this post


Link to post
Ajapted said:

EDGE is a no-Hexen port. If I were to implement this spec in EDGE I'd probably take the easy way out and do this:

if (spec->arg0 > 0)
  line->tag = spec->arg0
else
  line->tag = spec->id
Of course that won't work for linedefs which have both a special and are referenced by another line (for translucency or whatever). However in practice such a situation will be rare, so this solution would be good enough for me.



Honestly, this precise situation is what I absolutely want to forbid by precise unambiguous wording - because this is exactly what will break the spec.

Share this post


Link to post
Ajapted said:

YES YOU CAN!

Don't muck up the spec by making the Doom namespace work differently.

Agreed. You MUST do so in order to make UDMF a standard.

Graf Zahl said:

...
Honestly, this precise situation is what I absolutely want to forbid by precise unambiguous wording - because this is exactly what will break the spec.

Yea but you cannot actually force anyone to implement UDMF properly.

You DID gave an unambiguous wording for the implementation, so if the implementor fails to properly implement UDMF, it simply is NOT a UDMF-compliant sourceport, regardless of what the implementor claims it to be.

Ajapted said:

Of course that won't work for linedefs which have both a special and are referenced by another line (for translucency or whatever). However in practice such a situation will be rare, so this solution would be good enough for me.

I don't see why you would need such a lazy hack Ajapted. Graf Zahl already showed is is very easy to make it work properly. Do you really want broken UDMF support, just to save yourself a few more minutes from coding?

Share this post


Link to post
CodeImp said:

Yea but you cannot actually force anyone to implement UDMF properly.


I know that one. But the less ambiguous the spec is, the less likely it is for someone to unintentionally do it wrong.


You DID gave an unambiguous wording for the implementation, so if the implementor fails to properly implement UDMF, it simply is NOT a UDMF-compliant sourceport, regardless of what the implementor claims it to be.


Precisely why I reworded it.


Regarding all that I did some minor revisions and clarifications to the spec, mostly related to Strife flags. I also moved the 'repeatspecial' line flag into the SPAC flags block because it's directly related to those and only has meaning if Hexen special semantics are implemented and finally added my note from a few posts above. Read it here:

http://grafzahl.drdteam.org/other/udmf10_gz.html

I colored all changes and additions red so that they can easily be seen. Comments?

Share this post


Link to post

No comments really, looks fine.

Quasar: Maybe also a good idea for the documentation is to make a section which describes all the standard fields which apply to all namespaces and then a section for each namespace explaining the fields that are specific to that namespace, leaving out the standard fields which are in all namespaces.

Share this post


Link to post

I still think the thing flags for skill and game mode should default to true, come on, you know it makes sense

Share this post


Link to post

That's the editor's business, not the map format's. It's more important that it makes sense technically (meaning, it's easy to parse without having to bother too much about pre-initialization) than logically.

Share this post


Link to post
CodeImp said:

I don't see why you would need such a lazy hack Ajapted. Graf Zahl already showed is is very easy to make it work properly. Do you really want broken UDMF support, just to save yourself a few more minutes from coding?

I know what it would take to work properly: going through all the source code and checking whether every usage of the old tag field should use either the new id or the new arg0 field, and that would definitely take a lot longer than a few minutes.

Share this post


Link to post

Don't make it sound more complicated as it is. I just quickly scanned through the entire EDGE 1.29 source (latest version I could find) and although I'm not familiar with it could easily identify all places that have to be changed. If I had done this seriously it wouldn't have taken 5 minutes but maybe half an hour to check everything and write it down for reference.

Share this post


Link to post

Can't do that. The project depends too much on stuff that's so Linux that I won't bother. :P

Share this post


Link to post

Linux won't kill you, you know :)

Anyway, joking aside, I confess that updating the code to support the id/arg0 distinction would probably not be much more time, in percentage terms, compared with writing the UDMF parser itself.

Share this post


Link to post

Quasar, please update your text file. We should now be able to get to an agreement on version 1.0.

Share this post


Link to post

Spec updated, same URL.

Changes:
* Used Graf's wording for id/tag business.
* Changed "soundblock" flag to "blocksound".
* Moved "repeatspecial" down with other SPAC flags.
* Ajapted removed from credits by request. (But thanks for participating!)

Share this post


Link to post

Ok, so far, so good. Is there any reason why you didn't add my other clarifications? I think they are necessary to avoid problems.

The Strife flags are unlikely to be supported by most Doom ports, I'd think, so they should be excluded from non-Strife games - at least in the default namespaces.

And the thing special remark is necessary because there are absolutely no semantics defined how thing specials are to be used with Doom format specials.
The spec contains nothing about this which I consider a serious problem that may easily cause incompatibilities.

Share this post


Link to post

There's no way to tell ahead of time how many objects a map has in it. How are you guys going about loading textmaps?

  • Parse the lump twice (once for counting, twice to do the actual work)
  • Keep calling realloc on an array
  • Store parsed objects in a linked list and make an array of pointers when you're done (for random access)
  • Something else :)
I guess it would be nice if the format could give you a hint of how many objects to pre-allocate. Like say "numlinedefs = 673;" after the namespace definition but before any object definitions.

Share this post


Link to post
RjY said:

I guess it would be nice if the format could give you a hint of how many objects to pre-allocate. Like say "numlinedefs = 673;" after the namespace definition but before any object definitions.

While I don't have any need for this myself, I can see how it could make life a little bit easier for some and I see no problems when added to the UDMF specs.

numvertices = <integer>;
numlinedefs = <integer>;
numsidedefs = <integer>;
numsectors = <integer>;
numthings = <integer>;

Share this post


Link to post

I think it is a bad idea for such formats to have some data which are depended from another data. With such fears we should save number of nodes or something for xml for example.

Share this post


Link to post
RjY said:

There's no way to tell ahead of time how many objects a map has in it. How are you guys going about loading textmaps?

  • Parse the lump twice (once for counting, twice to do the actual work)
  • Keep calling realloc on an array
  • Store parsed objects in a linked list and make an array of pointers when you're done (for random access)
  • Something else :)
I guess it would be nice if the format could give you a hint of how many objects to pre-allocate. Like say "numlinedefs = 673;" after the namespace definition but before any object definitions.



Dynamic arrays are not that hard to write. In C++ it can even be done with a simple template class and even without that, calling realloc is not that hard. I don't see a problem with it. A two-pass approach is needed anyway to resolve some references in the data.

If you want to see how it can be done, look at p_udmf.cpp in the latest ZDoom SVN source. It's not up to the latest spec yet but it is working.

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
×