draw_healthbar() function

[score_under]

I'm relatively new with C++ so maybe I have completely missed something in terms of efficiency (since its over 650 lines).

You write code like:

Code: [Select]

   *q++ = *p++;
   *q = '\0';That's better than most C++ programmers. They just use array indices, which means adding a variable to another variable from memory *every loop iteration*. Not to mention it's completely unnecessary.

The only 2 problems I have with that specific function is that the *q='\0'; could firstly be *q=0;, and that it could be right before the calls to mkdir (to avoid writing a null byte every loop iteration, only to be overwritten the next iteration). You can also use arguments as variables - try that with __fastcall!

[serprex]

glBegin(GL_LINE_LOOP | GL_QUADS )

GL_LINE_LOOP=2
GL_QUADS=7
7|2=7=GL_QUADS

glBegin(GL_QUADS)

Git repo patched

[luiscubal]

There's nothing wrong with array indexes. Nowadays, runtime execution speed seems to be less important than maintainability and premature optimization is considered harmful.
That said, there's nothing wrong with C++ pointer arithmetic either, provided that it doesn't hurt code readability.

Theoretically, const should allow better optimization than variables. But that's just in theory. A good optimizer should detect constant variables... in theory. In practice, when something is a const, mark it as a const. There's no harm in it at all, it might improve readability and maybe(just maybe) it might improve performance. Anyway, I seriously doubt it'd worsen performance.

[serprex]

The issue with const is global const variables, which end having to require a place in the symbol table unless declared static. In this case it isn't really a const even, since it gets assigned to a variable expression, so it's more just a strengthened type check

[TrieBr]

I'm relatively new with C++ so maybe I have completely missed something in terms of efficiency (since its over 650 lines).

You write code like:

Code: [Select]

   *q++ = *p++;
   *q = '\0';That's better than most C++ programmers. They just use array indices, which means adding a variable to another variable from memory *every loop iteration*. Not to mention it's completely unnecessary.

The only 2 problems I have with that specific function is that the *q='\0'; could firstly be *q=0;, and that it could be right before the calls to mkdir (to avoid writing a null byte every loop iteration, only to be overwritten the next iteration). You can also use arguments as variables - try that with __fastcall!

I did not write the CreateDir() function  (I just did some minor editing)  . I just grabbed that function off the net for a quick fix on the DLL I had posted on the GMC. I think we can also all agree that the Encryption functions are not necessary, which could probably free a few lines of code if removed.

[serprex]

GL_LINE_LOOP*showborder | GL_QUADS * !showborder

Better written as showborder?GL_LINE_LOOP:GL_QUADS

But if you want GM mimicery, showborder>0?GL_LINE_LOOP:GL_QUADS. But that requires showborder be rounded, so that .2 be false IIRC

[Josh @ Dreamland]

Eh, showborder?GL_LINE_LOOP:GL_QUADS will suffice. Keep in mind var::operator bool() will cover that. And if they're simply passing .5 as a literal, I don't care if it turns out that it doesn't behave exactly like GM; the only reason someone would do that was if they were just trying to find some difference to shove in our noses.

[score_under]

the only reason someone would do that was if they were just trying to find some difference to shove in our noses.

C++ code errors in GML's execute_string. It doesn't in EDL, you with your cfile parser. That's a huge bug, you should fix it.

[Josh @ Dreamland]

Fuck, he's right.
*dumps three months of work*