Antriel

Members
  • Content Count

    221
  • Joined

  • Last visited

  • Days Won

    1

Antriel last won the day on June 5

Antriel had the most liked content!

About Antriel

  • Rank
    Advanced Member

Contact Methods

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

Profile Information

  • Gender
    Male
  • Location
    Slovakia/Czechia

Recent Profile Visitors

3166 profile views
  1. This is a copy of the first devlog I published on my blog a few months ago. You can see all the devlogs and sign up for the newsletter to get the next ones directly to your email at https://antriel.com/rpg/. Devlog 1 Few days ago I have decided to start an RPG project, as that’s what I’ve always wanted to make. I will be fairly limited with graphic assets and time, but at least the coding part will be fun. I will make do with what I have available. Right now I have depth sorting implemented: I’m using art assets. Tiled for level editor. Haxe as programming language. Phaser 3 as framework. Coffee as fuel. So far I’ve went through map loading (surprisingly simple in Phaser 3), animations based on keyboard input and basic collisions using Phaser’s Arcade. Then I switched to using Differ for collisions, because Phaser’s Arcade physics couldn’t handle custom shapes per tile by default. Given that I expect more requirements from the collisions/physics system, I like having more control over things instead of letting Phaser handle it all for me. After that, it was time to refactor all the code, because it was getting messy. I choosed to use ECS architecture, because I used it before and I find it very nice for these kind of games. Especially considering how big the game might grow, it’s important to keep the code clean. I was deciding between using Elias Ku’s ECX library and Kevin Leung’s ECS. Ultimately it probably doesn’t matter, but I chose Kevin’s. At this point the ECS consists of RenderSyncer, KeyboardInput, Movement, PhysicsDebugDraw, PhysicsSystem systems, and Velocity, ActorState, DifferShape, InputControllable, Position, Renderable, StaticCollidable components. This will change a lot as the work continues. Next I made a custom preprocessor for Tiled level files. I’m converting them to custom JSON that contains only the data I need, in format the game expects. This also allows for making rudimentary checks against typos and missing data. It also means I’m no longer using Phaser’s tilemap loader, and instead had to write a bit of code to populate the tilemaps myself. While this is some extra work, it allows for special handling. Last thing I did was implement depth sorting. Phaser can’t render different tiles at different depth, or allow you to insert something (like a moving character) in between tiles. If you look at the GIF on top, you see the character can move behind and in front of the tree log and the sign board. If they were part of a Phaser’s tilemap layer, it wouldn’t work. Instead, I mark the layer in Tiled as requiring depth sorting, and the game then creates individual depth sorted sprites. This way I didn’t have to change the level editing workflow and won’t need to manually handle future similar cases. Next I plan to work on some UI, changing location (loading different maps, like insides of a building), NPCs and interaction, and combat system. Subscribe to newsletter.
  2. Now it's `this.scale.resize`. The whole scale manager basically does all of this for you. Not entirely what I do though, but you can choose between scale and resizing.
  3. I have no idea how they did it, but technically it shouldn't be too difficult to get it working with the original html5. Switch does have a browser, it wouldn't be far-fetched if it supported webgl. And if not, bundling it with V8/chakra and doing some thin wrapper over opengl should also work, although that would probably require some tinkering.
  4. Think about the order of the items in the container. EDIT: And I just see it was pointless to waste time here, as you already had it solved on the Phaser forum...
  5. Could be the automatic depth sorting, implemented by heap sort iirc. Not entirely sure it's faster than insertion sort (at least at smaller counts I would expect insertion to be faster, but there it probably doesn't matter), but in either case, whenever anything is added to scene, it's pushed to the end and the child array is marked to be sorted. Then again, every other engine has to do something like that at some point too.
  6. Synthetic benches aren't very useful when it comes to big numbers. It all comes down to how the pipeline is setup, which is usually based on real-world uses and not optimizing for benchmarks.
  7. That is a bit weird. It shouldn't be happening often, maybe at most 1% of messages unless you are on very bad network. This leads me to think that the server has Nagle's algorithm enabled (TCP_NODELAY – buffering of data until there's enough to send out, it is usually enabled by default and the higher latency could make it more aggressive.). Try looking into that.
  8. Server sends message A then B. Message A gets lost along the way, client receives message B, but given how TCP works, it won't be accessible yet (head of line blocking). TCP handles resends and server sends message A again. Client receives it and supplies A and B one after another to your application. That's one very realistic option (longer the path, higher the chance for packet drops). But it can be anything that causes one message to arrive sooner or later compared to other message. Routes can change, packets can get delayed. In general, you can't depend on the rate to be perfect.
  9. They get rendered, although there is a way to cull them if you want (not always faster though, as it needs to figure out which are in bounds, but you can always make your own culling that would be faster if possible). No idea about fillrate of off-screen stuff. They do get send to GPU for rendering, but the actual fragments won't get rendered if they are outside, so I would reckon it won't affect fillrate. But I'm just guessing.
  10. Antriel

    OkijinGames Visual Fx

    Might be best to ask the man himself, pinging @OkijinGames. He did write this about it though:
  11. On WebGL, unless the engine does something really silly, it mostly comes down to fillrate (amount of pixels you push), and amount of data the CPU needs to prepare. That depends on the rendering pipeline. Usually it's much more worth it to send a lot of data, so it is flexible. The synthetic benchmarks that just try to spawn as much as possible don't really tell much about real-world performance. In either case, here's example from phaser that uses special object optimized for performance (doesn't send as much data to the gpu, but can't rotate/scale the objects). For me it doesn't slow down at all at 20k. http://labs.phaser.io/view.html?src=src\game objects\blitter\benchmark test 3.js I don't have experience with pixi, but knowing how Phaser 3 works, I would be quite surprised if pixi was substantially faster in anything. I would expect them to be similar, or pixi slightly worse. Of course Phaser being a whole game framework, there is some extra overhead, but definitely nothing that could cause problems.
  12. Personally I handle logic separate from Phaser, using it just for the rendering. What I use is a combination of update and my own setTimeout to move the game logic forward and send inputs to the server. Basically this, except I have 2 entry points (both RAF, i.e. Phaser's update, and my own timer). On top of that is interpolation of other entities, prediction of player's entity and syncing time with the server.
  13. It's a way to have refresh rate of something locked to signals from something else. I use it to sync clients time with server network tick.