Pending UDMF Revisions

esselfortium said:

On a somewhat related note, would it be possible to add a "Quantize Selection" option to DB2? ZDoom sometimes has some major difficulty rendering floating-point vertices with more than 1 or 2 digits after the decimal, and the only way to fix it is to open up the dialog to manually round each of them off from 1.671 to just 1.7 or whatever. As-is, it's rather time-consuming, and hugely diminishes the time-saving nature of the curve-line and overlapping-line-drawing functions of DB2 when working in UDMF. Such a feature would ideally allow the user to use it when vertices or things are selected, and allow them to specify the quantization amount. (0.1 units, 1, 8, 16, etc.) It'd be useful for other things in addition, so it wouldn't be just to work around that issue.

If that's true, then that is a bug in the ZDoom engine and they should fix it. If for some technical reason it simply can't support more accurate coordinates, then the engine itself should be smart enough to round the numbers when it loads the map.

Oh, UDMF already had floating-point support? If so, then I appologize for my previous posts here.

CodeImp said:

Double the processing time (except on a 64 bit CPU, but 32 bit CPUs are still the most common)

Eh? The x86 architecture has had an 80-bit hardware floating point unit since the 486 DX.

Yea you're right, I read that here also: http://stackoverflow.com/questions/417568/float-vs-double-performance
Still though, it is double the memory and that may also cost you performance (more data to copy and less optimal cache use).

CodeImp said:

Yea you're right, I read that here also: http://stackoverflow.com/questions/417568/float-vs-double-performance
Still though, it is double the memory and that may also cost you performance (more data to copy and less optimal cache use).

Alot of people have 1MB+ of cache these days, except my Pentium 3 Coppermine (SLOT 1) only has 256KB. In a dream world, my cache would fit 32k doubles.

But, performance of a more real time program is more important. Doom Builder isn't really real time, you save a map you wait and it saves.

strtod is basically

if string == "NAN"
   return NAN

else if string == "INF"
    return INF

else if string == "-INF"
    return -INF

else if string[0..2] == "0x"
{
    // same as below but in hex using p/P
}

else
{
    p = &string[2];
    q;
    while (q = *(p++))
    {
        if *q == '.'
           isfrac = true
        else if *q == '[eE]'
           isexp = true
        else if !isexp
        {
           out = ((double)*q) / div    // div is the distance from zero when a fraction, otherwise it's 1
           if isfrac
           {
               div /= 10
               result += out
           }
           else
           {
               result *= 10
               result += out
           }
        }
        else
    }   
}

Been reading the thread, and while I'm not a programmer I am a mapper (whenever I can muster the bother :D) and I like the purpose of UDMF for ease of mappers and all that jazz. However, I'd like to revisit kb1's (I think it was him and I'm too lazy to scroll up and find it again) suggestion for string id names for sectors/things/whatever. I understand that there's a problem with compatibility; however, such a ridiculously extremely goddamn useful feature seems worthy of requiring an update. I mean, it's a small sacrifice to require one more update to the format so that it can handle something like that. The previous formats should still be readable because the number would be processed as a string, right? I'm not a programmer so I have no idea if this is a feasible or easy idea or not, but I'd imagine you're just converting those numbers or possibly string ids into specific pointers anyway; who cares what they're called in the editor. I wouldn't extend this to like linedef numbers just because that would get horribly confusing and probably screws up rendering or something based on the numerical order, I don't know, but things like line ids for specials would be fine.

Also I'm still horribly confused as to why DaniJ and the Doomsday team's extra little lighting lumps and whatever can't be inserted into the format as raw data or whatever, like the format supports. Plugin for processing of it in an editor or possibly an editor just for the light stuff, who knows. And also his description of 3d editing: how is that any different from the editing available in Doom Builder? I ask that seriously and not accusingly, because Doom Builder would obviously not want to implement special rendering whatevers just for some source port's new features every time it comes out but the main 3d editor is comprehensive enough to do most things. What you have described sounds like something that could be implemented as a separate editor that could be used alongside an editor like Doom Builder or Slade, made especially for whatever lighting lumps. Oh, and I know you apologized for all the behavior and stuff and I think it includes this, but how does minor parsing load time and like 50 megs more at very max affect performance much in this day and age of at least a gig, probably more like 2-4 gigs, of RAM? I understand if you don't want to answer any of these, though.

For what we are planning for Doomsday we could use UDMF. We could even extend DB2 implementing the new editing features we need. However, that would not result in the real-time editing experience we are seeking to bring to DOOM. Furthermore, half of our user base would be left out in the cold simply because they don't use Windows. So even from an editing standpoint this is already a non-starter.

We aren't talking about a little extra data on top of the existing map format. This is something entirely different.

DaniJ said:

Furthermore, half of our user base would be left out in the cold simply because they don't use Windows.

Slade 3 is cross-platform. (Even though at the moment it has no level editor; it will eventually have one and it will support UDMF.)

Also, Doom Builder 2 is open source, so I guess it could be ported? I don't really know anything about it, though I think it uses Microsoft Visual C++ so that would be quite a project. Real time editing, do you mean like a Cube style thing?

ler said:

Also, Doom Builder 2 is open source, so I guess it could be ported?

It could, but there would be a lot of work needed to achieve that. Part of the problem here is reliance on the .NET architecture, which is not cross-platform. Some people have tried using Mono, its free software clone, but it didn't work: either they couldn't get DB2 to run at all, or it ran but did not function (e.g., a blank window instead of the 2D/3D view window) because many functionalities are missing from it.

Gez said:

Part of the problem here is reliance on the .NET architecture, which is not cross-platform.

Actually, that is not the problem at all. The .NET framework is very "cross-platform" (is that a state?) as long as you don't use anything from the Microsoft.Windows extension. Unfortunately DB2 uses Microsoft Windows stuff and also DirectX, so those are the hard part. I have successfully written a complete game server (console application, doesn't use Microsoft.Windows) that runs both on Windows and on Linux using Mono.

DaniJ said:

For what we are planning for Doomsday we could use UDMF. We could even extend DB2 implementing the new editing features we need. However, that would not result in the real-time editing experience we are seeking to bring to DOOM.

Real-time editing does sound incredibly bad-ass. It's great to be able to edit in 3-d mode, but editing in-game truly is the "real thing". Looking forward to see how it turns out - good luck!

BIG BIG BUMP!

Some questions:

1. Did UDMF v1.2 ever happen, or are we still at UDMF v1.1?
2. Similar: What's the latest version of UDMF?
3. What changed (do I need to support v1.0, etc?)
4. What's the total list of namespaces that have been defined, and/or reserved?
5. Is there a document describing each of these?
6. Is there a link where I can find the latest docs?
7. In reading udmf11.txt, namespaces "Doom", "Heretic", "Hexen", and "Strife" were mentioned, but also "ZDoom".

• Isn't that a conflict of interest: GameType vs. Engine?
• Cause ZDoom can handle a Doom map, Heretic map, etc.
• What would namespace "ZDoom" mean? Is it an abbreviation for "ZDoom w/Hexen specials"?
• Is there a "ZDoom w/Doom specials" namespace, or would that just be "Doom"?

I apologize in advance for my ignorance in these matters.

Some answers:

1.: AFAIK it never happened and it only was some minor clarification.

2. 1.1 for non-ZDoom. Since these namespaces operate on a fixed feature set there was no need to.

3. You do not need to support 1.0.

4. Aside from the base namespaces, ZDoom defines "ZDoom" and "ZDoomTranslated". Vavoom also defined its own one but this was never used for anything.

5. All relevant specs can be found in the ZDoom repo in the specs directory.

6. See 5.

7. The namespace does not specify the game but the feature set. You can well make a "Doom" map for Heretic if the underlying engine supports using Doom linedef types when playing Heretic.

Namespace "ZDoom" means using Hexen specials, namespace "ZDoomTranslated" means using Doom-type specials which are run through an XLAT lump. "ZDoomTranslated" adds most "ZDoom" features so it's not the same as "Doom".

I also made a draft for a "ZDEE" namespace for common ZDoom/Eternity features but so far not much happened with that. Still waiting for the Eternity team to do something with it.

Zdee is a funny name. The idea is nice, though I'd focus more on enhancing EE with original features, so there's less time for me with stuff like that. But maybe the other guys can.

15 hours ago, Graf Zahl said:

Some answers:

 

1.: AFAIK it never happened and it only was some minor clarification.

2. 1.1 for non-ZDoom. Since these namespaces operate on a fixed feature set there was no need to.

3. You do not need to support 1.0.

4. Aside from the base namespaces, ZDoom defines "ZDoom" and "ZDoomTranslated". Vavoom also defined its own one but this was never used for anything.

5. All relevant specs can be found in the ZDoom repo in the specs directory.

6. See 5.

7. The namespace does not specify the game but the feature set. You can well make a "Doom" map for Heretic if the underlying engine supports using Doom linedef types when playing Heretic.

Namespace "ZDoom" means using Hexen specials, namespace "ZDoomTranslated" means using Doom-type specials which are run through an XLAT lump. "ZDoomTranslated" adds most "ZDoom" features so it's not the same as "Doom".

 

I also made a draft for a "ZDEE" namespace for common ZDoom/Eternity features but so far not much happened with that. Still waiting for the Eternity team to do something with it.

On #7, can you make a Heretic namespace UDMF file, that uses Heretic linedefs/sector types/things? In ZDoom, you'd just translate the Heretic map internally. But, how does ZDoom know that it needs to translate this UDMF map from Heretic linedefs to Doom linedefs, or Hexen linedefs? There must be a "Heretic" identifier *somewhere*, right? Or, is it based on having loaded HERETIC.WAD? Or do people just not make UDMF Heretic maps?

2 minutes ago, kb1 said:

There must be a "Heretic" identifier *somewhere*, right? Or, is it based on having loaded HERETIC.WAD? Or do people just not make UDMF Heretic maps?

The default XLAT used is based on the game being played; it can be "Doom", "Heretic", or "Strife". In the rather unlikely case someone made a Doom-format map for Hexen, it'd use the Heretic XLAT (several Hexen actors couldn't work at all, but that's besides the point); pretty much every other game out there (Chex Quest, Hacx, and so on) uses Doom.

With MAPINFO you can override the default XLAT. This was used notably by the Hacx 2.0 project, which had its own custom set of translation, though they're probably going to move to UDMF now that EE officially supports it.

The UDMF base namespaces have hard coded translation lumps but there are no provisions to prevent them from getting loaded in case of game mismatch.

21 hours ago, Gez said:

The default XLAT used is based on the game being played; it can be "Doom", "Heretic", or "Strife". In the rather unlikely case someone made a Doom-format map for Hexen, it'd use the Heretic XLAT (several Hexen actors couldn't work at all, but that's besides the point); pretty much every other game out there (Chex Quest, Hacx, and so on) uses Doom.

 

With MAPINFO you can override the default XLAT. This was used notably by the Hacx 2.0 project, which had its own custom set of translation, though they're probably going to move to UDMF now that EE officially supports it.

5 hours ago, Graf Zahl said:

The UDMF base namespaces have hard coded translation lumps but there are no provisions to prevent them from getting loaded in case of game mismatch.

 

Please bear with me:

1. @Gez, you say the default XLAT is based on the game being played...meaning which IWAD is loaded, correct?
2. @Gez, you said "With MAPINFO you can override the default XLAT." By defining a different XLAT lump?
3. @Graf Zahl, regarding "game mismatch": You mean if the wrong IWAD is loaded here?

I am basically trying to understand *exactly*, for a given UDMF map that specifies "Line Type 123", how ZDoom knows that this is a teleport vs. a door (I just made those up).

Thanks.

There are a few possibly situations. Let's look at them separately.

• Loading a map in Doom format: use game's default translation, unless MAPINFO says otherwise.
• Loading a map in Hexen format: no translation
• Loading a map in UDMF, Doom namespace: use Doom translation (it's the Doom namespace)
• Loading a map in UDMF, Heretic namespace: use Heretic translation (it's the Heretic namespace)
• Loading a map in UDMF, Hexen namespace: no translation
• Loading a map in UDMF, Strife namespace: use Strife translation (it's the Strife namespace)
• Loading a map in UDMF, ZDoom namespace: no translation
• Loading a map in UDMF, ZDoomTranslated namespace: use game's default translation, unless MAPINFO says otherwise.
• Loading a map in UDMF, Vavoom namespace: no translation (pretend it's the ZDoom namespace)
• Loading a map in UDMF, other namespace: not currently handled AFAIK

https://zdoom.org/wiki/Map_translator

Clarification is a beautiful thing. Thanks for the detailed answer - it makes all the difference.

Gez is missing one important bit:

UDMF's base namespaces completely disable all line and sector special types which are not part of the original game, or Boom/MBF for Doom. So the Hexen namespace will not support any ZDoom special placed on the map - in scripts it will not block them because that would break gameplay mods.

15 hours ago, Graf Zahl said:

Gez is missing one important bit:

 

UDMF's base namespaces completely disable all line and sector special types which are not part of the original game, or Boom/MBF for Doom. So the Hexen namespace will not support any ZDoom special placed on the map - in scripts it will not block them because that would break gameplay mods.

 

Thanks - good to know.