Comments on Profile Post by TheoAllen

  1. Poryg
    Poryg
    I don't think the code was at fault, since JS is a high level language and as such has no ability to freeze your computer. There is only one exception, RAM overload. However, if you use windows 10, it will crash the app the moment it needs to free up RAM.
    Dec 5, 2018
    Marsigne likes this.
  2. Poryg
    Poryg
    Unless of course you mean the actual MV editor itself... Which would make more sense...
    Dec 5, 2018
    Marsigne likes this.
  3. TheoAllen
    TheoAllen
    I mean, I did something funny in main.js. Not sure if it's related. But maybe it also comes from overused RAM or whatnot. I also happened to own MV in steam version if that counted as another factor.
    Dec 5, 2018
    Marsigne likes this.
  4. TheoAllen
    TheoAllen
    Oh I mean the editor, during playtest.
    Dec 5, 2018
    Marsigne likes this.
  5. Poryg
    Poryg
    If you don't mind, send me the code?
    Dec 5, 2018
    Marsigne likes this.
  6. TheoAllen
    TheoAllen
    well sure
    Dec 5, 2018
    Marsigne likes this.
  7. Poryg
    Poryg
    Oh, if it's the editor, I think I can't help... :(
    Dec 5, 2018
    Marsigne likes this.
  8. TheoAllen
    TheoAllen
    It's okay I wasn't specifically asking for help lol.
    Dec 5, 2018
    Marsigne likes this.
  9. Poryg
    Poryg
    That script is suicide.
    Dec 5, 2018
    Marsigne likes this.
  10. TheoAllen
    TheoAllen
    Tell me about it.
    Dec 5, 2018
    Marsigne likes this.
  11. Poryg
    Poryg
    First of all, you flooded requestAnimationFrame with Scene_Example.prototype.updateEx. Then you also made a while true loop on window.onload, calling scene update. So you flooded BOTH synchronous AND asynchronous part of the engine with the same function, essentially freezing the engine, since it has no time to do anything else.
    Dec 5, 2018
    Acetonide and Marsigne like this.
  12. TheoAllen
    TheoAllen
    My goal is simple. To display a sprite in the "blank canvas" without creating a new scene and push them in SceneManager to do the work. This probably better to be asked in learning js forum, though, I don't quite feel like to learn seriously rn.
    Dec 5, 2018
    Marsigne likes this.
  13. TheoAllen
    TheoAllen
    So it's like "what will be my least effort to display a sprite only by using main.js?"
    Dec 5, 2018
    Marsigne likes this.
  14. Poryg
    Poryg
    Then you shouldn't push the scene.update into a while(true) loop. RequestAnimationFrame will do the updating for you if you just rework the code a bit.
    Scene_Example.prototype.update = function () {
    //whatever code
    requestAnimationFrame (this.update.bind(this));
    }
    Dec 5, 2018
    Marsigne likes this.
  15. TheoAllen
    TheoAllen
    Can it create a program loop?
    Dec 5, 2018
    Marsigne likes this.
  16. Poryg
    Poryg
    Yes, it can. But you need to call the requestAnimationFrame inside the function you want to call continuously, not outside of it. The way you did it you call update billions of times per second and each of these updates will call requestAnimationFrame on updateEx, so in the end you have an endless surge of functions needed to be executed synchronously.
    Dec 5, 2018
    Marsigne likes this.
  17. TheoAllen
    TheoAllen
    I see, so it has to be a sort of recursive call. Honestly, it's kinda strange, then again I never really try to code a game in js.
    Dec 5, 2018
    Marsigne likes this.
  18. Poryg
    Poryg
    The way MV does it is, it calls SceneManager.update continuously (via requestAnimationFrame). This then calls SceneManager._scene.update, which then does what's necessary to update the scene, as well as Graphics.render (this._scene).
    Dec 5, 2018
    Marsigne likes this.
  19. Poryg
    Poryg
    requestAnimationFrame is in Javascript to serve as a function that is fired automatically at max. 60x per second (but no sooner than the previous one is finished). Therefore it's a sensible ticker and it's the reason why it is used so frequently. while (true) has no limitations on how many times a second it can be called and as such it is unsuitable for loops.
    Dec 5, 2018
    Marsigne likes this.
  20. TheoAllen
    TheoAllen
    I mean, can we use while(true) loop and between each loop, we put a delay? like

    loop this
    do this
    delay(1000)
    endloop
    Dec 5, 2018
    Marsigne likes this.
  21. Poryg
    Poryg
    In Javascript there's no delay or sleep function like in C++, since JS has no sense of time. You can use setTimeout, which will call a function repeatedly after X thousandths of a second (for that you don't even need while(true)), however it's not a loop, because all these calls are fully asynchronous and therefore independent of each other.
    Dec 5, 2018
    Marsigne likes this.
  22. Poryg
    Poryg
    And even using
    while(true)
    setInterval
    wouldn't help, because setInterval will just set a function to execute asynchronously after waiting X thousandths of a second.
    So requestAnimationFrame is the only function that can create a real loop.
    Dec 5, 2018
    Marsigne likes this.
  23. Poryg
    Poryg
    You could potentially do a while(true) loop with Date.now() as a true loop. However, as long as you want a 60 FPS loop, that's not recommended, since requestAnimationFrame is more flexible. It is not however capable of creating loops outside of 60 FPS though.
    Dec 5, 2018
    Marsigne likes this.
  24. Poryg
    Poryg
    Also, requestAnimationFrame is not really a 60FPS thing, it's actually tied to refresh rate of your monitor, so on higher frequencies it might break the game (and is a known glitch with MV games). Nevertheless, due to the fact that it receives a timestamp from a browser that is capable of higher than 1000th of a second precision...,
    Dec 5, 2018
    Marsigne likes this.
  25. Poryg
    Poryg
    it's still more useful to just cap the frames using requestAnimationFrame and Date.now and keep the requestAnimationFrame's flexibility.
    Dec 5, 2018
    Marsigne likes this.
  26. Matseb2611
    Matseb2611
    Not an expert at scripts, but usually endless loops can cause crashes, because they basically never stop till the computer can no longer allocate enough memory to it.
    Dec 5, 2018
    Marsigne likes this.
  27. Poryg
    Poryg
    @Matseb2611 That's not exactly fully true. Endless loops can cause crashes, but usually don't, because they don't consume memory. This was an unhappy soft lock.
    Javascript is the only asynchronous language out there. The asynchronousness is there to mitigate the fact that it's 1. single threaded and 2. has no handling of time.
    Dec 5, 2018
    Marsigne and Matseb2611 like this.
  28. Poryg
    Poryg
    In every thousandth of a second Javascript has time window for asynchronous tasks before executing synchronous ones. If it can't execute the async tasks in time, it will move them to the next frame. And that's where the problem comes. He had while true in an asynchronous thread, which is bad, as it consumes all time for async tasks, but still not enough to soft lock a computer.
    Dec 5, 2018
    Marsigne and Matseb2611 like this.
  29. Poryg
    Poryg
    But he also constantly tried to bombard the synchronous part with requestAnimationFrame requests. This combination was essentially lethal. The browser had no time window to rest, because it constantly had to execute code, leading to 100% CPU usage and soft locking the computer in the end.
    Dec 5, 2018
    Marsigne and Matseb2611 like this.
  30. Matseb2611
    Matseb2611
    Ah ok. Thanks for explaining. I wasn't aware of the differences in synchronous and asynchronous tasks. Currently learning Javascript, so this is quite interesting.
    Dec 5, 2018
    Marsigne likes this.
  31. Marsigne
    Marsigne
    Are you all casting spells?
    Dec 6, 2018
    Acetonide and Matseb2611 like this.