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

UDMF v0.99 Specification Draft (aka TEXTMAP)

Recommended Posts

I wanna say congratulations to quasar and a big "die in a fire" to all hataz that may/may not post in the future

Also, hooray for floating point precision! Doom needed that for the longest.

Share this post


Link to post
CodeImp said:

I could use doubles which is slow or fixed point which is troublesome to code.

Sheesh, people have GHZ speed computers now.
Computers almost powerful enough to run Vista :)
Use doubles.

Share this post


Link to post
Ajapted said:

Sheesh, people have GHZ speed computers now.
Computers almost powerful enough to run Vista :)
Use doubles.

Doom Builder and Slade can already get pretty slow when working on maps with tons of data; I think anything that could lessen the speed loss from the added precision would be worthwhile. :\

Share this post


Link to post

Unless you set the FPU to single precision mode, all your floats are going to be converted to doubles when they get loaded into registers, so the only thing you save by using floats is space, not time. (Caveat: Direct3D normally sets the FPU to single precision mode unless you tell it not to. Is DB2 using D3D or OpenGL for 3D mode?)

Share this post


Link to post

Ajapted said:
Sheesh, people have GHZ speed computers now.

But Doom still runs on a 386/33 with 8MB of RAM. ;-)

Okay, maybe the ports that will support TEXTMAP won't, and I hope no one's still editing for Doom on a 386...

Share this post


Link to post

I'd say use doubles. I'm pretty sure (at least in SLADE's case) it wouldn't slow things down too much. The slowness on big maps is more likely to do with other things. Not to mention if you're editing really large maps on a modern editor you'd want a decently powerful machine anyway.

Share this post


Link to post
SlayeR said:

I'd say use doubles. I'm pretty sure (at least in SLADE's case) it wouldn't slow things down too much. The slowness on big maps is more likely to do with other things. Not to mention if you're editing really large maps on a modern editor you'd want a decently powerful machine anyway.

Slade 2 is sloooowww on my dual-core 2ghz with 1gb of ram on a map with around 20,000 sidedefs. Pasting a texture in 3D mode takes like a second and a half :(

Share this post


Link to post
esselfortium said:

Slade 2 is sloooowww on my dual-core 2ghz with 1gb of ram on a map with around 20,000 sidedefs. Pasting a texture in 3D mode takes like a second and a half :(

That's the horrible brute-force unoptimized undo system in action :P

Share this post


Link to post
Ajapted said:

Sheesh, people have GHZ speed computers now.
Computers almost powerful enough to run Vista :)
Use doubles.



Indeed. Worrying about microseconds when using an interpreted language for development seems to be a bit odd. So even if there is a performance loss of maybe 1%, who cares? It's not like when using doubles the performance breaks down. In real world applications you won't really notice any difference. For that you'd need code that makes heaviest use of complex mathematical operations.

As for D3D, that's simply annoying that it feels the need to force such a setting by default for absolutely questionable performance improvement. ZDoom uses D3D and had to disable this behavior because other code needs the added precision. The overall performance impact of this which I tested in GZDoom was precisely - Zero! It was completely irrelevant in relation to the rest of the program.

Share this post


Link to post

SlayeR is right though, I experience the same problem that the slowdowns are caused by the complex procedures that work with the map structure (like stitching geometry together), not because of the mathematical weight. I might get away with doubles without too much of a performance loss.

Share this post


Link to post

There's one important point that is unclear in the new spec:

How does it handle Doom-format linedef specials. Are they to be translated 1:1 (including activation) or do the activation bits still apply? Obviously for straight conversions of existing maps the activation type needs to be implicit and the spec states it uses the line id value as tag. Am I seeing this correctly?

Also, will mixed format maps be allowed and if yes, how are they to be detected?

Share this post


Link to post

As for precision, only double really makes sense IMO because the best function for reading floating point values from text files in C is strtod - string to double, which is going to return a double. If the implementing port wants to cast off the extra precision that it does not use to store the values, that is its choice I guess. As for the editor util it may as well use full precision.

In Eternity, all the different game map formats are read in and then translated to an internal unified format that can use the specials from any game. This sort of approach was necessitated by ExtraData, so that maps could continue to use Doom specials but also have access to the parameterized Hexen-compatible line types.

In EE, the default translation mode for a map is determined by the gamemode. So a map with no explicitly defined translation being played in Heretic will have the Heretic compatibility translation applied to it. If however the MapInfo for the map states it is a DOOM-type map, no translation occurs - and if the map was not designed using the Doom in Eternity configuration, there will be errors, such as the wrong line types, wrong sector types, and wrong monsters appearing.

As for the UDMF, I am not exactly certain what needs to be done. Although it seems to me that the problem could be addressed by having a "translation" specifier, much like the "port" specifier. So each port could support any number of translations. A UDMF map for Eternity with translation = Heretic would have Heretic's native line special numbers, thing numbers, etc. This is not an ideal solution, but the only IDEAL solution would be if we were to sit down and somehow agree upon unified tables or ranges of special/type #'s.

IMO, that sort of compromise is not even possible from a technical point of view, due to the code changes or massive conversion-lookup tables it would require in each implementing port. I think the simplest solution that works is the translation idea. If the only translation that ZDoom wants to support is ZDoom/Hexen, then there is no problem with that. It can just apply that translation regardless of whatever the translation flag says (perhaps print a warning in the console if it is not the expected value...)

Share this post


Link to post

Didn't we agree on a 'namespace' field (string) which tells the sourceport how to interpret the specials/actions? The namespace field could be set to 'doom', 'heretic', 'hexen' or 'strife' or whatever game the map is for. The specification must state the possible values ofcourse.

Share this post


Link to post
Quasar said:

In EE, the default translation mode for a map is determined by the gamemode. So a map with no explicitly defined translation being played in Heretic will have the Heretic compatibility translation applied to it. If however the MapInfo for the map states it is a DOOM-type map, no translation occurs - and if the map was not designed using the Doom in Eternity configuration, there will be errors, such as the wrong line types, wrong sector types, and wrong monsters appearing.

As for the UDMF, I am not exactly certain what needs to be done. Although it seems to me that the problem could be addressed by having a "translation" specifier, much like the "port" specifier. So each port could support any number of translations. A UDMF map for Eternity with translation = Heretic would have Heretic's native line special numbers, thing numbers, etc. This is not an ideal solution, but the only IDEAL solution would be if we were to sit down and somehow agree upon unified tables or ranges of special/type #'s.


All that is clear and the translation part is no big deal for ZDoom because translation tables already exist. So Maps with Doom format specials will be supported by ZDoom. I recently have invested some work to make this feature more customizable so that PWADs can add to or replace the translation tables through MAPINFO and I'd like to keep it this way if possible to avoid complicating matters when reading a map.

My questions regards the following issue:

If a Doom-type special is used, how are the trigger flags and args to be treated? If it is agreed that the specials are translated 1:1 it would mean that the type defines the trigger and the args are ignored unless used for something else, right?


CodeImp said:

Didn't we agree on a 'namespace' field (string) which tells the sourceport how to interpret the specials/actions? The namespace field could be set to 'doom', 'heretic', 'hexen' or 'strife' or whatever game the map is for. The specification must state the possible values ofcourse.


The Namespace field should contain the port and if necessary some additional information. For ZDoom I defined 2 namespaces:

- 'ZDoomTranslated' for maps with Doom format specials that will be run through the translator to map both sector and line specials to the internal values. Translation will always depend on the game or a user defined custom translator.
- 'ZDoom' for maps with Hexen format specials.

Aside from the linedef and sector special handling the feature set will be identical. So far I haven't defined anything though.

If I ever decide to add support for other ports' namespaces they will have to meet one minimum criteria: No mixture of Doom and Hexen format specials in the same map because this one will get messy. For everything else a new translator could be defined as long as there aren't too many unsupported features.

Share this post


Link to post

Oh yes ofcourse, the game is defined by the IWAD chosen by the user and the map author writes the intended game in the text file, duh! it has always been that way.

Graf Zahl said:

If I ever decide to add support for other ports' namespaces they will have to meet one minimum criteria: No mixture of Doom and Hexen format specials in the same map because this one will get messy.

Yea well ofcourse, a map is made for a specific game, so it uses one set of specials. I was thinking with my ass again :P

Share this post


Link to post

I'm not sure if we've come to an agreement on this or not, as the discussion is getting sort of vague.

Are we in agreement that maps should or at least can specify the type of translation to apply to them? From EE's point of view it is not at all clear simply from the gamemode. Due to aliasing, for example some Heretic specials conflict with those defined by BOOM, it's not sufficient to just confine all Heretic maps to using Heretic's native specials and type numbers.

If you want to use full EE support and have all BOOM/MBF/SMMU/EE features, as well as Heretic ones, then you'd have to use EE's native numbers, which btw do expose both DOOM and Hexen type specials at the same time, but not with the usual numbers.

There is no way for EE to tell this from the map alone unless it declares the type of editing configuration it was created with. I do have the ability for MapInfo to determine this, but requiring MapInfo would be better avoided by providing that info in the map itself. Since Doom Builder will have different configurations for each translation (Heretic UDMF vs Eternity UDMF), there's no reason such info couldn't be stored there and written to the map.

For example, parameterized Door line types are 300 to 305 IIRC. When Hexen maps are loaded, their specials are translated into EE's. In EE, SPAC flags only apply to parameterized line specials, and as Graf assumed, the trigger data for DOOM-style specials is implicit and thus the SPAC flags, if given, are ignored for those. EE's "extflags" are explained in the documents as only working for parameterized line specials.

EDIT:
Idea! Instead of a dual port/translation system, which is redundant and messy, we could simply have reserved port values for each of the original games - Doom, Heretic, Hexen, Strife. If a map declares such an original executable as its target port, then the line/sector specials and thing types are what you would expect from a normal binary map for that port.

This makes a lot more sense and is much simpler.

Share this post


Link to post
Quasar said:

I'm not sure if we've come to an agreement on this or not, as the discussion is getting sort of vague.

Are we in agreement that maps should or at least can specify the type of translation to apply to them? From EE's point of view it is not at all clear simply from the gamemode. Due to aliasing, for example some Heretic specials conflict with those defined by BOOM, it's not sufficient to just confine all Heretic maps to using Heretic's native specials and type numbers.

If you want to use full EE support and have all BOOM/MBF/SMMU/EE features, as well as Heretic ones, then you'd have to use EE's native numbers, which btw do expose both DOOM and Hexen type specials at the same time, but not with the usual numbers.


I know and that's why I was asking. I can tell you right now that ZDoom will not allow such a mix because I see no point in doing it considering that internally everything is translated to Hexen specials anyway.

Also, since this would require the editor to have full support for both types of specials at the same time which can be the larger obstacle unless some compromises are made.


There is no way for EE to tell this from the map alone unless it declares the type of editing configuration it was created with. I do have the ability for MapInfo to determine this, but requiring MapInfo would be better avoided by providing that info in the map itself. Since Doom Builder will have different configurations for each translation (Heretic UDMF vs Eternity UDMF), there's no reason such info couldn't be stored there and written to the map.


Different translators shouldn't be a problem. ZDoom currently defines them in MAPINFO. I wouldn't want to put this information into the namespace field to keep things simple because otherwise it's be too much of a hassle to distinguish between maps for the different ports if each one was having 5 or more namespaces for different configuration settings. I defined 2 namespaces for ZDoom and I want to keep it that way so that namespace 'ZDoom' always uses untranslated specials and namespace 'ZDoomTranslated' can use any translation table that exists.


For example, parameterized Door line types are 300 to 305 IIRC. When Hexen maps are loaded, their specials are translated into EE's. In EE, SPAC flags only apply to parameterized line specials, and as Graf assumed, the trigger data for DOOM-style specials is implicit and thus the SPAC flags, if given, are ignored for those. EE's "extflags" are explained in the documents as only working for parameterized line specials.
[b]


Ok, then this one is out of the way. Good.

[b]
EDIT:
Idea! Instead of a dual port/translation system, which is redundant and messy, we could simply have reserved port values for each of the original games - Doom, Heretic, Hexen, Strife. If a map declares such an original executable as its target port, then the line/sector specials and thing types are what you would expect from a normal binary map for that port.

This makes a lot more sense and is much simpler.


Let's just say that each namespace may define a set of global map properties. Then you can do what you want in the 'Eternity' namespace. For me this isn't a big consideration because ZDoom's native format is Hexen so any support for Doom-format specials is only there to load maps for other ports and to allow conversion of older maps to text format without reassigning the existing specials. Any new mapping for ZDoom should use Hexen format specials.

To be honest, I would have chosen not to support Doom format specials at all but that would mean that ZDoom would be unable to load any map not made for it which is of course even less desirable.

I think that most of this is academic anyway because how it can be used mostly depends on the editors. After all they have to implement a mechanism to make the various specials accessible to the mapper and the more complicated it gets the less likely it is to be supported.

------------------------------------------------

There's one other important thing:

Since I did some testing with a parser I think the spec needs to be slightly revised:

- The 'namespace' command (and all eventually associated global properties) *MUST* be the first information in a map because without it it is not possible to parse the namespace dependent information properly. The definition as it stands makes that very hard or even impossible and if allowed to stand as you defined it (the last 'namespace' found in the map defines what to do) would make it rather problematic for me. There also should only be one 'namespace' command allowed. Allowing to switch namespaces is a needless complication so any such option is absolutely counterproductive.

Share this post


Link to post
Graf Zahl said:

I think that most of this is academic anyway because how it can be used mostly depends on the editors. After all they have to implement a mechanism to make the various specials accessible to the mapper and the more complicated it gets the less likely it is to be supported.



This is an example ofcourse. The texture offset fields and brightness won't be in there because the editor has native support for them. This tab page is only for the fields that the editor has no other editing mechanism for.

The browse button on the far right of the selection changes to show an appropriate browser for the type (the types are more than what is specified in UDMF standard, a string can be a texture or flat or just a string).

Fields supported by the engine are defined in the game configuration with their appropriate type and default value (those cannot be removed and when default they are grey). Adding custom fields is possible also (so make sure you make some ACS functions to read fields from map elements!).

With the plugin system, programmers can also make plugins that extend the editor with editing mechanisms that control these fields. Think, for example, of a 2D sectors mode that shows the colors of the lighting of each sector.

Acceptable? :P

Graf Zahl said:

The 'namespace' command (and all eventually associated global properties) *MUST* be the first information in a map because without it it is not possible to parse the namespace dependent information properly. The definition as it stands makes that very hard or even impossible and if allowed to stand as you defined it (the last 'namespace' found in the map defines what to do) would make it rather problematic for me. There also should only be one 'namespace' command allowed. Allowing to switch namespaces is a needless complication so any such option is absolutely counterproductive.

I agree that there should be only one. But you could just parse it before interpreting the line/sector specials and then it doesn't matter where the field is located.

Share this post


Link to post
CodeImp said:

This is an example ofcourse. The texture offset fields and brightness won't be in there because the editor has native support for them. This tab page is only for the fields that the editor has no other editing mechanism for.

The browse button on the far right of the selection changes to show an appropriate browser for the type (the types are more than what is specified in UDMF standard, a string can be a texture or flat or just a string).

Fields supported by the engine are defined in the game configuration with their appropriate type and default value (those cannot be removed and when default they are grey). Adding custom fields is possible also (so make sure you make some ACS functions to read fields from map elements!).

With the plugin system, programmers can also make plugins that extend the editor with editing mechanisms that control these fields. Think, for example, of a 2D sectors mode that shows the colors of the lighting of each sector.

Acceptable? :P


This looks good but doesn't really address my concern about mixing Hexen and Doom style specials in the same map. If you can do it, the better.


I agree that there should be only one. But you could just parse it before interpreting the line/sector specials and then it doesn't matter where the field is located.


If the namespace field is not the first thing in the map I'd have to cache every single bit of information that may depend on it. For my current 2 namespaces it's exactly one value in the linedef, thing and sector field so it's not a problem yet. But who knows what else will depend on it later? Maybe some things will be implemented that require more intelligent handling?
Knowing beforehand what to do certainly makes things easier so forcing this information to the top of the data will make implementation of a compliant parser much, much simpler.

Share this post


Link to post
Graf Zahl said:

This looks good but doesn't really address my concern about mixing Hexen and Doom style specials in the same map. If you can do it, the better.

No, that would be a bit messy in my code I think. But this doesn't really sound very important. If there is anything you cannot do with Hexen specials, it is much easier to make a special that does that.

Share this post


Link to post

I think that communication is breaking down because my points just aren't getting through in a concise manner. Let me try to boil down what the real issues are here, and what are not issues:

Actual issues:

Various games define conflicting specials and thing type numbers. If the interpretation of these numbers is confined strictly to being determined by the IWAD in use, then it is impossible to present a unified set of such numbers. If, on the other hand, interpretation of the numbers is confined strictly to the unified set defined independently by each implementing port, then the following things become *impossible*:

1. Translating a binary map for the vanilla game engine (Doom, Heretic, Hexen, or Strife) into UDMF format and allowing it to be understood by ALL UDMF implementing source ports. Emphasis put on the important part.

2. Allowing editors to edit maps using the native set of line specials, thing type numbers, etc. that they have been accustomed to using for almost 15 years. I don't think the value of the availability of this 1:1 correspondence to the end user could be underestimated.

Some Examples:
A Doom Barrel is expected to be DoomEdNum 2035. However, in Heretic, the Pod is DoomEdNum 2035. Which should have precedence in a map that expects all defined object classes to be available? In EE, under a map marked as being untranslated (ie, the unified namespace), DoomBarrel wins, having 2035. But the Pod pays, getting translated to 7235.

In Heretic, sector type 15 is ice. In Strife, sector type 15 is instant death sector. In Doom, sector type 15 does nothing. In a unified space for a given port, each will be different. But no ports have ever agreed on how to disambiguate this stuff, so point 1 comes into play heavily here. It may be tempting to each of us to tell the other "do it my way," but we're going to get nowhere if we adapt that mentality.

We more or less implicitly agreed not to do such when we declined to standardize such line/sector/thing types.

Declaring that Doom and Hexen style specials cannot be intermixed by any port is actually a gigantic breach of this principle, in effect, because the absolute only difference between the two, and one that an editor can ignore entirely, is that one doesn't make use of any SPAC or args values that have been specified on the linedef.

Non-Issues:

Contrary to what you have stated, Graf, this should have absolutely no effect on the editor. The only thing the editor has to do is put a special number in the special field. It does not have to understand the semantics of that special. It doesn't have to disable the ability to set SPAC flags or args on such a line - nay, in fact, maybe the implementing port actually has uses for them in that case (EE does not, but it wouldn't stop somebody else).

Either special numbers have to be ENTIRELY defined by the implementing ports, or entirely defined by the standard. We decided, rightly I feel, that demanding implementation details is wrong. Let us stick to that now in finalizing the standard.

EE allowing intermixed special styles should not have any effect on ZDoom, unless ZDoom is intending to add support for Eternity maps, in which case the onus falls upon you or Randy to account for the differences in implementation between our two ports. Just as I have taken account of certain ZDoom implementation details as I have been implementing Hexen map format support. I do not think that it should be expected to be technically feasible for either of us to ever fully support the others' maps.

But the entire idea behind specifying the target port (be it one of the original EXEs or a newer one - the two are quite the same when you think about it) - is so that these differences can be understood and accounted for automatically.

As a thought experiment, let us say that someone is by mistake loading an Eternity map under ZDoom. Which is the better outcome?

1. The map attempts to load, and crashes the game.
2. The map loads silently without error message, and does not work.
3. The map loads with error messages, and does not work.
4. The map loads with error messages, and works partially.
5. The map loads and works perfectly.

Here are the necessary conditions for each:

1. UDMF does not specify target port. Incorrect interpretation of special numbers caused by assuming the host port's translation of such results in destabilizing the program. Quite possible even now with the binary map format.
2. UDMF does not specify target port, but the map just happens to not be able to crash the game, probably because the host port is well coded. Still, this is unfortunate.
3. UDMF specifies the target port. The host port does not implement a translation for the target port, but it CAN now let the user know they are not going to get what they expect. It is an improvement.
4. UDMF specifies the target port. The host port implements partial support for the target port's translation. Not mandatory for any port to do, but a good way to expand the scope of the program and move toward the elusive goal of cross-port map compatibility.
5. UMDF specifies the target port, and the host port has taken the trouble to use this vital information to fully translate the map into information that it understands. Again not mandatory. Again good.

The point is that the 3 GOOD options *require* the translation information to be stored in the UDMF map. Without it, we have actually made extremely little progress by defining this format :)

Share this post


Link to post
Quasar said:

Various games define conflicting specials and thing type numbers. If the interpretation of these numbers is confined strictly to being determined by the IWAD in use, then it is impossible to present a unified set of such numbers. If, on the other hand, interpretation of the numbers is confined strictly to the unified set defined independently by each implementing port, then the following things become *impossible*:

1. Translating a binary map for the vanilla game engine (Doom, Heretic, Hexen, or Strife) into UDMF format and allowing it to be understood by ALL UDMF implementing source ports. Emphasis put on the important part.

2. Allowing editors to edit maps using the native set of line specials, thing type numbers, etc. that they have been accustomed to using for almost 15 years. I don't think the value of the availability of this 1:1 correspondence to the end user could be underestimated.


To be honest all these ideas of mixing specials and whatnot is getting a bit confusing to me. Why don't we just keep it as it is? How to interpret the specials depends on the IWAD chosen. It has always worked fine that way. And it does not limit the sourceports in making new specials.

Share this post


Link to post

After reading through your lengthy post, here's my opinions about it:

- If you are concerned about base specs for each game's default configuration they will have to be defined in the specs. If the specs stay vague about this we will never come to a proper agreement because inevitably some people will deviate from it because 'they like it better that way'.

- Mixing features from different games should be defined per namespace. If this is important to you, you have to define your own namespace properly so that if other ports choose to implement it they get the necessary information. This is not a big concern to me because ZDoom does not allow such mixing unless you use supplementary engine features like DECORATE or custom linedef/sector translation tables.

- Your outline of how Eternity supports Heretic and Hexen things (meaning different editor numbers) plain and simply means that such maps will not be supported by ZDoom unless someone defines a DECORATE file that contains a proper mapping. The larger the translation tables get to support another port's map the less likely it will be implemented. Much better would be an additional GameFilter property that specifies from which game a specific item is to come from. This can be translated by any port with very little overhead.

One partcular point:

It may be tempting to each of us to tell the other "do it my way," but we're going to get nowhere if we adapt that mentality.


In general I'd say whoever came first wins. Intentionally implementing a feature differently than an existing reference unless there's a very good reason to do so strikes me as incredibly shortsighted and if this causes problems for you later on - well, you have been warned. ;)
In any case, I'm not bothered with Eternity compatibility. It's so different in so many ways that I really see no point to make maps work beyond the necessary minimum.
The base configs for the different games are another matter though.

Share this post


Link to post
CodeImp said:

To be honest all these ideas of mixing specials and whatnot is getting a bit confusing to me. Why don't we just keep it as it is? How to interpret the specials depends on the IWAD chosen. It has always worked fine that way. And it does not limit the sourceports in making new specials.



Heh... ;)

You are probably correct. Although for me it's really not an issue because ZDoom's translation tables can be overridden. :)

And let's be honest about one thing: Most of Quasar's issues are quite specific to Eternity (e.g. special thing numbers for Heretic items) so there is absolutely no point of worrying about them as part of the spec. As long as he defines his Eternity namespace properly it should all be fine - except, of course, for the high likelihood that other implementations won't support Eternity maps at all or only in a limited fashion.
I have set up my 2 namespaces for ZDoom and defined how they work and I see no need to change it.

Share this post


Link to post

Hello guys, nice to see something like that coming.

Some remarks from a retired doomer.

Q, isn't this special thingy issue linked to the fact you still use numbers, which are implementation dependent (heck, most ports actually translate them) ?

Since you have a text format, why stick to numbers ? Instead of "15" just put "ice" or "instant_death". All it takes is one hashmap per game type at loading side to translate into correct numbers/flags/whatever the implementation chooses to represent them with.

Of course, it may get a bit more tricky for BOOM generalized specials, but, then again, a notation like "special1 | special2 | special3 |..." could do the trick.

Also, I noted a lot of flags in the format that basically are all false by default. Why not a notation like "flags = blocking | passuse | secret" ?

And regarding line specials, why the "twosided" flag ? Isn't this implicitly determined by the backside value ?

Anyway, nice to see all these source ports & editors brains thinking together :)

Share this post


Link to post
Julian Now said:

And regarding line specials, why the "twosided" flag ? Isn't this implicitly determined by the backside value ?

No there is some special effect (I don't remember what) to leaving that flag clear on a linedef with two sides.

Share this post


Link to post

For me the overriding issue on whether the vanilla exe's should be available as standard target ports is point #1 in my above post.

Just think of it this way.

Let's call the old binary map format "JPG".
Let's call UDMF "PNG".

Let's suppose that all JPGs cannot be converted to PNGs, or that if you do convert them, not all paint programs can read them. This is due to each program having a different idea of what constitutes a PNG.

Without defining these standard target ports, this is exactly the sort of situation we'll face. Since each port has a different idea of how to unify namespaces, unless you also support translating the original special sets, then it won't be possible to, for example, load UAC_DEAD.WAD, save it in UDMF format, and have the resulting file be just as universally usable as the original was. If the only available target ports were ZDoom or Eternity, it would by necessity contain different special numbers :) If it is "Doom" on the other hand, then we may both use our already-existing code for "Doom" gamemode maps to load it.

And you are right, Graf, that what those standardized targets mean should be a subject of standardization. However, since the standard would consist of a simple copy of a good editor's configuration file for each game, I am not likely to spell that all out on my own. I'd rather copy Doom Builder's vanilla configs and say that they represent what is meant by the standard.

BTW, can we agree that the standard for Doom should include BOOM specials, or do we have to make BOOM a separate target? I can't see any advantage to that, as the two are strictly non-conflicting, and the only difference is that BOOM defines values that are undefined under Doom. If a supporting port didn't support BOOM, it would just do with such specials the same thing Doom always did. Ignore them or throw an error (ignoring being preferable obviously).

Share this post


Link to post
Julian Now said:

Hello guys, nice to see something like that coming.

Some remarks from a retired doomer.

Q, isn't this special thingy issue linked to the fact you still use numbers, which are implementation dependent (heck, most ports actually translate them) ?

Since you have a text format, why stick to numbers ? Instead of "15" just put "ice" or "instant_death". All it takes is one hashmap per game type at loading side to translate into correct numbers/flags/whatever the implementation chooses to represent them with.

Of course, it may get a bit more tricky for BOOM generalized specials, but, then again, a notation like "special1 | special2 | special3 |..." could do the trick.

Also, I noted a lot of flags in the format that basically are all false by default. Why not a notation like "flags = blocking | passuse | secret" ?

And regarding line specials, why the "twosided" flag ? Isn't this implicitly determined by the backside value ?

Anyway, nice to see all these source ports & editors brains thinking together :)


Sorry to double post but I need to answer these things.

The special number problem is related in part to using numbers. Since it has been decided that getting every port to agree on a standardized set of names for specials, types, and flags is impossible, it is necessary to instead come to a compromise, in which we have standard spaces, and each port gets its own private playground as well. This keeps the format universal, but not necessarily the interpretation of the data held in it.

BEX Flags syntax was rejected as part of the earlier specification process. It was decided that parsing it was too complicated for some implementations to handle, and that separating the flags into separate fields is better, even if it results in a larger file size, which the spec considers a non-issue due to the availability of large hard drives, file compression, and broadband internet connections.

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
×