Friday Facts #281 - For a Few Frames More

[Mango]

Now look at these graphs
Déjà vu

[MarvinCZ]

Thanks for calming my mind guys.
So hopefully the performance will get only better with 0.17.

Maybe one thing that confused me was the need to run the benchmarks with Low texture settings on Intel HD card since I have no problem to run it on High with 0.16.

[bman212121]

Signals on the outside indicate they're using a Right hand drive setup, if they're on the inside then they're Left hand drive.

The more you know!

SNIP..

I have to think about this even more. I'm fairly sure that Factorio the signal always will be on the right of the train when heading forward, so you'd be correct.

[quyxkh]

The goal is to eventually remove the 'low' and 'very-low' sprite resolution options, as 'low quality' texture compression on normal sprites + texture streaming should be able to run even on GPUs with very low VRAM sizes.

For `--benchmark`ing I set the graphics to very-low in my little option-processing frontender, it makes a gratifying difference in cycle time.

[<NO_NAME>]

This screen with a train looks really nice.

[adam_bise]

ok so if this gets optimized even more i could probably play it on a Raspberry Pi and take it with me for on the go

You should try it and let us know!

https://eltechs.com/product/exagear-desktop/


I would imagine you'd be counting seconds per frame, that is if you are able to get it working at all =)

[Jiehong]

That looks like a tramway mod to me! I like that!

For those that don't know, in Europe, we have trams over grass just like that one:

[burisk]

That optimalizations, I hope that 0.17 will fix that bug what I have on Mac OS (Macbook Pro 15" 2015).
When I am in game, and I'll show a map (M), and I'll look to the area covered by radars, and that area has a lot of walls, my FPS will drop from 60 FPS to 20 FPS. :/

I can't wait to 0.17!!!

[E-37]

ok so if this gets optimized even more i could probably play it on a Raspberry Pi and take it with me for on the go

You should try it and let us know!

https://eltechs.com/product/exagear-desktop/


I would imagine you'd be counting seconds per frame, that is if you are able to get it working at all =)

If there ever was an ARM port, you could probably get up to blue science working at 60 fps if you don't zoom out too far. I got the full version of Minecraft working at 50 fps on mine and it is optimized like garbage on top of being written in Java.

[adam_bise]

ok so if this gets optimized even more i could probably play it on a Raspberry Pi and take it with me for on the go

You should try it and let us know!

https://eltechs.com/product/exagear-desktop/


I would imagine you'd be counting seconds per frame, that is if you are able to get it working at all =)

If there ever was an ARM port, you could probably get up to blue science working at 60 fps if you don't zoom out too far. I got the full version of Minecraft working at 50 fps on mine and it is optimized like garbage on top of being written in Java.

There was a discussion about that.. dig.. dig.. dig.. here. There was a purple response saying "no promises" so it isn't out of the question! Of course playing the geekiest game the geekiest way possible would be right up many factorians alley lol

[ledow]

Emulating a PC on ARM would be atrocious, obviously. For emulation think "10 times at least". Wanna emulate a 4.77MHz Z80? You need 50MHz or thereabouts to do it any justice at all, not including other hardware.

Running natively - the code wouldn't be too hard to port and compile (a lot of work, but not hard). But the GPU in a Raspberry Pi sucks. Even a 3B+.

Then you have RAM issues, DEFINITELY VRAM issues, OpenGL ES issues, and so on.

Maybe the next gen Pi. Maybe. If someone wants to spend 6-months to a year porting it and optimising it all again. It might be playable for a base up to, say, the first rocket. Past that, I doubt it.

Source: I have ported several games from PC to GP2X (dual-200MHz ARM) and similar handheld consoles.

You can run Minecraft on a Pi. But it's not the Minecraft you know and love on PC. And a Pi can run Quake 3 (a 20 year old game this year!) if you port it natively (rather than try to emulate). Whereas Factorio can stress even the average PC you buy in a shop today.

I honestly wouldn't hold your breath.

[striepan]

What about the fill-rate independent issues, like FPS drop while zoomed out, no mater the resolution or sprite quality while the GPU seems to be chilling nowhere near full utilization? This also tends to drag UPS down when it's apparently not supposed to.

[Dixi]

config.ini
cache-sprite-atlas=true

Wonderful! Why it's not true by default?
Load time about 17 sec without cache (default) and only 9 sec after change.
1.8Gb atlas-cache really not a problem.

Do you have any more advises how to speedup loading, by chance?

Also, a question to DEV's:
Why you store zillion of .png files separately, not in form of a zip archive without compression? They will load much faster.
Most games do that. Some of them use own packing methods, but that cause problems for modders.

[posila]

That optimalizations, I hope that 0.17 will fix that bug what I have on Mac OS (Macbook Pro 15" 2015).
When I am in game, and I'll show a map (M), and I'll look to the area covered by radars, and that area has a lot of walls, my FPS will drop from 60 FPS to 20 FPS.

Do you have turrets by those wall by any chance?

Maybe one thing that confused me was the need to run the benchmarks with Low texture settings on Intel HD card since I have no problem to run it on High with 0.16.

It was still with High sprite resolution, but compression was set to Low quality. We seem to be memory bandwith limited on Intel iGPUs so I think 8bpp compression is more appropriate then 12bpp for them. Furthermore, usually if someone runs the game on Intel HD, they are probably playing on laptop so less work for GPU means less heat and smaller probability of thermal throttling of CPU (+ longer battery life). Also low quality compression seems to be good enough for FullHD 15" screen. Which model of Intel HD do you play on, how much system RAM do you have and did you disable smoke and decoratives?

What about the fill-rate independent issues, like FPS drop while zoomed out, no mater the resolution or sprite quality while the GPU seems to be chilling nowhere near full utilization? This also tends to drag UPS down when it's apparently not supposed to.

Can you create thread in Technical help or Bug repors section and post details there? Your Factorio log, your HW configuration, way how to reproduce the problem (save + instructions what to do to experience the issue).

Now look at these graphs
Déjà vu

[Durabys]

That optimalizations, I hope that 0.17 will fix that bug what I have on Mac OS (Macbook Pro 15" 2015).
When I am in game, and I'll show a map (M), and I'll look to the area covered by radars, and that area has a lot of walls, my FPS will drop from 60 FPS to 20 FPS.

Do you have turrets by those wall by any chance?

Maybe one thing that confused me was the need to run the benchmarks with Low texture settings on Intel HD card since I have no problem to run it on High with 0.16.

It was still with High sprite resolution, but compression was set to Low quality. We seem to be memory bandwith limited on Intel iGPUs so I think 8bpp compression is more appropriate then 12bpp for them. Furthermore, usually if someone runs the game on Intel HD, they are probably playing on laptop so less work for GPU means less heat and smaller probability of thermal throttling of CPU (+ longer battery life). Also low quality compression seems to be good enough for FullHD 15" screen. Which model of Intel HD do you play on, how much system RAM do you have and did you disable smoke and decoratives?

What about the fill-rate independent issues, like FPS drop while zoomed out, no mater the resolution or sprite quality while the GPU seems to be chilling nowhere near full utilization? This also tends to drag UPS down when it's apparently not supposed to.

Can you create thread in Technical help or Bug repors section and post details there? Your Factorio log, your HW configuration, way how to reproduce the problem (save + instructions what to do to experience the issue).

Now look at these graphs
Déjà vu

So what about Linux/UNIX OS optimization? It is similar to Windows and iOS?

[MarvinCZ]

It was still with High sprite resolution, but compression was set to Low quality. We seem to be memory bandwith limited on Intel iGPUs so I think 8bpp compression is more appropriate then 12bpp for them. Furthermore, usually if someone runs the game on Intel HD, they are probably playing on laptop so less work for GPU means less heat and smaller probability of thermal throttling of CPU (+ longer battery life). Also low quality compression seems to be good enough for FullHD 15" screen. Which model of Intel HD do you play on, how much system RAM do you have and did you disable smoke and decoratives?

Ah, I see now. I thought that you were referring to low resolution setting. My bad, I am sorry.

I have 2017 MBP with Intel Iris Plus Graphics 650 and 8 GB or RAM.
I play with smoke enabled but the decoratives I keep disabled (I like it more that way).

[Mike Pote]

@posila Forgive me for wondering the obvious, but before you guys went down the turret radius pixel shader rabbit hole, I'm wondering why you don't just render a semi-transparent triangle fan over the map to form a circle for the turret radius? I'm pretty sure you're already doing this for the electricity network visualisation and the car and tank icons. You could use the stencil buffer to prevent overdraw from overlapping radii here too, and it would cut out your pixel shader having to test each and every single pixel on the screen for a radius.

Something like this, but obviously with enough vertexes to look smooth:



I'm guessing you already tried that and it wasn't performant enough?

[posila]

@posila Forgive me for wondering the obvious, but before you guys went down the turret radius pixel shader rabbit hole, I'm wondering why you don't just render a semi-transparent triangle fan over the map to form a circle for the turret radius? I'm pretty sure you're already doing this for the electricity network visualisation and the car and tank icons. You could use the stencil buffer to prevent overdraw from overlapping radii here too, and it would cut out your pixel shader having to test each and every single pixel on the screen for a radius.

Something like this, but obviously with enough vertexes to look smooth:



I'm guessing you already tried that and it wasn't performant enough?

The middle mesh (I should have written mesh instead of geometry in the blog post, I suppose) is how we always draw it in 0.16 and still in 0.17 until you zoom in close enough onto cluster of turrets and the optimized version kicks in (we use trinagle strip instead of tringle fan because we can batch several circles into single draw call using degenerated triangles) and is what we needed to optimize. Stencil buffer was one of the two ideas we had (and first one we tried out) but it still was not fast enough, so we went to try out the second idea which was drawing geometry procedurally in shader, and were disappointed by its extraordinaly poor performance in some cases ... so we went on to come up with more ideas and essentially ended up combinig the two initial solutions.

[MaxUser01]

Wow!! You do not stop surprising us.

While other game developers are only concerned with releasing numerous DLCs, without even worrying about the performance of the game, you do the opposite and have not even officially launched the game yet (v1.0)...
incredible!!
Congratulations! Keep up the great work.

"Factorio must be the best game no matter what!" - (Someone on the team said this).

[Jap2.0]

I think they put oddities in their pictures just to watch every OCD squirm.

For example, there are rail signals in the middle of nowhere, and they are using a 2-way train on what is clearly a one-way track.

heresy.png

HERESY!

Umm... isn't the point of double headed trains reversing out of stations? Not two way tracks?

ok so if this gets optimized even more i could probably play it on a Raspberry Pi and take it with me for on the go

I think someone tried that once - iirc it took about 2 hours to get started and ran at about 0 fps. I'll edit this once I find the link.

Edit: I found it, here. 4 hours 12 minutes to start, 0.0 ups. This was back in 0.12. If anyone's interested in trying it's there's a config here that might help. I'm kind of curious how it's changed through the last few versions.

Edit 2: While I'm here, I forgot to say good job on the graphics optimizations. The results were already very impressive back in July, and somehow you managed to improve a ton on that.