Devlog Update: Tackling Multi-Screen and macOS Issues
Hey Pinball Fans!
We value your support and feedback, and we want you to know that we’re actively ironing out issues to deliver the best possible pinball experience.
We’ve fixed a crash issue that was affecting some players using multiple screens. After a lot of investigation, we discovered that the problem was related to how the Steam overlay interacts with the game. It wasn’t easy to track down, but the issue has now been resolved. We also addressed a similar problem on macOS. The fix will be included in Thursday’s update.
Thank you for your patience and support as we continue improving the game!
If you're curious about what caused these issues and how we fixed them, we’d love to share a bit more detail. It turned out to be a deceptively simple problem with a not-so-simple solution, and we had to get a little creative to work around it. Here's what happened behind the scenes:
Some of you have reported crashes on setups with a second or third screen. After a thorough investigation, we discovered that the underlying problem was very simple. In addition to this, we want to be transparent about our development process. We do not use the Steam version of our build during development, which meant that we didn’t catch this issue early on. It was only once players experienced the game on Steam that we were able to identify and address the problem.
Steam overlays its interface without distinguishing between the main game window and additional ones. This means that every time our game refreshed the content on any window, the overlay reinitialized itself. This constant reinitialization was causing a memory leak in the Steam overlay’s implementation.
However, the solution to this issue was far from straightforward. With no available API from Steam to restrict or manage the overlay’s behavior, our team had to think outside the box. Instead of refreshing the content on the second and third windows, we reverted to a legacy OpenGL function that updates the content without triggering a full screen refresh. In doing so, we moved away from using double buffering for these additional windows. Instead, we adopted a single buffer setup. By avoiding the full screen refresh altogether, we stopped the overlay from repeatedly reinitializing and switching windows, effectively preventing the memory leak.
We also identified an issue affecting our macOS users. Our Metal implementation was not handling external displays correctly. Since we develop on a MacBook Air (M1, 2020) without an external display, we had only been verifying the built-in screen.
Meanwhile, we saw a memory leak problem in our macOS implementation.
This fix was not easy, as it involved debugging across multiple programming languages (C++ and Objective-C). Once we identified the root cause, we were able to address the issue successfully.
Happy flipping, The Magic Pixel Team
We value your support and feedback, and we want you to know that we’re actively ironing out issues to deliver the best possible pinball experience.
We’ve fixed a crash issue that was affecting some players using multiple screens. After a lot of investigation, we discovered that the problem was related to how the Steam overlay interacts with the game. It wasn’t easy to track down, but the issue has now been resolved. We also addressed a similar problem on macOS. The fix will be included in Thursday’s update.
Thank you for your patience and support as we continue improving the game!
If you're curious about what caused these issues and how we fixed them, we’d love to share a bit more detail. It turned out to be a deceptively simple problem with a not-so-simple solution, and we had to get a little creative to work around it. Here's what happened behind the scenes:
Some of you have reported crashes on setups with a second or third screen. After a thorough investigation, we discovered that the underlying problem was very simple. In addition to this, we want to be transparent about our development process. We do not use the Steam version of our build during development, which meant that we didn’t catch this issue early on. It was only once players experienced the game on Steam that we were able to identify and address the problem.
Steam overlays its interface without distinguishing between the main game window and additional ones. This means that every time our game refreshed the content on any window, the overlay reinitialized itself. This constant reinitialization was causing a memory leak in the Steam overlay’s implementation.
However, the solution to this issue was far from straightforward. With no available API from Steam to restrict or manage the overlay’s behavior, our team had to think outside the box. Instead of refreshing the content on the second and third windows, we reverted to a legacy OpenGL function that updates the content without triggering a full screen refresh. In doing so, we moved away from using double buffering for these additional windows. Instead, we adopted a single buffer setup. By avoiding the full screen refresh altogether, we stopped the overlay from repeatedly reinitializing and switching windows, effectively preventing the memory leak.
We also identified an issue affecting our macOS users. Our Metal implementation was not handling external displays correctly. Since we develop on a MacBook Air (M1, 2020) without an external display, we had only been verifying the built-in screen.
Meanwhile, we saw a memory leak problem in our macOS implementation.
This fix was not easy, as it involved debugging across multiple programming languages (C++ and Objective-C). Once we identified the root cause, we were able to address the issue successfully.
Happy flipping, The Magic Pixel Team
