Lost in Play ultrawide solution

TL;DR? Download the solution here right away!

A few days ago one of my long-time supporters (who also happens to be a patron!) posted about Lost in Play having no ultrawide support. That was followed up by another user quickly going off topic and getting the message effectively buried, but I had noticed!

I began to think of looking into the game, though I was preoccupied with fixing Battlefield V and experimenting with at least two other games. I checked Lost in Play in between and then fully committed to it for more than one full day of code reading with few distractions.

As you know by now from many of my posts, dealing with a game on a familiar engine can be hit-or-miss. Sometimes the past knowledge applies in full and makes the solution trivial but other times it's not only like dealing with something unknown but also something very complex. It was definitely the latter for Lost in Play.

At first, I noticed that there was not much code from the developer responsible for the things that mattered to this community, so I had to switch my focus to dealing with the engine framework itself. I thought it had to be in real time in the memory so that I could see the interactions between the game and the framework.

It was not hard to force the game to allow to select the user's resolution, but that did absolutely nothing to the way it looked, because it was still pillarboxed. I still saw no code responsible for that pillarboxing and my old patterns were absolutely inapplicable, so I first discovered that the game is 32-bit, which got me to change the mindset of looking for the familiar for 64-bit.

After hours of searching, I found a way to force the game to use the player's resolution, as with my earlier solutions, such as the one for As Dusk Falls. This was an important prerequisite, as I understood that making this into a patcher was not viable.

The next step, intertwining with the previous, was the search for code that would allow me to get rid of the pillarboxing. Again, I found it over the course of hours and got to do it on the engine level, as opposed to any dev code. Initially it also stretched the UI, so I looked again for hours for another piece of code where I could get rid of the pillarboxing without touching anything else. It was a relief to get to something reliable at last!

However, as we often see with Unity games, the UI got all messed up with the expansion of the view. I released quite a number of Unity UI solutions since figuring out the basics via Earthlock, but again those findings were not directly applicable. I dug deeper and deeper, beyond the temporary and conditional memory functions, which finally got me to what looked like a perfect UI fix that adjusted each element and menu correctly compared to 16:9. I will try to use this newfound knowledge in other games (Milky Way Prince remains my go-to test case for this, as it uses multiple reference resolutions depending on the scene).

It felt like the solution was finished, but I still had to test it at other aspect ratios. Testing it at 32:9 revealed that the letterboxes that appear at the cutscenes do not have enough width to span the screen, so they looked broken. I knew that hunting down a Unity game object in the assembly code is effectively a lost cause, though I still did a bit of experimenting. Naturally, adjusting it was not reliably possible that way, so I went for hunting down the code that would trigger the bars to appear. It just needed to be made into a reliable fix.

A Unity game not using IL2CPP has its code quite accessible via the files but then it shows up in the memory with little to go by or separate unless you see the symbols for the class names. There is no static location and there can be no reliable way to find a specific class just by virtue of reading the pure assembly. I had to think up a solution and experiment with it, which required introducing new functionality to my trainer, but after some trying and writing conditional checks, I think I got it to work without being an issue to the user.

The final touch that I often forget about was making use of the timer code as seen in my Omikron fix so that the trainer could be run before the game, not necessarily after it, as most of my trainers. It's not necessary but I guess it's good for QoL. We'll have to see if the approach proves to be reliable, and if so, I'll do it more often, if not every time.

This concludes the yet another long read. You may not get to the end, but if you do, you'll have found another example of what it takes to make a fix, and that's without all the specifics and the countless lines of code that had to be read and tested for their purposes. Either way, I'm happy to bring another full-fledged fix to this community (even if the game is barely played and is short)! As mentioned, there is more already in the works, so stay tuned!