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.
To put it simply, locals in the ACS front have the same problem as globals. It needs to be in an array to access array members. In this case, unfortunately, you would need to copy it into one like:
function FPlayerHUD _H_CreateRainDroplet(FPlayerHUD playerHUD_, int type, int x, int y)
{
FPlayerHUD playerHUD[1] = {playerHUD};
// etc
return playerHUD[0];
}
Simply declaring the parameter as an array would cause it to be have a pointer type as in C.
The more technical explanation, for anyone curious, is that the compiler sees the address of playerHUD being used dynamically and changes it to be stored on the automatic storage stack. But the calling convention for ACS functions does not have a stack pointer, which makes the resulting IR code impossible to translate to ZDACS bytecode. The exact error occurring when it tries to determine which register index holds the stack pointer. To which I should probably improve the error message to something other than just the name of the function.
Please... option for error on forward declared function... this time it's not even about my custom build scripts anymore. I was putting something together in SLADE and I wasted almost half an hour wondering why do my scripts not even work, turns out I accidentally forward declared a function. SLADE happily compiles this and doesn't display any errors.
Vaecrius wrote:And now I've got a new problem: It can't find zcommon.acs no matter what I do.
Under non-Windows systems, the default library path is /usr/share/gdcc/lib. You can override it using the --lib-path option.
Vaecrius wrote:Is there a manual or something?
No, but a usage overview document would probably be a good idea. I would appreciate input people who have the perspective of learning to use GDCC, actually.
Nash wrote:Please... option for error on forward declared function... this time it's not even about my custom build scripts anymore. I was putting something together in SLADE and I wasted almost half an hour wondering why do my scripts not even work, turns out I accidentally forward declared a function. SLADE happily compiles this and doesn't display any errors.
I have made it an error if a forward declared function is not defined at the time of codegen, although this may have undesired consequences for other projects. Ideally, SLADE would have the ability to display compiler warnings, but I suspect this would conflict with how acc always prints stuff.
DavidPH wrote:I have made it an error if a forward declared function is not defined at the time of codegen, although this may have undesired consequences for other projects. Ideally, SLADE would have the ability to display compiler warnings, but I suspect this would conflict with how acc always prints stuff.
Thank you thank you thank you thank you... although you didn't have to change it... I did say "option"... so a command line parameter, so that other projects won't break with this change...
and I still get the same error even though it is most definitely in that folder. (I also copied the gdcc-acc binary into that folder and am attempting to run that - is that the problem?)
DavidPH wrote:
Vaecrius wrote:Is there a manual or something?
No, but a usage overview document would probably be a good idea. I would appreciate input people who have the perspective of learning to use GDCC, actually.
So far, I've had some snags on...
- what dependencies are required
- how to compile (I just extrapolated from how to compile (G)ZDoom)
- where the executables are once you've compiled them
- what to do with those things
- how it looks for ACS libraries and how to customize that
The directory that you point --lib-path at has to contain the lib/inc directory from the repository (or, of course, a copy of it). For example, if you have gdcc checked out at ~/src/gdcc, then you would use --lib-path ~/src/gdcc/lib.
Assuming something hasn't gone catastrophically wrong and ~/doom/GDCC-master/lib/inc/ACS/zcommon.acs exists, does --sys-include ~/doom/GDCC-master/lib/inc/ACS make it able to find zcommon.acs?
DavidPH wrote:Assuming something hasn't gone catastrophically wrong and ~/doom/GDCC-master/lib/inc/ACS/zcommon.acs exists, does --sys-include ~/doom/GDCC-master/lib/inc/ACS make it able to find zcommon.acs?
Still no luck, but that folder most definitely has a zcommon.acs.
EDIT: Sorry, my bad! It was a problem with my bash shortcut!
Stupid question: Have you tried reordering the argument to before the source name? I don't know why this would work, but try it: gdcc-acc --lib-path ~/doom/GDCC-master/lib/ _zip/acs/hdacs.acs _zip/acs/hdacs.o
Same "non-constant initializer for static storage object" error... my prior problem was actually that I was running gdcc from a script that only contained room for 2 parameters so the path was being ignored.
