GDCC: An Alternative ACS Compiler [0.15.0]

Any utility that assists in the creation of mods, assets, etc, go here. For example: Ultimate Doom Builder, Slade, WadSmoosh, Oblige, etc.
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.
Post Reply
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Nash »

One of my users cannot run GDCC no matter what he tries. The 32-bit version reports "this is not a valid Win32 application" and the x64 version just... gets stuck. As in, if he invokes gdcc-acc.exe, it just goes to the next line and freezes, the help stuff that normally gets shown by default doesn't even show. The command prompt session will be permanently stuck and he has to forcefully close this.

I don't have any other information other than he is using Windows 7 x64. Is there any other information we could find out to help figure out why GDCC isn't running on his system?
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: GDCC: An Alternative ACS Compiler

Post by DavidPH »

Unfortunately, I do not know enough about Windows to know what might cause that error on one system, but not others.

In development news, I have changed the default behavior of gdcc-cc and gdcc-as to output bytecode by default instead of IR, as in the other GDCC programs. To get IR output, use the -c or --ir-output option. Additionally, I have added an option (on by default) to use a named script for the autogenerated init script. The name by default is derived from the output name.

Additionally, the only known gotcha left for the ACS front is now the lack of StrCpy, so a 0.8 release might be coming within a few days, representing a feature-complete (and hopefully bug-free) gdcc-acc.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Nash »

DavidPH wrote:Additionally, I have added an option (on by default) to use a named script for the autogenerated init script. The name by default is derived from the output name.
Care to elaborate on this feature? What's a real-world usage of this?
User avatar
Marrub
 
 
Posts: 1192
Joined: Tue Feb 26, 2013 2:48 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Arch Linux
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Marrub »

Nash wrote:
DavidPH wrote:Additionally, I have added an option (on by default) to use a named script for the autogenerated init script. The name by default is derived from the output name.
Care to elaborate on this feature? What's a real-world usage of this?
I probably shouldn't speak for David, but I think it's mainly so you can have multiple GDCC C libraries in the same project (or even over other compatible projects) where the init script must not interfere with others'.
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: GDCC: An Alternative ACS Compiler

Post by DavidPH »

Mostly that it prevents conflicts with other modules, both those compiled with GDCC and with modules of existing maps, where applicable.
User avatar
The Zombie Killer
Posts: 1528
Joined: Thu Jul 14, 2011 12:06 am
Location: Gold Coast, Queensland, Australia

Re: GDCC: An Alternative ACS Compiler

Post by The Zombie Killer »

It also allows you to have libc/libGDCC combined into a separate library from your own code, which feels more organized and keeps the filesize of your libraries down
User avatar
Kyle873
Posts: 667
Joined: Thu Jun 28, 2012 11:48 am
Location: Ontario, Canada

Re: GDCC: An Alternative ACS Compiler

Post by Kyle873 »

DavidPH wrote:Unfortunately, I do not know enough about Windows to know what might cause that error on one system, but not others.

In development news, I have changed the default behavior of gdcc-cc and gdcc-as to output bytecode by default instead of IR, as in the other GDCC programs. To get IR output, use the -c or --ir-output option. Additionally, I have added an option (on by default) to use a named script for the autogenerated init script. The name by default is derived from the output name.

Additionally, the only known gotcha left for the ACS front is now the lack of StrCpy, so a 0.8 release might be coming within a few days, representing a feature-complete (and hopefully bug-free) gdcc-acc.
>Implying anybody even needs to use StrCpy() anymore
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: GDCC: An Alternative ACS Compiler

Post by DavidPH »

Version 0.8 is a go! I am declaring gdcc-acc to be a feature-complete drop-in replacement for acc. Since it has been so long since I did a version bump, the other new features since 0.7 are innumerable and will not be listed.

Downloads: Win64 Win32 Source

And Kyle, people do not need to know that.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Nash »

Thank you for your amazing work, Dave... GDCC is a game changer!
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Nash »

Code: Select all

#library "dungeon"

#include "zcommon.acs"

#define MAX_ROOMS 1024
#define MAX_TILES 128

// size of a cell in Doom map units
#define DUNGEON_CELLSIZE 128

// default light level
#define DUNGEON_LIGHT_BASE 128

// ceiling height
#define CELL_OPENHEIGHT  128 / 8

// dropped height
#define CELL_CLOSEHEIGHT 128 / 8

// rooms must leave a fixed amount of cells empty around it
#define SPACE_BETWEEN_ROOMS 1

// directions
#define NORTH 0
#define SOUTH 1
#define EAST  2
#define WEST  3

#define FIXEDANGLE_NORTH 0.25
#define FIXEDANGLE_SOUTH 0.75
#define FIXEDANGLE_EAST  1.0
#define FIXEDANGLE_WEST  0.5

#define BYTEANGLE_NORTH  64
#define BYTEANGLE_SOUTH 192
#define BYTEANGLE_EAST    0
#define BYTEANGLE_WEST  128

enum ETiles
{
    TILE_NONE,
    TILE_ROOM,
    TILE_WALL,
    TILE_DOOR,
}

struct FRoom
{
    int startX, endX, startY, endY;
    int dir;
}

struct FCorridor
{
    int length, dir;
}

struct FDungeon
{
    // this dungeon's max size (can be smaller than MAX_TILES)
    int sizeX, sizeY;
    
    // list of rooms
    FRoom room[MAX_ROOMS];
    
    // tiles
    int tile[MAX_TILES][MAX_TILES];
}

// dungeon data is per-map!
FDungeon dungeon;

// marks a cell as "visited"
function void D_SetTile(int x, int y)
{
    dungeon.tile[x][y] = TRUE; // <-- this is returning "unknown error"
}

script 1 ENTER
{
    PrintBold(s: "dungeon lib loaded");
}
Why is this making gdcc go "unknown error"? It looks perfectly valid to me. I have commented which line is producing the error. If I substitute x and y for an explicit number, it compiles.
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: GDCC: An Alternative ACS Compiler

Post by DavidPH »

When you get "unknown error" in the log file, that means then that means an error was printed in such a way that it could not be redirected to the error file (that is, non-exception errors). So when you see that, you can try running from a command prompt to see what it is yelling about.

Other than that, the problem is that dungeon needs to be an array in order to do the runtime indexing. You can do:

Code: Select all

FDungeon dungeon_[1];
#libdefine dungeon (dungeon_[0])
And to preempt questions about doing something like that automatically: As I have said previously in other contexts, I do not want to implicitly turn certain declarations into arrays. My primary concern is the rules getting out of hand over time with exceptions and exceptions to those exceptions. One day someone asks, "Does this declaration use variables or an array?" and the answer needs to not be "It's complicated." Both expected and unexpected complications would arise, particularly for world/global objects. What if someone needed to store a structure in normal variables? Even though that is an edge case, it would still need an answer (new syntax? pragma?). Even for map objects, there is the fact that array access consumes more instructions (and presumably takes more host CPU time), which can be relevant for particularly complex code. And it trades one gotcha (unexpected number of variables consumed) for another (unexpected use of an array slot). Then there are the unknown implications for any future extensions that could be considered. Both in terms of user-facing concerns (syntax/semantics) and the internal cost of implementation and maintenance. Nothing sucks quite like having permanent syntactic or semantic baggage for any sort of legacy reason, though particularly when it is because of what amounts to a minor inconvenience.

Long story short, language design is hard.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Nash »

Understood, thanks. I think using macros is fine as it is and isn't really that big of a deal.
User avatar
DavidPH
Posts: 382
Joined: Fri Aug 28, 2009 1:46 pm

Re: GDCC: An Alternative ACS Compiler

Post by DavidPH »

A critical flaw in the handling of forward function references in ACS has been discovered and fixed, so I am releasing version 0.8.1.

Downloads: Win64 Win32 Source
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GDCC: An Alternative ACS Compiler

Post by Nash »

Can I get back compilation halt and error-file-generation for forward-declared functions? It looks like this was recently changed and TBH I am so used to the compilation failing and my entire build script halting instead of silently allowing the entire compile process to finish and then get bombed with a million errors when the game starts because of an incorrectly built ACS object...

(My build scripts check for the existence of the error file to halt the entire build procedure... but since now forward declared functions don't generate errors, my build script is fooled into thinking the compilation was successful even though it wasn't and of course nothing works correctly after that point in time)
ijon
Posts: 108
Joined: Thu Mar 17, 2016 12:09 pm

Re: GDCC: An Alternative ACS Compiler

Post by ijon »

so how do you print fractional numbers of any sort with any of the printf family? none of %e, %f, or %g are working in either zandronum 3 or gzdoom - the output cuts out right at those.

switching to ACS_ZDoom.h didn't change anything (which isn't surprising)

I guess if I really need to I can cast to accum and hack around it with ACS_StrParam for the time being, but I'm using this specifically so I don't have to do bullshit like that.

the test code I'm using is just this (gist link if you like syntax highlighting):

Code: Select all

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

#include <ACS_Zandronum.h> 



int testFunc1(int a)
{
    return a + 10;
}

int testFunc2(int a)
{
    return a + 110;
}

[[call("ScriptS"), address("butt")]]
void TestScript()
{
    int rand = ACS_Random(1, 2);

    int (*func)(int a);

    if (rand == 1) { func = testFunc1; }
    else { func = testFunc2; }

    printf("ayy lmao (");
    printf("%f", 0.1);
    printf(")\n");

    ACS_BeginPrint();

    int x = ACS_Random(1, 10);

    __nprintf("rand -> %d; func(%d) -> %d", rand, x, func(x));
    __nprintf("\ndouble testing");
    __nprintf("\n%%e: %e", 0.1f);
    __nprintf("\n%%f: %f", 0.1f);
    __nprintf("\n%%g: %g", 0.1f);

    ACS_EndPrint();
}
pls respond, I don't want to go back to acc

edit: actually, never mind, I just noticed this in lib/src/libc/printf.c:

Code: Select all

   case 'e': return ~ret; /* TODO */ \
   case 'f': return ~ret; /* TODO */ \
   case 'g': return ~ret; /* TODO */ \
well that takes the piss.

noticed %K is for fixed points - I guess that'll work well enough for now, since the underlying floating-point math works and all, but maaaaaaaan
Post Reply

Return to “Creation, Conversion, and Editing”