Jump to content

Rendering Questions


Loonride
 Share

Recommended Posts

I have been working for a while on a game called loons.io (https://loons.io) using Phaser 3. Some people have said the game is very laggy for them, and there are some assumptions about performance that I made previously which probably led to frame rate drops for players. If you can give me advice on any of these questions, that would be very helpful.

 

1. Are large GameObjects.Graphics bad for performance? If I have a single, huge circle, most of which is not visible on the screen, will that cause any problems? Similarly, if I draw some polygons far from the origin of the GameObjects.Graphics, is that bad? Or should both of these things have a negligible effect?

 

2. Are tileSprites the best option for a repeating pattern that will not change? This is how I have the grid pattern in my game, then simply shift it by the dimensions of a single tile each time the player moves a certain threshold.

 

3. Will scaling up the canvas within CSS affect performance? I have a canvas container which I adjust to fit the screen, then I do width: 100% and height: 100% for the canvas. Is scaling up the canvas element different in any way from the options that the Phaser 2 ScaleManager provided?

 

4. How much does the actual size configuration of the game affect performance? For example, my game is currently at 720x1280. Would I recieve high performance benefits from 540x960, at the cost of quality on screens larger than those dimensions?

 

5. Does camera zoom affect performance? Obviously it will if more is being drawn as a result of zooming out. But what if you set a zoom of 0.5, then scale the dimensions and everything to 2 for all of your game objects, would it perform the same as zoom of 1 and scale of 1?

 

6. Ultimately, is Phaser 3 ready for rendering to the same extent that Phaser 2 was, or should I still be using Phaser 2 for things such as the ScaleManager or to avoid frame drops?

Link to comment
Share on other sites

1 - It's not the size of the Graphics, it's the complexity of the paths within them. For example, a massive rectangle would cost hardly anything to draw. A massive circle, on the other hand, would cost more because of the way Graphics triangulate all of the paths every frame. If you're using more complex paths (like polygons or curves or arcs) then see if you can use the native Shape objects instead, because they cache their triangulation data so don't calculate it each frame, which makes them faster. Even if the circle within the Graphics object isn't visible on-screen, it will still be triangulated and drawn each frame anyway. There's no culling, especially not for Graphics objects.

2 - It depends on the size of the texture and the area you are covering. First of all, I see lots of people create TileSprites that are the size of their game world. This is insane. Please don't do it! They should never really be any larger than the canvas size. The way they're supposed to work is that you scroll the texture inside of them in time with your camera (using tilePosition), so you get the effect of a scrolling background without needing to have a massive texture in your game. Secondly, they're not always faster. If the image you are tiling is relatively large then it may actually be faster to just render a group of Images in a grid arrangement to simulate the tiling area (or, if you don't need rotation, I'd use a Blitter object) because then in WebGL it will all be batched into a single draw call, providing the base texture is shared. If your game is running in Canvas anyway, then always use a TileSprite as it'll be faster than repeated drawImage calls. If you're primarily in WebGL then profile it and see what happens. WebGL will have to batch flush to draw the tiling texture, because it's canvas backed, so it's a bit of a trade off between this vs. using a grid of images vs. using a larger single texture where you've just repeated the texture within Photoshop or similar.

3 - Theoretically, no. In reality, I would expect the browser to have to do more work to handle rendering the scaled canvas, but it should be (hopefully) minimal. It's out of your hands though, it's down to browser implementation. The Scale Manager works in a similar way (i.e. using CSS to scale the canvas) as it's the best way we have.

4 - It matters massively. Next to texture batching, it's the single biggest contributor to performance. The bigger, the slower, because the more work the GPU has to do. On desktop the difference may not be much (but even then, there plenty of crappy desktop GPUs) but on mobile the difference can sometimes be like night and day.

5 - No, it won't make any difference.

6 - It's already faster than v2 by quite some margin and it isn't going to get any slower, only faster still.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...