Friday Facts #251 - A Fistful of Frames

[luc]

Why will the library be running a custom build of Factorio? Doesn't it run on Fedora by default, or do they have some funny hardware on which you need a special build, or what will be different in that build?

[Tricorius]

I don’t have anything technical to add. I’m just a web developer who dreams of being a game developer.

But I still love these technical posts. They are quite fascinating. I do like how the team is able to simplify highly technical topics and make them digestible for those of us with lesser knowledge.

I also love the humor in this thread. Even though we might disagree about bots, this is one of (if not THE) best gaming communities.

[ignatio]

Interesting optimisations, but when reading FFFs like this I can't help but think "why don't they ever release 1.0 and start working on an expansion?"

Your Steam EA has been extremely successful, but the backside of that is that you probably shouldn't expect the majority of sales of this game still to be in the future. I'd hate to see you run dry and have to close down before you have a follow-up ready.

The technical quality of this game is already far beyond what almost all players require. Even important stuff like the UI overhaul might not translate to enough more sales to motivate holding off a 1.0.

I bought the game two years ago and still enjoy it more than any other title. Please give me a reason to send you more money. (Edit: Of course I got the t-shirt too. )

[luc]

I send them more money by selling it to friends, either as gift for a birthday or by recommendation

[posila]

I'm confused how all this detailed performance knowledge is going on and then the topic is performance on 25k sprites.

I am aware 25k sprites is not impressive benchmark. We have chosen the number of sprites that the game will render most of the time, instead of extreme cases. On my home computer (i7-6700K) I still get 60 FPS in scenes with 300k sprites at maximum. In vanilla I don't think you'll ever see that many, but you might see 100k which was starting to be a problem in the previous engine. At the current engine about half of the time is spent by going through the game state collecting states of the objects that need to be rendered and sorting them by their position so they overlap each other properly. (We have not touched this step at all, so same absolute time was spent on this step in the previous engine too).

It seems to me you implemented a particle system, and articles about particle systems were great source of information for us, but we have needs for more generic sprite drawing. For example we need to be able to control per sprite scale (independently for x and y axis), rotation, arbitrary cut-out from any sprite, and tint. Need to change blend modes and effects per sprite, etc. So I don't even dream to be able to compare ourselves with particle systems.

What you described reminded me we were considering to put texture coordinates for each registered sprite into a buffer that would live on GPU and fetch it dynamically in VS by index, but than it didn't seem to be worth effort since we wouldn't save us much data when implementing point sprites through instancing/geometry shader. We might revisit the idea if it will look like this needs more optimizing.

Thumbs up for F#

...

We have trouble to figure out how to utilize 3D optimization techniques, like Z-buffer, because all our sprites have some semi-transparent pixels and we often render something in a way that blends with background in some way, so we draw everything from back to front. I was thinking if we could use alpha-to-coverage, but that would require supersampling enabled and we don't have other need for supersampling and I am afraid it might be even bigger performance issue to have it enabled on 4K screens. I was looking also into some techniques of doing order independent blending, we might experiment with that.

[exi2163]

While i usually endulge technical aspects of FFF i'm out of this one. The only graphical stuff i did was painting images with GDLIB in PHP and using the G15 library for some text and rectangles in EVEMON. Maybe one of you guys who does this for a job could dumb this down a bit? So what i know is that the engine needs to draw us something nice to look at. So for example trees (because we all love chopping them down one by one). The tree is a sprite (2d bitmap or a picture) which is cut out of a bigger bitmap because loading one jpeg (i know noone uses jpegs for this, its tiff or this dx-compressed stuff) is faster than loading a few thousand, correct?

So i assume we have a bitmap that contains a lot of different trees that is loaded into the game engine's memory. Now we need to tell the gpu to draw this. Because the gpu needs to have the picture first we copy it into the gpu's memory, right?

Now the gpu has the larger bitmap and we now want it to draw the second from right tree, so we give it the x/y coordinates of the start and end points of the sprite to copy from the bitmap?
Is this information that sprite draw call?
I guess we also need to tell the gpu where to draw it and how large it should be (because we can zoom in or out). Are these those 6 vertices?

Because we have 100 trees that would be 100 draw calls which would be what goes into our sprite batch (And we do those because starting talking to the gpu is time expensive)? For what do we need a vertex buffer now? Also, what is a vertex buffer?

[Lubricus]

While i usually endulge technical aspects of FFF i'm out of this one. The only graphical stuff i did was painting images with GDLIB in PHP and using the G15 library for some text and rectangles in EVEMON. Maybe one of you guys who does this for a job could dumb this down a bit? So what i know is that the engine needs to draw us something nice to look at. So for example trees (because we all love chopping them down one by one). The tree is a sprite (2d bitmap or a picture) which is cut out of a bigger bitmap because loading one jpeg (i know noone uses jpegs for this, its tiff or this dx-compressed stuff) is faster than loading a few thousand, correct?

So i assume we have a bitmap that contains a lot of different trees that is loaded into the game engine's memory. Now we need to tell the gpu to draw this. Because the gpu needs to have the picture first we copy it into the gpu's memory, right?

Now the gpu has the larger bitmap and we now want it to draw the second from right tree, so we give it the x/y coordinates of the start and end points of the sprite to copy from the bitmap?
Is this information that sprite draw call?
I guess we also need to tell the gpu where to draw it and how large it should be (because we can zoom in or out). Are these those 6 vertices?

Because we have 100 trees that would be 100 draw calls which would be what goes into our sprite batch (And we do those because starting talking to the gpu is time expensive)? For what do we need a vertex buffer now? Also, what is a vertex buffer?

The GPU can only draw triangles (makes sense for 3D graphics). So drawing an rectangular sprites needs 2 triangles, hence 6 vertices. Possila is talking about how to optimize the CPU side and communication to the graphics card and ways to send fewer vertices and doing magic in the GPU to calculate the extra...

[Paul17041993]

Now to upgrade the entire sprite system to openCL, and probably everything else eventually...

On a more serious note, has vulkan been considered as an even better latency and performance jump for modern hardware? particularly integrated GPUs and/or in laptops where less CPU use has a positive impact on battery life, as well as better performance in general. AMD has a simplified vulkan front-end you could use which should work on all hardware and platforms (other than OSX).

[ratchetfreak]

In newer opengl versions you can have buffers mapped persistently. Then you can do away with the map/unmap operation.

I know, but we are really doing OpenGL just for legacy support, so it doesn't make sense for us to have two different backends for OGL 3.3 and 4.5. We will do Vulkan instead.

I believe you only need to adjust 3 places to support optional persistent mapping: the init, glMapBuffer and glUnmapBuffer.

in init you test the presence of the extension/version and map the buffer if so.

at glMapBuffer you just return the previously mapped pointer instead

at glUnmapBuffer you instead flush, if the mapping is coherent you don't even need to do that.

Of course the slippery slope argument comes into play when doing this kind of customization.

[Jap2.0]

Now to upgrade the entire sprite system to openCL, and probably everything else eventually...

On a more serious note, has vulkan been considered as an even better latency and performance jump for modern hardware? particularly integrated GPUs and/or in laptops where less CPU use has a positive impact on battery life, as well as better performance in general. AMD has a simplified vulkan front-end you could use which should work on all hardware and platforms (other than OSX).

Yeah, they're planning on adding support for other APIs eventually - see FFF 244 (and the associated forum thread).

[Durabys]

I would like to know to how late will that LAN Party be open? You said 16:00 o'clock..but when is the ending time? I need to know if I should book a hotel in Prague for the 23rd or not.

[WarpZone]

https://www.factorio.com/blog/post/fff-251

What happens if Batch Size exceeds Buffer Size?

[ThorsDragon]

My vote is for option 4. It honestly sounds the best, and the problems are minor, and would just take getting used to. I love your guy's work, as always!!!!!!

[Durabys]

https://www.factorio.com/blog/post/fff-251

How long will the LANfest take? Will it end before midnight or in the morning? When please. Thanks.

[Danjen]

As an amateur gamedev that does it as a hobby, this sort of article is very helpful and interesting to me. I appreciate it when people do technical articles that explain why they chose a technique and why it does/doesn't work.

I'm working on my own small engine using SFML/C# (thus OpenGL) so a lot of how Factorio handles things and reading about it is very relevant to me. Using vertex buffers / arrays of vertices pushed to the graphics card seems to be the fastest general approach to rendering, for example. I'm still muddling over how to set up texture atlases like how you guys did in the game debug info. Cool stuff!

[bobingabout]

I am pleased to see that the i7-4790K is amongst the fastest (3rd, but by a small margin) of all the CPUs you tested.
That just re-enforces the fact that I really don't need to upgrade my computer.

[Visione]

Awesome and interesting post! Can't wait for the VRAM optimization FFF

[dee-]

I know, but we are really doing OpenGL just for legacy support, so it doesn't make sense for us to have two different backends for OGL 3.3 and 4.5. We will do Vulkan instead.

Oh happy joy!

So Factorio is going to be Vulkan with both DX11 and OGL as backup?

[Klonan]

https://www.factorio.com/blog/post/fff-251

How long will the LANfest take? Will it end before midnight or in the morning? When please. Thanks.

The library closes at 22:00, so it will have to end then

I am not sure how long we will stay there

[Klonan]

fam.

i got a question for you: there are not enough CPU for overall testing, the GPU test was not wide enough, like missing 8-core tier (???)

[hr]

by the way, the NTK will have Factorio, does that mean this game is originated in Czech?

We tried to eliminate GPU as a factor of this benchmark, as we did make any changes to the GPU side.

We might do another benchmark when we do GPU optimizations, where the CPU will be the same, and only GPU will be changed

Yes Factorio originated in Czech, our office is here too near Namesti Miru