GDCC: An Alternative ACS Compiler [0.15.0]

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Thu Apr 07, 2016 5:01 am

Code: Select allExpand view

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


ijon wrote: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=php]. Not sure if it works on all phpBB forums on the internet but... just your information, I guess. :D
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Thu Apr 07, 2016 8:23 am

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.)
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby ijon » Thu Apr 07, 2016 2:56 pm

__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 allExpand view
#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.
ijon
 
Joined: 17 Mar 2016

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Fri Apr 08, 2016 7:42 am

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.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby ijon » Sat Apr 09, 2016 4:41 am

Code: Select allExpand view
#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 allExpand view
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.
ijon
 
Joined: 17 Mar 2016

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Sat Apr 09, 2016 7:45 am

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.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby ijon » Sat Apr 09, 2016 7:11 pm

--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)
ijon
 
Joined: 17 Mar 2016

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Sun Apr 10, 2016 9:06 am

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.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Sun Apr 17, 2016 2:53 am

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.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Wed Apr 20, 2016 3:22 pm

Hi, I have another feature request: support for #region and #endregion (acc supports these)
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Wed Apr 20, 2016 9:38 pm

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.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Wed Apr 20, 2016 9:47 pm

DavidPH wrote: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 allExpand view
#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!
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Tue Apr 26, 2016 7:51 am

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

Code: Select allExpand view
#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
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Tue Apr 26, 2016 10:15 pm

I meant that you might be able to replace GDCC's zdefs.acs with acc's, although I have not tested that.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Sun May 08, 2016 4:49 am

Bear with me on this one...

Code: Select allExpand view
#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?
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 1 guest