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 » Sun Jan 24, 2016 12:55 pm

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

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Fri Jan 29, 2016 10:34 am

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

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Fri Jan 29, 2016 5:47 pm

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

Re: GDCC: An Alternative ACS Compiler

Postby Marrub » Fri Jan 29, 2016 6:33 pm

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
Marrub
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Discord: Marrub#5455
Github ID: marrub--
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Fri Jan 29, 2016 9:25 pm

Mostly that it prevents conflicts with other modules, both those compiled with GDCC and with modules of existing maps, where applicable.
User avatar
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby The Zombie Killer » Fri Jan 29, 2016 10:40 pm

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
The Zombie Killer
King of the Kangaroos
 
Joined: 14 Jul 2011
Location: Gold Coast, Queensland, Australia
Discord: Zombie#1795

Re: GDCC: An Alternative ACS Compiler

Postby Kyle873 » Wed Feb 10, 2016 8:11 am

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
Kyle873
 
Joined: 28 Jun 2012
Location: Ontario, Canada

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Wed Feb 10, 2016 8:42 am

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

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Wed Feb 10, 2016 9:29 am

Thank you for your amazing work, Dave... GDCC is a game changer!
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Tue Feb 16, 2016 7:18 am

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

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Tue Feb 16, 2016 8:18 am

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 allExpand view
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
DavidPH
Crazy Compiler Man
 
Joined: 28 Aug 2009

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Tue Feb 16, 2016 8:26 am

Understood, thanks. I think using macros is fine as it is and isn't really that big of a deal.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: GDCC: An Alternative ACS Compiler

Postby DavidPH » Fri Feb 26, 2016 9:55 pm

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

Re: GDCC: An Alternative ACS Compiler

Postby Nash » Tue Mar 29, 2016 11:25 am

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

Re: GDCC: An Alternative ACS Compiler

Postby ijon » Thu Apr 07, 2016 3:54 am

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

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 1 guest