Audio Popping

Regardless of the SFX Volume and Music Volume settings, there will be some short audio pops that play at full volume sporadically while driving. These sounds originate from the Sound Manager; patching out the Sound Manager update function makes them, and every other sound, stop playing. The game thinks it is playing these sounds at the correct volume as the DisplaySoundInfo command shows the user-selected volume for all of the sounds it displays. It is likely that they are being configured using a different interface than the rest of the sounds; one that does not set the Direct Sound buffer volume to be the same as the game's internal sound structure volume in the Sound Manager's update function. They are created and played with the same interface as the rest of the sounds, so the bug must originate in proximity to creation when the game's internal sound structure is configured. Hooking the IDirectSound::CreateSoundBuffer method and setting the volume to DSBVOLUME_MIN before handing the buffer handle back to the game successfully eliminates the popping. This is proof that the game is never setting the volume of these buffers.

No VSync

The EnableVSYnc command appears to have no effect on the actual VSync setting.

Weird FPS Locking Behavior

When launching the game with DisableMOvie so that the intro video is never played, the framerate will be capped 64 fps. After enabling movies again and playing one, the framerate cap will rise to 500 fps. This indicates that the Bink Video player used by the game is affecting the game's framerate cap.

Prominent Zouna Underground member 0x5abe has discovered the cause of this bug and introduced a fix for the Ratatouille video game in commit 7bdc9cb: Added 64fps bug fix. Added removeFpsCap option of his RatataR custom launcher for the PC version of Ratatouille. An explanation of the cause of the bug as described by 0x5abe follows.

The bug is caused by a change from the default value of the system timer resolution by binkw32.dll, the dynamic library used by Bink Video. The game calls Sleep(1) in the message loop intending to sleep for 1ms, instead of the 15.625ms the game was actually sleeping for due to the low default resolution. Bink would change the resolution by calling timeBeginPeriod/timeEndPeriod which raised the fps cap. The article Windows Timer Resolution: The Great Rule Change was instrumental in 0x5abe's discovery of the cause of the bug.

Weird Driver Model Pose On Spawn

Sometimes when the driver respawns after a crash, the mount points will be in the right place but the other parts of the mesh will be in weird positions. This bug appears to go away when the fps is locked to 60. If you Alt-Tab at the right time while loading, the guy wont respawn on the bike but you can still drive it.

Alt-Tab Unload Behavior

When alt-tabbing out of the game in full-screen mode, all world objects will unload and slowly load back in when the window gains focus. This has the side effect of disabling collision with most things while the game is minimized.

Alt-Tab Soft Lock

If you Alt-Tab fast enough, the screen will go black and lock until the process is killed.

Alt-Tab During Shaders Compiling

If you alt-tab while the compiling shaders screen is up, the game might crash or freeze. This might be a special case of the previous bug.

Camp Menu Text Replacement When Exiting With GFWL

When you exit with GFWL the camp menu's name gets replaced by the networking menu's name.

DirectInput Support Is Broken

Only the XInput support is fully functional.

Ghost Barn

One of the barn meshes doesn't have collision.

Invisible/Disappearing FUEL Barrels

Sometimes the FUEL Barrels will disappear while on screen.

Memory Leaks

Performance decreases dramatically as the game runs and memory usage increases. I'm not too sure about this. When running with dmalloc on the decomp it didn't report anything, so maybe the game is just holding on to resources for longer than it needs to, and it's not a proper memory leak. More research to be done for sure.

Collision Crash

The game will crash during a physics collision very rarely. Although if you play for a long enough time it will happen eventually. It can also happen only 1-2 hours into playing. The address of EIP that raises the out-of-bounds memory access looks like a float value. Maybe they are dereferencing a float. This most commonly happens when checking if it's ok to save the respawn location at 0x00527D64. When it crashes there, the pointer value is always 0x3f800000 aka 1.0f, that gets set at 0x00807DCF. But it can also happen at 0x004063b9 in the CameraMove_G class. Patching the float assignment to nops seems to fix the crash. See also: Respawn Behavior.

Tree Missing Face

One of the "ramp trees" is missing a face on the underside of the ramp part.

Select any Car Glitch

https://steamcommunity.com/sharedfiles/filedetails/?id=408757353

Respawn in Ground

If a respawn point is recorded on a steep slope and you are oriented perpendicular to the slope, there is a chance you will respawn with half of the vehicle embedded in the slope.

Flickering

I don't think this is related to fps. Looks like really fast scanlines. Most noticeable in snowy areas. Messing with the time of day and weather seems to let you trigger this. Setting the framerate with RTSS doesn't have an effect maybe? hard to tell. Literally only the snow flickers. If its raining or something then it goes away. but if its slighly overcase it happens regardless of time of day. moving the camera makes it a lot worse. makes me want to vomit. Go to an area covered in snow like near mount rainier camp, turn on Special Effects -> Weather -> Toggle Weather Edit. Turn clouds up to 1.0 and everything else to 0.0, set time to 13.00 or therabouts, it will happen when you move the camera. happens even with shadow maps disabled. Seems to have something to do with the clouds scattering shaders. it should be happening everywhere but the snow is just really reflective and you need the right cloud cover so it isnt very likely to happen, maybe only storm clouds like when there is lightning. when you move in debug cam only translatons make it flicker not rotations. so it has to do with the camera position. and if you go back to the same place it will be on the same stage of flicker. moving slowly it flickers slowly. if you stay in one place and it keeps flickering its because the clouds are moving.

This is probably more pronounced with the snow because it is so shiny. The shadow flickering might also be related to this.

Transparent Terrain

Sometimes when returning from Alt-Tab certain models like trees will be visible through the terrain.

Invisible Bush

There's a bush that has collision but no model.

Bad Bridge Collision

Sometimes trucks will drive through the bridges if you aren't close enough for collision to be enabled.

Flattened Terrain No Collision

Sometimes when running under a debugger, the flattened terrain will render but not be collideable. Instead, you will fall through it/drive over it on the height map terrain. This happens when having a breakpoint on where the vehicle params pointer is copied, and other times too I guess.

Ghost A-Frame Fence

When hitting the 2 A-frame fences that line some dirt roads a third one will pop in. This only happens for the fences placed on a certain road type, like the ones at (6148.37, -21667.72) and (6267.63, -23439.29). The same fence can spawn on a different road type, like at (5303.70, -26513.78), too but this bug doesn't happen for those fences. It kind of looks like they're spaced as if there should be 3 of the fences with the ones that break into 3. Maybe it's more about the type of fence prefab that gets placed than the road.

Render Order

Sometimes water will render over leaves, or far smoke renders over near smoke. Seems to be a problem with sorting the transparent meshes.

Ghost Window Shutter

The shutters on one of the house models are 1-sided, and transparent stuff renders over them from one direction. Probably marked transparent by accident, and this is a special case of the previous bug.

Firefly Bumper Duplication

Every time you crash into something with the Firefly, the front bumper is left behind, even if it has already fallen off. If you crash just right, then it might leave behind >20 bumpers at once.

AutoSave Spinner Draws Over Mouse

During the opening sequence, the spinner on the autosave warning screen will draw over the mouse cursor. Also, the stars and fuel count in the pause menu draw over the mouse cursor.

Crash deep in SpecialEffectsManager_G::~SpecialEffectsManager_G on exit

After finishing a race with a tornado and returning to freeride, if you exit the game normally, it may crash several calls deep in the SpecialEffectsManager_G destructor. See also: https://github.com/widberg/FUELDecompilation/issues/1

Helicopter Name Not Translated

The hardcoded string "heloico" is used as the name of the helicopter in the race ranking. It should probably be translated.

Sitting in Place for a Long Time

If you get unlucky, the game might crash from sitting in place for a long time due to how the respawn location list works. See also: Respawn Behavior.

Day Night Stutter

The game freezes up for a second or two when switching to the nighttime shaders.

Binary_Z Stutter

The game can occasionally get stuck in the loop at 0x0069C597 in Binary_Z. edx will have a crazy high number in it like 0x80000000, possibly indicating a signedness bug. This manifests as a few seconds of the game being frozen, I often worry that this is a case of the collision crash bug which also freezes before crashing, but the game unfreezes, and I stop worrying.

Ok, another stupid piece of shit. It seems to be related to my game param file edit making the F14 planes fly way faster, lower to the ground, and more frequently. The 0x80000000 seems to be related to this https://www.vogons.org/viewtopic.php?t=78127. It happens when the game tries to get the height of the terrain at a point in one of the F14 methods. For some reason it happens way more often in fmtk. If you keep restarting the game while spawing at pinwheels it is bound to happen before you even make it to the menu. The game will hang between the auto save TRC menu and the main menu. Would like to know what the exact problem is and why it happens more in fmtk. does it happen in fmtk without the modifications? just the decomp?

Somehow the x and z components of the quat being passed in to the function at 0x00445500 are -nan. Still not sure why this is more likely in fmtk. /fp:fast or something? but returning 0 if the coords are invalid works fine. This is all related to the planes trying to figure out how high the terrain is below them so they can fly above it, although they love flying through terrain which is kind of its own bug.

Ok, some more clarity, some of the members of F14Move_G are not initialized by the constructor. When running the game in a debugger, the msvcrt will use the debug heap and initialize these to 0xBAADF00D, which as a float is -0.00132703932467848062515, see https://float.exposed/0xbaadf00d, which is a valid float and very close to 0. In practice, this means that you should never see a plane when running in a debugger because of how the math works out. When not using the debug heap, you get whatever garbage was on the heap before you, which happens to be some pretty reasonable numbers most of the time the game starts so there's no issue. But sometimes its NaN and since NaN is viral, everything after that goes wrong until FISTP stores the 0x80000000 and has the function increment from that to the target value which takes ages. This happens more with FMTK just because of the different heap and allocation patterns. It is easily fixed by initializing these Vec3fs to 0s and 1s to make the math work.

I'm not sure that's the whole issue though. The F14 bug only explains why the game might freeze up while loading, since the game constructs one F14 at startup and reuses it. I have also found the game spinning in here for a second or two after extended play, which indicates other calls to the function have similar FISTP issues. It might be best to check if the arguments are 0x80000000 rather than play whack-a-mole at every call site.

const BINARY_FUNC = ptr('0x0069C560');

Interceptor.attach(BINARY_FUNC, {
  onEnter: function(args) {
    var a2 = args[1];
    var low = a2.add(0x50).readUInt();
    if (low == 0x80000000) {
      console.log('BINARY_FUNC called from:\n' +
        Thread.backtrace(this.context, Backtracer.ACCURATE))
    }
  }
});

While cleaning up my old notes, I came across a theory that "The lag may be from tricks. Like the game is trying to figure out how far above the ground you're going to be, so it knows whether there's enough time for you to do a trick (driver swinging his legs around)." It's worth investigating whether stutter and lag persist after fixing the aforementioned issues.

Crazy Rendering Bugs

Not sure how to reproduce all cases of this reliably, but after playing for ~2 hours, a weird green strap texture may appear in the bottom left of the screen. Also, trees and other meshes may flicker when close by and viewed at certain angles, and large white triangles may stick out of the vehicle. On rare occasions, the skybox will become subject to this glitch and look very strange. See also: https://github.com/widberg/FUELDecompilation/issues/2

This is due to a driver bug; see the linked issue.

Startup Stutter

Really jittery frames while the game is loading, but then it settles down, and the game runs fine once you make it to the main menu. This is caused by running the game with a relative path "../../FUEL.exe" -W for example. When you do this, the game will have to recalculate the absolute path to every file it tries to load, and there are a lot of shader cache files it has to load when starting up. The solution is to either run the game directly from the FUEL directory using "FUEL.exe" -W so it will get the absolute path to itself using GetModuleFileName or similar, I haven't actually checked. Or the even more recommended fix, use the absolute path when launching the game, "D:\SteamLibrary\steamapps\common\FUEL\FUEL.exe" -W. This last method is required for older games like Ratatouille; they will crash otherwise. WALL-E more closely mirrors FUEL's laggy startup behavior.

Salt Flats Billboards

2 of the billboards in the salt flats camp have a weird second billboard in front of them that is only visible from one side.

Rainer Peak Scrap

The pile of fallen metal in the center of the frozen spiral has some cross beams that are only visible from the inside. These should be double-sided.

The Ashtray Door

The door on the satellite tower in the ashtray is only visible from one side. Also, the open bit you can see the back of the door through is still colidable, but it looks like you should be able to drive in it.

Sleepy Freeze

Sometimes the game freezes up at the sleep call at 0x0077BA4F. Started happening to me on Windows 11. It can also be a black screen. Honestly, it looks like the only thing any thread is doing is calling sleep when this happens. Maybe related to Alt-Tab or the window losing focus.

Hot GenWorld_Z Function

Not a bug really, but Luke Stackwalker revealed that WorldGenAutoMesh GenWorld_Z::BaseObject_vftable_3 is an extremely hot function. While fixing bugs, profile and optimize the hot functions.

Bugs in 3rd Party Tools Interacting With FUEL

Not bugs in FUEL, but if I don't write them down somewhere, I'll forget. And maybe it's kind of FUEL's fault, who knows?

RenderDoc

When using RenderDoc with DXVK, since it doesn't support D3D9 (see note at the end), and doing a frame capture of FUEL anywhere but the loading screens, it will fail with the message Capture failed: Encountered an out of memory error: Couldn't allocate readback memory. It was suggested to disable GPUReadbackDeviceLocal in UI Settings window → Core → Config Editor Vulkan → GPUReadbackDeviceLocal here https://github.com/baldurk/renderdoc/issues/2060#issuecomment-697911665. This made the capture slower, and it still failed for me. There was also a reported VK_ERROR_OUT_OF_DEVICE_MEMORY here https://github.com/baldurk/renderdoc/issues/2157 where baldurk responded with the classic "don't use RenderDoc for games you didn't create". RenderDoc with DXVK works with other Zouna games, and it's very useful. I would like it to work with FUEL. It seems like the root of this is a DXVK problem. I'll wait it out and hope the next time I feel like I need to use RenderDoc for something, this was fixed in a newer version; if not, maybe I'll look into it more. As being tracked on the How To Help page, I am "working" on a fork of RenderDoc that works with D3D9, widberg/renderdoc-d3d9.

The Fix

Enabling Large Address Aware for FUEL fixes this. You can run editbin /LARGEADDRESSAWARE FUEL.exe to edit the FUEL executable, enabling the LAA flag. On 64-bit Windows, this increases the available address space from 2GB to 4GB, which is enough for RenderDoc to do its job. I have started enabling LAA in FMTK.

The Other Fix

If you're using RenderDoc with FMTK because I told you to, and "Collect Callstacks" is not working, you need to make a tweak. FMTK depends on dbghelp.dll to collect callstacks for crash reporting. RenderDoc hates this. You can apply the following diff and rebuild RenderDoc to keep it from being overly cautious.

diff --git a/renderdoc/os/win32/win32_callstack.cpp b/renderdoc/os/win32/win32_callstack.cpp
index ef0fc7bde..af99d9d99 100644
--- a/renderdoc/os/win32/win32_callstack.cpp
+++ b/renderdoc/os/win32/win32_callstack.cpp
@@ -480,7 +480,8 @@ static bool InitDbgHelp()
   HMODULE module = NULL;

   // can't reliably co-exist with dbghelp already being used in the process
-  if(GetModuleHandleA("dbghelp.dll") != NULL)
+  // if(GetModuleHandleA("dbghelp.dll") != NULL)
+  if(false)
   {
     RDCLOG(
         "dbghelp.dll is already loaded, can't guarantee thread-safety against application use. "

Although ironically, RenderDoc captures with callstacks in them are quite large, so you'll have to use the x64 version of qrenderdoc to open them to avoid an out-of-memory error.