GDCC: An Alternative ACS Compiler [0.15.0]

[luckyp3616]

Hi, I am new here and I would like to let you know of a problem when trying to build this in Linux with GCC.

This error comes up:

Code: Select all • Expand view

In file included from /root/src/GDCC.git/inc/CPP/../CPP/PragmaDTBuf.hpp:17:0,
                 from /root/src/GDCC.git/inc/CPP/TStream.hpp:23,
                 from /root/src/GDCC.git/src/CPP/IncludeDTBuf.cpp:16:
/root/src/GDCC.git/inc/CPP/../CPP/../CPP/Pragma.hpp: In constructor ‘GDCC::CPP::PragmaParserACS::PragmaParserACS(GDCC::CPP::PragmaData&)’:
/root/src/GDCC.git/inc/CPP/../CPP/../CPP/Pragma.hpp:119:57: error: invalid initialization of non-const reference of type ‘GDCC::CPP::PragmaData&’ from an rvalue of type ‘<brace-enclosed initializer list>’
          PragmaParserACS(PragmaData &data_) : data{data_} {}
                                                         ^


I did some googling and people mention that this happens because MSVC accepts the non-const reference as a Microsoft extension. I just want you to know about this issue with compiling on Linux.

Thanks in advance.

[DavidPH]

I am reasonably confident that is a bug in gcc. I doubt the standard is intended to prohibit conversion from a reference type to the same reference type in a member initializer. And gcc was apparently fixed in some version, since I use mingw-w64 (5.2.0) for cross-compiling to Windows. I primarily use clang for compiling, though, so you should be able to use that until your distribution updates gcc. If clang is not an option (or does not work for other reasons), you can make it compile in gcc by changing the {} reference member initializers to use ().

Incidentally, if anyone with access to Windows and MSVC would like to confirm or deny that GDCC does or does not compile in that, I would be interested in knowing.

[luckyp3616]

OK, then GCC didn't impement it in 4.8.5. I'll have to add ~amd64 keyword to my Gentoo package.accept_keywords, because the stable GCC in that distro must be out of date.

I try it, and see.

P.S.: So GCC is up to 5.2? Wow!

EDIT: I updated GCC to 4.9.3 and then another error happened, which was fixed by updating the GMP library.
Sure enough, updating GCC and GMP fixed it.

[hjalg]

Hmm. Looks like SetActorProperty accepts only numbers. For example, i can't set

Code: Select all • Expand view

SetActorProperty(0,APROP_Species,"TEST")

, i got "cannot implicitl y convert to arithmetic type from non-arithmetic type" error instead.

[DavidPH]

You will need to use SetActorPropertyString for that. gdcc-acc inherits the implicit conversion rules from C, still. It is something I intend to fix eventually, but it is nontrivial and a low priority.

[hjalg]

You will need to use SetActorPropertyString for that

Alright, thank you. Would be nice if you update your first post with such unusual functions, to let others know about them.

[hjalg]

Two more bugs:
1. Thing_Move doesn't return a boolean value, e.g.

Code: Select all • Expand view

if (Thing_Move(0,TID,1))

will return "expected scalar type"

2. SetPlayerLivesLeft accepts only one argument, must be two: http://wiki.zandronum.com/SetPlayerLivesLeft

[DavidPH]

Thing_Move (and other line specials) now correctly return an int. SetPlayerLivesLeft, however, already takes two arguments.

Additionally, since the ACS front is relatively usable now (but still with some caveats, as seen), I have updated the first post with information on it.

[hjalg]

Thing_Move (and other line specials) now correctly return an int...
Additionally, since the ACS front is relatively usable now (but still with some caveats, as seen), I have updated the first post with information on it.

Thanks!

SetPlayerLivesLeft, however, already takes two arguments.

Weird. I got "too many arguments" when i use

Code: Select all • Expand view

SetPlayerLivesLeft(number,10);

It works only if i change

Code: Select all • Expand view

int   -105:SetPlayerLivesLeft(2, int),

to

Code: Select all • Expand view

int   -105:SetPlayerLivesLeft(2, int, int),

Old version maybe? I use gdcc_v0.7.0-95-g848517c_win64

[DavidPH]

Code: Select all • Expand view

int   -105:SetPlayerLivesLeft(2, int),

Oops. Somehow I saw the 2 for minimum args and overlooked the lack of actual args. This has been fixed and a new build will be up shortly.

[hjalg]

Thanks! Also, check ConsoleCommand please, because something wrong with it. If script contains this function, it compiles without any errors. But in game i have "Unknown P-Code in script scriptnumber" error in console, and all code after ConsoleCommand doesn't execute.

[DavidPH]

ZDoom itself does not implement the ConsoleCommand instruction, and will issue that very error if it is used.

[hjalg]

ZDoom itself does not implement the ConsoleCommand instruction, and will issue that very error if it is used.

Yes, but it's still widely used in Zandronum, i thought GDCC is fully compatible with this port. Is it hard to implement it for Zan? And how can i do this?

[Gez]

Well then you have to precise that the "unknown P-code" error is from Zandronum, not from ZDoom. It's probably just a #define that's wrong so ConsoleCommand is given a bad P-code.

[DavidPH]

As it turns out, one of the many terrible things about ConsoleCommand is that the instruction pair (stack argument and immediate argument) is in the reverse order compared to every other such instruction pair. The declarations have been fixed accordingly.

EDIT: As for the question of how to declare new pcode-based functions with gdcc-acc:

Code: Select all • Expand view

special ReturnType {PCodeNumber}:FunctionName(Arguments);


As in:

Code: Select all • Expand view

special void {94}:SectorSound(str sound, int volume);
special int {57, 58}:Random(int, int);


Note that the second pcode is for the immediate argument (const:) version, if any. Also note that gdcc-acc will automatically use or not use the immediate argument versions of functions based on whether the arguments can or cannot be evaluated at compile time.