GDCC: An Alternative ACS Compiler [0.15.0]

[Nash]

Code: Select all

if (!heh)
{
    // do stuff
    DoStuff();
    heh++;
    print("lmaoooooo");
}

if you like syntax highlighting

Just thought I'd make a side remark to this, you can actually do colour-highlighted code here on these forums by doing

Code: Select all

. Not sure if it works on all phpBB forums on the internet but... just your information, I guess. :D

[DavidPH]

Yeah, you use %k/%K for signed/unsigned fixed. You can also use %lk for long fixed, which should have enough range and precision for most floating values you will generate. Note that currently the values when printing are truncated rather than rounded, which may sometimes result in slightly unexpected results. Writing formatting code for floats is obviously something I want to do, but it remains a bit beyond my knowledge and skills.

As for issuing an error for forward references in the ACS front, that is something I will have to consider how best to handle. One thing that acc does that gdcc-acc does not is to check at the end that functions which get forward referenced are actually defined, so that is probably what I will have to add in. In the meantime, all I can suggest is that you somehow set up to be notified of warnings that the compiler emits, as it does have warnings for forward references.

(With apologies for disappearing for a week, got caught up in some other stuff.)

[ijon]

__nprintf doesn't output anything on the client in Zandronum 3.0. The BeginPrint and EndPrint work, as evidenced by the bars in the console, but there's nothing in between them.

Same deal with printf logging, and I'm sure the same thing would happen with HUD messages.

Making the script serverside and puking it will get the expected results: "test\nCPLN: -1".

Code: Select all

#include <stdio.h>
#include <string.h>

#include <ACS_Zandronum.h> 

[[call("ScriptS"), address("butt"), script("Clientside"), script("Net")]]
void TestScript()
{
    // shows print bars
    ACS_BeginPrint();

    // shows no text
    __nprintf("test\n");
    __nprintf("CPLN: %d", ACS_ConsolePlayerNumber());

    ACS_EndPrint();

    // shows nothing
    printf("log CPLN: %d\n", ACS_ConsolePlayerNumber());

    // crashes
    fputc('a', stdout);
    fputc('y', stdout);
    fputc('y', stdout);
    fputc(' ', stdout);
    fputc('l', stdout);
    fputc('m', stdout);
    fputc('a', stdout);
    fputc('o', stdout);
    fputc('\n', stdout);
} 

edit: I tried to use fputc as a workaround for the printf logging. It just straight up crashes clientside. Serverside it works fine.

[DavidPH]

Does it work if you use __nprintf_str(s"test\n"); instead? I have a sinking suspicion that the problem is that statics are not initialized clientside, which would break ordinary C strings. If that is the case, I think I have a solution, though there are likely to be other related problems in the future.

[ijon]

Code: Select all

#include <stdio.h>
#include <string.h>

#include <ACS_Zandronum.h> 

[[call("ScriptS"), address("butt"), script("Clientside"), script("Net")]]
void TestScript()
{
    ACS_BeginPrint();
    __nprintf("__nprintf %d", 5);
    ACS_EndLog();

    ACS_BeginPrint();
    __nprintf_str(s"__nprintf_str %d", 5);
    ACS_EndLog();
}

This will log a blank line, then "__nprintf_str 5" when puked online.

I definitely remember issues with map variables with default values not being defined clientside, even with ACC. For example, this line:

Code: Select all

int IsServer = 1; 

at the top level would have IsServer (as a map var) equal 1 on the server, but 0 on the client.
(I think I might've actually used that behaviour once, although now I put "IsServer = 1;" in an OPEN script because I'm not that much of a masochist)

As you can imagine it's pretty bad.

[DavidPH]

I have added --bc-target=Zandronum, which will enable the generation of clientside initialization. Hopefully this will solve the C string problem, though it does leave some other possible issues in the future. Since I have very little experience with and understanding of using ACS with Zandronum's netcode, I am open to suggestions on how to better handle this.

As an aside, GDCC is currently on version 0.9.3, though the only major new feature of 0.9 was the addition of gdcc-ar-wad.

[ijon]

--bc-target=Zandronum just causes it to straight-up crash when the ACS is loaded in Zandronum 3.0, both in single player and as a host. (I recompiled from git btw)

Here's the core dump, crash log, executable, and debugging symbols for it if it'd help https://my.mixtape.moe/mzevth.7z

The executable's for 64-bit Linux.

edit: oh right you might want the actual test pk3: https://my.mixtape.moe/bpdxfp.pk3 (actual filename gdcc-test.pk3)

[DavidPH]

I had a slight "2gud4math" moment, which has now been corrected. In the future, I will endeavor to not be lazy about installing and running the ports I am claiming to support. New, working builds should be up now.

[Nash]

Suggestion (if it hasn't been done already): an automated system that will always grab the latest ACC headers from Randi's repository and update the GDCC version of the headers, so that users can just grab the latest headers any time ACC is updated.

[Nash]

Hi, I have another feature request: support for #region and #endregion (acc supports these)

[DavidPH]

Automatically adapting acc's headers would be largely impractical, since GDCC's versions need to include type information which is totally absent in acc's. However, acc's zdefs.acs should be directly compatible with gdcc-acc.

As for #region and #endregion, I am assured that acc ignores those directives, so I have updated gdcc-acc to do the same.

[Nash]

Automatically adapting acc's headers would be largely impractical, since GDCC's versions need to include type information which is totally absent in acc's. However, acc's zdefs.acs should be directly compatible with gdcc-acc.

Hmm, what do you recommend? I include zcommon twice, with the ACC one being an explicit path?

Code: Select all

#include "zcommon.acs" // gdcc's
#include "d:/games/doom/acc/zcommon.acs"
 

Appreciate any advice you can give me, I think constantly having to hand-edit gdcc's copy of zspecial.acs every time acc is updated is kind of counter-productive, IMO.

As for #region and #endregion, I am assured that acc ignores those directives, so I have updated gdcc-acc to do the same.

Ah yes, my bad. By "support" I mean ignored. =P Thanks!

[Nash]

I just re-read what you said, you said acc's zdefs should be compatible with gdcc-acc, not zcommon.

Code: Select all

#include "zcommon.acs" // gdcc's
#include "d:/games/doom/utils/acc/defs.acs"

Even so, gdcc-acc bombs out with "ERROR: d:/games/doom/utils/acc/zdefs.acs:27:10: incompatible macro redefinition"

Furthermore, even if the above worked, it doesn't solve the problem of newly added functions, which are contained inside acc's zspecial.acs (which also does not work, ERROR: d:/games/doom/utils/acc/zspecial.acs:325:6: function redeclared with different return type)...

I will just resort to hand-editing gdcc-acc's headers every time acc is updated, for now. :S

[DavidPH]

I meant that you might be able to replace GDCC's zdefs.acs with acc's, although I have not tested that.

[Nash]

Bear with me on this one...

Code: Select all

#define MAXRAINDROPLETS 10

enum ERainDropletType
{
    DROPLET_None,
    DROPLET_Droplet,
    DROPLET_Trail
}

struct FRainDroplet
{
    int type;
    int x, y, frame, frameDelay;
    int alpha;
}

struct FPlayerHUD
{
    // frame number of noise animation
    int noiseFrame;

    // list of droplets on screen
    FRainDroplet droplet[MAXRAINDROPLETS];
}

//===========================================================================
//
// Rain Droplets
//
//===========================================================================
function FPlayerHUD _H_CreateRainDroplet(FPlayerHUD playerHUD, int type, int x, int y)
{
    // find an empty slot to create the droplet in
    for (int i = 0; i < MAXRAINDROPLETS; i++)
    {
        if (!playerHUD.droplet[i].type) // <--- ERROR: hud.acs:134:1: bad getStkPtrIdx
        {
            // do stuff
        }
    }
    return playerHUD;
}

function FPlayerHUD _H_UpdateRainDroplets(FPlayerHUD playerHUD)
{
    for (int i = 0; i < MAXRAINDROPLETS; i++)
    {
        // do stuff
    }
    return playerHUD;
}

function FPlayerHUD H_DrawRainDroplets(FPlayerHUD playerHUD)
{
    // if raining && looking up && random chance
    if (1)
    {
        // create droplet
        int type = Random(1, 2);
        int x = Random(0, UI_RES_WIDTH),
            y = Random(0, UI_RES_HEIGHT);
        playerHUD = _H_CreateRainDroplet(playerHUD, type, x, y);
    }

    // update droplets
    playerHUD = _H_UpdateRainDroplets(playerHUD);

    return playerHUD;
}

The error is "bad getStkPtrIdx" (I've marked it in the code snippet above)... what does that mean and what am I doing wrong?