UDMF common namespace, first draft

[Graf Zahl]

Let's do this here, the other thread has already become a bit unwieldy.

Here's the first draft for a common namespace, I went through ZDoom's and removed everything that was marked 'not supported' by EE.

Once I've gotten some feedback I'll create a repo at Github for it and will give all EE devs commit access so that you can add new features as they become available.

http://pastebin.com/DQay4iiy

The ACS section needs some input. While I was able to check the function list, I couldn't get much else out the ACS VM's code, so you'll have to fill in the missing pieces.

[printz]

Neat-o. I should also take some time to write the UDMF Eternity text file, if not for anything else but for visibility, so that users trust that it exists in the current form.

EDIT: there's no WRAPMIDTEX in Eternity yet. Only CLIPMIDTEX.

[Altazimuth]

Thanks for getting this spec done so quickly, it's really appreciated.

Graf Zahl said:

While I was able to check the function list, I couldn't get much else out the ACS VM's code, so you'll have to fill in the missing pieces.

What pieces to do need to be filled in for the purposes of this spec? I feel I'm missing part of the big-picture here.

[Graf Zahl]

The spec needs to document which ACS features are supported and which are not. I couldn't do that because I was unable to find out which PCodes map to some other operation than a function. All I could do was to list the functions that get handled but some codes are for more complex things where several codes work in conjunction. To check these parts I need a few pointers where to look.

[printz]

Graf Zahl said:

The spec needs to document which ACS features are supported and which are not.

Problem is that those common "features" (do you mean functions?) may keep growing, on both sides.

[Graf Zahl]

Surely. But for now we need a baseline so that modders can work with it. You don't want as much as me that mappers use stuff that doesn't work because they don't know, do you?

I think best would be two lists: One with supported features and one with planned features so they can be ticked off when done and integrated into the spec.

Like I said, my main issue is simply that from the implementation I haven't found out yet which PCodes work and which don't. For functions it's easy but for 'internal features' I need something to check.

[DavidPH]

All of the PCodes with a translation work. All of the not-commented translations and all of the ranges noted as "ACSVM internal codes" here are translated.

As for ACS functions which result in multiple instructions: Eternity does not implement CreateTranslation or HudMessage, but should have all of the other printing functions (Print, Log, StrParam, etc.). It does not implement the k: print specifier and the l: specifier just prints the input string. All other print specifiers should be implemented.

And since you were asking earlier where the translation actually happens, that would be in Tracer.cpp.

[Graf Zahl]

Out of curiosity, why did you do it in such a fashion instead of just running the code as-is?

[DavidPH]

Doing a translator on the code allows for the interpreter to be structured to be more maintainable. The core interpreter loop itself can contain only the generic computational instructions, making it smaller. Which aside from making it a less daunting function, also potentially helps with cache coherence (not sure, though, as it does still have to call out for array accesses, so it may be a wash in that respect). Doing callfuncs as function pointers is half because ACSVM is a separately developed library and half because being able to distribute those function definitions across multiple files is a useful organizational tool. (Eternity's acs_func.cpp needs to be so split at some point. I really hate massive source files.)

It also allows for some performance improvements in the interpreter. The check for the compressed bytecode is handled entirely in the loader, rather than during execution. There are no gaps in the internal code indexes for a switch to have to work around (or a jump table and computed goto can be used). I also use the opportunity to turn jump table instructions into small hash maps. And the guards for executing past the end of bytecode are handled by simply inserting additional instructions into the output.

There are also some code analysis opportunities, though I do very little with that at present. I have at least considered the possibility of autodetecting if additional global/world/map variables are needed, since the translator is able to see what indexes for those are used.

[Altazimuth]

Been almost a week since last post. Has anything been going on? Is there any more planning to do?

[Graf Zahl]

From my side, no. I was actually waiting for one of you commenting on the listed features and say if I missed something or not.

[printz]

I've been putting higher priority on fixing bugs in Eternity (and experimenting with some "cool stuff" such as the overlay automap, which I didn't yet push to master) and I still have a lot of challenging bugs to fix. I've just added a Github issue for this (link), but I'll address it after I fix all known remaining bugs.

[Altazimuth]

As printz said, we have no wrapmidtex (but it is something I've personally wanted to see in, so hopefully we can add it later). We have no decal support (and by extension, no nodecals). We have no floor_reflect or ceiling_reflect.

Specials look fine, it's worth nothing that anything here is run at map start, and cannot be called by ACS, except for those defined here.

[Graf Zahl]

Altazimuth said:

As printz said, we have no wrapmidtex (but it is something I've personally wanted to see in, so hopefully we can add it later). We have no decal support (and by extension, no nodecals). We have no floor_reflect or ceiling_reflect.

I intentionally left a few things in that can safely be ignored if the feature it is associated with does not exist.

Nodecals is such a thing, it does no harm in an engine that does not support decals (as there are no to begin with) but is of use if the map is being played with them on.

The reflect fields can possibly be removed.

[Altazimuth]

Ah that makes sense, given they don't affect playsim at all.

[Graf Zahl]

Concerning the health key, this was incorrectly implemented in ZDoom and didn't match the spec. Of course it cannot be changed now because it may break actual maps out there so I split up the key in two to repair the damage:

   thing
   {
	  health = <int>;			// Set per-actor health as an absolute value. Default = actor default.
	  healthfactor = <float>;	// Set per-actor health as a factor to the original. Default = 1.
   }

[printz]

Wait what? What happened? Did you just change the specification (documentation) to match GZDoom, or did you also change the GZDoom internal behaviour?

What is the formula if you have both fields? Does HealthFactor multiply the overriding Health value? Or does Health fully replace monster's health, no matter if you apply HealthFactor or not?

EDIT: I just looked in your git commits, so I see the answers. But looks like I need to make another late change to the EE behaviour... Sorry WIP authors.

Also GZDoom Builder Bug-Fix UI needs to be updated with these new fields.

[Graf Zahl]

I matched the spec to what was actually implemented.

The relevant commit describing the 'health' property was made by Gez and missed the existing implementation by a wide margin (which in other words means, it was utter horseshit) and I only noticed yesterday when I was looking at a feature suggestion about this matter.

So what can I do? I can't change the implementation, it has been out for 3 years by now and actually been used in real maps. So the only option is to match the spec to what is actually in the code and then use another property to what the spec said.

[esselfortium]

If I'm understanding correctly: For the shared spec, then, would it make sense to only include Healthfactor, and leave out Health?

[Graf Zahl]

That's why I posted it here. But in the end both are trivial to implement, but that's up to the Eternity devs to decide.

[printz]

Yeah, guess I'll fix that.

Still, I feel this is a moving thing. Unless I take a break from Eternity, the boundary is blurry.

Graf Zahl said:

The relevant commit describing the 'health' property was made by Gez and missed the existing implementation by a wide margin (which in other words means, it was utter horseshit) and I only noticed yesterday when I was looking at a feature suggestion about this matter.

Then what's up with this part of the code (GZDoom p_mobj.cpp bottom of P_SpawnMapThing)? Apologies if I didn't get to run ZDoom first, but it looks a bit suspicious.

	if (mthing->health > 0)
		mobj->health *= mthing->health;
	else
		mobj->health = -mthing->health;
	if (mthing->health == 0)
		mobj->CallDie(NULL, NULL);
	else if (mthing->health != 1)
		mobj->StartHealth = mobj->health;

Apparently if the mapthing health (as set in UDMF) is greater than 0, the thing health is multiplied by that amount. And the negation trick (previously described in the UDMF spec) still applies. It seems pretty much compliant to the UDMF spec before your recent change.

[Graf Zahl]

Damnit, I thought I looked everywhere. Thanks for finding. I should have gone to bed earlier instead of working late...
Of course that stuff will get reverted ASAP and the property just turned into a float.

[Death Egg]

How goes progress on this? Having a common modern mapping format I think is really important and I would hate to see the idea die.

[printz]

Don't worry, it won't die. Of course it depends on our time we spend to develop it. As soon as I'm free of the current Eternity bugs/issues, I'll slowly work towards this.

 

A main prerequisite: document UDMF in a definitive file for EE. Right now I've been too lazy to even write it on the wiki, but I will go through it...

[Altazimuth]

I've been unable to pay much attention to this as I've been busy with university work. As I catch up I should be able to dedicate some time to Eternity.

[Altazimuth]

OK, it's the summer (almost), the latest Eternity release has happened, should have some time to focus on this now. What do we need to do before going forward?

[Xaser]

I'll need to take a closer look later, but this looks like it covers almost everything I XLAT/ExtraData-hacked together for Hacx 2.0. Take that with a grain of salt until I comb through the wad and confirm, though.

 

The one thing offhand I know is missing is slopes, but that's an unusual case considering that EE slopes are physics-less, so reconciling that may go a bit beyond this proposal.

[Gez]

On jeudi 18 mai 2017 at 0:41 PM, Altazimuth said:

What do we need to do before going forward?

First order of business: establish order of business.

[Xaser]

Well derp, slopes are indeed there in the proposal. My brain-tired Ctrl+F spree earlier failed to remember that the special is named "Plane_Align". :P

 

tl;dr: this covers all of Hacx 2.0's use cases, FWIW -- and, of course, opens the door for a ton more. Flat alignment by itself is a gorram godsend.

[Death Egg]

@XaserYou think with there being a commonspace for UDMF now you might see if other source ports that'll adopt it could be supported? Only one I know of offhand is 3DGE.