ConstructLaw's Forum Posts

  • 2 posts
  • Thanks!

    So, as I kinda said, portability is my primary goal.

    I do like the idea of an event driven approach, so this

    method sounds kinda cool. Especially since the event's would fire from the worker at a desired frequency.

    It might be that I'm simply trying to have something I know I can't have? LOL. (I'm weird like that!)

    Anyhow, I've abandoned the idea for now, because I'm pretty sure

    it's not possible. I just wanted to test myself, and then I was curious if any construct/JavaScript guru out there could actually solve this. (I'll still take a solution if anyone has one!)

    Game Over!

    Thanks for reading!

    Merry Christmas!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Hey all!

    I'm new to construct 3 (and webwokers!) (new-ish to javascript) and loving it!

    I do hope this hasn't been discussed before - I did search, and was presented with over 5,000 results of which the first like 20 I read were not relevant to me, so I kinda gave up!!

    ..anyhow, I'm trying to make a super-kick-arse inputWorker that sends my game action events by polling input device(s). I got quite a bit designed on paper and got rather excited, then I read that workers cant access the DOM and therefore cant hook the keyboard. So, I thought to myself "Well, construct probably has it's own in the runtime, somewhere somehow, maybe I can use it?" So I tracked the keyboard down in the runtime! Good! So then I tried to use it in my worker and got told it doesn't exist. So, I made an event to send the runtime to the worker from the main. Which brings me to my spooky problem. The event triggers, ofc, but the runtime comes into the worker empty!

    Some code:

    Here's me making the worker and firing the event to send the runtime in the main:

    const inputWorker = new Worker('InputWorker.js');

    inputWorker.postMessage({ runtime: runtime });

    And here's the event in the worker:

    self.onmessage = function(event) {

    runtime = event.data.runtime;

    console.dir( runtime ); //Empty!

    //console.log(runtime.keyboard.isKeyDown("ArrowRight"));

    };

    My *ONLY guess is that the worker is not loaded? But my kung-fu falls short of testing for or awaiting the load in this case. The Worker() constructor doesn't seem to support promises, but somehow is async itself? So my limited javascript has me weirded out about this!

    I also thought even if I was to solve this, I just feel I'm heading down a strange path with this input worker. So in addition to a solution to my code problem, does anyone have any experience with such a beast? Any success or horror stories?

    I do a lot of little prototypes, and I figure having a great input system packaged up like this is great for portability. That's more my goal with this, as opposed to performance. I wanna write one full featured system once, and bring it with me everywhere I go. (I know webworker support isn't 100% either - I accept that.)

    (I know I could write say a class and run it async in the main thread and be kinda done with it, but I fancy really separating it with the worker method - it feels right to me!)

    Any ideas on my code issue or a little advice about such a beast would be appreciated. Sorry for two crazy questions in one post - I think I need sleep now! 😁

  • 2 posts