Factorio Forums

Yeah, I wonder how your system is going to fare with Vulcanus' To the point that even my (Linux) desktop with a dedicated GPU sees large slowdowns in those moments ! (It's not too bad, since these are )

ergzay wrote: Mon Nov 04, 2024 5:25 pmOne of the great things about Factorio was how well optimized it was, but that seems to have taken a huge hit in this new version. I wish more playtesting had been done before release.

Well, I think it is still well optimized, it's just optimized for different kind of hardware than you have and is doing more things than 1.1 did. It bothers me and frustrates me, that you make it sound like we don't care about rendering performance. You have no idea how many feature requests from our artists I have straight up rejected, and how much effort we have put into trying to make what we want to make while keeping unreasonably low HW requirements. You have no idea how high Space Age HW requirements could have been, if we didn't care about them. You just come, use the highest graphics settings on a machine with high desity display and mediocre GPU and then say the game is poorly optimized. Because "it's 2D game, so it doesn't have right to require GPU". I don't think you have any idea what are challenges of making 2D games, not what are challenges of making 2D game about large scale factories. Yes, the game is not computationally intensive on GPU, it basically just blends layers of sprites on top of each other. But it blends shit ton of them, which is shit ton of memory being moved around, and dedicated GPUs have very wide memory bandwidth. Integrated GPUs not so much.

ergzay wrote: Mon Nov 04, 2024 5:25 pm I hope this issue is fixed before too long though as it may cause other planets to be unplayably slow.

Frankly, I am not in rush. There are plenty of graphics settings you can turn off to make other planets less GPU intensive.

Oleg_7777776 wrote: Mon Nov 04, 2024 6:09 pmin general, it turns out that the game does not meet the stated minimum hardware requirements))) interestingly, turning off the smoke doesn't help me.

The game launches and runs on the stated minimum hardware, so obviously it does meet it
I understand you have suboptimal experience playing the game, and it must be frustrating that nobody seems to pay attention to it. Unfortunatelly, at the moment I don't know what is causing the issue on your mac, if it happens even when Render in native resolution is disabled (you have to restart the game for the setting to take effect). I currently don't know what to ask you that would help me figure it out, and I believe it is different problem than what ergzay is experiencing, or different problem what people with external display are observing (as long as you also don't use external display)

posila wrote: Mon Nov 04, 2024 9:51 pm

ergzay wrote: Mon Nov 04, 2024 5:25 pmOne of the great things about Factorio was how well optimized it was, but that seems to have taken a huge hit in this new version. I wish more playtesting had been done before release.

Well, I think it is still well optimized, it's just optimized for different kind of hardware than you have and is doing more things than 1.1 did. It bothers me and frustrates me, that you make it sound like we don't care about rendering performance. You have no idea how many feature requests from our artists I have straight up rejected, and how much effort we have put into trying to make what we want to make while keeping unreasonably low HW requirements. You have no idea how high Space Age HW requirements could have been, if we didn't care about them. You just come, use the highest graphics settings on a machine with high desity display and mediocre GPU and then say the game is poorly optimized. Because "it's 2D game, so it doesn't have right to require GPU". I don't think you have any idea what are challenges of making 2D games, not what are challenges of making 2D game about large scale factories. Yes, the game is not computationally intensive on GPU, it basically just blends layers of sprites on top of each other. But it blends shit ton of them, which is shit ton of memory being moved around, and dedicated GPUs have very wide memory bandwidth. Integrated GPUs not so much.

ergzay wrote: Mon Nov 04, 2024 5:25 pm I hope this issue is fixed before too long though as it may cause other planets to be unplayably slow.

Frankly, I am not in rush. There are plenty of graphics settings you can turn off to make other planets less GPU intensive.

I think you took my post as being a more severe critique than it was. Also I'm glad you rejected tons of things the artists requested. The best engineering (and game design) comes from working within restraints and using them to their maximum.

Though I disagree with calling the requirements "unreasonably low". M1 is a very powerful chip and was made only a couple years ago. At the time it was released it blew away all but the most power hungry AMD and Intel processors. It should be noted that the M1 is not the "Minimum" system requirements. It's the Steam "Recommended" system requirements.

Also I did not say or imply "it's 2D game, so it doesn't have right to require GPU". I said nothing like that. I was not thinking that either.

I'll add my general perspective that gives context to my statement. As a low level (of the stack) software engineer myself its become a pet peeve of mine that all software just seems to run worse and worse over time despite from the user perspective nothing has changed. So this has become a thing of mine that I never want to make software run worse when it is doing the same thing it did before. If features are added they should only tax the system more when those features are used. In this case nothing from the expansion or new version is being used nor are any new effects at play, yet the performance is significantly worse. That's the context for my statement and why it frustrated me, because it hit a pet peeve of mine.

If anything, by taking advantage of newer hardware and software techniques and by cleaning out a lot of old cruft with the new version by deprecating backward compatability, the software when doing the same old thing should be able to do it even faster in the new version rather than slower.

ergzay wrote: Mon Nov 04, 2024 5:25 pm

posila wrote: Mon Nov 04, 2024 5:22 pm It's not actively worked on at the moment. It is difficult issue, I don't know what we are gonna do about it yet.

At least for the moment, I've found a workaround is to disable smoke which seems to make the issue basically disappear, so that may be related. I'm worried about when I reach the other planets though as I assume this has something to do with how shaders are implemented in the new version and I've heard the other planets use a lot more shaders. One of the great things about Factorio was how well optimized it was, but that seems to have taken a huge hit in this new version. I wish more playtesting had been done before release.

I hope this issue is fixed before too long though as it may cause other planets to be unplayably slow.

Yeah, I guess it was this post and mine that triggered it, but we shouldn't get confused about how Space Age's system requirements are understandably much higher than non-Space Age Factorio 2.0 system requirements...
(But 2.0's might still be higher than 1.1's, for instance those extra rail angles probably came with an extra VRAM cost ?)

Actually, I guess, space-age's requirements in particular, rather than elevated-rails and especially not quality
(good thing those can be separated, and not just for gameplay reasons, for performance reasons too !),
though I guess quality and especially elevated-rails's performance cost is still not zero ?
(Assuming a similar-sized factory, and I don't necessarily mean by a Science per Minute metric.)

Oleg_7777776 wrote: Mon Nov 04, 2024 6:09 pmin general, it turns out that the game does not meet the stated minimum hardware requirements))) interestingly, turning off the smoke doesn't help me.

The game launches and runs on the stated minimum hardware, so obviously it does meet it
I understand you have suboptimal experience playing the game, and it must be frustrating that nobody seems to pay attention to it. Unfortunatelly, at the moment I don't know what is causing the issue on your mac, if it happens even when Render in native resolution is disabled (you have to restart the game for the setting to take effect). I currently don't know what to ask you that would help me figure it out, and I believe it is different problem than what ergzay is experiencing, or different problem what people with external display are observing (as long as you also don't use external display)
[/quote]

Sorry, the conversation really didn't go as planned, you're 100% right. I think that the negative is caused by the fact that everyone was playing on their mac book, at 60/60, they were happy with the 2.0 outputs, and suddenly 60/60 exceeded 30-40 fps, while fff basically wrote about optimization and performance improvement. since the sharp drop in performance was noticed mainly by mac book users (and those who played with the native screen resolution), this created a feeling of some kind of glitch or narrow error; you got sick unsuccessfully and for the first week no one could say that 2.0 or SATA simply had higher graphics requirements. I have described my user experience, but I think many people have it like this. Do not take criticism to heart, all the negativity is caused by the inability to play your favorite game in the previously familiar (in 1.1.10) format. You did a great job!

ergzay wrote: Tue Nov 05, 2024 2:05 am Also I did not say or imply "it's 2D game, so it doesn't have right to require GPU". I said nothing like that. I was not thinking that either.

ergzay wrote: Thu Oct 24, 2024 1:02 pmThe GPU and CPU requirements of Factorio have always been quite modest in modern hardware terms. I'm hoping that they didn't completely throw that away in the expansion. I'm worried about the other planets now requiring a ton of shaders when they didn't before.

You are correct, BlueTemplar said "It would be especially a shame if a 2D game like Factorio couldn't be run on low end hardware" and later on in the thread you agreed with his different post, which in my mind grouped you together as "people who have an expactation a 2D game must run on low end HW." I am sorry about that, my mistake.

From my point of view, Factorio 1.0, was a game that was promised to IndieGoGo backers in 2013 and was selling in early access on Steam from 2016. It was fair to deliver the "finished" version of game such that it could possibly run on computers people had when they first supported or purchased the game. And complains about 2.0 running worse than 1.1 did are valid. But Space Age is 2024 game, it's a new purchase, and if we wanted to stuff it with expensive shaders so that you'd need high end gaming computer to even launch it, I think that would be perfectly acceptable thing for us to do. If it doesn't run well on someones computer, they can just refund it, and that's fine.

And lastly, when you write things like "I wish more playtesting had been done before release" I read "You didn't do good enough job." No, I stand by my work, this is not a bug (but I now acknowledge it is an issue that deserves to be improved), another year of playtesting wouldn't change a thing about this.

ergzay wrote: Tue Nov 05, 2024 2:05 am If anything, by taking advantage of newer hardware and software techniques and by cleaning out a lot of old cruft with the new version by deprecating backward compatability, the software when doing the same old thing should be able to do it even faster in the new version rather than slower.

I don't feel like we are allowed to do that. On PC, we are still building against nearly 20 year old instruction set of Core 2 Duo. We don't use 13 year old AVX instructions, and not even 18 year old SSE4 instructions. We limit ourselves to hardware capabilities of DirectX 10 and OpenGL 3.3, which are also around 15 years old APIs. And even that was a problem for some people when we replaced Allegro 5 which used OpenGL 1.2 with our own graphics backend using OGL 3.3 6 years ago. Similar to how somebody used every oportunity to complain about us dropping 32bit builds years after we did it.

Internally, we are currently discussing when we can drop compatibility with MacOS X 10.10, so that we can update C++ compiler, so that we can use some C++ 20 standard library classes and functions.

And your exchange with BlueTemplar in the thread created by person with 12 year old office laptop strenghtens my feeling that deprecating backwards compatibility and taking advantage of newer hardware is absolutely NOT allowed.

ergzay wrote: Tue Nov 05, 2024 2:05 amThough I disagree with calling the requirements "unreasonably low". M1 is a very powerful chip and was made only a couple years ago. At the time it was released it blew away all but the most power hungry AMD and Intel processors. It should be noted that the M1 is not the "Minimum" system requirements. It's the Steam "Recommended" system requirements.

M1 is powerful chip, at late game states of our playtesting I used my Macbook Air to play the game, because none of my other computers were fast enough to keep up with the server. Including the computer I have in the office, which was able to render the scene you reported in this thread in 120 FPS. M1 is very powerful CPU, and possibly decent GPU. The GPU may be amazing computationally, but it probably has the same memory bandwidth as the CPU (I am assuming, I have not read the technical specification document), which is order of magnitude less than what dedicated GPUs have. Combine this with high resolution display and it's inadequate.

Normally, I my Macbook is set to 1650x1050 with "Render in native resolution" disabled. And I did not understand how the resolutions on mac work. Now that you helped me understand it better, I can see and understand that disabling "Render in native resolution" when you have your macbook configured to 1280x800 is something you'd like to avoid. And that's why I am keeping this report alive. I do agree M1 is powerful chip, and it's possible we'll find a good way to use power of the CPU to reduce workload put on the GPU (which is something we always try to balance, but what makes it complicated is that it needs to be ballanced for different systems differently - essentially M1 Macs being near one extreme of the spectrum and Nintendo Switch being on the opposite extreme)

For PC, I have tried to define recommended system requirements for graphics as HW configuration on which you'll be able to play the game smoothly with high sprite quality and high texture compression quality in 1080p. From my experience of playing on Macbook Air in 1650x1050 it seemed to me like HW I can recommend.

ergzay wrote: Tue Nov 05, 2024 2:05 am I'll add my general perspective that gives context to my statement. As a low level (of the stack) software engineer myself its become a pet peeve of mine that all software just seems to run worse and worse over time despite from the user perspective nothing has changed. So this has become a thing of mine that I never want to make software run worse when it is doing the same thing it did before. If features are added they should only tax the system more when those features are used. In this case nothing from the expansion or new version is being used nor are any new effects at play, yet the performance is significantly worse. That's the context for my statement and why it frustrated me, because it hit a pet peeve of mine.

Thanks for your perspective. I am sorry for unleashing some of my anger and frustration from past exchanges with disappointed fans and from years of Space Age development. It was uncool out of me. I don't mean professionally (I don't care much about that), I mean as person to person.

But 2.0 doesn't do the same thing it did before, and it is percievable in vanilla too. So, pre-1.1 the game had just 1 type of lights, large spotlights usually with very wide falloff. These lights are rendered to a lightmap of 1/4th size of the game view. In 1.1 we added new type of lights - we call them detail lights (and the old type we call gradient lights now), these are sprites used for LEDs and various glows on parts of entities. These are rendered to the second lightmap in full scale.

In 1.1 there is a flaw with these lights. They render separately from sprites, so if the detail light is behind another sprite, it "shines" through the sprite. This has been reported as bug several times (115286, 68280, 45614 - reports I could find quickly, but there were many more. I remember one in particular with tank and heat pipe.) We have discarded such bug reports, because at that time we thought the performance cost of the fix was not worth it.

But it was one of the first things we changed for 2.0. Now game sprites are rendered into multiple render targets in single pixel shader invocation - game view, and light map. Detail light sprites are just regular sprites with a flags which pixel shader interprets and either blends the sprite to game view normally and as light occluder into the lightmap, or as additive light into the lightmap. It is prette cheap even on lower end dedicated GPUs, but makes every game view pixel about 50% more expensive to render on integrated GPUs with much lower memory bandwidth. And light sprites being just regular sprites with a flag is core engine change for which it is not practical to make an option to switch between old and the new behavior. Whether the cost is worth it is debatable. But, the game is not doing the same thing 1.1 did. And as far as I know, it does the new thing in very optimized way (but clearly not optimal for M1 + high resolution)

Oleg_7777776 wrote: Tue Nov 05, 2024 4:59 pm...

Thanks. And I am sorry I didn't communicate the higher HW demands better.
I believed there were 3 separate issues, but all of them manifesting in FPS drops, but now I am confused ... Are you saying that disabling "Render in native resolution" improved FPS for you?

posila wrote: Tue Nov 05, 2024 5:08 pm
And lastly, when you write things like "I wish more playtesting had been done before release" I read "You didn't do good enough job." No, I stand by my work, this is not a bug (but I acknowledge it is an issue that deserves to be improved), another year of playtesting wouldn't change a thing about this.

My intention with that wasn't to say "you didn't do a good enough job" but more "you didn't have enough time". Playtesting is something that is hard. And honestly this expansion came out faster than I was expecting. Reading the FFF posts I was sure it was going to be a 2025 release.

posila wrote: Tue Nov 05, 2024 5:08 pm I don't feel like we are allowed to do that. On PC, we are still building against nearly 20 year old instruction set of Core 2 Duo. We don't use 13 year old AVX instructions, and not even 18 year old SSE4 instructions. We limit ourselves to hardware capabilities of DirectX 10 and OpenGL 3.3, which are also around 15 years old APIs. And even that was a problem for some people when we replaced Allegro 5 which used OpenGL 1.2 with our own graphics backend using OGL 3.3 6 years ago. Similar to how somebody used every oportunity to complain about us dropping 32bit builds years after we did it.

I think limiting yourself to the techniques of older graphics APIs is a generally good idea, unless there's a newer graphics API that allows for more efficient accomplishment of a given task. I also think even given that, there's nothing stopping say implementing use of Vulkan or Metal with those same limitations of DirectX 10 and OpenGL 3.3 which would allow for more efficient rendering with a fallback for older systems.

posila wrote: Tue Nov 05, 2024 5:08 pm And your exchange with BlueTemplar in the thread created by person with 12 year old office laptop strenghtens my feeling that deprecating backwards compatibility and taking advantage of newer hardware is absolutely NOT allowed.

I guess I'm missing which thread that was.

posila wrote: Tue Nov 05, 2024 5:08 pm The GPU may be amazing computationally, but it probably has the same memory bandwidth as the CPU (I am assuming, I have not read the technical specification document), which is order of magnitude less than what dedicated GPUs have.

I'm no expert but I believe I've read that the memory bandwidth for the GPU and CPU are shared as it's a combined GPU/CPU architecture given that the DRAM is soldered directly on top of the CPU/GPU die into a single package. This has advantages as data doesn't need to travel very far to reach the GPU from the CPU memory (or rather I think it doesn't need to move at all). According to Wikipedia the M1 uses 128 bit bandwidth at a data rate of 68.3 GB/s for the GPU. I'm guessing that the hardware uses a lot of tricks though that makes that lower transfer rate matter less because of the shared architecture. Tricks that I'm guessing may not happen without a proper Metal implementation as the GPU has to do extra work that it may not need to do.

posila wrote: Tue Nov 05, 2024 5:08 pm But 2.0 doesn't do the same thing it did before, and it is percievable in vanilla too. So, pre-1.1 the game had just 1 type of lights, large spotlights usually with very wide falloff. These lights are rendered to a lightmap of 1/4th size of the game view. In 1.1 we added new type of lights - we call them detail lights (and the old type we call gradient lights now), these are sprites used for LEDs and various glows on parts of entities. These are rendered to the second lightmap in full scale. In 1.1 there is a flaw with these lights. They render separately from sprites, so if the detail light is behind another sprite, it "shines" through the sprite. This has been reported as bug several times (68280, 45614, these are reports I could find quickly, but there were many more. I remember one in particular with tank and heat pipe.) We have discarded such bug reports, because at that time we thought the performance cost of the fix was not worth it. But it was one of the first things we changed for 2.0. Now sprites are rendered using multiple render targets - game view, and light map. Detail light sprites are just regular sprites with a flags which pixel shader interprets and either blends the sprite to game view normally and as light occluder into the lightmap, or as additive light into the lightmap. It is dirt cheap on even lower end GPUs, but makes every game view pixel about 50% more expensive to render on integrated GPUs with much lower memory bandwidth compared to dedicated ones. And light sprites being just regular sprites with a flag is core engine change for which it is not practical to make an option to switch between old and the new behavior. Whether the cost is worth it is debatable. But, the game is not doing the same thing 1.1 did. And as far as I know, it does the new thing in very optimized way.

Personally I quite liked the Uranium glow effect and the way it made other things glow on top of it. As to the rendering change, seems like a pretty expensive change for something so minor, but I realize opinions can differ I guess. Personally I find strange graphics quirks that are a result of how the game is designed is something that adds charm to the game. That "adapting game design to implementation limitations" is something that is hard to do and also something that makes great games. Turn negatives into positives.

(And also why I find this constant effort to do things "properly" in the game industry with regards to game engine rendering like the push toward path tracing in 3D game engines kind of frustrating. Factorio is a game I've always viewed as being a type of game for the strange people that like Dwarf Fortress or Rouge-like games or Zach Industries games that were designed around limitations. DoshDoshington is a perfect example of that type of person. See his non-Factorio videos.)

I have no problem with things "looking slightly off" if it gives massive performance benefits. In fact that's the mark of almost every great rendering technique that's been invented in the history of computer graphics. They're almost all tricks done in the name of getting something that manageably works and gives games using them their own characteristic feel.

But anyway, that's just my opinionated rant.

posila wrote: Tue Nov 05, 2024 5:30 pm

Oleg_7777776 wrote: Tue Nov 05, 2024 4:59 pm...

Thanks. And I am sorry I didn't communicate the higher HW demands better.
I believed there were 3 separate issues, but all of them manifesting in FPS drops, but now I am confused ... Are you saying that disabling "Render in native resolution" improved FPS for you?

And again yes, and again you are 100% right. I'm dumb because I didn't reboot the system, it's a childish mistake.
I spent several hours testing on different settings today, I was going to make a separate theme expanded. in order not to clog up the forum, let's write the conclusions here, if necessary, I'll attach screenshots to debug mode.
MacBook M3 pro 18 gb. Screen 3024 × 1964

1) The mode on the laptop is 1280 by 800 (as we understood from the old post, 2560 by 1600 in the game - in retina mode, I really didn't know this like you) - on 1.1.10 - everything worked 60/60. VSYNC is enabled. All graphics are at maximum, all effects are included. after the update - when zooming or being near stoves / drills, etc. - drawdown up to 30/60. Any disabling of effects, changing the resolution does not have an effect, during the first 40-50 seconds everything is super - after the FPS decrease. Everything is as described by colleagues. The processor load is 7-8%, 9-10 GB of 18 GB of memory is used.

2) If you disable VSYNC, the indicators will become 60.2/60.2 - (renedering in native resolution is still enabled, pay attention). - but - there will be slowdowns and friezes, I don't know how the translator will translate this expression - slowdowns or lags.

3) If you disable rendering in native resolution - (VSYNC is turned back on, graphics are at maximum) - everything will be super, FPS/ UPS 60/60 - but the graphics and picture will be much worse, I raised the graphics to 1800 by 1169 - the picture is more acceptable, everything is also 60/60 - that is, in general, the playable mode, only every time before the game you need to change the resolution of the laptop)

4) With rendering turned off, I raised the resolution to 2560 by 1600 (in fact, the resolution is in retina mode, see point 1) and the FPS sank to 30-40/60, that is, this is no longer the working limit mode.

p.s - any playable mode for me is up to 1800 by 1169 with full settings, and with rendering turned off.

Right, my bad, with the new Space Age features being so new and standing out so much, it's kind of easy to forget about all the other graphic improvements.
And indeed, hardware improved tremendously since 2013, even on the low end.
So, yeah, it does seem fair for even non-SA minimum requirements to have increased significantly from v1.1 to v2.0 (but in practice staying ~constant relative to the price of newly available hardware), my expectations were knee-jerk and wrong. (Good luck on that Factorio v2.0 for Nintendo Switch though...)
And it's not like it's the first time this happens, and not like (unlike for some other games) v1.1 (or even older 32-bit versions) cannot be played any more.
(Not to mention that the earliest players would have gotten Factorio for much cheaper.)

I guess I'm missing which thread that was.

This one I guess ?
viewtopic.php?p=624239#p624239

I see this got moved to assigned, does that mean that it's being worked on or is on the schedule to be worked on? Not that familiar with how the forum works.

In general, it's not reliable indicator that the bug is being actively worked on. In this case, yes, I am working on it right now.

Thanks for the report.

For 2.0.21, I added "Occlude light sprites" graphics option to switch back to 1.1 light rendering. The feature is currently required for tile glow to work, and I thought I'll need to also implement alternative lava glow effect for when the option is turned off. I still will sometime, but Vulcanus has super bright nights and the lava doesn't look super broken when it's not glowing, so the alternative effect doesn't seem to be critical feature at the moment.

Also, I was wrong and underestimated GPU power of even the weakest Apple M1 model. During profiling on macOS, I noticed unusually high amount of time spent in glQueryCounter(queryId, GL_TIMESTAMP) calls. GL_TIMESTAMP counter is not implemented in macOS's OpenGL and the query always returns 0. So that it even showed up in the profiling results surprised me. When I disabled the calls, rendering performance significantly improved. Your reported scene now runs almost smoothly 60 FPS in 1280x800 HiDPI even without disabling the "Occlude light sprites" option, and saw significant improvement of performance on Gleba (but still not 60 FPS) without disabling any effects (those effects are usually enveloped by pair of glQueryCounter for the debug timing info). It looks like glQueryCounter was causing CPU-GPU sync point. I tested disabling it also on Windows when using OpenGL backend, but without any measurable difference in performance.

So with these changes, I can now run your save in smooth 60 FPS even on the default 1440x900 HiDPI. At least in 2.0 and Space Age Nauvis. There is another option - "Additional terrain effects" as an alternative option to help with Gleba performance, to disabling fog, clouds and animated water.

posila wrote: Tue Nov 05, 2024 5:08 pm
Internally, we are currently discussing when we can drop compatibility with MacOS X 10.10, so that we can update C++ compiler, so that we can use some C++ 20 standard library classes and functions.

By all means, please drop support for macOS 10.10, please! macOS 10.10 Yosemite has not received a single security patch since mid-2017, over 7 years ago. It is beyond obsolete. Anyone still running it should be "encouraged" to upgrade to a supported OS. No major browser supports that version of macOS either, so anyone browsing the web on that machine is using a browser just riddled with exploits and is asking to be hacked again and again. I admire your dedication to maintaining a long support lifecycle but IMHO there should be NO issue dropping support for 10.10 in late 2024.

posila wrote: Tue Nov 05, 2024 5:08 pm
Internally, we are currently discussing when we can drop compatibility with MacOS X 10.10, so that we can update C++ compiler, so that we can use some C++ 20 standard library classes and functions.

Please do so and drop MacOS X 10.10 today - not tomorrow !

I'll forward your support for dropping 10.10 to StrangePan. (It's possible someone uses it, because higher macOS doesn't support their HW)

I also feel need to add kind of "in my defense" comment for not catching glQueryCounter problem in 2.0 playtesting: We use it the same way since 0.17 when we replaced Allegro 5 with our own graphics backend. In 1.1 we had total 7 time queries, in 2.0 we have 13. Most of them "envelope" specific effect passes, so only some of them are queried in each frame. At first, I thought we have added some around clouds or smoke, but no ... in the scene in this bug report, only the same 5 timers are queried as in 1.1.

EDIT: Moderators locked the thread due to offtopic, so I split it to 122600

posila wrote: Thu Nov 21, 2024 4:16 pm Thanks for the report.

For 2.0.21, I added "Occlude light sprites" graphics option to switch back to 1.1 light rendering. The feature is currently required for tile glow to work, and I thought I'll need to also implement alternative lava glow effect for when the option is turned off. I still will sometime, but Vulcanus has super bright nights and the lava doesn't look super broken when it's not glowing, so the alternative effect doesn't seem to be critical feature at the moment.

Also, I was wrong and underestimated GPU power of even the weakest Apple M1 model. During profiling on macOS, I noticed unusually high amount of time spent in glQueryCounter(queryId, GL_TIMESTAMP) calls. GL_TIMESTAMP counter is not implemented in macOS's OpenGL and the query always returns 0. So that it even showed up in the profiling results surprised me. When I disabled the calls, rendering performance significantly improved. Your reported scene now runs almost smoothly 60 FPS in 1280x800 HiDPI even without disabling the "Occlude light sprites" option, and saw significant improvement of performance on Gleba (but still not 60 FPS) without disabling any effects (those effects are usually enveloped by pair of glQueryCounter for the debug timing info). It looks like glQueryCounter was causing CPU-GPU sync point. I tested disabling it also on Windows when using OpenGL backend, but without any measurable difference in performance.

So with these changes, I can now run your save in smooth 60 FPS even on the default 1440x900 HiDPI. At least in 2.0 and Space Age Nauvis. There is another option - "Additional terrain effects" as an alternative option to help with Gleba performance, to disabling fog, clouds and animated water.

Great news! Thank you so much for working on this and figuring this out! Factorio devs are awesome!

posila wrote: Fri Nov 22, 2024 11:27 am I'll forward your support for dropping 10.10 to StrangePan. (It's possible someone uses it, because higher macOS doesn't support their HW)

I also feel need to add kind of "in my defense" comment for not catching glQueryCounter problem in 2.0 playtesting: We use it the same way since 0.17 when we replaced Allegro 5 with our own graphics backend. In 1.1 we had total 7 time queries, in 2.0 we have 13. Most of them "envelope" specific effect passes, so only some of them are queried in each frame. At first, I thought we have added some around clouds or smoke, but no ... in the scene in this bug report, only the same 5 timers are queried as in 1.1.

EDIT: Moderators locked the thread due to offtopic, so I split it to 122600

So does that mean that there is other things that were causing the regression and this performance penalty was still there on 1.1 but everything else was just sufficiently fast that it was covered up?