• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Antriel

  1. I'm not really sure what's happening here from just the pic. It looks as if the RAF was throttled by the browser, considering the total time is just ~7ms. No, there shouldn't be any additional columns. You do physics along with the render, but you do enough physics steps to catch up if needed (or none if not enough time passed). If the movement rate (not FPS) isn't stable, it means the fixed timestep isn't implemented properly.
  2. Compare the accumulated delta given to you in the update function with actual real time delta.
  3. Seems to be the case from the code, but I didn't test it. It runs within the scene update loop inside another loop.
  4. Maybe something to do with how Phaser smooths the delta time. I would try to debug and see what are the raw delta values and the actual delta applied to Arcade. The fixed timestep code in Arcade's World.update looks good.
  5. Hmm, looking at the source, it seems the ticker doesn't honor the fps settings and just goes with 16 ms ticks with `forceSetTimeOut`. Not sure if that's intended or a bug @rich?
  6. Assuming you want to render just 2 frames instead of as much as the system can handle, try changing the fps part of the config into: fps: { target: 2, min: 2, forceSetTimeOut: true } Unless you force usage of setTimeout, Phaser will use RAF to trigger updates and render, which will try to sync to your display refresh rate. Also without that `min` part, the ticker would lower the delta time to 5 FPS (the default), so if you want 2, set the min too.
  7. If you are using a physics engine, you need to call its update using fixed timestep. Both Arcade and matter.js have that available, if you look at the docs. Though I'm not sure it's properly implemented. In comes down to doing what is described here:, basically decoupling render and physics update. I also talked about that here:
  8. Judging from the server response headers it's uWebSockets.
  9. This issue will appear always with whatever tiling you use if you render it on the GPU and scale things around. It's just how GPUs work. To fix it, you need to extrude your tiles in the texture atlas. That is, repeat the border pixels of every tile. Texture Packer can do that, or do it yourself in your assets pipeline. It's called pixel bleeding and what happens is that due to how GPUs work, pixels beyond the tile are sampled from the texture atlas, resulting in artefacts like this.
  10. It's a snippet from my Haxe code. It's basically a static function I call right after I create a game instance, so you could just copy what's inside. Also `js.Browser.window` is just Haxe's way to get to the global window property, in js you can just access `window` directly I think. Otherwise it should work as is.
  11. Thanks Nope, started as Phaser 3 game since the beginning sometimes in summer 2017. The GFX are CC0 though, so it's possible you saw some other version. I thought about it, but didn't want to distract the player more. It could work though.
  12. Interesting. I do that already. It's designed for landscape mode, so in portrait the ground gets too big, but it's perfectly playable. I guess safari has some issues with scaling, will have to check that out when I get some time. Thanks for the report. EDIT: Thinking about it, it's probably due to my website iframe code not being responsive at all, the game itself would work fine. See here: I will have to update the website code to be more responsive eventually. Yes, like the hundreds of others
  13.\geom\rectangle\get points.js\geom\rectangle\marching ants.js might help? you can look at the phaser's source to see how it's implemented
  14. Well, you can have pixelart in 3d games, that's not an issue. It's more about that old-school feel which would be difficult to simulate in 3d environment. That youtube video you shared doesn't look like pseudo 3d, more like actual 3d with 2d cars/items. At least judging by the intro before race start. I never did pseudo 3d, but from what I googled it doesn't seem too difficult. That said, if 50k is "magnitudes" and not just one order of magnitude away, I fear it is indeed too little. Especially with any kind of usable multiplayer. Two orders of magnitude away would barely get you basic pseudo 3d driving without texturing and with one simple road.
  15. Why the fake 3d instead of normal 3d? Just the rendering itself isn't very difficult. Physics a bit more work depending on realism required. Multiplayer a lot more work depending on other factors like the physics. I can see doing it for much less than 50k, depending on the scope.
  16. Test your tapping and timing skills in this fun game. Traditional flappy gameplay, tap to stay afloat! Avoid obstacles and get as far as you can. Unlock five different secrets, each funnier than the previous one. Can you unlock them all? Play the game here: Developed in Haxe, using phaser v3 You can put the game on your portal using this url. The game is also available for licensing.
  17. Antriel

    Upload game

    Are you using 3.7.1 which is listening on the click event to activate sound? Previous versions only listened to touch events.
  18. Well there is perspective camera in phaser 3, but I'm not sure how usable it is for now. For a simple card flip I would look into using a quad anyway, it should be just a bit of matrix math.
  19. You could use Quads, but keep in mind it's WebGL only.
  20. Can't get over the first hill If I had to guess, you're not using fixed timestep for physics and it breaks with low dt.
  21. Just a browser window with the game in it. The game will always stretch to fill the whole area it has available as portals iframe it with whatever dimensions they want anyway.
  22. I'm using code from that example (game and cameras resize) + some basic css. It could be part of Phaser, but honestly that's all I will ever need. If you want proper responsive game, you have to implement it yourself anyway. This is my custom ScaleManager's initialize method that I call after I create the Game instance (Haxe code). public static function initialize(game:Dynamic):Void { function resize() { var w = js.Browser.window.innerWidth; var h = js.Browser.window.innerHeight; var scale = Math.min(w / Config.DEFAULT_WIDTH, h / Config.DEFAULT_HEIGHT); game.canvas.setAttribute('style', ' -ms-transform: scale(' + scale + '); -webkit-transform: scale3d(' + scale + ', 1);' + ' -moz-transform: scale(' + scale + '); -o-transform: scale(' + scale + '); transform: scale(' + scale + ');' + ' transform-origin: top left;' ); width = w / scale; height = h / scale; game.resize(width, height); game.scene.scenes.forEach(function (scene) { scene.cameras.main.setViewport(0, 0, width, height); }); } js.Browser.window.addEventListener('resize', resize); if(game.isBooted) resize(); else'boot', resize); }
  23. Antriel

    mmorpg advice?

    Right, yes, thanks for correcting me. I mainly meant event-driven/non-blocking as opposed to multi-threaded. I agree with the rest, I only pointed JIT out because saying JS is interpreted and slow seemed like too big an oversimplification. I have no late experience with PHP, but I doubt that. Compared to JS it has much less support which will mirror itself in available libraries and community help. That said, it doesn't much matter what you start with. It's quite possible you will need to change your environment a few times as you requirements and design changes. Starting with the basic requirement: a WebSocket server, you might find out the ones for PHP aren't as fast as you need and might need to find something better. But that doesn't mean you can't start with what you know now.
  24. Antriel

    mmorpg advice?

    JS is JIT-ed where possible. NodeJS uses V8 engine (same as chrome), and is usually not much slower than well written cpp. The single vs multi threaded approach – there's high overhead with switching threads (not to talk about cache invalidation), which causes the issues. You can handle a lot of connections on single thread, so the new NodeJS based servers like nginx actually perform better than old school multithreaded apache.
  25. 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).