Factorio Forums

A matter of fun and not only: have you tried to place around 10+ lamps nearby? I have 53. It starts lagging in about 10+lamps. I wanted around 200 at first

Hi, I tested it, and after placing 200+ lamps I could see the drop, so I built 576 lamps which made my fps go down to cca 20.
The strange thing is, that this applied when I was zoomed in, when I unzoomed it was fast again, does this apply to you as well?

I got the same problem in 0.9.1 At about 10 lamps close to me the game slows down. It also only happens zoomed in. When the lamps turn off in the morning the game instantly speeds up.

Also there is stuttering like that mentioned in https://forums.factorio.com/forum/vie ... f=7&t=2454

I only have a slow system (i5-3337U 2x1,8 GHz, 4GB ram, Intel HD 4000 graphics) but the CPU is at 20-25%.

//I noticed that the slowdown was really bad close to my steam engines. So i tried to turn of smoke and it helped a lot. The logistic network range is also really bad when shown, but the moment the lamps turn of the game again runs at full speed.

I have encountered this issue on 0.9.4, I have less than 10 lamps but the FR drops a huge amount.

Moving this to known issues. We have this high on our TODO list since it is rather annoying issue.

Other occurences: https://forums.factorio.com/forum/vie ... php?t=4021, https://forums.factorio.com/forum/vie ... php?t=3421

How is lamps light rendered?
If it is rendered by using some sprite representing white gradient then zooming in would cause the game to have to strech rener that sprite which could scale larger than whole visible area. And in case of multiple lamps game would require multiple full screen passes to render the light from all the lamps. This could significantly affect the overl FPS.

If it is so as described above one posible solution would be to split that one big light sprite into multiple smaller ones. This would mean that when you are zoomed in you only need to render those smaller parts which are in visual range. This should speed up the rendering. But the problem is that this might casue a bit slower performance on normal zoom as you will have to render several smaller sprites instead of one big one.
So maybe implementing something similar to Level of detail which will controll when big sprite is used and when smaller ones are used.

The best solution would be the use of shaders. The only thing I'm woried about is how limited is their support with Allegro.

SilverWarior wrote:How is lamps light rendered?
If it is rendered by using some sprite representing white gradient then zooming in would cause the game to have to strech rener that sprite which could scale larger than whole visible area. And in case of multiple lamps game would require multiple full screen passes to render the light from all the lamps. This could significantly affect the overl FPS.

If it is so as described above one posible solution would be to split that one big light sprite into multiple smaller ones. This would mean that when you are zoomed in you only need to render those smaller parts which are in visual range. This should speed up the rendering. But the problem is that this might casue a bit slower performance on normal zoom as you will have to render several smaller sprites instead of one big one.
So maybe implementing something similar to Level of detail which will controll when big sprite is used and when smaller ones are used.

The best solution would be the use of shaders. The only thing I'm woried about is how limited is their support with Allegro.

You just won a medal!
We were thinking about it and testing it, and we were concentrating on the facts, that it is drawn over the edge of the screen, and that it is drawn in different mode, and that it is drawn on temp-bitmap. And we just forget the most simple explanation of "too many pictures drawn over the whole screen".

If this is the true reason, and I'm almost sure it is, we can just lower the resolution of the lightmap temporary bitmap to be 1/4 to 1/64 of the size of the actual screen to allow 4 to 64 times faster drawing for the price of slightly blurry lightmaps.