GDCC: An Alternative ACS Compiler [0.15.0]

[Marrub]

C++ is not really based on C at all, and thus has a lot of features that are different, like operator=.

[DavidPH]

Even in C++ a class like that would have a default assignment operator that does a simple copy, so I do not know what VS would be complaining about.

[Nero]

I dug through my C++ manual and I think I found my confusion: you can't compare objects, i.e. if(obj1 == obj2), but you can compare member, i.e. if (obj1.val == obj2.val).

I'll have to dig out my lab work on overloading but I think it was a lesson in setting copying across generally incompatible object types, i.e. struct obj1 = struct obj2, which just made it worse.

[Nero]

Hey, odd error, just added ctype to my header list, and I get this when compiling:

Code: Select all • Expand view

ERROR: (no file): expected primary-expression got ' '

My syntax looks like this, which looks right to me
#include <ctype.h>

Something I'm doing wrong? Updated to 11.0-16 and same problem.

[DavidPH]

And it compiled fine before adding the include directive? I am not even sure right now how you can get that error without an origin, so I might need a copy of the code to figure out what happened.

[Nero]

Yeah ok, I will send the source by PM; I'm not seeing a problem so more eyes are needed. And yeah, things are good if I don't include ctype. I'm only using it for one call to isalnum, in one file, so a workaround could be acceptable.

[Player701]

This toolset is awesome (despite lacking the proper documentation - or is it just hard to find?) but it really, really needs a GZDoom Builder configuration so that scripts can be compiled from its built-in script editor rather than from the command line. I thought I could write a library in GDCC ACS and #import it in the script editor, but I forgot that #import accesses the source file, and acc.exe cannot process the said file for obvious reasons. This means I have to compile both the library and the map script with gdcc-acc.exe and then embed the resulting lumps in the WAD file. Oh my, developing ZDoom maps was never that hard...

Also, it seems that gdcc-acc.exe allows functions such as Delay() to be used inside function definitions. This compiles and links, but when a script with a call to such a function is executed in GZDoom, it crashes with a "GZDoom has stopped working" message - no crash report generated. Sorry, I have no idea if this has been brought up before or not.

[ZzZombo]

Delay() is invalid inside functions, DON'T DO THAT! As well as other functions from the same category.

[arookas]

it really, really needs a GZDoom Builder configuration so that scripts can be compiled from its built-in script editor rather than from the command line.

As awesome as that would be, it would definitely need to be done internally on GZDB's side. The main obstacle is the AcsParserSE class which preprocesses ACS files, used by AccCompiler to get script names and look through #includes. Even if you make a wrapper program for gdcc-cc or gdcc-acc, the wrapper program can't even run because the builtin parser chokes on any new syntax.

[Player701]

Delay() is invalid inside functions, DON'T DO THAT! As well as other functions from the same category.

Of course it's a "don't do that" case but acc.exe prevents users from shooting themselves in the foot, while gdcc-acc.exe (and gdcc-cc.exe as well, BTW) does not. It could issue a warning at least.

[The Zombie Killer]

Delay() is only invalid in a function in ZDoom, it works fine in Eternity

[DavidPH]

A warning for use of functions which delay (or potentially delay, as in a call to a sync script) from StdCall/StkCall functions when targeting ZDoom or Zandronum would be good, though. I will try to get to that after I merge in the BC_DGE branch. However, I consider it a low priority since I think it is well known that ZDoom's interpreter does not allow delays while there are call frames or other data on the stack.

[Player701]

I'm quite surprised that Eternity does allow this (have never used it myself), since I thought ZDoom was the most advanced port in terms of scripting.

[DavidPH]

I rewrote its interpreter years ago. Internally, it has a lot of capabilities that ZDoom's interpreter does not.

[Nash]

Kindly requesting update to the new parameter introduced to PlaySound... as well as all other latest ACC additons. Thanks :D