• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Antriel

  1. I'm literally working on some hacking solution for my project atm. I'm thinking, instead of pointerdown, use pointerover/out to store some global `action` variable while it's rolled over. And before game boots add `document.addEventListener('click', function(event) { ... });` where you handle the stored action, if any.
  2. You must destroy the created particle manager. Not the emitters. var particles = this.add.particles('spark'); var emitter = particles.createEmitter(); emitter.setPosition(400, 300); emitter.setSpeed(200); emitter.setBlendMode(Phaser.BlendModes.ADD); this.time.delayedCall(3000, function() { particles.destroy(); });
  3. It's work in progress but yes: That said you can work with any JS without any defs in TS. So the answer to your question would be implicit yes.
  4. Few notes: Phaser 3 smooths out deltaTime so I can't see it ever being over 1000. That check isn't really needed. You pass the raw elapsed time to `phys()`. That's not fixed timestep, you should pass `frameduration` (which is really bad name imo, it's not duration of the frame, it's your physics timestep). What you pass into render isn't `delta`, it's progress towards next update that is to be used as interpolation value. I usually call it `alpha`, and although the name doesn't matter, I would avoid calling it `delta` as that's not what it is.
  5. I'm not very versed in terms as far as math and physics goes, but basically physics engines use only approximations to calculate what happens. There's a few approaches and each have their pros and cons. If you take basic Euler: position += velocity * dt; velocity += acceleration * dt; You will find out that different `dt` will give you different result within the same time. Semi-implicit Euler (just swap those 2 lines) is lot better, but still wrong. You can read pretty good article about it here. So basically, to have predictable and stable physics, you want to run your `physics.update(dt)` with fixed `dt`. That means it's the same every time. But that also means you can't just call it once every frame, because time between frames won't be exactly `dt` every time. So you do something like: var accumulator = 0; var physicsTimestep = 1/60; function renderUpdate(timeSinceLastFrame) { accumulator += timeSinceLastFrame; while(accumulator >= physicsTimestep) { accumulator -= physicsTimestep; physics.update(physicsTimestep); } render(timeSinceLastFrame); }
  6. More precise would be to say that browsers support svg rendering and Phaser can use that to generate textures to render. The main difference is that you can't easily scale things around while maintaining pixel perfect rendering and anti-aliasing for free. OpenFL had some swf rendering thing that worked on html (real vector rendering), but I'm not sure if it's still there and works (this was many years ago).
  7. Yes, alright. Except that it might not be stable on gpu-synced displays. Using provided delta time is of course the way to do anything, but you can't always apply it raw like that. Thus the need for fixed timestep for physics and basically any kind of numerical integration. As I mentioned before, even simple `speed += acceleration * dt` will behave differently at different dt.
  8. When it comes to syncing with server, it gets much more complicated. Depending on the approach you take, from simple interpolation from past data with a buffer through basic prediction and correction to converging prediction. All these, even though work similarly to rendering interpolation with fixed timestep physics, are there to solve different kind of problem though. I wrote an article about Entity Interpolation for multiplayer games, but it's not really aimed at total beginners. That said I do link to other articles that describe the basics, so all this should get your started.
  9. RAF will fire as fast as it can, synced to display refresh rate. So on 60 Hz display, you get 60 Hz or less. On 144 Hz display it will run 144 Hz or less. On g-sync/freesync/hdmi 2.1 vrr, it can be anything. What needs to be understood here is that phaser doesn't provide you with proper game update loop. It gives you RAF loop (or fallbacks). It's on your to handle whatever you need, e.g. fixed timestep physics with interpolation. V3 had recently added automatic fixed timestep and manual update options to matter.js physics. I'm not sure if the automatic fixed timestep is still running off RAF (which makes the option kinda pointless), but you can use the manual option in any case. In my case, if the game is mostly async tween actions (think match 3 sliding stuff), I just use tweens and don't care about deltatime. As soon as I have any kind of physics or time based logic (even simple speed += acceleration), I switch to fixed timestep with interpolation. I did describe my approach in at least one topic here
  10. In that case it doesn't really matter, whichever is easiest. When doing it during physics loop you might save yourself additional iteration, but that's negligible so really whichever you like more.
  11. It seems to me that maybe you misunderstood what interpolating positions means. Fixed timestep for physics is great, but that means you are out of sync with render rate. You want to update gfx positions inside the RAF loop, but you can't just set them to what physics tells you it's at at that time. Or well, you can, but then you are limiting yourself to whatever frequency your physics runs (not to mention frame pacing issues). The optimal solution is to do what that article explains and update position within your reneder loop by interpolating: `State state = currentState * alpha + previousState * ( 1.0 - alpha );` which would translate to something like `obj.gfx.x = obj.body.prevX + (obj.body.x - obj.body.prevX) * alpha;` I once talked about this approach here too: But if you don't want to interpolate, then it doesn't really matter where you update the positions.
  12. This is best: You can't tell how often will requestAnimationFrame fire, so you should interpolate your positions.
  13. Actually, by default it is backed by RequestAnimationFrame, which can run at whatever. You shouldn't assume 60 FPS for your logic.
  14. Antriel

    typescript defs

    Docs are the current priority. I haven't heard of any ETA, but it probably won't be long now. Meanwhile there's and modified ones here Although there's really not much reason to wait, you don't really need the defs to make something
  15. The TS Defs are basically waiting on jsdocs to be fixed. Not ETA from me, but @rich could tell.
  16. Nowhere yet, I'm currently waiting for instructions. PR towards the defs would be mostly pointless as the defs are generated and PR towards the code are also mostly pointless as the majority of issues is with the docs themselves not the generator.
  17. Antriel


    Not really that hidden: objects/particle emitter/
  18. Antriel

    Phaser 3 API's?

    They currently live in this folder on github. Not sure when they will be properly launched and published, but you can download them from there.
  19. First step is getting the jsdoc convert to valid TS defs without any hacks. That will require lot of fixes in the actual jsdoc. Then we can think about these dynamic plugins, possibly adding custom jsdoc tag for it. It shouldn't be too difficult I hope. In any case it will definitely have to be automatic and based on the jsdoc, not custom per-plugin manual hacks in the converter or anything like that. By the way, a lot of work already went into the jsdoc being TS friendly, but it's more difficult than it might seem on such a big project. JSDoc itself doesn't help there much either
  20. Compiled down the current version of the TS defs for Phaser 3. It's work in progress and hackishly processed to be valid (i.e. doesn't generate TS errors), but it seems to work. Get it here: phaser.d.ts Let me know if there are issues (although there's already plenty that I know of).
  21. Antriel


    This folder contains generated docs. I'm not sure they're hosted somewhere yet, but you can download them from there and use them locally.
  22. Yes, there will be TS defs for Phaser 3.