[posila] [for 0.17] drawing decoratives is slow

[sthalik]

Drawing decoratives is slow on the Windows Radeon driver. I can't keep up 60 Hz at 4K with max unzoom. It can go down to 30 Hz on some tiles, depending on the amount of decoratives. I was watching the timing info–renderer is over 16 ms and buffer flip takes up to few milliseconds.

Please consider an option to cache the static tile layer (ground and decoratives) and draw it all in one go. It could be very compact, e.g. RGB565. Or instanced glMultiDraw. But you know this stuff well and I shouldn't be giving unsolicited advice on it.

[posila]

Can you try to turn on "Separate lower object atlas" and post if it changed performance in any way, please? The option was made specifically to troubleshoot this particular problem in 0.16

Note: I was wondering why did you turn off mipmaps for trees in your other post, 4K display explains it. That particular problem should be addressed in our rendering overhaul too.

[sthalik]

I have the separate lower object atlas enabled at this time. The issue's happening inside a normal unmodded game but especially visible with a mod adding additional biomes.

Please note, the default of "max possible size" atlas makes a single atlas 800 MB in size: (2^14)^2 * 3. This works on my GPU at sensible speed only if all atlases can fit into VRAM at a single time. That's not the case (regardless of decoratives' usage) with medium quality, all VRAM-saving options enabled, and a very small base like the one in New Hope's first mission startup. With 4096-size atlases it's either 6 unmodded or 11 with the biome mod.

Edit: I get the highest framerate on 2048x2048 atlases. It's strange since 4096-sized are small too but it can make a difference between 43 and 60 Hz.
Edit: Running on a 6xx series Intel GPU renders at ~43 Hz compared to AMD's 60 Hz. It looks like the game isn't starved for fillrate given how puny the Intel is.

Does the "memory usage" option mean a fraction of VRAM, or a fixed value? Setting it to "high" or "all" chokes the framerate. Also does texture quality apply to all objects or only some? Does it keep some things of higher resolution than others?

Could you speak of the rendering overhaul please? Either informally or in a blog post. It's interesting what methods work for you, in terms of a prebaked-sprite game with a continuous world. I'm starting on an indie AI-heavy "cities-that-manage-themselves" game and could use some of your knowledge.

I'm happy you're working on making the graphics part more efficient. Not much to do for me other than sit and wait for the results.

[posila]

I have the separate lower object atlas enabled at this time. The issue's happening inside a normal unmodded game but especially visible with a mod adding additional biomes.

Ah, infamous Alien Biomes, I suppose.

Please note, the default of "max possible size" atlas makes a single atlas 800 MB in size: (2^14)^2 * 3.

It's actually 1GB as it is full RGBA. Our sprites are quite heavy on transparency.

Does the "memory usage" option mean a fraction of VRAM, or a fixed value? Setting it to "high" or "all" chokes the framerate. Also does texture quality apply to all objects or only some? Does it keep some things of higher resolution than others?

Sprite quality applies to all objects, but some doesn't have high-res sprite yet. Sprites have some predefined prioritites and "video memory usage" setting determines which priorities will be included in atlases. So it influences how big atlases end up being or how many there will be. Name of the option doesn'T make very much sense, I suppose it came to be from original intention to keep sprites that are outside of atlases only as blob of data RAM until needed by GPU, in which case it would be uploaded to a texture object. But I don't remember it ever actually working that way, until I fixed it and exposed it in 0.16 under "Low VRAM mode" option. I didn't want to call it texture streaming, because it is just basic implementation of streaming and it can stall graphics pipeline a lot or even cause Allegro to fallback to software rendering and I didn't want people to associate texture streaming with something bad. For the new rendering we are looking into virtual texturing techniques to make proper streaming and to be able to keep drawing in large batches.

Could you speak of the rendering overhaul please? Either informally or in a blog post. It's interesting what methods work for you, in terms of a prebaked-sprite game with a continuous world. I'm starting on an indie AI-heavy "cities-that-manage-themselves" game and could use some of your knowledge.

So far we have only announced it in FFF #230, I am thinking of starting FFF series on the rewrite progress - what we learned, what we tried, what worked for us best etc. But I don't quite enjoy writing blog posts because I'm pretty bad at it

[Jap2.0]

But I don't quite enjoy writing blog posts because I'm pretty bad at it

We don't care (edit: to clarify, I meant the quality of Posila's blog posts)

[Zavian]

But I don't quite enjoy writing blog posts because I'm pretty bad at it

We don't care

Some of us do care. (Edit: Just to clarify, I'm only talking about Posila doing something he doesn't want to, not about about whether he is good or bad at writing FFF).

I know I would be interested in reading that sort of FFF. Maybe someone else on the team would be happy to write them?

[Jap2.0]

But I don't quite enjoy writing blog posts because I'm pretty bad at it

We don't care

Some of us do care.

I know I would be interested in reading that sort of FFF. Maybe someone else on the team would be happy to write them?

I could have phrased that better - if Posila doesn't want to, he doesn't have to, but personally the quality of his blog posts is fine - if you want to look for yourself you can see FFFs 168, 172, 214, 227, 228, and 232.

[sthalik]

What is the reason behind the game freezing on max unzoom and very overused VRAM? It fails to render even one frame more at that point. Is it VRAM thrashing or something more? I saw a video of a guy who made a pacman computer who said the same in the video: "zooming out further makes Factorio crash". He had an immense complex for the game's logic and display but this seems a similar case, with entities drawn over hardware resources.

I greatly appreciate you posita being open about discussing the internals. In fact I should use apitrace already to get more than a bird's-eye view of your drawing process. The challenges you face in that sort of game are unique and interesting.

[posila]

Thanks for the report.

This should be greatly improved in 0.17