Preloading should help with the "pauses" that you see, and turf atlases may eke out a little more performance for drawing, but I'm not sure how much. When I did the turf atlas test originally it looked like a moderate improvement, but it was difficult to quantify.

What will you be focusing on first and when do you intend to work on it? Thanks!

You should check the performance in 510. This might surprise you.

Updated 510 profile:

https://dl.dropboxusercontent.com/u/10657252/510.cpuprofile

Do you have an idea of when you'll be able to put time into those mentioned optimizations? Because at the moment both of our games (Severed & Eternia) are not playable in the webclient, in the sense that FPS often dips as low as 3FPS for the majority of machines (and struggles at times even for very good machines)... and is generally not presentable.

I'm hoping that you're still confident that the webclient can match the performance of DS. Our game is an ORPG so we'll also need to make sure the webclient isn't bogging down server CPU.

EDIT: Answered in a pager message exchange.

New CPU profile:

https://dl.dropboxusercontent.com/u/10657252/ byond1324.cpuprofile



It could just be a case of confirmation bias, but there seems to be some noticeable performance increases. I'll get a second opinion (WANO) soon.

Pixel Realms wrote:

Movement is typically a steady 40-50FPS, though in new areas it can dip as low as 20 on my machine. The longer you're in an area, the more stable the FPS becomes, and it can take a little while (~5-10) seconds before it's 40+.

Idle is now 58-60FPS, movement is 50-60FPS. Increased onscreen animation (such as mobs attacking) will still cause FPS drops but it's not nearly as severe, though it can hit the 20s. Much smoother overall nonetheless, and I think once your other changes are made, such as preloading, the webclient will be in good shape.

I tested with another 5 people or so, and all were reporting FPS at 40-60, with most consistently at 50+.

Will building an atlas be the next focus for the webclient optimizations?

The worrying part about atlasing is that the performance improvement may be negligible or computationally impossible to achieve with the manpower that we have.

While it's true that buffer swapping from a material change at the GPU level decreases performance due to an inability to batch drawcalls efficiently, the real question is just how much of our hangups are from how we're building and transmitting the data into the GPU in the first place, and just how much of it is actually happening at the GPU level.

This is one of those blind spots that keeps getting harder and harder to research because modern graphics interfaces and tile-based 2D games aren't a place that tend to overlap very often.

Tile-based games are generally designed in such a way that the underlying structure presumes that all tiles are uniformly sized, uniformly positioned, and uniformly layered.

BYOND makes none of these assumptions, so it makes atlasing incredibly complex and also makes drawcall construction almost unoptimizable. Most tile-based engines also assume that different scenes have self-contained graphics. Again, BYOND's design does us no favors here by making absolutely zero distinctions between distinct regions of the gameworld by which we can divide loaded assets. BYOND has two ways to look at assets given the current segmentation model: Load everything ahead of time, or load everything upon need.

Atlasing gets extremely difficult to pull off when you have variable-sized sprites in the mix. Normally, games don't bother atlasing multiple sprites together because there's no point in doing that. There's not enough of them on the screen at once to see improvements, and the difficulty is massive. However, tiles are easily batched by simply assuming that an entire region of the tilemap will all share the same root graphical assets and dimensions. Unfortunately, these assumptions are largely made because it's quite easy to get to the point where you have tens of thousands of tiles being rendered at a time.

BYOND assumes worst-case behavior in almost every category as far as typical 2D game engines are concerned, and it has to make it a nightmare to work with for Lummox as well as a nightmare to optimize.


The other problem in terms of WebGL performance is overdraw. Overdraw is a massive problem for WebGL apps. Overdraw occurs when you draw to the same pixel on the display twice. The more often you overdraw, the worse performance gets. 3D games prevent overdraw by rendering front-to-back. They preserve pixels that have been drawn by recording the draw depth in a GPU surface called the zbuffer. It will only draw if the pixel's z value is closer to the render plane than the one already there. By sorting your polygons front-to-back before sending them to the GPU, you gain significant optimizations due to GPU-level early ejections.

The problem with that? Transparent pixels don't draw what's behind them. conditional branching is slow as sin in a shader. (Shaders operate on the GPU, not the CPU) So you can't just test if a pixel is transparent and unmark the zbuffer. What you wind up doing is sorting semi-transparent graphics to draw last, and then performing a binary AND against the zbuffer on the separate draw call. Then you draw the resulting image over the finalized render. This creates a minimum 2x overdraw if you have even a single transparent pixel in the scene.

BYOND, again, makes no assumptions regarding layering to make any of this easier. Every sprite and every tile needs to assume both transparency and z-order conflicts. This means that your CPU-driven sort needs to reorder the entire drawcall every time an object's appearance changes. And Javascript is slow.

Starting to see the bigger picture now?

So atlasting might not be worth the trouble for the gains we'd see

Might be, might not be. Problems are problems and programming is the art of compromise. Just saying that we're working with several unknown quantities because ultimately we are playing with a double-blind.

If that sounds pessimistic, it's not meant to be. The challenges are there, but so is reality.