Does the compiler optimize?

[Radiant]

I'm curious if AGS optimizes calculations? For instance, if my code contains

Code: ags

  enum { FLAG1 = 1, FLAG2 = 2 };
  enemy[5].flags += (FLAG1 | FLAG2);

then does this effectively combine into

Code: ags

  enemy[5].flags += 3;

? Or does the compiled code still combine the flags separately, or look them up as constants?

[Crimson Wizard]

Existing compiler in 3.* versions does not perform any mathematical calculations at compile time.
Enums are replaced with literal values at compile time (just like preprocessor macros made with #define), their names are never saved into compiled code.

New compiler in AGS 4 branch calculates certain things at compile time (but I don't remember all details).

[Radiant]

Thanks!

Suppose I have a big while loop in repeatedly_execute that I rather want to optimize, does it make sense to "cache" certain things in local variables, e.g. use

Code: ags

int f = enemy[n].flags;

and then use f in further comparisons instead of looking up enemy[n].flags every time?

(I'm talking about line-of-sight and distance calculations on a large grid, they seem to be a bit CPU-intensive, esp. on older systems)

[Crimson Wizard]

Suppose I have a big while loop in repeatedly_execute that I rather want to optimize, does it make sense to "cache" certain things in local variables, e.g. use

Code: ags

int f = enemy[n].flags;

and then use f in further comparisons instead of looking up enemy[n].flags every time?

(I'm talking about line-of-sight and distance calculations on a large grid, they seem to be a bit CPU-intensive, esp. on older systems)

With AGS script it's not always obvious which combinations of commands lead to faster or slower code, because some operations are done simply suboptimal from the start, and some became less optimal after the script interpreter got rewritten in AGS 3.3 for compatibility with 64-bit computers and other reasons.
So this may be only found by trying and comparing.
EDIT: I think i'd mention that 3.6.1 has a good performance improvement to running scripts compared to 3.6.0, getting overall perf close to 3.2.1 (but it still somewhat slower).

But even if we talked about the real language, usually it is better to look which options exist for a logic optimization first, that is something that would reduce number of processed objects, for example, cutting some early, by checking something that is faster to check.

I do not know your case, but if it's a big game world, then an example of a bigger optimization is dividing a world into smaller cells, where objects may only interact with objects in this and neighbour cells. This is achieved by having auxiliary object reference arrays per cell, and other things. I think the proper term for this approach is "spatial division" or "space partitioning".