User Tag List

Page 6 of 12 FirstFirst ... 4 5 6 7 8 ... LastLast
Results 51 to 60 of 115

Thread: AngelScript: The Revenge

  1. #51
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    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
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #52
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    If you remove handlers the callbacks are going to be a bitch to work with @Gleeok , there I spelled it out fo you.

  3. #53
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    just popping in to say it's starting to look good. :) Not saying zc script types will be done very soon but...


    Quote Originally Posted by Tamamo View Post
    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.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  4. #54
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Quote Originally Posted by Gleeok View Post
    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.

  5. #55
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    Quote Originally Posted by Tamamo View Post
    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?
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  6. #56
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    Quote Originally Posted by Gleeok View Post
    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.

  7. #57
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Tamamo View Post
    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.

  8. #58
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    Quote Originally Posted by ZoriaRPG View Post
    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:
    Code:
    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.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  9. #59
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,781
    Level
    21
    vBActivity - Bars
    Lv. Percent
    73.04%
    Quote Originally Posted by Gleeok View Post
    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:
    Code:
    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.

  10. #60
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,827
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,978
    Level
    33
    vBActivity - Bars
    Lv. Percent
    28.3%
    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+.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social