Alex Builds His Farm & Laura's Happy Adventures Widescreen

[AlphaYellow]

So, both of these games also use the OpenSpace engine, Laura's Happy Adventures came out in early 1998 and Alex Builds His Farm in 1999. I have no idea what addresses to change in the game's .exe or the SNA files to get the right resolution values, aspect ratio and FOVs. I'd be glad to have some feedback, thanks.

[myst123]

I have no idea, but would love to know how as well. I grew up with Alex and Laura too . Maybe someone on this forums can help.

[AlphaYellow]

Making some progress, seems like the ScreenSize variable set in ubi.ini works for Alex, and adjusting the FOV like in Hype's fix really works. But sadly, this solution is glitchy in the sides beyond the 4:3 safe area, objects disappear in the sides. And this fix doesn't work for Laura. Still work in progress!

Before:

After:

[AlphaYellow]

Another update, I managed to bring widescreen to Laura's Happy Adventures as well, by altering the 00 00 80 3F (4:3) to 00 00 10 3F (16:9), it's glitchy in the sides just like Alex's fix above, but it is what I got so far.

Before:

After:

[Garo]

Good job! I'm very bad at hex editing so this is very impressive! I'm very curious how you found these values? It may help me in the future lol.

[AlphaYellow]

Well, I mostly based on the same hex values of the widescreen fix for Hype: The Time Quest (viewtopic.php?t=31049), since they use the same engine (OpenSpace), but still getting objects appearing and disappearing outside the 4:3 area whenever moving the camera around. Wondering if anyone here knows the original FOV values that the games use, they're stored in Fix.sna inside GameData/World/Levels (and probably other .sna files too). That way a non-glitchy FOV would be possible, because it really breaks immersion this way. I released a widescreen fix on PCGamingwiki for Laura and a FOV fix for Alex, but they are NOT ideal. Here are the links:

- Laura: https://community.pcgamingwiki.com/file ... creen-fix/
- Alex: https://community.pcgamingwiki.com/file ... m-fov-fix/

[Garo]

Sorry but I have no clue. I tried to also fix the FOV for Tonic Trouble but I never could find anything. But I'm not very experienced with a hex editor so someone with the right skills might be able to achieve this.

[AlphaYellow]

The most reliable FOV fix without the objects disappearing on the sides would be through editing a decoded Fix.sna file, I've done for both files of Alex and Laura, but I have no idea what's the default FOV value they use (tried searching for 1.2, 1.3 and 1.4 and changed to 1.786, but nothing worked), so will be waiting for someone here that has more knowledge about this And also changing the 00 00 80 3F part changes both the aspect ratio and FOV at the same time, which makes the sides glitchy, hence why I wanted to do through Fix.sna.

[lk19]

Hello everyone!

I took a look at these two games and managed to locate the FOV values in the fix.sna files. For Alex it was straightforward, as it uses the same SNA format as Hype Alex's default value for the horizontal FOV is 1.2 btw
Laura turned out to be a lot more difficult, because
a) it uses a different file format for fix.sna (the "old" version of the game uses an unencrypted and uncompressed format and the "Pentium III" version uses a format similar to Hype, but with one "weird" block) and
b) the game has two different FOV values: 1.3 for inside scenes and 1.4 for outside scenes.

I have attached the Python scripts. To use them, install Python 3 and make sure you have python-lzo installed ("pip install python-lzo").

Laura:
Open a command prompt and run the following code (replace XXX by the corresponding script and <PathToGame> with the path to your game folder ).

Code: Select all

 python Change_FOV_XXX.py "<PathToGame>\GameData\World\Levels\fix.sna" 

Alex:
Copy Change_FOV_Alex.py to your game folder and then run it by either double-cklicking the script (if the py file extension is already asscociated with python.exe), or run it from the command line:

Code: Select all

 python Change_FOV_Alex.py 

If you have access to both the old version and the "Pentium III" version of Laura's Happy Adventures, I highly recommend you to use the "Pentium III" version, since it has the much easier widescreen fix and runs more stable.

I will also update the PCGamingWiki pages https://www.pcgamingwiki.com/wiki/Alex_Builds_His_Farm and https://www.pcgamingwiki.com/wiki/Laura ... Adventures accordingly.

Edit: Bug fix in the Laura scripts
Edit2: Updated Alex scripts.

[Garo]

Nice findings lk19! Glad to know you're still making these widescreen patches! This reminded me of my widescreen patch for Donald Duck: Goin' Quackers that I forgot about, maybe I might try to finish it up in the future. If anyone's interested here's the link to the video of what it looks like: https://youtu.be/cz4Yx_I9SZE

[lk19]

Btw: If anyone is wondering how I figured out the standard FOV values for each game, here's what I did:

We know that the game stores the horizontal FOV (let's call it H) somewhere in fix.sna. From this, it somehow has to compute the vertical FOV (let's call it V). According to Wikipedia (https://en.wikipedia.org/wiki/Field_of_ ... ideo_games), in order to obtain V from H, at some point, the game needs to compute the tangent of H/2. Now luckily, in video game logic, the tangent function is a rather rare operation
Therefore I searched the disassembled code (I used Ghidra, but you could also use Cheat Engine's disassembler) for the x86 instruction for the tangent function. Luckily there weren't too many results, and from my work on Hype: The Time Quest, I already knew that the relevant code was inside a function called "GLI_xAdjustCameraToViewport". Next, I attached the Cheat Engine debugger to the game, set a breakpoint on said instructions and looked at the floating point register when the instruction was executed. For example in Laura's Happy Adventure, this told me that the three values for H/2 are 0.65, 0.7 and 0.75. This corresponds to horizontal FOV values of 1.3, 1.4 and 1.5 (I wonder if 1.5 is ever used in the game... if so I might have to adjust my script ).

[AlphaYellow]

Btw: If anyone is wondering how I figured out the standard FOV values for each game, here's what I did:

We know that the game stores the horizontal FOV (let's call it H) somewhere in fix.sna. From this, it somehow has to compute the vertical FOV (let's call it V). According to Wikipedia (https://en.wikipedia.org/wiki/Field_of_ ... ideo_games), in order to obtain V from H, at some point, the game needs to compute the tangent of H/2. Now luckily, in video game logic, the tangent function is a rather rare operation
Therefore I searched the disassembled code (I used Ghidra, but you could also use Cheat Engine's disassembler) for the x86 instruction for the tangent function. Luckily there weren't too many results, and from my work on Hype: The Time Quest, I already knew that the relevant code was inside a function called "GLI_xAdjustCameraToViewport". Next, I attached the Cheat Engine debugger to the game, set a breakpoint on said instructions and looked at the floating point register when the instruction was executed. For example in Laura's Happy Adventure, this told me that the three values for H/2 are 0.65, 0.7 and 0.75. This corresponds to horizontal FOV values of 1.3, 1.4 and 1.5 (I wonder if 1.5 is ever used in the game... if so I might have to adjust my script ).

Thanks a lot for your work Lk19, I tried Laura's Pentium III version at different aspect ratios, and it works perfectly, finally without disappearing objects on the sides! I didn't know there were different FOV values for indoor and outdoor, interesting.

[AlphaYellow]

Well, seems like this area of the game still has the same FOV, so the image is cut off at wider resolutions. Maybe it happens in other parts of the map too, haven't tested all yet.

[lk19]

Well, seems like this area of the game still has the same FOV, so the image is cut off at wider resolutions. Maybe it happens in other parts of the map too, haven't tested all yet.

Thanks for the bug report!

I took another look at the fix.sna and there are, indeed, three references to the value "1.4".
I also cross checked the scripts in RayMap and found the following piece of code in the script for the camera object ([Camera] StdCam | StdCamer):

RayMap_1.png (6.94 KiB) Viewed 4383 times

This function (Procedure_Camera_ChangeFocal) comes up a total number of three times in the scripts for the camera object, and the offsets displayed in RayMap coincide exactly with the positions of the three occurences of "1.4" in fix.sna. So with a bit of luck, we should have found ALL the relevant bytes in fix.sna

What COULD theoretically happen, of course, is that there are map-specific scripts (e.g. cutscenes) that change the FOV. The sun-dial time travelling in Hype is an example of this. In this case, one would have to make adjustments to the individual <MapName>.sna files just like I did with Hype. If anyone stumbles across one of these situations - please let me know and I will try to fix it.

TLDR: I have made the necessary adjustments to the python scripts in the post above

[AlphaYellow]

Well, seems like this area of the game still has the same FOV, so the image is cut off at wider resolutions. Maybe it happens in other parts of the map too, haven't tested all yet.

Thanks for the bug report!

I took another look at the fix.sna and there are, indeed, three references to the value "1.4".
I also cross checked the scripts in RayMap and found the following piece of code in the script for the camera object ([Camera] StdCam | StdCamer):
RayMap_1.png
This function (Procedure_Camera_ChangeFocal) comes up a total number of three times in the scripts for the camera object, and the offsets displayed in RayMap coincide exactly with the positions of the three occurences of "1.4" in fix.sna. So with a bit of luck, we should have found ALL the relevant bytes in fix.sna

What COULD theoretically happen, of course, is that there are map-specific scripts (e.g. cutscenes) that change the FOV. The sun-dial time travelling in Hype is an example of this. In this case, one would have to make adjustments to the individual <MapName>.sna files just like I did with Hype. If anyone stumbles across one of these situations - please let me know and I will try to fix it.

TLDR: I have made the necessary adjustments to the python scripts in the post above

Thanks for that, maybe there are defined FOV values for certain scripted moments, I'm not really sure . Although I found the inventory menu seems to have its own FOV for the 3D objects that are selectable (including the backpack, which seems to be 3D as well):

4:3:

16:9:

[lk19]

Although I found the inventory menu seems to have its own FOV for the 3D objects that are selectable (including the backpack, which seems to be 3D as well):

... aaand you have found out where the FOV value 1.5 is used I've updated the fix once more

I made another interesting discovery. There seems to be one more floating point variable that is passed on to the function that handles the FOV value, and it also has a value of 1.5 (but it is not the same as the inventory FOV variable).

This "FOV-like" variable seems to determine the position of the savefile names in the savegame menu:

• You can see the text position in the unpatched 4:3 game in the attached screenshot 4_3.png.
• When you only change the aspect ratio to 16:9, this text now gets a little bigger and its vertical position seems a little off (it's not right on the line anymore). It's horizontal position with respect to the (now stretched) background seems correct. See picture 16_9_A.png.
• If you change the aspect ratio to 16:9 AND scale the "FOV-like" variable with the aspect ratio in the same manner as the other FOV variables, then the text ends up in exactly the same position on screen as in the unpatched 4:3 game (although it still "looks" misplaced, because the background is stretched). See picture 16_9_B.png.

What is even more interesting is that in the "old" version of the game, this variable also seems to determine the positioning of the items on the inventory screen. If you don't scale the variable the items end up off-screen and are not visible at all!
For now, I have implemented the scaling of this variable into both the "old" and the "Pentium III" version of the fix, because even though it is not strictly necessary in the "Pentium III" version, it seems like the more "reasonable" solution and might fix problems in other areas of the game, too

BTW: I wonder if such a variable exists in Hype: The Time Quest, too... and if it could be used to fix the text positioning for higher aspect ratios

[AlphaYellow]

Although I found the inventory menu seems to have its own FOV for the 3D objects that are selectable (including the backpack, which seems to be 3D as well):

... aaand you have found out where the FOV value 1.5 is used I've updated the fix once more

I made another interesting discovery. There seems to be one more floating point variable that is passed on to the function that handles the FOV value, and it also has a value of 1.5 (but it is not the same as the inventory FOV variable).

This "FOV-like" variable seems to determine the position of the savefile names in the savegame menu:

• You can see the text position in the unpatched 4:3 game in the attached screenshot 4_3.png.
• When you only change the aspect ratio to 16:9, this text now gets a little bigger and its vertical position seems a little off (it's not right on the line anymore). It's horizontal position with respect to the (now stretched) background seems correct. See picture 16_9_A.png.
• If you change the aspect ratio to 16:9 AND scale the "FOV-like" variable with the aspect ratio in the same manner as the other FOV variables, then the text ends up in exactly the same position on screen as in the unpatched 4:3 game (although it still "looks" misplaced, because the background is stretched). See picture 16_9_B.png.

What is even more interesting is that in the "old" version of the game, this variable also seems to determine the positioning of the items on the inventory screen. If you don't scale the variable the items end up off-screen and are not visible at all!
For now, I have implemented the scaling of this variable into both the "old" and the "Pentium III" version of the fix, because even though it is not strictly necessary in the "Pentium III" version, it seems like the more "reasonable" solution and might fix problems in other areas of the game, too

BTW: I wonder if such a variable exists in Hype: The Time Quest, too... and if it could be used to fix the text positioning for higher aspect ratios

Good work so far! Finally now the inventory 3D items look right, but sadly the background images are still stretched... Also could something be done about the missing geometry in the main menu?

Missing geometry at 16:9

In 48:9 it's hilarious, apart from the totally missing geometry in the sides, there are some 2D elements that are stretched, like the menu buttons:

Also I think it would be best to unstretch all the background images in selection menus, loading screens and settings menus to center them at the 4:3 area and leaving black bars on the sides, better than the stretched look:

The 3D items in the inventory now have the proper FOV, but the stretched image makes it look weird:

Also the pause menu background is stretched, but at least the texts in all menus look correct:

Last but not least, could you release the fix for the resolution limit ingame? Seems to be the same issue for all three Playmobil games :/

[lk19]

Also could something be done about the missing geometry in the main menu?

The problem is that the main menu is actually its own map ("Marelle_4"), which is simply missing these objects. So unless we have a working map editor for this game (I don't know if RayMap is capable of this) and someone is willing to edit all these objects back in, I don't see any chance of this happening soon...

Also I think it would be best to unstretch all the background images in selection menus, loading screens and settings menus to center them at the 4:3 area and leaving black bars on the sides, better than the stretched look:

Maybe there's a way of doing this by hacking the main executable... Unfortunately, I don't even have a clue where I should start looking. Another way would be to hack the game's ressources and simply add black bars to the backgrounds (or even better: use AI to extend the images). But again, I have no idea how the ressources work in this game. Also, you would have to supply a separate fix for each aspect ratio then (although I guess most people would be happy with 16:9).
Maybe someone who is more capable than me (both knowledge-wise and time-wise) finds a way

Last but not least, could you release the fix for the resolution limit ingame?

I have updated the PCGamingWiki pages for both Laura and Alex (fix is different between the two games, because Alex uses a binarized version of the file game.mem, whereas Laura's file has a more human-readable form). The fix for Hype would be identical to Laura if you would like to try it out, but currently my widescreen patch only supports resolutions of 640xXXX... maybe later

Next, I will take a closer look at the FOV (and "FOV-like") values for Alex. I have found at least one more value, which governs the FOV in the little 3D animation window that comes up when the game asks you if you really want to teleport to another place. Maybe I also find a way to fix the misplaced HUD elements when you set the x-resolution to anything other than 640. It's interesting how the game shares this property with Hype, but not with Laura. I guess Laura is the only game that was really meant to be played in any resolution other than 640x480, as you can see by the resolution selector in the "Pentium III" version's VidSelect.exe

[lk19]

I have discovered some additional FOV values in Alex and updated my script accordingly.

• The main menu uses it's own special FOV of 0.3702 (not joking ). I guess it was chosen so that the gigantic models for Alex and his dog look good at the chosen angle. This FOV value resides in bkgd.fix so that I had to adjust my script to also edit this file. You can now run the script directly from the game folder and it will update both files automatically. I updated the instructions in the post above and on PCGamingWiki. Unfortunately – just as in Laura – you will be able to see that the background map is just a minimalistic scene with many missing objects once you increase the FOV...
• The little animation that plays whenever you have to confirm something ("do you really want to quit the game?") has a FOV of 1.5. I patched this.
• There is another variable with the value of 1.5 that the game reads into the same function that processes all the other FOV values. I have no idea, what exactly it does, but to be on the safe side, I also patched this variable.

Note: It is still recommended to play Alex at a resolution of 640xXXX due to the fact that one of the main HUD elements (the little menu bar where you select items) gets misplaced once you change the internal x-resolution. I think I've found a way to fix this by editing Alex_D3D.exe but I need to give it some more testing

[lk19]

Okay, so I think I've found the solution for the misplaced HUD element (green menu bar at the top, that pops up whenever you select an object to interact with).

I attached an edited Alex_D3D.exe, where the bar should appear in the top center no matter which x-resolution you choose. It's still a little experimental so it would be great if I could receive some feedback before I link this on PCGamingWiki
Also: I used the English/French/German version as a basis, but it might work with other versions of the game too.

For the sake of documentation, here's what I changed in the EXE:
There are two functions that seem to determine the placement of the green bar. One is used for the animation when it appears and disappears, and the other is used for when the bar is just resting staticly on screen. If you load the EXE into Ghidra you can easily find them by searching for the floating point value 0.00078125 and trace the only two functions that access this data.
These two functions load the game's x-resolution (e.g. 1920) from address 0x0071caa0 (in my version of the game). I patched both funcitons to load the value 640 instead of the changed x-resolution: 8b 15 a0 ca 71 00 (MOV EDX,dword ptr [DAT_0071caa0]) -> ba 80 02 00 00 90 (MOV EDX,0x280; NOP).