GDCC: An Alternative ACS Compiler [0.15.0]

[Nash]

Sooooo sorry man but REOPEN still isn't working. Tried gdcc_v0.11.0-8-ge19bcaa_win64.7z

I just extract all of the contents into my gdcc directory and overwrite everything. Is there anything else I might be doing wrong?


EDIT: KILL scripts don't work too, BTW.

Also throwing this here just in case: I'm a gdcc-acc user. Always have been.

[Nero]

Hey, I'm having a problem with, it seems, sprintf. Take a look at the example functions for usage, maybe I'm doing something wrong there?

---

Code: Select all • Expand view

const char * zLog_LWORDS (char *ltxt, short snum, bool zout)
{
   char z_log[257],
      z_num[11];
   
   strcpy((char*)z_log, ltxt);
   sprintf(z_num, "%hi", snum);
   strcat((char*)z_log, (char*)z_num);
   
   
   if (zout) {
      ACS_BeginLog ();
      __nprintf (z_log);
      ACS_EndLog ();
   }
   
   return z_log;
}

---

My apologies for leaving my typedefs in but I think the function should be clear enough.

Code: Select all • Expand view

const NSTRG zLog_LWORDS(NSTRG ltxt, short snum, bool zout)
{
   NSTRG z_log = NULL;
   LWORD z_num[11];
   size_t nlen = strlen(ltxt);
   nlen += sprintf(z_num, "%hi", snum) + 1;
   z_log = (NSTRG)malloc(nlen * sizeof(LSTRG));
   if (z_log != NULL)
   {
      strcpy(z_log, ltxt);
      strcat(z_log, z_num);

      if (zout)
      {
         ACS_BeginLog ();
         __nprintf (z_log);
         ACS_EndLog ();
      }

      return z_log;
   }
   return NULL_NSTRG;
}

This function, and it's sisters, tries to put a string and a number together. The string gives the number meaning. The final product might be "Player 0 TID is: 42", with the string being "Player 0 TID is: ", and the number being 42. Both values get sent to the function to be concatenated, but the number has to be converted to a string as well. Tested in VS2015, both functions work fine and I have complete strings, but not with GDCC. It's as if the converted number string isn't being concatenated. The reason I think the problem is with sprintf is that I also have a function that concatenates two strings and it's working fine. The difference between the functions is the sprintf usage.

---

No usage of sprintf

Code: Select all • Expand view

const NSTRG zLog_NSTRG (NSTRG ltxt, NSTRG rtxt, bool zout)
{
   NSTRG z_log = NULL;
   size_t    nlen;
   nlen = strlen(ltxt);
   nlen += strlen(rtxt) + ONE;
   z_log = (NSTRG)malloc(nlen * sizeof(LSTRG));
   if (z_log != NULL){
      strcpy (z_log, ltxt);
      strcat (z_log, rtxt);
      
      if (zout == true){
         ACS_BeginLog ();
         __nprintf (z_log);
         ACS_EndLog ();
      }
      
      return z_log;
   }
   else
      return NULL_NSTRG;
}

Am I doing something wrong or is there an issue with sprintf?

[DavidPH]

Nash: Forgot to add them to the list of ACS keywords, so the parser ignored them for script types. It should actually really be working now.

Also, when updating, you should delete the old version first, as I do sometimes remove files from the distribution.

Nero: And on the same subject of code with insufficient testing, I forgot to flush the special stream used for sprintf in the latest stdio rewrite. That also seems to be working correctly now.

[Nero]

Can confirm updates fixed my issues! Thank you!

[Nero]

Quick question: I currently use the following code for HudMessages, which works fine for just plain messages. What is the syntax for combining types and where do the extra arguments go?

Code: Select all • Expand view

ACS_BeginHudMessage ();
__nprintf ("A");
ACS_MoreHudMessage ();
ACS_OptHudMessage (HUDMSG_PLAIN, tid, ZERO, x_pos, y_pos, ZROF);
ACS_EndHudMessage ();

Something like this snippet didn't seem to work:

Code: Select all • Expand view

ACS_BeginHudMessage ();
__nprintf ("A");
ACS_MoreHudMessage ();
ACS_OptHudMessage (HUDMSG_PLAIN | HUDMSG_ALPHA, tid, ZERO, x_pos, y_pos, ZROF, 0.5);
ACS_EndHudMessage ();

[DavidPH]

The extra arguments go in the ACS_EndHudMessage call. Just make sure they have the right type, since they are passed as variadic arguments.

On a side note, you may want to replace the __nprintf there with ACS_PrintChar('A'), to avoid all the extra time in nprintf.

[Nero]

It took a couple tries but I got it now. I do output stings too, so the __nprintf is sometimes necessary, but since I'm fixing my HudMessage use I'm separating my code into an image function and a string function. Either way, thanks for the tip, I'm all for efficiency tweaks.

I'm stuck on one thing though: color strings. From my understanding of the wiki if I specify a message type with HUDMSG_COLORSTRING, the color arg accepts a string instead of an int. GDCC doesn't like strings in an int arg, obviously, so what do I do there?

[DavidPH]

There's OptHudMessageS for that, or you can just cast it to an int, depending on the circumstances.

[Marrub]

I've created a wiki for GDCC since there's a lot of things that need explaining commonly.
I am not very good at administering mediawiki software, so any suggestions are welcome.

[Nash]

Not sure if this is a GDCC problem or not... I'll check with here first.

Code: Select all • Expand view


function void DebugText_Game(void)
{
    str gameStateNames[5] =
    {
        "GS_None",
        "GS_EnterLevel",
        "GS_NoPlay",
        "GS_Play",
        "GS_ExitLevel"
    };

    str text;

    PrintDebugString(StrParam(
    s:"GameInstanceCount = ", d:gameInstance.gameInstanceCount, s:"\n",
    s:"gameState = ", s:gameStateNames[gameInstance.gameState], s:"\n",
    s:"MainTimeInstance = ", d:MainTimeInstance, s:"\n",
    s:text
    ));
}


"text" will appear to print junk (the level's name for example). Changing it to

Code: Select all • Expand view


str text = "";


Will not print junk. Don't know what recent change caused unassigned strings to print junk... I am okay with this change if it has to be this way but I just want to know what's causing this (GDCC or ZDoom, and intentional or not)

[DavidPH]

Should be zero-initialized by the engine just like under acc, but I don't know what printing string index 0 does under ZDoom currently.

EDIT: Or, well, it's obvious what it will do: Print the first string from the table of the map's BEHAVIOR (or the first loaded module if the map has no BEHAVIOR). So there you have it.

[Nash]

It didn't do this until very recently though... must be something that changed in ZDoom, then. Since I don't have the energy to track it down and make isolated examples, I'll just play it safe and initialize my temporary strings with "" and hopefully the string garbage collector is doing its job... :S

[Nero]

Hey David, while debugging my code in VS I found something that VS calls an error that GDCC is allowing:

Code: Select all • Expand view

// example.h

// So I create an object
typedef struct objectA objectA;
struct objectA
{
     int objAx,
          objAy;
     char objStr[objStrSize];
};

// Now I declare an object and a pointer
objectA NULL_objA, *NULL_objAptr;

Code: Select all • Expand view

// example.c

// So now in a function I do something like this:
void foo ()
{
     NULL_objAptr = initalizeObjA();     // so the function returns a pointer to the object it created
     NULL_objA = *NULL_objAptr;         // and here's the problem, I just set the global object to the dereferenced pointer!
}


My code doesn't overload the "equal" operator, not sure if that's even doable here, so I'm not sure if this is a bug in GDCC or just a case of "don't do that!" Just a heads up

*edited so it's one problem, not multiple, my other issues were my own.

[DavidPH]

Looks perfectly legal to me. Structures are assignable in C in that way. It copies the contents of the right operand into the left operand.

[Nero]

Ah, ok, that's something I didn't know. Maybe I'm forgetting my C++ but I thought you couldn't do that without overloading the operand; which is what made me think that should be illegal in C as well. I guess I should check my solution settings if VS is balking on a C project, just specifying a .c filetype isn't enough for it.