AngelScript: The Revenge

[Gleeok]

Yep, it should be fine once I figure out how to split the dang asTT_Scope token type into forwards and backwards tokens. :/

If anyone with some 1337 c++ macro skills wants to try their hand at generating about 100x the classes that this one currently does feel free to go crazy show me up. (It only generates a 38kb script file ATM which isn't near enough for serious performance or memory allocation testing.)

https://github.com/ArmageddonGames/Z...tCompileTime.h

[Tamamo]

If you remove handlers the callbacks are going to be a bitch to work with @Gleeok , there I spelled it out fo you.

[Gleeok]

just popping in to say it's starting to look good. :) Not saying zc script types will be done very soon but...

If you remove handlers the callbacks are going to be a bitch to work with @Gleeok , there I spelled it out fo you.

I meant the syntax, not the actual handles. That would require rewriting the entire script library; that's just crazy sauce.

[Tamamo]

I meant the syntax, not the actual handles. That would require rewriting the entire script library; that's just crazy sauce.

Okay first what the fuckall you talking about, zscript syntax doesn't even have function handles. Second enlighten me.

[Gleeok]

Okay first what the fuckall you talking about, zscript syntax doesn't even have function handles. Second enlighten me.

This is Angelscript not ZScript. Declaring and using "handles" means typing the "@" @at @symbols @everywhere @in @the @scripts. @The @person @who @wrote @the l@anguage @and a@ll t@he @code @had s@implifying @this @on @his @todo@ list@ for @AS 3.0. @But it @seems @it @hasn't @happened @yet.


Also, sure thing:



Are you enlightened now?

[Tamamo]

This is Angelscript not ZScript. Declaring and using "handles" means typing the "@" @at @symbols @everywhere @in @the @scripts. @The @person @who @wrote @the l@anguage @and a@ll t@he @code @had s@implifying @this @on @his @todo@ list@ for @AS 3.0. @But it @seems @it @hasn't @happened @yet.


Also, sure thing:



Are you enlightened now?

Another reason i dont like angelscript. It's implementation of callbacks and handles is just plain stupid.

[ZoriaRPG]

Another reason i dont like angelscript. It's implementation of callbacks and handles is just plain stupid.

Is it really that different to using *pointer ? I suppose you could always change the preprocessing and lexing side to use *handle?

Here's a question that has been bothering me: Is this parser that you are making still going to use the present ffscript code? If so, and it is just a drop-in replacement for flex-bison, then I would be willing to help test, and possibly work on it, but it it means rewriting ffscript, and all the functions... Hell, will it be using ri->D[] and similar? How will it change stack calls? As far as I can see, it requires rewriting the whole damned engine, which is why I'm not interested in working on it.

[Gleeok]

Is it really that different to using *pointer ? I suppose you could always change the preprocessing and lexing side to use *handle?

Here's a question that has been bothering me: Is this parser that you are making still going to use the present ffscript code? If so, and it is just a drop-in replacement for flex-bison, then I would be willing to help test, and possibly work on it, but it it means rewriting ffscript, and all the functions... Hell, will it be using ri->D[] and similar? How will it change stack calls? As far as I can see, it requires rewriting the whole damned engine, which is why I'm not interested in working on it.

Nope. 18-bit zscript fixed types are an atrocity. No more divide or multiply by 10000 stuff. There, I said it.
It is also not compatible with the current ZScript parser, which is actually a good thing.

Let me fill you in on what is done really quick. -(Keep in mind I did all this in one week, by myself; like I said last year: if we move away from ZScript then productivity will increase by a huge margin and people will be able to work with it much easier)

~We have a fully standards compliant c/c++ preprocessor that scripts /and engine/ may use.
~As per above, script logging, asserts, and exceptions are only compiled with the "DEBUG" flag set. This means no commenting in/out Trace(..) functions, and script errors give detailed info and even a callstack.
~The compiler/preprocessor is separate from ZQuest and ZC, (and serialization support for edit/continue is planned). This means you will be able to recompile/write/test scripts directly while you test them in ZC.
~Compilation is currently blazing fast compared to the ZScript parser: A 120 KB script file compiles and builds in 0.2 seconds and I have not even optimized anything (But if you know me you know I will!).
~Math library built in is already 10x the usefulness of ZScript. We have vector math and utility types that are all c++ code so scripts will be very fast as they just call directly into an c++ function. Parts of std.zh will be put in c++ as well so huge speed improvements all around are planned.
~Delegates and callbacks are basically in already (see other thread on messaging).
~No limit (currently 2048) on scripts. RAM usage seems to be very low so I don't see why not.


What's going in this week:
~Maybe DMap, Map, Screen, and Global Scripts. (Whatever I feel like basically)
~Any script can be created at any time by any other script. For example:

class ChildrenOfTheCorn
{
  int Children;
  int Corn;
  void MakeSequel(bool blood) {...}

  //stuff (like an ffc script kinda)
}

void OnSomeCallback(...) //called by the engine
{
  foreach(...)
  {
    Script@ globalScript = zc.CreateScript(GLOBAL, "ChildrenOfTheCorn");
    globalScript.Children = 212;
    globalScript.Corn = lots;
    globalScript.MakeSequel(true);
  }
}

It's not all fun though. The bindings to existing ZScript things are going to take the longest. Although comparatively speaking each built-in function is much easier to add to AS than ZScript, they don't exist yet.

[ZoriaRPG]

Nope. 18-bit zscript fixed types are an atrocity. No more divide or multiply by 10000 stuff. There, I said it.
It is also not compatible with the current ZScript parser, which is actually a good thing.

Let me fill you in on what is done really quick. -(Keep in mind I did all this in one week, by myself; like I said last year: if we move away from ZScript then productivity will increase by a huge margin and people will be able to work with it much easier)

~We have a fully standards compliant c/c++ preprocessor that scripts /and engine/ may use.
~As per above, script logging, asserts, and exceptions are only compiled with the "DEBUG" flag set. This means no commenting in/out Trace(..) functions, and script errors give detailed info and even a callstack.
~The compiler/preprocessor is separate from ZQuest and ZC, (and serialization support for edit/continue is planned). This means you will be able to recompile/write/test scripts directly while you test them in ZC.
~Compilation is currently blazing fast compared to the ZScript parser: A 120 KB script file compiles and builds in 0.2 seconds and I have not even optimized anything (But if you know me you know I will!).
~Math library built in is already 10x the usefulness of ZScript. We have vector math and utility types that are all c++ code so scripts will be very fast as they just call directly into an c++ function. Parts of std.zh will be put in c++ as well so huge speed improvements all around are planned.
~Delegates and callbacks are basically in already (see other thread on messaging).
~No limit (currently 2048) on scripts. RAM usage seems to be very low so I don't see why not.


What's going in this week:
~Maybe DMap, Map, Screen, and Global Scripts. (Whatever I feel like basically)
~Any script can be created at any time by any other script. For example:

class ChildrenOfTheCorn
{
  int Children;
  int Corn;
  void MakeSequel(bool blood) {...}

  //stuff (like an ffc script kinda)
}

void OnSomeCallback(...) //called by the engine
{
  foreach(...)
  {
    Script@ globalScript = zc.CreateScript(GLOBAL, "ChildrenOfTheCorn");
    globalScript.Children = 212;
    globalScript.Corn = lots;
    globalScript.MakeSequel(true);
  }
}

It's not all fun though. The bindings to existing ZScript things are going to take the longest. Although comparatively speaking each built-in function is much easier to add to AS than ZScript, they don't exist yet.

What are you planning to do to convert all of the existing types? What type are the existing int and float declarations from script code using?

You didn't ever answer my concern about zscript object, and array pointers; given that AS doesn't have pointers at all, I need to know how that syntax would cross, if at all.

Is it going to be able to utilise the ZASM labels and registers, by removing the division and multiplication factors? Are you just implementing zscript INT and FLOAT as real floating pint with four points of precision? Isn't that going to cause hell with typecasting, given that ZASM stuff expects longs and ints (and occasionally fixed values), and the ZC engine needs fixed values regularly?

I would just have added a type for fixed to it, and parsed the old scripts to that. I'm still unconvinced about compatibility here, because none of these issues have ever been addressed, so, let me know.

I would absolutely need to see how you convert ZASM functions across, and such.

[Gleeok]

I don't read/write from ZASM bytecode at all. It's all separated. ZScript is only 32 bit integers, so this best maps to int by default. Having AS to be responsible for maintaining legacy zscript bytecode was never a goal, and I suspect never will be, but even though I'm not going to do it, maybe someone else will.

AS can work with native types easily, this includes pointers, primitives, and structs. ZScript can only handle one type: long.


You're thinking about it the wrong way:
The truth is nobody really wants (or has enough experience) to work with the ZC code because the reality of breaking computability is such a huge burden that most people are crushed by it instantly when they realize how difficult simple refactoring or other trivial things could become. In addition, we're basically running out of useful things to add to it due to complexity of working with the old systems. I'm not going to be able to get to a ZC 3.0, the best I can do is clean up some of the allegro stuff and replace it one thing at a time. You guys are pretty much the only new people who are working on ZC right now. Surely you realized by now that it's way more complicated than it needs to be, and that for all the cool stuff and good work you guys have done on 2.5x the amount of time spent for very minor improvements is sort of disproportional. If the next-gen of ZC developers want to do things differently, or even the same, then they should have that option, and I'll support them. Saffith has moved on, and the truth is I never really came back. I'm still semi-retired, and will probably stay that way for a while; I just have too many other things to do. At least Dark Dragon is currently around for the time being.

AS is something that is documented, works well, an anybody can work with without too much trouble. It's more for the future of ZC rather than the past, to put it one way. We won't even add it until 2.6 so it doesn't interfere with 2.5+.