Quote Originally Posted by Gleeok View Post
Yeah, an angelscript engine is probably just a horrible and slower form of a Java engine without any of the positives. That's why I'm never going to be in favor of moving c++ code to AS. In fact, I want to do the opposite: Move common usage patterns to c++! We just couldn't without adding tons of new code to the ZScript compiler.

Take the most common script ever as an example:
Code:
for(int i = 1; i <= Screen->NumEWeapons(); i++)
{
  eweapon w = Screen->LoadEWeapon(i);
  if(Abs(w->X-8)<someX && Abs(w->Y-8)<someY) // probably more stuff too
  {
    //collision or whatever
  }
}
Which is horribly inefficient. Basically scripts are doing low-level stuff and I can tell you while I am able to optimize scripts to a degree most users can not.
The fact that most scripts use "ZScript engines" (ghost.zh, etc.) kind of compounds the issue.

Here's another example:

Code:
void foo(int, a, b, c, d, e, f, g){ // a is false
  if(a && b && c && d && e && f && g && bar(a,b,c))
  {
    /....
   }
}
Even though 'a' is false every other statement is evaluated and bar(...) is also called.
The first issue can be solved by checking collision internally, as an option, in both cases. Either way, users will want self-defined collision, and you fall back on needing to check bounding areas of objects. I don;t see the difference, save that we don;t have an internal collision call now, which we could add to give the user engine collision checking.

The second, needs a parsing correction. If a statement reaches a condition that would evaluate false, exit, but I don;t think that the risk is worth the reward at all. If we added this, it would need to be a compiler directive that is disabled by default; and I would also point out that code may expect bar() to be called in that statement, even if the conditions are false. Short-circuiting belongs in languages where it is anticipated from the onset.

If you don't favour the AS engine with the parser, than I really don;t see the point. TO me, the entire reason for even wanting this paradigm shift, was to open the engine up to more fluidic control by the scripter. This comes at a performance hit, which is why I was happy to accept it for ZC3, a rewrite, that changed the entire ZC dynamic, moved us to modern libs, added scrolling, and essentially provided an emulation layer to play classic quests. Pretty much, Solarus in ZC style, with AS, and the ability to play most, but not all, older quests.

This is why we were going to work on 2.x, while you worked on the initial set-up for something of that scope. The discussion on AS and the discussion on a modernisation rewrite, to me, are intertwined. The average user couldn't care what script engine is under the hood: They only care that the scripters supply them with free goodies. What they want, more than anything, is to make SNES style games, and they can;t, so they beg the scripters to supply them with the 'next-best-thing'.

I think this constant debate on what scripting engine to use, is just side-stepping the real issue, of how ZC needs to evolve in the next five years, to avoid being surpassed, overshadowed, and forgotten. 2.xx is a stopgap measure, toward that type of goal, and I feel as if you are spending energy trying to hammer in a new engine when the entire thing needs to be blown up and rebuild from the ground up in the near future. I just hope I'm still alive, to see it.

I'll certainly be willing to entertain whatever you create, but I think it will be offset a version or two, no-matter what. I do like the updates we've already managed to get working, and I feel that they should be deployed, and allow users to utilise them. Give them a learning curve that isn't just a cold slap in the face, and they will be more appreciative of the entire thing, and more welcoming of controversial change, in the future.

Maybe we should use the AS engine instead of cpp, and have the ZScript parser output AS instead of ZASM. [/sarcasm]