User Tag List

Page 3 of 12 FirstFirst 1 2 3 4 5 ... LastLast
Results 21 to 30 of 115

Thread: AngelScript: The Revenge

  1. #21
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    Also Tamano is just joking. I don't think that was serious.
    Ok.

    Would you like to wager on an ZScript vs AS performance comparison?
    Depends on the context. Presumably AngelScript is at least mildly optimized, in which case I would expect it to outperform ZScript handily for running equivalent code. But I am not so sure about ZScript user code+C++ internal engine vs AngelScript user code + AngelScript engine.

  2. #22
    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%
    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.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  3. #23
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,047
    Level
    31
    vBActivity - Bars
    Lv. Percent
    10.69%
    Yes I'm all in favor of better built-in library support for common ZC tasks.

    Short-circuit boolean operations may or may not be a good thing -- it's useful in some cases, but also one of the often-criticized features of C.

  4. #24
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    35
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    800
    Level
    9
    vBActivity - Bars
    Lv. Percent
    91.57%
    My main concern with short circuiting is if it'll kill any existing scripts. I'd really like it to be added, but I'm pretty sure there's some script out there that does a() && b() && c() or similar.

    Maybe some sort of flag at the top of the script/function/whatever?

  5. #25
    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
    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]

  6. #26
    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%
    Oh no I'm very serious, one project that has done incredible things with lua is Starbound which also uses JSON along with it and was created to be moddable from the bottom up. This is the sort of approach we need to take when implementing a new language, in fact I'd rather just rewrite zc from scratch. But ya'll too damn lazy for that.

  7. #27
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    38
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,582
    Level
    30
    vBActivity - Bars
    Lv. Percent
    54.35%
    Quote Originally Posted by Tamamo View Post
    Oh no I'm very serious, one project that has done incredible things with lua is Starbound which also uses JSON along with it and was created to be moddable from the bottom up. This is the sort of approach we need to take when implementing a new language, in fact I'd rather just rewrite zc from scratch. But ya'll too damn lazy for that.
    Lua is gross, though. What advantage would it have over AS? Atleast AS is somewhat similar to ZScript. I think that is a big factor in it being the right choice. Most people who script in ZC aren't programmers. They only learn what they need of ZScript and would probably be scared off by something so ... different.

  8. #28
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    35
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    800
    Level
    9
    vBActivity - Bars
    Lv. Percent
    91.57%
    That's a good point. As much as I like Lua, AS is much closer to ZScript. At least as far as the average scripter is concerned.

  9. #29
    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%
    Neither am I, and I learned lua in 5 days.

  10. #30
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    38
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,582
    Level
    30
    vBActivity - Bars
    Lv. Percent
    54.35%
    Quote Originally Posted by Tamamo View Post
    Neither am I, and I learned lua in 5 days.
    And you could learn AS is 5 days.

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