ZDoom ACC -h thread

[Gez]

So, I've been informed that Randy Heit's ACC doesn't output Hexen bytecode in compatibility mode. I don't want to hijack the Doomsday release thread with chatter about an unrelated topic, so this is a new thread.

To check this, I have used DeScript to "obtain" the source code for the scripts in Winnowing Hall.

Then I put that in a test wad file. I've copied the original ACC acs files (common.acs and co) in the ZDoom ACC directory so that it can work with them.

I then used Scripts -> Compile ACS (Hexen bytecode) in SLADE 3 to get it compiled with ZDoom ACC in compatibility mode. SLADE identified the resulting lump as "Compiled ACS (Hexen)".

Last step of my test, loading both the original MAP01 BEHAVIOR lump and the DeScripted and recompiled lump in a hex editor (HxD) to use its file comparison tool. Verdict: "The chosen files are identical."

Verdict: it seems to actually work. I'd hazard the guess that if you get ACS bytecode in ACSE instead, it's because the scripts unwittingly use some old ZDoom enhancement that couldn't be expressed as Hexen bytecode.

[Quasar]

Gez said:

I'd hazard the guess that if you get ACS bytecode in ACSE instead, it's because the scripts unwittingly use some old ZDoom enhancement that couldn't be expressed as Hexen bytecode.

In order to be less Microsoft-Embrace-and-Extinguishy, it would really be appropriate if ZDoom ACC were to output a warning when this happens.

[kristus]

Seemingly it is what you say. I tried compiling a script I knew for sure would work in Vanilla Hexen and Slade3 accepted it as Hexen ACS bytecode. (what is strange is that it despite several different attempts didn't work before when I tried compiling the same script with ACC for Zdoom, but I digress)

Is it possible that ACC could do something about this though? Like tell the person compiling that there are conflicts? Or would that be an unreasonable expectation? I'm a bit at a loss at how I am supposed to weed out these errors when I don't even know what I am looking for.

[CodeImp]

This is how you would expect it to work and it does works fine, I tested it also (the Hexen game configuration uses ZDoom's acc with -h). I guess I fail to see your point.

EDIT: Oh so when you use ZDoom-specific stuff AND you use -h then it doesn't give any kind of warning? Ok yea that is a bit unfortunate.

[DaniJ]

Indeed the issue here is that the output format will change silently in spite of the user having already specified with -h that they want vanilla Hexen compatible bytecode.

With the current setup the user has no idea that what they end up with is not what they actually requested.

However, I do seem to recall in my own tests that there are certain logic constructs that this tool is interpreting differently to the original compiler and consequently generates different (although statement-compatible) bytecode.

[CodeImp]

When -h is used and the user wrote ZDoom-specific code, the compiler should just output an error in the same manner as when the user would try to compile the works of Shakespeare. In my opinion.

[kristus]

So I made some progress with my dilemma. Turns out that because I was using a modern ACS decompiler, I also got an entirely different script source dump. (dunno why I didn't realize this earlier, but obviously I didn't)

Anyway, using descript to decompile I got a very different looking script dump and this will at least help me figure out what I need to change in my scripts to make them vanilla compliant.

[kristus]

Can't figure out why this script doesn't comply with vanilla ACS.

I've done like Gez and tested to compile a dump from descript as a Hexen ACS compliant BEHAVIOR lump. So far that worked. But when I try to clean up my own scripts. I am not meeting the same kind of success. In an attempt to isolate the scripts and hopefully easier narrow down the culprits. I tried to compile this following script. But it always ends up as "Enhanced".

#include "common.acs"

int map1 = 0;

script 1 (void)
{
    if (map1 == 0)
        {
        Polyobj_RotateRight(const: 4, 8, 64);
        map1 = 1;
        }
}

EDIT: When I try to compile it though Dosbox with vanilla ACC I get the error :
Line 3 in file <Filename> ...
Error #16: Missing semicolon.

EDIT2: ARGH: Oh I see it now. When you declare the integers in ACS you only declare the name, not with any value. It still won't compile with Vanilla ACC. But it will compile properly with ZDoom's ACC.

[kristus]

There, finally. All scripts are now Vanilla Hexen compliant. I've not tested them in game yet. But they should work.

[DaniJ]

I know this is a slippery slope of re-interpretation, however, ACC could very easily produce bytecode for this instead:

int map1;
map1 = 0;

[kristus]

I'm not sure what you want to say by that. But matematically speaking, if you don't assign a value as you declare the integer, it should be zero anyway. At least I can't think of any case where this wouldn't be logically accurate (though I bet someone can tell me where, how and why I am wrong on that assumtion).

[DaniJ]

In this instance the assignment of constant value zero is indeed redundant. What I was meaning to imply was that there is no need for a special opcode to achieve assignment on creation behavior.

[kristus]

Basically making the compiler more tolerant?

[DaniJ]

Basically, yes.

As I alluded too, this is a slippery slope, however in this particular instance I can see no reason not to apply this very minor interpretation when vanilla ACS output is requested and there is otherwise nothing else which would result in format escalation/promotion to the extended opcodes. It is natural for a user to assume they can assign a value on variable creation so I personally see this as more of a compiler usability issue.

[Gez]

kristus said:

But matematically speaking, if you don't assign a value as you declare the integer, it should be zero anyway.

If there is no assignment made at all (even implicitly by the compiler), it could be any value left over at the same place of memory that the variable occupies.

Anyway, the latest version of ZDoom ACC will fail compilation when Hexen-incompatible code is required for compilation and the -h switch is used. (A new -hh switch is provided for anyone who wishes to use the old approach of elevating script format instead.)

[kristus]

Very good. Is this version up on the Zdoom website now?

[Gez]

kristus said:

Very good. Is this version up on the Zdoom website now?

No, but I compiled it and uploaded it here. (It's the first time I compile ACC; I hope it works.)

[kristus]

Tried it. Seem to be working just dandy. :)

[DaniJ]

Gez said:

If there is no assignment made at all (even implicitly by the compiler), it could be any value left over at the same place of memory that the variable occupies.

This depends on the runtime environment. In ACS's case, most variables will have a default zero value as this is the behavior of the bytecode interpreter. However, in practice one cannot assume this because it isn't handled as default assignment (its a one-time clear of the fixed-size variable store on script load). Though I dare say there are some scripts out there which rely on it.