Antriel

Members
  • Content count

    131
  • Joined

  • Last visited

About Antriel

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://antriel.com
  • Twitter
    PeterAchberger

Profile Information

  • Gender
    Male
  • Location
    Slovakia/Czechia

Recent Profile Visitors

1,739 profile views
  1. Looking good now Technically not. It's there to improve the smoothness and avoid frame skips. Even if the display has the same refresh rate as physics, it will eventually go out of sync (frame skips, etc.). What happens then is that you could possibly be juuuust not enough to update physics, so you render the same frame again. That will cause visible stuttering. Alternatively, if your user has higher refresh rate display (120/144, even more Hz displays are pretty common now), you essentially limit them to whatever your physics update is. By providing alpha or however you call it. That is, a relative value of how close we are to next update, and then use that for interpolation, you essentially remove the stutter and enable smoother movement than your physics update rate is. The interpolation itself looks like this: `obj.pos = (obj.next_pos - obj.old_pos) * alpha + obj.old_pos;` Where `obj` is whatever you update in physics and `pos` is whatever property that is (x, y, rotation usually). The `old_pos` and `next_pos` are previous and current values respectively. So in your physics update, first thing you do (before running physics) is `obj.old_pos = obj.next_pos` for all objects. And then instead of updating `pos` directly in your physics update, you update `next_pos`. At a cost of at most one physics step additional input latency (which is really negligible in the whole picture), you get smooth movement at any display refresh rate (if it's high enough for smoothness that is :D). Alternatively, you could run your physics using this approach at much much higher rate, say 200 Hz. And then interpolation stops being that useful. This is usually done if you need very stable physics and can afford the computational time (as you would be running multiple physics update per frame).
  2. https://github.com/photonstorm/phaser/issues/3497 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.
  3. how to destroy particle Emitter ?

    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(); });
  4. Does this version support typescript?

    It's work in progress but yes: https://github.com/photonstorm/phaser3-docs/tree/master/typescript That said you can work with any JS without any defs in TS. So the answer to your question would be implicit yes.
  5. 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.
  6. 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); }
  7. Alternative HTML5 Platform to Adobe Air?

    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).
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. This is best: https://gafferongames.com/post/fix_your_timestep/ You can't tell how often will requestAnimationFrame fire, so you should interpolate your positions.
  14. update vs render - frequency

    Actually, by default it is backed by RequestAnimationFrame, which can run at whatever. You shouldn't assume 60 FPS for your logic.
  15. 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