Alex Builds His Farm & Laura's Happy Adventures Widescreen

[AlphaYellow]

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

I think it's more than worth doing it for both Alex and Laura, the amount of people using ultrawide and wider setups nowadays is bigger than you might think. And unstretching the background images doesn't actually require editing the images directly, there are values in the EXE and neighbouring files that control how the HUD is positioned on screen, for example, ThirteenAG's widescreen fixes address those values, usually it goes by dividing 1 by the width (for the background images), and dividing the HUD x-position by the res width (for HUD elements) or something like that (to move them around), however to unstretch it, I'm not really sure how, you'd have to contact other modders who have done HUD fixes for this engine, like Automaniak did for Donald Duck Goin' Quackers and Rayman 2 (he's usually active on Steam, so might give him a shoutout). For the main menu maps, I'm not sure how hard it would be to add those objects in a mapping editor that would work for Alex and Laura, but could be a possibility in a near future.

Anyways, I tried your new FOV script for Alex and seems like this camera during the conversation with Alex's father still has the same FOV, might be a different value from those you found out so far.

How it should be in 16:9 (with my original solution, glitchy on the sides obviously):

How it is with your script:

[lk19]

Anyways, I tried your new FOV script for Alex and seems like this camera during the conversation with Alex's father still has the same FOV, might be a different value from those you found out so far.

Great spot! These are the problematic ones, since they are specific to the particular cutscene / animation (not unlike the FOV in the main menu or the time-travelling issue in Hype). They are not stored in fix.sna, but in the map's own SNA-file.

But come to think of it.. it might be easier to patch the function that processes the FOV in the EXE rather than editing each SNA file separately. I will try to take a look at it later.

[lk19]

Now I remember, why I didn't try to patch the EXE in order to change the FOV before

Recall that in order to scale the FOV, we use the following formula: NewFOV = 2 * atan(tan(OldFOV / 2) * (3 / 4) * AspectRatio).

Here is a decompilation of the relevant part of the function GLI_xAdjustCameraToViewport that processes the FOV:

In line 125 the FOV value from the SNA file gets loaded and multiplied by 0.5. My first idea was to patch the FOV here, by simply changing 0.5 to a different value. The problem is that the relationship between NewFOV and OldFOV is not linear, so it would have to be a different factor for every FOV value in the game.
The next idea was to change the FOV after the tangent function has already been applied to it in line 127. This is EXACTLY what the "glitchy" solution that we have already found does (i.e. changing the 1.0 in line 128 to 0.75). This works, because after applying the tangent to the FOV, the relationship between old and new value should be linear!
Unfortunately, as we can see from lines 133 and 134, the variable fVar1 from BEFORE this fix was applied, gets used some more in the function (and even more further on in the code). This is the reason, why we have the glitchy objects popping in!

However... I have an idea : I'll try to find a "code cave" (a bunch of zeros or NOP instructions used for padding) that is large enough to accomodate the formula above for the NewFOV. Then I will insert a jump instruction in line 125, so that this NewFOV will be processed by the function instead of the old one. Let's see if this works

[lk19]

Alright... I think I've done it I attached a patched Alex_D3D.exe with the integrated FOV fix (+ the fix for the misplaced HUD elements from before).

It should work independent of the set resolution and does not require editing any SNA-files. So if you applied one of my previous patches, please restore the backups of fix.sna and bkgd.sna that the script created.

I will wait for some feedback before I link this on PCGamingWiki. Also, I haven't quite made up my mind whether I want to publish this fix as a standalone EXE or as a python script that patches the existing EXE. The advantage of the Python script is that it might work with versions of the game that don't support the English/French/German EXE (e.g. in Hype, you could use the English EXE for the German version of the game, but not for the Spanish version). The disadvantage is that it requires the user to remove the SafeDisc encryption first (although most people will most likely use a no-cd patch anyway, since SafeDisc does not work on modern Windows anymore).

In the meantime, I'll check if the same can be done for Laura and eventually for Hype

Edit: The patched EXE now no longer requires the CD.
Edit2: Removed the attachment. See newer version below.

[AlphaYellow]

Now I remember, why I didn't try to patch the EXE in order to change the FOV before

Recall that in order to scale the FOV, we use the following formula: NewFOV = 2 * atan(tan(OldFOV / 2) * (3 / 4) * AspectRatio).

Here is a decompilation of the relevant part of the function GLI_xAdjustCameraToViewport that processes the FOV:
Screenshot_Ghidra.png
In line 125 the FOV value from the SNA file gets loaded and multiplied by 0.5. My first idea was to patch the FOV here, by simply changing 0.5 to a different value. The problem is that the relationship between NewFOV and OldFOV is not linear, so it would have to be a different factor for every FOV value in the game.
The next idea was to change the FOV after the tangent function has already been applied to it in line 127. This is EXACTLY what the "glitchy" solution that we have already found does (i.e. changing the 1.0 in line 128 to 0.75). This works, because after applying the tangent to the FOV, the relationship between old and new value should be linear!
Unfortunately, as we can see from lines 133 and 134, the variable fVar1 from BEFORE this fix was applied, gets used some more in the function (and even more further on in the code). This is the reason, why we have the glitchy objects popping in!

However... I have an idea : I'll try to find a "code cave" (a bunch of zeros or NOP instructions used for padding) that is large enough to accomodate the formula above for the NewFOV. Then I will insert a jump instruction in line 125, so that this NewFOV will be processed by the function instead of the old one. Let's see if this works

Alright... I think I've done it I attached a patched Alex_D3D.exe with the integrated FOV fix (+ the fix for the misplaced HUD elements from before).

It should work independent of the set resolution and does not require editing any SNA-files. So if you applied one of my previous patches, please restore the backups of fix.sna and bkgd.sna that the script created.

I will wait for some feedback before I link this on PCGamingWiki. Also, I haven't quite made up my mind whether I want to publish this fix as a standalone EXE or as a python script that patches the existing EXE. The advantage of the Python script is that it might work with versions of the game that don't support the English/French/German EXE (e.g. in Hype, you could use the English EXE for the German version of the game, but not for the Spanish version). The disadvantage is that it requires the user to remove the SafeDisc encryption first (although most people will most likely use a no-cd patch anyway, since SafeDisc does not work on modern Windows anymore).

In the meantime, I'll check if the same can be done for Laura and eventually for Hype

Great work! I was always wondering if it was just easier to patch the function in the EXE that handles the FOV calculations, and you did exactly that. Would it be possible to remove the CD check in your exe as well? For me, the noCD exes at GameCopyWorld for the English/German version don't even boot into the game for some reason, but your exe does. Would be cool to not depend on the CD for this fix, and PCGamingWiki's policies allow it as well.

[AlphaYellow]

I found something that I don't know if it's an issue of the game, but when the FOV is high (like in 48:9), the heads of characters get squished instead of stretched as they should at the sides, it's a small thing but just wanted to point it out. Happens with both your new and old solutions, it's part of how the FOV works in the game I guess.

[Garo]

I found something that I don't know if it's an issue of the game, but when the FOV is high (like in 48:9), the heads of characters get squished instead of stretched as they should at the sides, it's a small thing but just wanted to point it out. Happens with both your new and old solutions, it's part of how the FOV works in the game I guess.

l40rw5.webp

Yeah I don't think you can change that it's probably just how the game was programmed.

[lk19]

Great work! I was always wondering if it was just easier to patch the function in the EXE that handles the FOV calculations, and you did exactly that. Would it be possible to remove the CD check in your exe as well? For me, the noCD exes at GameCopyWorld for the English/German version don't even boot into the game for some reason, but your exe does. Would be cool to not depend on the CD for this fix, and PCGamingWiki's policies allow it as well.

Done! I updated the experimental patch in the post above.

There's one more thing I would like to have a few opinions on:

When I created the widescreen patch for Hype, I patched the EXE so that it no longer requires ubi.ini to be in the windows directory, but instead looks for it in the game directory. This makes the game "portable".
I did this, because the well-known unofficial nGlide-patch for this game has the same modification. The problem is that many people don't seem to know about this and most instructions on the internet tell you to use the nGlide patch and then tell you to edit ubi.ini in the windows directory . This, of course, does not work, because when you use the nGlide patch, you first have to create a folder UbiSoft in your game directory and move ubi.ini there. I think this might be one of the main reasons why the game (Hype) crashes for so many people: It tries to play the FMVs (which are known to cause crashes), even though they disabled FMV-playback in ubi.ini...
Now the question is if I should make the game "portable" by patching the EXE to look for ubi.ini in the game directory or if I should leave it as it is to avoid confusion? What do you think?

[AlphaYellow]

Great work! I was always wondering if it was just easier to patch the function in the EXE that handles the FOV calculations, and you did exactly that. Would it be possible to remove the CD check in your exe as well? For me, the noCD exes at GameCopyWorld for the English/German version don't even boot into the game for some reason, but your exe does. Would be cool to not depend on the CD for this fix, and PCGamingWiki's policies allow it as well.

Done! I updated the experimental patch in the post above.

There's one more thing I would like to have a few opinions on:

When I created the widescreen patch for Hype, I patched the EXE so that it no longer requires ubi.ini to be in the windows directory, but instead looks for it in the game directory. This makes the game "portable".
I did this, because the well-known unofficial nGlide-patch for this game has the same modification. The problem is that many people don't seem to know about this and most instructions on the internet tell you to use the nGlide patch and then tell you to edit ubi.ini in the windows directory . This, of course, does not work, because when you use the nGlide patch, you first have to create a folder UbiSoft in your game directory and move ubi.ini there. I think this might be one of the main reasons why the game (Hype) crashes for so many people: It tries to play the FMVs (which are known to cause crashes), even though they disabled FMV-playback in ubi.ini...
Now the question is if I should make the game "portable" by patching the EXE to look for ubi.ini in the game directory or if I should leave it as it is to avoid confusion? What do you think?

Great stuff. In my opinion, I think both Laura and Alex should be portable, and not depending on old outdated directories inside the Windows folder, but it's just my opinion!

[deton24]

Do you really need to use "UbiSoft" folder inside the game folder for ubi.ini instead of root folder of the game? Maybe in such case it will just create the file instead of crashing it.
Portability idea would be great. You could just warn people in readme or instructions about where the ubi.ini for the game is now located and that's all.

[lk19]

Do you really need to use "UbiSoft" folder inside the game folder for ubi.ini instead of root folder of the game?

I guess, you're right. There's really no need to do that. The reason I did it was a) because the nGlide patch for Hype did it this way and b) because the relative path "\UbiSoft\Ubi.ini" is hard-coded into the game. Of course.. there's nothing stopping me from changing it So I guess I'll make it <GameDir>\Ubi.ini instead of <GameDir>\UbiSoft\Ubi.ini

[lk19]

So here are new versions of the patched EXE files for Alex and Laura. They are all for the English/French/German releases of the game and I cannot guarantee that they work with other versions. If you have an incompatible version, please let me know. I also attached the Python scripts I used for patching the EXE files. With a bit of luck, different localizations are similar enough so that the scripts work on them, too.

Here are the things that I've patched:
Both games

• Made the games "portable" so that they are searching for Ubi.ini in the game's root directory rather than the Windows directory (Note: You don't need a subfolder "UbiSoft" – just copy Ubi.ini to the game directory).
• Adjusted the FOV so that it scales with the new aspect ratio.

Alex only

• Removed SafeDisc encryption (Note: Laura does not have SafeDisc ).
• Removed the checks if the CD is the drive.
• Patched the green menu bar that appears when you press the space bar. Normally, when you change the x-resolution, it gets misplaced.

Unfortunately, I wasn't able to make a no-CD patch for Laura. The code is just too different from the other games, and no-one seems to have done it before. The best I could do was to remove both the CD check in the main menu and the one whenever you enter a new map. However, entering a new map would corrupt the game's memory and lead to graphical glitches and crashes I guess it's not too much trouble to make an ISO image of your disc and then just play with a virtual drive (btw: Windows 10 automatically mounts the image if you double-cklick on it).

To change the resolution/aspect ratio or extend the game's internal memory limits, you still need to follow the guides I wrote on PCGamingWiki. These things are not changed in the EXE, but in other files.

[AlphaYellow]

So here are new versions of the patched EXE files for Alex and Laura. They are all for the English/French/German releases of the game and I cannot guarantee that they work with other versions. If you have an incompatible version, please let me know. I also attached the Python scripts I used for patching the EXE files. With a bit of luck, different localizations are similar enough so that the scripts work on them, too.

Here are the things that I've patched:
Both games

• Made the games "portable" so that they are searching for Ubi.ini in the game's root directory rather than the Windows directory (Note: You don't need a subfolder "UbiSoft" – just copy Ubi.ini to the game directory).
• Adjusted the FOV so that it scales with the new aspect ratio.

Alex only

• Removed SafeDisc encryption (Note: Laura does not have SafeDisc ).
• Removed the checks if the CD is the drive.
• Patched the green menu bar that appears when you press the space bar. Normally, when you change the x-resolution, it gets misplaced.

Unfortunately, I wasn't able to make a no-CD patch for Laura. The code is just too different from the other games, and no-one seems to have done it before. The best I could do was to remove both the CD check in the main menu and the one whenever you enter a new map. However, entering a new map would corrupt the game's memory and lead to graphical glitches and crashes I guess it's not too much trouble to make an ISO image of your disc and then just play with a virtual drive (btw: Windows 10 automatically mounts the image if you double-cklick on it).

To change the resolution/aspect ratio or extend the game's internal memory limits, you still need to follow the guides I wrote on PCGamingWiki. These things are not changed in the EXE, but in other files.

Thanks a lot, finally the games are portable now, just unfortunate that Laura still requires the CD, but I understand the problems of trying to circumvent CD checks Could you also do for other versions of the game (there are quite some apart from the English/German/French version, also Dutch, Brazilian and European Portuguese, Spanish and also Italian , not sure if there are others too).

Also I noticed when increasing the memory limit to run either Alex or Laura at 1920x1080, the game quite often runs below 60 FPS with constant FPS drops in certain areas of the map, and that's just really odd, not sure if it's the engine's issue or my computer.

Just tested the Laura Pentium III exe, and the sides are glitchy, just like my original solution, something in the new FOV code must be wrong

I'd say the HUD could be taken care of too, but I suppose that's a harder task.

[lk19]

Just tested the Laura Pentium III exe, and the sides are glitchy, just like my original solution, something in the new FOV code must be wrong

Interesting... neither the "old" version nor Alex seem to suffer from this issue. I also recently implemented this FOV fix into Rayman 2 – without any disappearing objects. I'll look into it!

Edit: I did find A bug in my code for Laura P3, but apparently that's not the reason for the disappearing objects. When I loaded the x- and y-resolution from memory, in order to compute the new FOV, I accidentally loaded two INTEGERS as floats into the FPU (in the other games, the values I loaded were actually floats in the first place). Well... turns out that 4-byte float representation works in a way that it doesn't make a difference if you interpret the integer bytes as float, as long as you're only interested in the quotient I'll still "fix" this when I figured out what causes the disappearing object

Edit2: Found the problem and I think I know how to fix it. Unfortunately, I probably won't have the time to do it for a couple of days

[deton24]

Also I noticed when increasing the memory limit to run either Alex or Laura at 1920x1080, the game quite often runs below 60 FPS with constant FPS drops in certain areas of the map, and that's just really odd, not sure if it's the engine's issue or my computer.

Maybe try out this Dege's patch. It was made for Rayman 2 and both Glide and DX6 renderers, where a similar issue occurred frequently.
https://www.vogons.org/download/file.php?id=83792

[AlphaYellow]

Also I noticed when increasing the memory limit to run either Alex or Laura at 1920x1080, the game quite often runs below 60 FPS with constant FPS drops in certain areas of the map, and that's just really odd, not sure if it's the engine's issue or my computer.

Maybe try out this Dege's patch. It was made for Rayman 2 and both Glide and DX6 renderers, where a similar issue occurred frequently.
https://www.vogons.org/download/file.php?id=83792

Tried, doesn't help at all. And game doesn't even use those files at all, this seems to be an engine issue rather than renderer one.

[deton24]

Maybe check various wrappers for the renderer. E.g. DX6 has broken ddraw support since Windows 8.
dgVoodoo (DX, Glide), nGlide (Glide, optionally with Vulkan support), dxwrapper (DX, e.g. the specific version linked on PCGamingWiki's for Rayman 2).
E.g. for dgVoodoo, also fiddle with various settings like e.g. fast memory access or set turn on DX12 in the configurator (but it can be glitchy).

[AlphaYellow]

Maybe check various wrappers for the renderer. E.g. DX6 has broken ddraw support since Windows 8.
dgVoodoo (DX, Glide), nGlide (Glide, optionally with Vulkan support), dxwrapper (DX, e.g. the specific version linked on PCGamingWiki's for Rayman 2).
E.g. for dgVoodoo, also fiddle with various settings like e.g. fast memory access or set turn on DX12 in the configurator (but it can be glitchy).

Yes, I tried that all, but nothing really works to fix it, it's an engine thing

[lk19]

Just tested the Laura Pentium III exe, and the sides are glitchy, just like my original solution, something in the new FOV code must be wrong

I fixed the glitchy sides and updated the EXE and the script in the post above!

[Ftwtv]

So here are new versions of the patched EXE files for Alex and Laura. They are all for the English/French/German releases of the game and I cannot guarantee that they work with other versions. If you have an incompatible version, please let me know. I also attached the Python scripts I used for patching the EXE files. With a bit of luck, different localizations are similar enough so that the scripts work on them, too.

Here are the things that I've patched:
Both games

• Made the games "portable" so that they are searching for Ubi.ini in the game's root directory rather than the Windows directory (Note: You don't need a subfolder "UbiSoft" – just copy Ubi.ini to the game directory).
• Adjusted the FOV so that it scales with the new aspect ratio.

Alex only

• Removed SafeDisc encryption (Note: Laura does not have SafeDisc ).
• Removed the checks if the CD is the drive.
• Patched the green menu bar that appears when you press the space bar. Normally, when you change the x-resolution, it gets misplaced.

Unfortunately, I wasn't able to make a no-CD patch for Laura. The code is just too different from the other games, and no-one seems to have done it before. The best I could do was to remove both the CD check in the main menu and the one whenever you enter a new map. However, entering a new map would corrupt the game's memory and lead to graphical glitches and crashes I guess it's not too much trouble to make an ISO image of your disc and then just play with a virtual drive (btw: Windows 10 automatically mounts the image if you double-cklick on it).

To change the resolution/aspect ratio or extend the game's internal memory limits, you still need to follow the guides I wrote on PCGamingWiki. These things are not changed in the EXE, but in other files.

I tried your fix for the old version of the game, it makes my game really slow + it's crashes whenever I try to open the gate in front of the house (the music's still playing but Laura is frozen in front of the gate). It's not specific to your fix tho, it's D3D which's causing that. I have to launch the game with the Glide exe & 3DFX to be able to play (but whithout your fix then).

It's kind of funny beacause with Hype I can play with D3D but 3DFX is slow and crasing. Does it really change anything anyway?

I would like to try it on Laura P3 version but the game doesn't work with AMD processor.
Right now it's displaying an error "Streaming SIMD Extension not detected. This Game requires at least a PIII to run".

Do you think it's possible to bypass that?