Introduction

On the SilentPatch GitHub issue tracker, I received a rather specific bug report:

Skimmer airplane doesn’t exist in Windows 11 24H2

When I upgraded my windows to version 24H2, the Skimmer plane disappear completely from the game. It can’t be spawn using trainer nor it can’t be found anywhere on it’s normal spawn points. I’m using both my modded copy (which is before the update, is completely fine) and vanilla copy with only silentpatch (I tried the 2018, 2020 and the most recent version of silentpatch) and the plane still won’t exist.

If this was the first time I had heard about it, I’d likely consider it dubious and suspect there are more things at play, and it’s not specifically Windows 11 24H2. However, on GTAForums, I’ve been receiving comments about this exact issue since November last year. Some of them said SilentPatch causes this issue, others however stated the same happens on a completely unmodded game:

Apparently the skimmer cant spawn when playing on Windows 11 24h2 update, hope this bug gets fixed.

EDIT: So I think I confirmed it, I set up a VM with Windows 11 23h2 and the damn plane spawns fine, and updating that same VM to 24h2 breaks the skimmer, why would a small feature update in 2024 break a random plane in a 2005 game is anyone’s guess.

After the latest Silent patch update there is no Skimmer in the game and when I try to spawn it with RZL-Trainer or Cheat Menu by Grinch, the game freezes and I have to close it via Task Manager.

[…] I was forced to update to 24H2, and now after the update, I have the same problem with the Skimmer in GTA SA as others. This means that mods or anything else are not causing the issue, the problem appeared after the latest Windows update.

My home PC is still on Windows 10 22H2, while my work machine is on Windows 11 23H2, and, to no surprise, neither machine reproduced the issue – Skimmer spawned on the water just fine, creating one via script and putting CJ in a driver’s seat worked too.

That said, I also asked a few people who upgraded to 24H2 to test this on their machines and they all hit this bug. Attempts to debug “remotely” by giving instructions over the chat didn’t go anywhere, so I set up a 24H2 virtual machine on my own. I copied the game over to the machine, set it up for remote debugging from the host OS, headed to the usual place the Skimmer spawns, and sure enough, it wasn’t there. All other planes and boats still spawned fine, only this one vehicle did not:

I then used the script to spawn a Skimmer and put CJ inside it, just to be launched 1.0287648030984853e+0031 = 10.3 nonillion meters, or 10.3 octillion kilometers, or 1.087 quadrillion light-years up in the sky 😆

With SilentPatch installed, the game freezes shortly after launching the player up, as the game code gets stuck in a loop. Without SilentPatch, the game doesn’t freeze, but instead, it succumbs to a famous “burn-in effect” known to occur when the camera gets launched into infinity or close to it. Funny enough, you can still kind of make out the shape of the plane even though the animations give up completely to the inaccuracies of the floating point values:

Investigating the bug

What is broken?

But, enough messing around; now I knew it was a real bug and I needed to figure out the root cause. At this point it wasn’t possible to say whether the game was at fault, or if I was really dealing with an API bug introduced in 24H2, as looking at how many games have issues with this OS version, it could go either way.

I didn’t have much to go with, but the fact the game froze with SilentPatch installed provided me with a good starting point. Upon entering the seaplane, the game froze in a very small loop in CPlane::PreRender, attempting to normalize the rotor blade angle to the 0-360 degree range:

this->m_fBladeAngle = CTimer::ms_fTimeStep * this->m_fBladeSpeed + this->m_fBladeAngle;
while (this->m_fBladeAngle > 6.2831855f)
{
  this->m_fBladeAngle = this->m_fBladeAngle - 6.2831855f;
}

In the debugged session, this->m_fBladeSpeed was 3.73340132e+29. This value is obviously enormous, big enough to make decrementing the value by 6.2831855 entirely ineffective due to the difference in floating point exponents of these two values.¹ But why is the blade speed so ridiculously high? The blade speed is derived from the following formula:

this->m_fBladeSpeed = (v34 - this->m_fBladeSpeed) * CTimer::ms_fTimeStep / 100.0f + this->m_fBladeSpeed;

where v34 is proportional to the plane’s altitude. This matches the initial findings – as mentioned earlier, the “burn-in effect” traditionally happens when the camera is very far away from the map center, or at a great height.

What caused the plane to shoot so high up? There are two possibilities:

1. The plane spawns high up in the sky already.
2. The plane spawns at ground level and then shoots up in the next frame.

As for this test, I was spawning the Skimmer myself with a test script, so I could start from the function used in the game’s SCM (script) interpreter, named CCarCtrl::CreateCarForScript. This function spawns a vehicle with a specified ID at the provided coordinates, and those come from my test script, so I know they are correct. However, this function transforms the supplied Z coordinate slightly:

if (pos.z <= -100.0f)
{
  pos.z = CWorld::FindGroundZForCoord(pos.x, pos.y);
}
pos.z += newVehicle->GetDistanceFromCentreOfMassToBaseOfModel();

CEntity::GetDistanceFromCentreOfMassToBaseOfModel contains multiple code paths, but the one used in this case simply gets the negated minimum Z value of the model’s bounding box:

return -CModelInfo::ms_modelInfoPtrs[this->m_wModelIndex]->pColModel->bbox.sup.z;

At this point, I expected this value to be incorrect, so I peeked into Skimmer’s bounding box values just to find out that the minimum Z value is indeed corrupted:

- *(RwBBox**)0x00B2AC48	RwBBox *
  - sup	RwV3d
      x	-5.39924574	float
      y	-6.77431822	float
      z	-4.30747210e+33	float
  - inf	RwV3d
      x	5.42313004	float
      y	4.02343750	float
      z	1.87021971	float

If all the components of the bounding box were corrupted, I would have suspected some memory corruption, like another code writing past boundaries and overwriting these values, but it’s specifically sup.z that is corrupted that is neither the first nor the last field in the bounding box. Once again, two possibilities came to my mind:

1. The collision file is read incorrectly and some fields remain uninitialized, or read unrelated data instead of the bounding box? Highly unlikely, but not impossible given that this issue could potentially have been an OS bug.
2. The bounding box is read correctly, but then it’s updated with an outrageously incorrect value.

A data breakpoint set up at pColModel reveals that at the time of the initial setup, the bounding box is correct, and the value of the Z coordinate is completely reasonable:

- *(RwBBox**)0x00B2AC48	RwBBox *
  - sup	RwV3d
    x	-5.39924574	float
    y	-6.77431822	float
    z	-2.21952772	float
  - inf	RwV3d
    x	5.42313004	float
    y	4.02343750	float
    z	1.87021971	float

Turns out, the first time a vehicle with a specific model is spawned, the game sets up the suspension in a function SetupSuspensionLines, and updates the Z coordinate of the bounding box to reflect the car’s natural suspension height:

if (pSuspensionLines[0].p1.z < colModel->bbox.sup.z)
{
  colModel->bbox.sup.z = pSuspensionLines[0].p1.z;
}

This is where things went wrong first. The suspension lines are computed using a combination of values from handling.cfg and the wheel scale parameter coming from vehicles.ide:

for (int i = 0; i < 4; i++)
{
  CVector posn;
  modelInfo->GetWheelPosn(i, posn);

  posn.z += pHandling->fSuspensionUpperLimit;
  colModel->lines[i].p0 = posn;

  float wheelScale = i != 0 && i != 2 ? modelInfo->m_frontWheelScale : modelInfo->m_rearWheelScale;

  posn.z += pHandling->fSuspensionLowerLimit - pHandling->fSuspensionUpperLimit;
  posn.z -= wheelScale / 2.0f;
  colModel->lines[i].p1 = posn;
}

Since I knew colModel->lines[0].p1 is corrupted, this meant either pHandling->fSuspensionLowerLimit, pHandling->fSuspensionUpperLimit, or wheelScale were bogus. Skimmer’s handling.cfg values didn’t seem any different to any other plane in the game, but then I spotted something interesting in vehicles.ide. Skimmer’s line looks like this:

460, 	skimmer,	skimmer, 	plane,		SEAPLANE,	SKIMMER,	null,	ignore,		5,	0,	0

Compare this line to any other plane in the game, in this example Rustler:

476, 	rustler, 	rustler, 	plane, 		RUSTLER, 	RUSTLER,	rustler, ignore,		10,	0,	0,		-1, 0.6, 0.3,		-1

The line is shorter and it’s missing the last four parameters, moreover, two of the missing parameters are the front and rear wheel scale! This is normal for boats, but Skimmer is the only plane to omit these parameters.

Does re-adding those parameters fix the seaplane? Unsurprisingly, it does!

But why and how?

I have a likely explanation for why Rockstar made this specific mistake in the data to begin with – in Vice City, Skimmer was defined as a boat, and therefore did not have those values defined by design! When in San Andreas they changed Skimmer’s vehicle type to a plane, someone forgot to add those now-required extra parameters. Since this game seldom verifies the completeness of its data, this mistake simply slipped under the radar.

Problem solved? Not quite yet, as for SilentPatch, I need to fix it from the code. A peek into the pseudocode of CFileLoader::LoadVehicleObject reveals the true nature of this bug: the game assumes all parameters are always present in the definition line and it doesn’t default any but two parameters, nor it checks the return value of sscanf, and so in the case of all boats and Skimmer, those parameters remained uninitialized:

void CFileLoader::LoadVehicleObject(const char* line)
{
  int objID = -1;
  char modelName[24];
  char texName[24];
  char type[8];
  char handlingID[16];
  char gameName[32];
  char anims[16];
  char vehClass[16];
  int frq;
  int flags;
  int comprules;
  int wheelModelID; // Uninitialized!
  float frontWheelScale, rearWheelScale; // Uninitialized!
  int wheelUpgradeClass = -1; // Funny enough, this one IS initialized

  int TxdSlot = CTxdStore::FindTxdSlot("vehicle");
  if (TxdSlot == -1)
  {
    TxdSlot = CTxdStore::AddTxdSlot("vehicle");
  }
  sscanf(line, "%d %s %s %s %s %s %s %s %d %d %x %d %f %f %d", &objID, modelName, texName, type, handlingID,
        gameName, anims, vehClass, &frq, &flags, &comprules, &wheelModelID, &frontWheelScale, &rearWheelScale,
        &wheelUpgradeClass);

  // More processing here...
}

Given the symptoms, those uninitialized values must have evaluated to small, valid floating point values all the way until now, whereas with Windows 11 24H2 they got out of hand and tripped the bounding box calculations.

In SilentPatch, the fix is easy – I wrap this call to sscanf and provide reasonable defaults for the final four parameters:

static int (*orgSscanf)(const char* s, const char* format, ...);
static int sscanf_Defaults(const char* s, const char* format, int* objID, char* modelName, char* texName, char* type,
      char* handlingID, char* gameName, char* anims, char* vehClass, int* frequency, int* flags, int* comprules,
      int* wheelModelID, float* frontWheelSize, float* rearWheelSize, int* wheelUpgradeClass)
{
  *wheelModelID = -1;
  // Why 0.7 and not 1.0, I'll explain later
  *frontWheelSize = 0.7f;
  *rearWheelSize = 0.7f;
  *wheelUpgradeClass = -1;

  return orgSscanf(s, format, objID, modelName, texName, type, handlingID, gameName, anims, vehClass,
                  frequency, flags, comprules, wheelModelID, frontWheelSize, rearWheelSize, wheelUpgradeClass);
}

Fixed! Another compatibility win for the patch.

If this was a regular bug, I would’ve ended the post right here. However, in the case of this rabbit hole, the discovery of this fix only raised more questions – why did this break only now? What made the game work fine despite of this issue for over twenty years, before a new update to Windows 11 suddenly challenged this status quo?

Finally, is this somehow caused by a problem in Windows 11 24H2, or is this just an unfortunate coincidence, stars aligning just right?

Here be dragons – the true root cause

Diving deeper

At this point, the working theory was that the uninitialized local variables in CFileLoader::LoadVehicleObject happened to have reasonable values until something changed in Windows 11 24H2, and those values became “unreasonable”. What I knew could not be the cause was the CRT (and thus, the sscanf call) – San Andreas uses a statically compiled CRT, and therefore any OS-level hotfixes wouldn’t apply to it. However, considering the plethora of security enhancements in Windows 11, I couldn’t rule out that one of those enhancements, for example, Kernel-mode Hardware-enforced Stack Protection, ends up scrambling the stack in a way the game’s bugged function doesn’t like.

I set up an experiment where I broke into a debugger before a sscanf call when parsing Skimmer’s line (vehicle ID 460) specifically, and the observed variable values supported that claim. On my Windows 10 machine, they happened to be both 0.7:

frontWheelSize  0x01779f14 {0.699999988}
rearWheelSize   0x01779f10 {0.699999988}

while on the Win11 24H2 VM, they are huge, similar in order of magnitude to the wrong values observed in the bounding box earlier. The stack pointer has also shifted by 4 bytes for some reason, but that is unlikely to be related – and it’s likely caused by some changes to the thread startup boilerplate inside kernel32.dll:

frontWheelSize  0x01779f18 {7.84421263e+33}
rearWheelSize   0x01779f14 {4.54809690e-38}

This got me curious - 0.7 is a bit “too good” of a value to be a result of interpreting random garbage from the stack as a floating point; what’s more likely is that it’s an actual floating point value that was sitting on the stack in exactly the right spot. I then inspected vehicles.ide for TopFun – the vehicle defined directly before Skimmer. Sure enough, its wheel scale is 0.7!

459,	topfun,		topfun,		car,		TOPFUN,		TOPFUN,		van,	ignore,		1,	0,	0,		-1, 0.7, 0.7,		-1

vehicles.ide is parsed in order, in a function working similarly to this (pseudocode):

void CFileLoader::LoadObjectTypes(const char* filename)
{
  // Open the file...

  while ((line = fgets(file)) != NULL)
  {
    // Parse the section indicators...
    switch (section)
    {
      // Different sections...
    case SECTION_CARS:
      LoadVehicleObject(line);
      break;
    }
  }
}

Seems like the code somehow persisted the stale wheel scale values, so Skimmer ends up getting the same wheel scales as Topfun. I set up another experiment to verify this claim:

1. Set up a breakpoint before sscanf again, but this time before Topfun’s line (vehicle ID 459) gets parsed.
2. Set up write breakpoints on frontWheelScale and rearWheelScale.
3. Resume execution until the game gets to parsing the next vehicle definition.

Windows 10 verified my claim – nothing wrote to these two stack values between the calls to CFileLoader::LoadVehicleObject, so the function’s effective behavior was to preserve (albeit, unintentionally) the wheel scale values between the consecutive calls!

Repeating the same exercise on Windows 11 24H2 triggered the write breakpoint! However, it wasn’t anywhere close to any security feature: the stack values were overwritten by… LeaveCriticalSection inside fgets:

>	ntdll.dll!_RtlpAbFindLockEntry@4()	Unknown
 	ntdll.dll!_RtlAbPostRelease@8()	Unknown
 	ntdll.dll!_RtlLeaveCriticalSection@4()	Unknown
 	gta_sa.exe!fgets()	Unknown

Seems like a change in Windows 11 24H2 modified the way Critical Section Objects work internally, and the new code unlocking the critical section uses more stack space than the old one. I ran one more experiment, comparing the changes to the stack space that happened after sscanf inside LoadVehicleObject, until the next invocation of this function. Changed values are highlighted in red:

This is the exact proof I needed – notice that in the Windows 10 run, some of the local variables are even still visible to the human eye (like the normal vehicle class), while in Windows 11, they are completely gone. It’s also worth pointing out that even in Windows 10, the very next local variable after the wheel scales has been overwritten by LeaveCriticalSection, which means the game was 4 bytes away from hitting this exact bug years earlier! The luck at display here is insane.

Whose Stack Is It Anyway?

To illustrate why the game got away with this bug for so long, I need to show how the stack changes across calls. Let’s say the stack looks like this after the call to LoadVehicleObject. Emphasis on the local variables we’re interested in:

The call to fgets, and consequently LeaveCriticalSection, that follows the call to LoadVehicleObject, reuses the stack space previously occupied by that function, as the lifetime of the function stack is limited to the duration of the function itself and once the function is done, this space is up for grabs again. On Windows 10, the stack looked like this once fgets and LeaveCriticalSection returned:

Highlighted parts overwrite what used to be the stack space of LoadVehicleObject, but notice how it doesn’t reach the area of the stack where the wheel scales resided. In Windows 11 24H2, LeaveCriticalSection uses more stack space, so the stack space instead looks more like this:

Parts of the stack highlighted in red are now also scrambled when in the past they were left intact; those parts include the wheel scales read by the previous call to LoadVehicleObject! This in turn exposes the bug caused by those variables being uninitialized, and since sscanf can’t read those values from Skimmer’s vehicles.ide definition, they are kept as-is in garbage form, and propagate further to the vehicle’s data.

What are the odds this only broke now? Darn Windows 11!

I want to make it clear: all these findings prove that the bug is NOT an issue with Windows 11 24H2, as things like the way the stack is used by internal WinAPI functions are not contractual and they may change at any time, with no prior notice. The real issue here is the game relying on undefined behavior (uninitialized local variables), and to be honest, I’m shocked that the game didn’t hit this bug on so many OS versions, although as I pointed out earlier, it was extremely close. San Andreas still supported Windows 98, which means it got away with this bug in at least a dozen different Windows versions and many more releases of Wine!

…or, did it? I found it hard to believe that the game would never hit this issue on any of the many, many platforms it released on, so I looked into the binary files of some other releases. While this bug was not fixed in the official 1.01 PC patch, it was fixed in the original Xbox release, where a “reasonable default” of 1.0 was added to the code, much like in my fix. This fix was then “inherited” by many future versions of San Andreas, including:

• Steam 3.0, newsteam, and RGL, as they were all based on the Xbox branch of the code.
• Any releases from War Drum Studios, including Android, X360, and PS3.
• The Definitive Edition.

However, unlike Rockstar, I decided to use the wheel scale of 0.7 instead of 1.0 as a default, for multiple reasons:

1. This is the effective wheel scale Skimmer had on PC (and possibly PS2) until now since that’s the wheel scale of Topfun.
2. Two other non-boat vehicles that float on water, Sea Sparrow and Vortex, both have a wheel scale of 0.7.
3. Many cars in the game have a wheel scale of 0.7.

I want this fixed in my game!

The code fix will be included in the next SilentPatch hotfix, but for now, you may easily fix it yourself by editing vehicles.ide:

1. In your San Andreas directory, open data\vehicles.ide with Notepad.
2. Scroll down to Skimmer’s line beginning with 460, skimmer.
3. Replace the original line with:

   460, 	skimmer,	skimmer, 	plane,		SEAPLANE,	SKIMMER,	null,	ignore,		5,	0,	0,		-1, 0.7, 0.7,		-1
   

4. Save the file.

Final word

This was the most interesting bug I’ve encountered for a while. I initially had a hard time believing that a bug like this would directly tie to a specific OS release, but I was proven completely wrong. At the end of the day, it was a simple bug in San Andreas and this function should have never worked right, and yet, at least on PC it hid itself for two decades.

This is an interesting lesson in compatibility: even changes to the stack layout of the internal implementations can have compatibility implications if an application is bugged and unintentionally relies on a specific behavior. This is also not the first time I encountered issues like this: regular visitors might remember Bully: Scholarship Edition which famously broke on Windows 10, for very similar reasons. Just like in this case, Bully should have never worked properly to begin with, but instead, it got away with making incorrect assumptions for years, before changes in Windows 10 finally made it run out of luck.

Yet again, we are reminded to:

• Validate your input data – San Andreas was notoriously bad at this, and ultimately this was the main reason why an incomplete config line remained unnoticed.
• Not ignore the compilation warnings – this code most likely threw a warning in the original code that was either ignored or disabled!

In the end, the GTA players are lucky: in many other games, issues like this would’ve remained unfixed and they’d become a folk legend. Thankfully, GTAs are moddable and well understood, so we can act upon problems like this and ensure the game stays functional for many more years to come.

The mysterious Magazine 22

Theory – the current knowledge

The career mode in NFS Underground has a built-in achievements system in form of the Magazine covers. There are 27 magazines in the game, 4 tied to the Online reputation system, and the remaining 23 awarded for various feats in the career. The last four offline magazines are awarded for beating the best track times for Circuit, Sprint, Drag and Drift events on Hard difficulty. Three of those are reasonably easy to achieve – I am currently replaying Underground for the first time since 2003, and I beat the best times for Circuit, Sprint, and Drag without even trying; I just got them after certain Career races.

The Drift Track record magazine is a whole other story. Thanks to the official strategy guide, we knew this magazine tied to the Drift Track record so there was no mistake here. However, even though the unlock conditions were known, people were not getting the magazine regardless.

Turns out that the requirements for this magazine are much more difficult than originally assumed – to get the magazine in a Career event, the high score has to be obtained in a single lap. This has been documented online in old guides, people have been talking about the “one lap requirement” at least since 2005, and it’s also been the topic of investigative work on YouTube:

Recently, this issue saw a resurgence of attention because of the NFS Underground RetroAchievements set that tied one of the achievements to this magazine. Some of the comments are dire, showing just how much more difficult this magazine is compared to any other unlock in the game:

Damn finally got it, took me almost two days xD

This is the hardest thing I’ve ever done, it took probably 30 hours of attempts on Drift Track 8 to get for me, and I was already “decent” at drifting.

This was probably the worst experience I’ve had in a need for speed game and sooo unnecessary to have as an unlockable in-game. I’m not blaming the RA dev, but the NFS:U devs themselves.

Reality – sorry, you are all (partially) wrong

For my playthrough, I didn’t want to go through all this pain just because of what almost certainly is a bug in the game, so I dived into the code. I found out that the game unlocks the magazine if the following inequality passes:

This check is not wrong per se. The magazines can also be obtained in Quick Race, where events up to 10 laps can be created. Comparing the scores directly would make the requirements easy to hit with high lap counts, as all the preset scores in the game were set for 4-lap events. Therefore, this formula makes it clear that the idea is to compare the average lap score, so the achievement is still challenging regardless of how many laps there are.

While the function is correct, the way it is used is not, as instead of the total player score, the best lap score is passed to the function as \(player\_score\)! This aligns with the existing community findings, as with \(laps = 4\), the best lap score effectively must be higher than the preset score (as both are divided by 4). This more or less means that to get this magazine in the Career, the player must be 4 times better than (most likely) originally intended.

There is one detail everyone missed, though. Contrary to popular belief, you do not need to necessarily run a 4-lap event while working towards this achievement! Everyone incorrectly assumed this since all Drift events in the Career are 4 laps long, but this is simply not true. Therefore, there is a way to outsmart this issue and nullify the effect of this coding mistake: if the player were to run a 1-lap event, the best lap score and the total score would be identical, and the value is not divided by laps, effectively reducing the check to:

See it now? It is relatively easy to get this magazine after all, despite this bug:

1. Head to Quick Race and set up a 1-lap Drift event.
2. Get at least 25% of the high score points within that single lap.
3. Go to the Underground mode and win any event to unlock Magazine 22.

Fix it! Fix it! Fix it!

Before I move on to fix this issue myself, I wanted to find out if it was fixed officially in any of the many game versions released.

• On PC, this bug is present even in the fully patched game.
• On PS2, there is a single version where this bug was fixed! A Japanese re-release of the game, Underground J (or J-Tune) changed the high score formula not to divide the best score by laps. This means that this version of the game awards the magazine for getting at least 25% of the high score points in the best lap, regardless of how many laps the event has.

Looking at the code, I am certain the original intention was to compare the average lap score:

• The current calculation of dividing the best lap score by laps makes no sense at all, and I cannot think of any plausible reasons for it.
• Rewarding the player only for the best lap makes more sense, but if this was the intention, I don’t think the function unlocking the magazine would then be taking the \(laps\) parameter. It only makes sense to care about this if you intend to calculate an average score across the entire event.

For SilentPatch, it’s an easy fix, with one caveat – this time, I needed this fixed not only in the PC version but also in the PS2 version, due to the RetroAchievements set. Who says it couldn’t be fixed for both platforms, though?

For this SilentPatch, I targeted multiple versions of the game:

• For PC, you get an ASI plugin as usual.
• For PS2, you get a PNACH patch for use with PCSX2.

With this bug fixed, I could finally resume my playthrough and at last, get the magazine without much trouble:

However, that’s not the only issue fixed in this SilentPatch.

Other fixes in SilentPatch, going cross-platform

• High scores for Drift events are shown in the menu incorrectly. Before the player sets a score for the first time, the game shows the total target score for the event (the one you have to beat for the Magazine 22), but after that, it shows a number not related to the player’s score at all. In the video I linked above, DanielCarter1615 figured out that the game saves… style points. With SilentPatch, the total event score is saved instead:

  

• On PC, under very specific circumstances the game could crash while saving. The game checks the time while saving and formats it according to the user’s system date format, but it only allocates space for 11 characters. While this is fine with common date formats (for example, on my PC it’s dd.MM.yyyy), some European locales may have longer formats (for example yyyy. MM. dd.). SilentPatch sets a fixed date format without punctuation and with abbreviated month names (like 12 Mar 2025), so it looks pretty and unambiguous, while also staying within the limit.

  

• The original PS2 releases had a bug where long opponent names appeared corrupted in the UI. It showed up only in a race against Samantha:

  

  This bug was later fixed on PC (possibly in a patch), and the PS2 Korean and J-Tune releases, so only the EU/US/JP PS2 SilentPatch includes it.

Downloads

SilentPatch for the PC and PS2 versions of Need for Speed: Underground can be downloaded from Mods & Patches. Click here to head to the respective pages:

Download SilentPatch for the PC version Download SilentPatch for the PS2 version

TL;DR: This article details the various fixes introduced in this update, making it a relatively long read. If you want to jump straight to SilentPatch or check the source code, go to the Download and source code section for the links.

November 2, 2024 update: Hotfix #1 has been released for GTA III, Vice City, and San Andreas! This hotfix addresses several known issues introduced by the latest update, and addresses compatibility issues with multiple modifications. Updating is strongly recommended.

• Introduction
• New fixes
  • Shared fixes
  • Grand Theft Auto III
  • Grand Theft Auto: Vice City
  • Grand Theft Auto: San Andreas
• Internal changes
• Download and source code
• Credits and acknowledgments
• Future of SilentPatch?

Introduction

Tomorrow, on October 26th, 2024, GTA San Andreas turns 20 years old. I haven’t had the chance to play it upon its release in 2004 – I was a kid who, back then, played exclusively on PC and would play Vice City whenever my parents allowed me. My first experience with San Andreas was in mid-2005 when the game was released on PC; little did I know back then how influential GTA in general, but most specifically San Andreas, would later be for my life and my professional career – and that nearly two decades later, well into my adult life, I would still be fixing it to make it as enjoyable an experience as I possibly can.

Today, on October 25th, I’m honored to publish the biggest update of SilentPatch for the classic Grand Theft Auto trilogy to date, with the full source code now available on GitHub under the MIT license! While I originally planned for the open source release to go live in January, a combination of an increased update scope and several real-life issues happening in the background resulted in this much of a delay, for which I sincerely apologize.

However, this delay comes with a silver lining – what I initially planned to be a simple upload of the source code cleaned up for a public release turned into the biggest content update I’ve ever released. This release contains not only a wide selection of new fixes; I also went back to many older fixes and upgraded them to be safer, simpler, more compatible with other modifications, and free of side effects. Numerous minor regressions introduced by SilentPatch are now resolved, ensuring the patch goes open source in as perfect a state as possible.

In this blog post, I’ll break down the most significant fixes introduced in this update, a culmination of approximately 10 months of development (although not without breaks), and a lot of testing over nine Release Candidate builds. My explanations may get a bit more technical than usual, but I did my best to keep them digestible. No code names this time! The last time I tried that, my code name of choice aged poorly very quickly 😑.

Before we move on, a small unrelated announcement – regular visitors to the blog may have noticed that it has been updated a bit! Most of the changes are purely cosmetic, but there are also a few things that should be immediately noticeable:

1. PNACH codes in Consoles can now be downloaded directly! There is no need to go through GitHub anymore.
2. Fonts have been slightly updated.
3. Buttons have been redesigned. They are now thicker, consistently placed, and don’t have useless padding around them.
4. Embedded Tweets now respect the Dark Mode setting.
5. My Portfolio has been updated with the latest work projects I’ve been involved in, including the one I’m currently on when I’m not patching games on the side.

New fixes

Shared fixes

Numerous fixes included in this update apply to multiple games from the trilogy. Those are:

• I’m a good citizen, and I always keep my headlights on
• Did that car explode twice!?
• Ooh, shiny!
• Credits roll! …ZZzzzZZZ….
• Mission passed! Now please let me play, I get it
• Minimal HUD
• Other fixes

I’m a good citizen, and I always keep my headlights on

Affects: All trilogy games.

To provide some variety in the game world, traffic vehicles act with a degree of randomness. One of the random decisions they make is when they turn the lights on at night, or when it gets foggy or rainy. For each vehicle in the world, a random “threshold” gets picked, deciding how dark, rainy, or foggy it has to be for the vehicle to turn the headlights on.

However, this tiny feature suffers from a difference in how randomness works on PC vs PS2 – the range of randomness is lower on PC (0-32767) than it is on PS2 (0-65535), but the code calculating the thresholds has not been updated. This keeps the variance in decisions, but unintentionally gets rid of an interesting outcome – on the PS2, during rainy or foggy conditions, some vehicles may decide to never turn their headlights on! On PC, because the range of randomness is smaller, they will all eventually turn on their headlights.

SilentPatch rescales the code calculating the thresholds to match the PS2 behavior, so starting with this update, you may encounter some unlawful drivers who don’t use their lights even when they really should:

Did that car explode twice!?

Affects: All trilogy games.

The entire trilogy had a weird bug where cars would sometimes explode more than once for no discernible reason. Together with Nick007J we dived into this issue and figured out that it’s caused by the following chain of events:

1. The vehicle is set on fire.
2. The driver bails out. Before they finish their bailing animation, the vehicle explodes and changes its status to “wrecked”.
3. The driver finished their bailing animation. This changes the vehicle status to “abandoned”, overwriting the previous state.
4. Changing the vehicle’s status doesn’t replenish its health, so it’s set on fire again, and explodes shortly after.

From these steps, the fix becomes apparent: SilentPatch now doesn’t allow the game to transition the vehicle state from “wrecked” back to “abandoned”, fixing this issue.

Unfortunately, this fix also corrects another well-known issue that for once I did not intend to fix:¹ it is no longer possible to execute a famous trick allowing the player to drive exploded vehicles in GTA III and Vice City:

With this fix, the first vehicle explosion simply kills the player 😥

Ooh, shiny!

Affects: GTA III, GTA Vice City.

In III and Vice City, environment mapping wasn’t applied to vehicle extras. This resulted in all extras appearing matte (with no specularity), which is fine for parts like leather roofs on Stallion and Mesa Grande, but not necessarily on metallic extras, like Stinger’s roof, that now matches the way Yakuza Stinger looks:

However, there is a catch: theoretically, non-reflective parts should just have their specularity set to zero, but this isn’t done with multiple stock models. For this reason, the INI file now includes an exception list ExtraCompSpecularityExceptions where models with non-reflective extras can be specified. By default, this is Stallion (for III and Vice City) and Mesa Grande (for Vice City). Additionally, I also made sure that these exceptions don’t apply to glass materials, which gives Mesa Grande a reflective rear windshield:

For custom models, the fix is simple: just make sure that your extras have specularity and the environment map coefficient set correctly. This value is simply ignored on extras without SilentPatch.

Credits roll! …ZZzzzZZZ….

Affects: All trilogy games.

Congratulations, you completed the final mission and beat the game! Now it’s time to watch the credits. “Ugh, why are they so small and slow?”, you think to yourself. Well played, you just spotted a bug! The credits don’t scale to resolution, so they appear smaller and slower the higher your selected resolution is, to the point where they are nearly unreadable at 4K.

Starting with this SilentPatch update, credits scale to the resolution correctly and thus now look just like on the PS2. Because they now move at a consistent speed regardless of resolution, their run time now also matches the original release. Additionally, in GTA III, credits would run for a bit longer than needed, so for the last camera cut, the game would show it and immediately fade out again, as the credits have already rolled to completion. To fix this, I made the credits scroll a few percent faster, so they end on the previous camera cut instead.

Mission passed! Now please let me play, I get it

Affects: All trilogy games.

This is one of the issues that make the lives of speedrunners harder: in all three trilogy games, the bigger your selected resolution is, the longer the mission title and mission completion/failure texts stay on the screen! At first, this sounds completely crazy and I wouldn’t blame anyone for thinking it’s a lie or placebo – alas, it’s true.

It all only comes together thanks to one of the pre-release clips from GTA III. Pay attention to the “Reward” text:

At some point, this text (called “odd job text” internally), mission titles, and the mission completion/failure text were intended to slide from left to right. Although this feature never made it to the final game, much of the code remained. When the games were ported to PC, a (perhaps automated) attempt was made to scale the sliding animation to arbitrary resolutions. However, this attempt was incomplete – while the scaling margins scale, the sliding speed does not. Texts stay on screen longer, because the game waits for the slide to complete, even though the results of those calculations are not used in the end.

In this update, SilentPatch fixes this logic, so now the “sliding speed” remains consistent regardless of the resolution. Additionally, since I had to modify this code either way, two new INI (and debug menu) options were added to all 3 games – SlidingMissionTitleText and SlidingOddJobText may be used to re-enable this cut feature. Even though the mission passed texts technically can slide too, they were always centered, so sliding does not look right, and therefore it makes no sense to enable it.

Minimal HUD

Affects: GTA Vice City, GTA San Andreas.

The games have an unused, yet mostly finished mode of displaying the HUD – when it’s enabled, only the clock displays continuously. Money, the weapon icon, wanted level stars, and the energy bars only display when their statuses change (e.g. you lose health, or pick up money), and after that, they fade out after several seconds. SilentPatch fixes multiple visual bugs this feature exhibited, and can optionally enable it via the INI file.

Even with my fixes, it’s still hard to call it “production ready” – health and armor don’t show up when replenishing health or losing oxygen (in San Andreas), and, unlike in GTA IV, it’s not possible to show the entire HUD on demand, so you are unable to peek at your health or money whenever you wish.

Minimal HUD in San Andreas isn’t introduced in this update – it existed in SilentPatch since late 2017 and was first made public in Build 29 released in May 2018. However, for some reason, I never documented this option, so it remained “hidden” and the users had to add it to the INI file by themselves. With this build, I finally officially documented it, so it appears in the configuration file, and consequently, also in the debug menu.

However, it is new for Vice City – as only recently I was made aware that this feature existed also there! Therefore, in this update, Minimal HUD can now also be enabled in VC. Be mindful that the same shortcomings as in San Andreas apply.

Other fixes

• (All trilogy): Script randomness has now been made 16-bit, like on the PS2, instead of 15-bit. The results are the most noticeable in GTA III:
  • “Bling-bling Scramble” has three possible checkpoint paths on the PS2, but the script could only pick two on the PC.
  • The ambulance in “Plaster Blaster” can pick three possible destinations on the PS2, but only two on the PC.

  This fix makes those two missions reach feature parity with the original PS2 version.

• (GTA III, GTA VC): Text lines read in CPlane::LoadPath and CTrain::ReadAndInterpretTrackFile are now null-terminated. This technical-sounding issue has an amusing and easily noticeable effect: under very specific conditions that are only possible to happen in modded games, the Z values of predefined train, plane, and yacht paths could be read incorrectly, leading to them resetting back to 0. Funny enough, I unknowingly hit that issue 11 years ago, when working on III Aircraft – and even recorded it in one of the test gameplays! In this video, starting from 0:40, you may observe the plane flying at sea level, exactly because of… some long file names causing this issue:

Grand Theft Auto III

• Boat driving animations
• Platform-specific diving for your life?
• Platform-specific speeding for your life??
• Stealth FBI cars
• “Nasty game” with improvements
• Why is this radar so ugly?
• Are car models broken on PC? No, the code is
• Other fixes

Boat driving animations

Careful observers likely noticed a long time ago that in GTA III, Speeder is the only boat with a driver’s seat. This doesn’t stop Claude from standing inside that seat, though, as only in Vice City Rockstar had introduced a flag indicating that the boat driver should use the sitting animation. Fire_Head also noticed this issue years ago and made a fix for it. In this update of SilentPatch, Fire_Head’s work has been integrated:

Together with this change, Fire_Head also backported a small fix from Vice City: now, a small delay between entering the boat and the game considering Claude to be inside one has been removed; the game was waiting for the entering animation to finish, but boats don’t have one, so that made no sense. This fix has also been integrated into SilentPatch.

Good news for III Aircraft users – for this change, SilentPatch applies an identical fix to Skimmer.

Platform-specific diving for your life?

The PC version of GTA III has an interesting gameplay regression compared to the original PS2 release. Usually, pedestrians can react to incoming cars in three ways – they can:

• Turn towards the car and raise their hands,
• Try to step out of the way,
• Try to dive to the side, out of the car’s way.

On PC, raising hands and stepping away works fine. However, pedestrians dive… towards the car instead!

It’s difficult to know exactly what happened in this instance, but I have my guess based on a particular quirk of this feature: when the “threatening” vehicle is honking, this makes the NPC more alert and they always try to dive out of the way. Coincidentally, in this scenario, the bug doesn’t manifest. I can only theorize based on the code differences between PS2 and PC, but the fact PC is missing some calculations makes me believe that this bug was introduced by a failed code optimization – someone may have misread the code, then thought the dive angle was calculated twice, and introduced a bug, since the two calculations happened under different circumstances.

In this update, SilentPatch restores the missing code from the PS2 release, making the dive behave just like it did originally:

Platform-specific speeding for your life??

In GTA III, drivers may react in several ways to being shot at. When bullets hit their car, they randomly pick one of the three actions:

• Speed up and escape in the car,
• Do nothing,
• Leave the car and flee on foot in panic.

This list may have raised eyebrows – do you feel like you’ve never encountered some of these events? If you did, you’d be correct, as this feature is bugged on all platforms, in more ways than one.

All entities in the game world have a random seed value assigned to them, allowing different pedestrians and cars to behave differently, yet ensuring that each entity remains consistent in its actions. On the PS2, this random seed is an integer value in the range 0-65535, on PC (and likely Xbox too) it’s 0-32767. The issue with the drivers’ behavior lies in the function assigning those behaviors to the random seed:

• 0-34999 – flee in car.
• 35000-69999 – do nothing.
• 70000-99999 – flee on foot.

Do you see the issue now? An incorrect assumption about the range of the random seed led to one (on PS2) or two (on PC/Xbox) cases being unreachable. In SilentPatch, the ranges have been rescaled for the real range of the random seed, so now drivers may either ignore the bullets or flee on foot, for the first time.

Stealth FBI cars

In all 3D-era games, FBI vehicles are pitch black. However, this does not apply to some FBI Kurumas in GTA III. Unlike the later games, in GTA III, the car’s carcols.dat entry specifies a dark grey body color with unpainted bumpers. Cars that spawn in roadblocks and cars imported via the Import/Export cranes adhere to this setting, while the chasing units are forcibly set to black via the game’s code. This leads to a discrepancy between the cars depending on where they come from and also causes the pitch-black Kurumas to permanently change their color when resprayed.

I am not sure why the game forces FBI cars to black via code. Perhaps at some point in development FBI used regular civilian cars painted black, and this was never reverted when they were given their dedicated vehicle? Regardless, SilentPatch now removes this code, so all FBI cars use the colors specified in carcols.dat.

“Nasty game” with improvements

Exclusively in the PS2 and PC versions of GTA III, the player could shoot limbs off the other characters. However, the detached limbs never looked quite right, but not because the models weren’t detailed enough – a simple code mistake caused both the normal model and the LOD model to show at once, ignoring the game’s LOD system. This has now been fixed.

Why is this radar so ugly?

Ever since the very first release, SilentPatch fixed numerous UI elements not scaling to resolution correctly. This included the text shadows and a few specialized message types. Turns out, more things needed fixing, although they weren’t immediately obvious.

On PS2, the radar disc texture extends 4 pixels around the rendered map. On PC, that map, as well as the radar disc, scale to resolutions, but that 4px margin does not. Back in the day, this was likely barely noticeable on resolutions like 1024x768, but with modern resolutions like 4K, the issue becomes so pronounced that the radar disc no longer even covers the map underneath:

You’ve likely noticed that the positioning has changed too – that’s because the horizontal position also didn’t scale to resolution (even though the vertical position does), so the radar was always a constant 40 pixels away from the screen edge. In this update, both issues are fixed, so the entire radar scales correctly.

Are car models broken on PC? No, the code is

In the GTA modding circles it’s relatively well known that a few pieces of code from an early version of Vice City made their way to the PC version of GTA III; helicopter physics, bike hierarchy (but no other bike leftovers!), etc. For example, III Aircraft was only possible thanks to those leftovers. This theory has also been confirmed by Obbe Vermeij himself:

For a number of months, the pc version of gta3 and Vice City shared a codebase.
So it's probably stuff that was done for Vice that 'leaked back' into gta3-pc.

— Obbe Vermeij (@ObbeVermeij) October 22, 2024

Just a few days before this post goes live, we learned about yet another PS2 vs PC difference that is a consequence of this code mixup: cars in GTA III have separate taillights and brakelights dummies,² while Vice City only kept the former! This had an adverse effect on the way these lights work. That’s how they were intended to function:

• During the day, when the lights are off, brake and reverse lights use the brakelights dummy.
• At night, when the lights are on, all lights use the taillight dummy, and the tail light’s corona changes intensity or color accordingly. This also means that the reverse lights “move” to another spot at night.

With the brake lights dummy gone, III on PC fell back to the Vice City behavior: that is, always putting all the lights on a taillight dummy. In this SilentPatch update, I re-introduced the missing code to the PC version, restoring feature parity. It’s quite a neat detail, so I’m glad to see it working again. On many cars, the differences are hard to spot, but on others it’s much more prominent:

Other fixes

• In version 1.0, the Stats menu now has the correct font, like in the 1.1 and Steam versions.

  

• Nick007J contributed a fix to CCarCtrl::PickNextNodeRandomly (backported from Vice City) that allows traffic to turn right from one-way roads. Previously, they could only go straight or turn left.

  

• Bilinear filtering is now applied on the player’s skin, just like in Vice City, or when SkyGfx is installed. This makes Claude’s skin texture look smoother when viewed close up.

  

  

• Temporary pickups (like money) are now properly cleaned up if there are too many of them, fixing a possible object leak. This issue, officially fixed in Vice City, is now also resolved in GTA III.
• Dodo keyboard controls were previously not enabled for all cars when the “Flying Vehicles” cheat was activated. This issue, officially fixed in Vice City, is now also resolved in GTA III.
• Timers now reset on the New Game, preventing the playtime from carrying over from the saves.
• A semi-placebo fix for broken car reflections in the Steam version of GTA III has been replaced with a proper fix, integrating Steam Car Colour Fix from Sergeanur.
• A bug in the way the game saves the Brightness option has been fixed, allowing lower brightness values to save and load properly. Because the game stored a 2-byte long brightness variable as a 1-byte value in the configuration file, the option was only loaded partially. This caused increased brightness values to load correctly, while the decreased values appeared overly bright.

Grand Theft Auto: Vice City

• Pickups and glows
• Backface culling fixes
• Construction Site LOD
• Greetings from Vice City… but not for this long, please!
• Giving a finger in style
• Why is this radar so ugly? Part 2
• Other fixes

Pickups and glows

Vice City had multiple issues with the pickup objects fixed:

• Almost all pickups have predefined text colors for cases where something (like a price or collected revenue) displays over them. However, this wasn’t the case for the asset money pickup, which led to the pickup text having random colors (on the PS2) or flickering colors every frame (on the PC). In this update, a generic red color (also used e.g. by the clothes) has been assigned to this pickup.

  

• Every weapon type has a unique color of the glow.³ For sniper rifles, the glow is pink, while for heavy weapons, it is purple. However, the minigun’s glow was much brighter than the one of a flamethrower or an RPG, closer to the glow of a sniper rifle. While this initially looked like a wrong color assignment, turns out it’s because the pickup of a minigun consists of two models – the static base and a rotating barrel. For some reason, this barrel was given a white glow, so it had an additional white glowing spot and also lightened the overall weapon pickup. This has now been corrected.

  

  

Backface culling fixes

While it is a useful GPU performance improvement, backface culling wasn’t always a thing in the 3D-era GTAs:⁴

• No original version of GTA III has it enabled.
• GTA Vice City enables it on PC, but not the PS2.
• GTA San Andreas enables it on all platforms.

While Rockstar fixed many models in the PC version of Vice City to render correctly with backface culling, many more were missed. In this update, I implemented several exceptions to the backface culling, similar to what was done in the mobile versions of GTA III and Vice City:

• Backface culling was always disabled on vehicles, but that did not extend to the detached car parts. This was fixed in SilentPatch for San Andreas for the longest time, but now it’s also present in Vice City.

  

• Multiple ped models (including Tommy’s outfits) break with backface culling. To fix this, it has been disabled on all peds, much like in San Andreas.

  

  

• For map models, an exception list similar to DrawBackfaces.txt from the mobile releases has been implemented. This list includes all the models from the mobile versions, along with many more that have been meticulously identified by Tomasak.

  

  

Construction Site LOD

In the infamous “Demolition Man” mission, the player is tasked with destroying a construction site with the use of a remote-controlled helicopter. Due to a bug in the mission’s script, when the regular construction site model gets swapped for the damaged model, the building’s LOD model becomes “orphaned” (as in, it loses a link to its corresponding high-quality model) and starts showing at all times, resulting in the low-quality building rendering “inside” the damaged model. Starting from this update, the LOD gets re-linked to the newly swapped damaged model and thus retains the correct behavior.

Fun fact – the behavior where LOD models without a corresponding high-quality model render at any distance is new to Vice City, and Rockstar most likely introduced it to fix cranes disappearing up close. If that sounds familiar, it’s because I introduced a similar fix to GTA III in the Corona Update!

Greetings from Vice City… but not for this long, please!

The outro splash in the PC version of Vice City kind of seems to take forever, doesn’t it?

For this release, I was asked if SilentPatch could shorten the duration of this splash, and upon looking into the code, I discovered that there is more to this request than just a subjective wish. The game determines the duration of this splash as follows:

• When the fade-in is complete, the game starts counting time in milliseconds.
• Every 10 milliseconds, a counter increments.
• Once this counter reaches 150, the game exits.

There is a problem, though – when the game is capped to 30FPS, this function executes every 33.(3) milliseconds, so the counter increments only 30 times per second. This means that instead of taking 10ms * 150 = 1.5 seconds, it actually takes 33.(3)ms * 150 = ~5 seconds! With the Frame Limiter disabled, or in the main menu (where the game locks to VSync only), this time would be proportionally shorter.

The fix in SilentPatch is to re-time the fade – if we increase the counter every 33ms, and count up to 45, the splash takes around 1.5 seconds regardless of the frame rate. I implemented this fix but then realized that while the original 5s was way too long, 1.5s is also kind of short. Therefore, SilentPatch now settles on a time of 2.5 seconds (33ms * 75).

Giving a finger in style

In both GTA III and Vice City, the protagonists shake their fists⁵ at incoming traffic vehicles. Usually, this is supposed to happen when the player is unarmed or holds a melee weapon, pistol, or an SMG. However, in Vice City, this feature had several distinct bugs, now all fixed in SilentPatch:

• Holding Brass Knuckles made Tommy never shake his fist.
• Holding the Chainsaw didn’t prevent Tommy from shaking his fist, even though it’s a two-handed weapon.
• In one instance, where the game code was not updated to account for weapons introduced in Vice City, Tommy didn’t shake his fist at stopped traffic when holding any melee weapons, pistols, or SMGs introduced in this game.

Why is this radar so ugly? Part 2

Radar again? Yep, but this time, it’s even worse.

The issue I mentioned earlier in the context of GTA III is still present, and on top of that, new issues have appeared: in Vice City, the radar disc has been rescaled and re-styled – the outer disc now extends 6 pixels around the map, and a fancy shadow effect has been added 2 pixels below the disc. This worked fine on PS2, but is broken in multiple ways on other platforms:

• The shadow doesn’t scale to resolution either, so at high resolutions, it’s hardly noticeable.
• Making the radar disc scale reveals another issue: its size of 6 pixels (or 6 “units”, when scaling) is too much, and there is now a gap between the bottom half of the radar disc and the map! I initially thought I incorrectly scaled this element, but… the same gap shows in the Xbox version! Pay close attention to the radar in a timestamped segment of this gameplay video, and you’ll notice a 1-2 pixel wide gap, through which the scene can be seen:

SilentPatch rolls out multiple fixes to make the radar look consistent and tidy:

• Just like in GTA III, the horizontal placement and the radar disc margin, as well as the shadow, scale to resolution.
• The radar disc has been shrunk by 2 pixels​/​“units”, so the gap in the bottom never shows up.
• The outline of the destination blip now scales to resolution – while Vice City fixed the bug where the blip itself didn’t scale, the outline remained of a constant thickness. Interestingly, when fixing this bug in the first release of SilentPatch for GTA III, I also addressed the scaling of the outline, not realizing that it was still partially broken in Vice City.

Additionally, the onscreen counter bar’s shadow and the loading bar outline now also scale to resolution:

Other fixes

• Fixed an issue where muzzle flashes from assault rifles faced the wrong direction. This fix was contributed by Wesser.

  

  

• Fixed an issue where looking at a shopkeeper while using Classic controls counted as aiming at them. This happened because the IS_PLAYER_TARGETTING_CHAR script command, updated for Standard controls on PC, didn’t previously differentiate between those control styles. This fix was also contributed by Wesser.
• Starting a New Game would previously reset the mouse sensitivity, the same as when restoring settings to defaults. This has now been resolved.
• In this release, I revisited the Rosenberg Audio fix, famously the very first fix made for SilentPatch. The results are surprising – 12 years later, it turns out this fix was placebo all along! Contrary to popular belief, this feature was never broken on PC after all, and all of Rosenberg’s lines can be heard even without mods. The perceived difference in frequency of those lines may boil down to a different randomness function across platforms. Therefore, just for a good measure, together with the removal of a placebo fix, I also made this feature use a PS2 randomness function, to ensure the odds of this audio playing match the console.
• Ped Speech Patch from Sergeanur has now been integrated into SilentPatch. This makes pedestrians and Tommy much more talkative than by default. My variation of this fix also includes a fix for improper randomness of the chat initiation action – the odds of that now match the PS2 version.
• Hitting vehicles and objects with a screwdriver now produces an impact sound. Previously, screwdriver was the only weapon that was completely quiet.
• Tear gas can now deal damage to Tommy and other mission characters, like in the PS2 version.
• Thanks to Tomasak, more interiors have been updated to have their outside areas visible from the inside.
• The rain stream effect on roads, which displays for a short period after the rain stops, now resets on loading a save. This prevents the effect from showing when the weather in the loaded save is sunny.

Grand Theft Auto: San Andreas

While all three games received countless new fixes, this time, San Andreas took center stage. After all, its 20th anniversary is just around the corner:

• Improving vehicles, one animation at a time
• Can’t recruit anyone? That’s what you get for playing without a disc!
• Fire! Fire! Oh, wait…
• Carl Johnson is an innocent man!
• BOOM! Where did that wheel go?
• That’s not a bazooka, Zero
• Where are you going, homie? We got work to do!
• UFO, shooting star, or both?
• Ninja jacking begone!
• Multiple monitors, multiple problems
• I’m dizzy, hazy, and I see funny under the water
• Other fixes

Improving vehicles, one animation at a time

For this release, Wesser has contributed several fixes related to CJ’s animations in vehicles:

• CJ’s clothes are being moved by the wind when driving a bike, but not when driving the Quad. This is now corrected.
• When coasting at low speeds, Quad’s handlebar movements didn’t match CJ’s animations. This is now corrected.
• Inverse to a fix featured previously in GTA III, changing radio stations while driving a boat where CJ stands upright would make him play the sitting animation. This is now corrected, although the game lacks a suitable animation for changing radio stations when upright, so now this is done with no animation at all.

  

Can’t recruit anyone? That’s what you get for playing without a disc!

This is a fun bug, and likely the main reason why speedrunning San Andreas on a 1.01 patch is preferable! On the surface, it’s just a simple error – once the player activates a replay, recruiting gang members by aiming them and pressing a button is no longer possible. Although it was never mentioned in the official changelog, no one ever observed this issue in the 1.01 version of the game, only in 1.0, so it was assumed that it was just fixed there.

However, Wesser found out there’s more to that. This is not a game bug – instead, it was a mistake made when HOODLUM initially defeated SecuROM in the 1.0 executable back in 2005! A chunk of code obfuscated by DRM was decrypted incorrectly, resulting in this breakage, which has later been carried over by listener to his famous Compact EXE. Wesser figured out this issue in detail and reimplemented the missing chunk of code that’s now also included in SilentPatch.

If only listener was still around to update the Compact EXE… 😔

Fire! Fire! Oh, wait…

Has this ever happened to you? You’re minding your business somewhere in San Andreas, then out of nowhere, a 🔥 fire 🔥 breaks out! You don’t have a fire extinguisher with you, but there’s a solution: you recall that there are fire extinguishers spawned in all food joints, and there’s The Well Stacked Pizza Co. just around the corner! You mash the sprint button as fast as you can, hoping to save the day, you enter the place and…

The pickup is not there!? 🧯❌😭

Fortunately (or unfortunately?) for you, that’s not randomness, but a bug. While San Andreas is generally OK at resetting the game state on restarting a new game within the same session, and SilentPatch further improves the situation by resetting a few more variables that were missed, map IPL files also exhibited a similar bug. While binary IPLs re-initialized fine due to their streamed nature, text IPLs initialized several in-game spawns only once on game start, and never again – so starting a new game after loading an existing save resulted in those spawns simply not being present. Those are:

• Weapon pickups (five in the stock game, including fire extinguishers in kitchens)
• Car generators (none in the stock game, but supported)
• Unique stunt jumps (none in the stock game, but supported)

In this release, SilentPatch keeps track of those IPL definitions and re-initializes them when starting a New Game. Sadly, the existing saves affected by this issue cannot be automatically fixed, but at least any future playthroughs will have the missing items spawn reliably.

Carl Johnson is an innocent man!

Back in 2005 or 2006, when I was casually messing around in San Andreas as a kid, I often found myself in a familiar situation: I’d get a wanted level, biker cops would come after me, then I’d enter the legendary AEZAKMI cheat code to get rid of the pursuit, and yet… the biker cops would keep shooting at CJ. Annoying, right?

In 2024, I finally dived into this issue, and after some heavy debugging, I realized it happens because of an oddity in how the specific Drive-By task used by the biker cops is coded: unlike all the other pursuit activities, the drive-by task is actually the same as the one used by the gang members, and thus it’s not coded to automatically finish when the player loses pursuit!

In SilentPatch, I updated the code to check if a cop aborting pursuit has a TASK_SIMPLE_GANG_DRIVEBY task active, and if they do, cancel it. It works great and fixes one of the game’s quirks that used to annoy an 11-year-old Silent 😅.

BOOM! Where did that wheel go?

In GTA III and Vice City, exploding vehicles would always lose their front left wheel. In an attempt to improve this feature in San Andreas, the developers made it detach a random wheel on explosion instead. However, Rockstar half-baked this improvement – the wheel may have detached visually just fine, but as far as the physics was concerned, the old behavior of always losing the front left wheel persisted. This results in a new visual glitch, where the wrong wheel sinks:

In this update, I fixed multiple bugs related to this feature:

• The detached wheel now matches “visually” and “physically”.
• The rear right wheel can now also be detached. Previously, the random function would only consider the front wheels and the rear left wheel.

This fix also comes with an unintentional but cool side effect – exploding the vehicle multiple times using cheat codes can make it lose multiple wheels, eventually leaving a wreck with all four wheels detached!

That’s not a bazooka, Zero

“Air Raid”, the first mission given to the player by Zero, is an interesting case of Rockstar trying to fix script errors… and failing. This mission places CJ in a turret mode operating a minigun that is given to him only for the duration of the mission. In the original PS2 version, and PC 1.0, this mission “steals” the player’s heavy weapon entirely, and there is no way to avoid it. In 2.0, Rockstar attempted to fix it by saving information about the existing weapon on this slot, and it was given back to the player afterward. However, the script fails to load the weapon model, so the player… is given back an invisible weapon instead. Don’t try to use it – your game will crash!

Thankfully, this mistake wasn’t severe, and simply saving the game, and then reloading that save, fixes it. Nonetheless, in this update SilentPatch injects a proper fix to this mission, ensuring that the weapon is preserved, and the model is loaded correctly.

Where are you going, homie? We got work to do!

Amidst the chaos of the Los Santos riots in the final parts of San Andreas’ story, the game presents a rather frustrating quirk. At random points, gang members in CJ’s group can abandon him and flee, seemingly for no reason. While this might add some interesting dynamics during free roam, it can be a deal breaker during missions. Therefore, Nick007J dived into the code to thoroughly understand these events.

1. At regular intervals, the police chopper flying above the city targets a random gang member. This can be someone from CJ’s group or any other random person.
2. The targeted person starts fleeing, trying to escape the chopper.

SilentPatch refines this feature slightly to prevent it from being a hindrance – during missions, CJ’s group can no longer be targeted by the chopper.

UFO, shooting star, or both?

One of the mysteries “haunting” San Andreas since the dawn of time is the presence of unusual black dots rapidly moving in the sky. People theorized it may be a strange raindrop, a shooting star, or… UFO. This was something I was aware of for a while, but only after Bob El Aventurero made a detailed video trying the unravel this mystery I looked into this phenomenon in more detail:

The video touches on the technical side of this effect a bit, stating that it is supposed to be rendered as a single-pixel-wide white line, but doesn’t answer the question as to why it comes out black instead. Turns out it renders as such only because… it attempts to draw using the cloud texture. Since the line is just a single pixel wide and it has no UV data, it most likely sampled the top left corner of the cloud texture, ignoring alpha. The fix, as usual, is trivial – draw the star with no texture. At last, the mystery is put to rest:

Ninja jacking begone!

Twitter user Radiant Eclipse asked Obbe Vermeij an interesting question regarding a well-known, yet mysterious bug/feature:

Hi @ObbeVermeij, in GTA SA when you steal a car through the passenger door while holding the run button the driver leaves the car dead. Do you know of this is intentional or is it a bug? I'm asking this because the game never talks about it. I made a short video showing this pic.twitter.com/WnsqlYEnQE

— Radiant Eclipse (@RadiantEclips10) May 25, 2024

I asked Nick007J if he looked into this before, and he did, but without a definite answer – so we decided to look into this again. It turns out that in the event of the player holding the throttle and/or brake buttons while jacking the car from the passenger side, the game does the following checks:

• If the driver is alive, make them leave the car dead.
• If the driver is dead, make them step out of the car as normal.

This sounds… backwards, especially since a different code path in the same function had those checks switched around. We theorized that this was likely just a mistake and the conditions were meant to be swapped, but only once ultragirl468 ran tests themselves, we had definite proof. They managed to jack the car from an already dead driver, and…

This was the proof we needed – simply inverting the check fixes this issue. Now alive drivers stay alive, and dead drivers stay dead. This issue was also fixed in the Definitive Edition (but not the “classic” mobile/PS3/X360 releases), where it behaves the same way as the classic San Andreas with my fix applied.

Multiple monitors, multiple problems

This section contains affiliate links, meaning I get a commission for every purchase made through them.

Recently, I was invited to a promo campaign and received a JSAUX FlipGo, a portable dual-screen monitor. Before I only had a single monitor, so only now I realized how strange the monitor selection dialog in GTA San Andreas is. Since I was now “affected” by it, I fixed several annoyances present in that dialog and enhanced it with some QoL improvements.

• Remade the dialog with modern Common Controls, so it looks native, instead of being limited to Win9x style controls.
• Made the dialog use user-friendly monitor names (on Windows 7 and newer) instead of the DirectX 9 adapter names, which for most people just duplicated the GPU names. In my case, I had three NVIDIA GeForce GTX 1070 entries, and now they are named after the screens.
• The dialog ignored the X control and the Esc button, now it closes on those properly.
• The dialog now gets keyboard focus on creation.
• The taskbar icon now shows reliably, and the title bar displays a small icon.
• The dialog now remembers the selected screen. Previously, it remembered the resolution index but not the screen index (despite storing this information in the .set file), so it instead pointed at some random resolution on the first screen.
• The dialog now defaults back to the first screen if a non-existent screen is selected, for example when starting the game after unplugging one of the screens.
• The dialog is now explicitly DPI unaware, so DPI compatibility settings can’t prevent it from scaling.
• Most importantly – monitor and resolution choices can now be remembered in a separate .set file, and the dialog can be suppressed! A tooltip has been added to the new checkbox, instructing the player to delete device_remembered.set from GTA San Andreas User Files if they want the dialog to show again.

I’m dizzy, hazy, and I see funny under the water

Thought we were done with the resolution scaling issues, after all the problems I already detailed earlier? Haha, no.

San Andreas post effects are not only the most elaborate out of all 3D-era games but also quite different between PS2 and the other platforms. That said, the heat haze effect appears to be identical between PS2 and PC… at least if you don’t keep changing the resolution in-game. If you do, weird things can happen – here’s how the effect looks if you run the game in 4K, and then change the resolution to 640x480:

A simple game restart solves this, so it’s not a critical bug – nonetheless, it has been fixed in this update of SilentPatch, so now the effect rescales properly once settings are changed.

But, there is more! The ripple effect when the camera is underwater, as nice as it is, also looks slightly distinct at different resolutions. It’s not broken per se, as it mostly scales fine, but the frequency of the wave effect is noticeably higher at high resolutions. This has now been fixed, so the effect looks consistent:

Other fixes

• Stats counted in kilograms now display correctly in the Stats menu.
• Past SilentPatch builds already made the game accept several typos in the vehicle hierarchy, fixing e.g. a missing middle wheel in DFT-30. For this release, two more typos are now accepted by the game:
  • transmision in Dumper, making the suspension animated, like in the Monster Truck.
  • tailights in Uranus, relocating the tail light coronas from the interior of the car to the rear lamps.
• A significant memory leak when taking photos with an in-game camera has been fixed.
• Wesser contributed a fix to the gang members taking a photo of CJ. Previously, holding a sniper rifle changed the camera “crosshair” to the sniper rifle crosshair. This has now been resolved.
• Racing checkpoints are now correctly colored even if no enex markers were displayed on-screen before. This obscure bug was practically impossible to witness in a stock game, but could easily be seen with mods, or in MTA races.

  

  

• Fixed a crash that occurred when mashing the replay button near groups of gang members holding items. This involves a rather elaborate list of steps that went wrong in the game logic, but I documented it in detail in the patch source code, so I’ll just quote my technical explanation here:

  CWorld::Process processes all entries in the moving list, calling ProcessControl on them. CPlayerPed::ProcessControl handles the gang recruitment which in turn can result in homies dropping cigarettes or bottles. When this happens, they are destroyed immediately. If those props are in the moving list right after the PlayerPed, this corrupts a pre-cached node->next pointer and references an already freed entity. To fix this, queue the entity for delayed destruction instead of destroying it immediately, and let it destroy itself in CWorld::Process later.

• Wesser contributed a fix to the SCM interpreter, where spawning a biker cop (lapdm1) with a type PEDTYPE_COP spawned a normal cop instead. This issue doesn’t affect the default script but might have affected mods.
• Impound garages can now only impound cars and bikes (and their subtypes), as other vehicle types are either too big or cannot leave the garage without exploding. This puts a stop to helicopters and boats being impounded.

  

• Several more crashes related to replays have been fixed:
  • A crash occurred when starting a cutscene after playing a replay where CJ wore different clothes from what he is currently wearing.
  • A crash occurred when playing back a replay with CJ having a different body type (fat/muscular/normal) than his current one.
• The spawning logic of planes has been slightly improved. While they can still crash after spawning, this should now occur less frequently.
• Hovering with a jetpack is now possible using the keyboard controls by holding the next/previous weapon buttons simultaneously (Q + E by default).

• Heat-seeking missile crosshair and the weapon crosshair shown while aiming with a gamepad now properly scale to resolution.

  

  

  

  

• Wesser contributed a fix for a well-known script glitch in the Driving and Bike Schools. Previously, an error in how these scripts destroyed the cones used in lessons could cause random objects to be removed from the game. This glitch was most famously known as the “Blackboard glitch”. Unfortunately, SilentPatch cannot repair saves already affected by this issue.
• The cursor on the Map screen now scales to resolution and it can now always reach the top left corner of the map, regardless of resolution. This fix was contributed by Wesser.
• The inner 4-pixel padding of the text boxes with a background now scales to resolution correctly. This fix was contributed by Wesser.
• Nitrous will no longer regenerate faster when reversing the car. Instead, recharging speed while reversing is now identical to when the car is stationary. Once again, this fix was contributed by Wesser.

Internal changes

Aside from all the new fixes, for this release, the codebase of SilentPatch has also been heavily modernized, and multiple fixes have been… well, fixed. Some of those changes are well worth highlighting.

Some of those points might get a little technical, but they may be useful for modders who want to be mindful of keeping compatibility with SilentPatch or are looking for tips on how to make their projects apply code patches in a more resilient way.

• The most severe regression introduced by SilentPatch has finally been addressed. Ever since the first build, SilentPatch attempted to fix the ‘Cannot find 640x480 video mode’ error. While my fix worked fine for users not using DPI scaling, it made things worse for those using that feature – and the game would instead complain about being unable to find impossible resolutions like 1152x867. This bug has finally been addressed, and the new fix works correctly regardless of the DPI scaling.

• Migrated several fixes to use HookEach. These fixes would hook multiple calls to a function, and add my own changes on top. However, previously SilentPatch assumed all those calls were pointing to the same function, which is true for an unmodded game, but another modification installed alongside SP may have broken this assumption. With HookEach, each instance is treated separately, without the risk of stomping on another hook, and “stacking” with other modifications gracefully. In fact, multiple fixes within SilentPatch also stack on each other like this, and they’re completely unaware of each other, even when they hook the same call in the code.

• All SilentPatches released after May 2021 use transactional patterns. For this release, I upgraded the codebase to use those too. Previously, if any pattern failed to match while the patch was applied, the entire library would unload and either crash the game or just do nothing. With transactional patterns, every single fix is applied separately, and if any pattern forming a particular fix fails to match, an exception is thrown and the entire fix is aborted without making any changes to the game’s memory.

  For the patch code, this simplifies the way fixes are applied to the game and makes it impossible for me to accidentally break the entire patch if I forget to account e.g. for another mod making changes to the code. This comes with benefits for users too, as compatibility with other mods should be improved even further! Other recent SilentPatches showed that with transactional patterns, it’s nearly impossible to “break” SP completely.

• SilentPatch for San Andreas introduced this fix several releases ago:

  • A muzzle flash will now show up when firing the last bullet from the clip.

  However, this introduced a regression where “firing” from an empty gun while on a jetpack still displayed the muzzle flash:

  

  This fix has been remade, addressing the issue.

• SilentPatch for San Andreas has had this fix ever since the first release:

  • Detached vehicle parts will now remain the same color as the vehicle they came from.

  In this release, this fix has received multiple improvements:

  • Recently, it was discovered that this change would cause the game to crash if a part detached from a modded vehicle had more than 15 materials. This has now been resolved.
  • While the colors of the detached parts were always preserved, turns out they were never correctly lit. Furthermore, later SilentPatch updates removed the auxiliary vehicle light in favor of properly working directional lighting, so the lighting appeared as if it had regressed. In this update, detached parts are now lit the same way the cars are.

• Earlier releases of SilentPatch for San Andreas rolled out multiple fixes for the license plates not working correctly. Recently, it’s been discovered that this fix would cause the license plates to stop generating if a vehicle with custom plates was fitted with tuning parts. I reimplemented this fix from scratch, making it simpler, and in turn also resolving this issue.

• The last release of SilentPatch for San Andreas introduced a fix for the parachute animations. However, at that time this fix came at the expense of the removal of Night Vertex Colors from the parachute model, making it appear too bright at night. Thanks to B1ack_Wh1te, for this update this fix has been revisited and now it combines both the correct colors with working animations. Additionally, since this fix caused rendering issues in SA-MP, it’s now disabled in multiplayer, unless Graphics Restore is installed.

  

  

• In the last update, this fix present in GTA III and Vice City was rewritten:

  • Reintroduced light glows under weapon/health/armor pickups, bribes, hidden packages, and money pickups – they showed only on PS2 due to a bug in all PC versions.

  However, back then I didn’t notice that my rewrite caused those light glows to disappear when “light boxes” on cars were rendered on-screen (because the widescreen fix disables those boxes). I now updated this fix again to resolve this issue and bring parity with the San Andreas version of this change.

• In III and Vice City, variable resets like the Pay ‘n Spray flag have been upgraded to use the same, less invasive, approach as the one used in SilentPatch for San Andreas.

• Patches for GTA III and Vice City have been upgraded to support 32-bit model IDs from fastman92 limit adjuster. The San Andreas version was already supported previously.

• Patches for GTA III and Vice City have been updated to support ASLR. Whilst no officially released executable of those games has this security feature enabled, some of them contain valid relocation info, and therefore a Windows security option forcing ASLR wherever possible could have caused SilentPatch not to apply correctly. This has now been resolved.

  In case you are wondering what is ASLR good for, here’s a great example – an exploit in BeamNG.drive (that was additionally made easier and more reliable to pull off due to the game disabling ASLR on one of its libraries⁶) has been used to hack Disney! If ASLR wasn’t disabled, this exploit would have been much harder to create; the code comments in the proof-of-concept exploit even mention a “static base address” specifically.

• In all 3 games, fixes related to randomness now use the same randomness engine, based on the PS2 algorithm. It’s unlikely to result in any noticeable differences, but it simplifies the code.

• In all 3 games, the INI options listing vehicle model IDs (like RotorFixExceptions) can now also accept model names.

Download and source code

The latest SilentPatch builds can be downloaded from the Mods & Patches section:

Download for GTA III Download for GTA Vice City Download for GTA San Andreas

Those new to SilentPatch are encouraged to check the Setup Instructions. However, the easiest way to install SP boils down to:

• For GTA III and Vice City, get both downloads for the respective game and extract them to the game directory.
• For GTA San Andreas, players using a 1.0 or Steam version can use my ASI Loader. Rockstar Games Launcher versions of the game need to use Ultimate ASI Loader instead.

Wish to check out the source code instead? Check it out on GitHub. I have also included the compilation instructions and contribution guidelines:

See source on GitHub

TJGM has also published a showcase video focusing on San Andreas, covering many of the additions introduced in this update of SilentPatch:

Credits and acknowledgments

This update was only possible thanks to the contributions of many individuals. Multiple modders generously shared their findings and fixes, which were later integrated into SilentPatch. Others took their time to test the patch through its many iterations to ensure I could ship it in a near-perfect state:

Contributors:

• B1ack_Wh1te
• Fire_Head
• Nick007J
• Sergeanur
• Wesser

Testing and socials:

• Ash_735
• TJGM

Testing:

• Team at Luigi’s Club
• Tomasak
• Wr3nch

Last but not least, a special shout-out to Obbe Vermeij for all the GTA development trivia he’s shared with the world, and most importantly, for all the work he put into the games we still care about decades later 🙌.

Future of SilentPatch?

Will there ever be another SilentPatch for the GTA games? I don’t know. Half a decade passed between “The Corona Update” and this post, so if that’s any indicator, it’s likely there won’t be. However, I am acutely aware I’ve said “no more new fixes” at least twice throughout the lifespan of SilentPatch for San Andreas, so… you never know.

SilentPatch has since thrived as a “brand” outside of GTA, breathing new life into many other old (and newer) games. Whether or not GTA receives more updates in the future, I’m sure many more releases and blog posts are to come. May classic games continue to bring joy to both new players and those reliving their childhood memories!

This article is a follow-up to Fixing EA Sports WRC decal rendering on GeForce GTX 10 series cards.

Introduction

On December 14, 2023, Codemasters released the v1.4.0 update for EA Sports WRC. Among countless fixes, two items align with the fixes previously published in SilentPatch:

• Fixed an issue where Fanatec and location event plates would appear stretched when using NVIDIA GTX 10 series GPUs.
• Fixed an issue where framerate would drop to below 10 fps when using the Livery Editor on NVIDIA 10 series GPUs.

This was somewhat expected, since by the time I released SilentPatch last month, I’ve had the opportunity to get in touch with Codemasters and share my findings in as much detail as possible. I was later informed that the issue was fixed internally and was given an OK to publish SilentPatch as a stop-gap solution for the affected users. My efforts have also been highlighted on the official EA Sports WRC Discord 🙂 In the end, everyone won.

With this out of the way (and with SilentPatch officially deprecated), I was curious about the approach used for the official fix. In this short article, I’ll dissect the official fix and compare it with mine.

The official fix

Let’s start with a recap. When I figured out the root cause of the original bug, I outlined two possible approaches that could be taken here:

1. Make the SRV typeless by defining the stride explicitly and setting the format to DXGI_FORMAT_UNKNOWN. This approach does not require modifying the shaders.
2. Modify the shader the same way I did, replacing StructuredBuffer<uint> with Buffer<float2>. This way the shader handles the existing input buffer layout correctly, regardless of the GPU vendor/generation, and a current way of accessing the buffers is used.

In my fix, I went for the second approach, because replacing shaders is a much easier task than tracking down specific resource creation. However, I was under the impression that the official fix would adopt the other approach, as that would’ve fixed all similar broken cases. Surprisingly, I was wrong – with the v1.4.0 update, the buffer definitions remain unchanged:

Instead, automatic variable names from RenderDoc immediately show that Codemasters changed the shaders themselves – in v1.3.0, the automatically generated name of the first bound resource was structuredbuffer0, in v1.4.0 it’s texture0, indicating that the way the resource is accessed by the shader has changed!

Indeed, looking at the shader assembly of the fixed shader, it now looks identical to the shader from SilentPatch – which means my suggested solution of changing the shader inputs was used as-is:

   imad r0.x, v1.x, cb0[1].x, cb0[1].y
   ld_indexable(buffer)(float,float,float,float) r0.xy, r0.xxxx, t0.xyzw
   mov o3.xy, r0.xyxx

Is this the best solution? I can’t say this with absolute certainty of course, but I am somewhat surprised at the approach taken. However, the other solution (making the buffers typeless) may have introduced problems with other shaders, so perhaps the current solution was thought of as the safest.

However, I have a few more points to raise about this fix. It technically is complete, but it could have been done better, as I believe the current solution is not complete, and DirectX specification is still violated by those shaders:

1. texture1 is of type R8G8B8A8_SNORM, but the shader accesses it through Buffer<float4>. If my knowledge of HLSL is correct, the sampler used here should have been Buffer<snorm float4>.
2. structuredbuffer2 and structuredbuffer3 still use StructuredBuffer<> samplers, despite those buffers not being typeless. In an ideal case, they should also have been changed to use Buffer<>. This is most likely a violation of the DirectX spec.
3. texture0 is of type R16G16_FLOAT, therefore the shader could have leveraged GPU’s support for 16-bit floating point values if the resource was sampled as min16float2. This type combines compatibility with specialization – as it leverages native support for half-floats on supported hardware, and falls back to full floating point values otherwise.

Other fixes in the v1.4.0 update

The changelog of this update is massive, but I’d like to highlight two other things:

1. Aside from the aforementioned changes, the Livery Editor performance is now improved on all PC configurations. Before this update, the editor was slow for everyone since the game was re-rendering all decals to an 8192x8192 render target every frame. In v1.4.0, this is only done when the decals are added/removed/moved/scaled.
2. This update introduced the Central European Rally, a new location in the Czech Republic. Unfortunately, this has introduced a critical issue with the existing Career Mode saves, making saves from further WRC seasons unusable. This is a gameplay issue that in a game of this scope is effectively un-fixable from the outside, and the fix addressing it is scheduled only for mid-January – so it’s a bummer 😔

TL;DR: If you are not interested in a technical dive into the graphical glitch fixed by SilentPatch, scroll down to the Download section for a download link.

• Introduction
• Investigation and debugging
• Putting the fix into the game
• Download

For the follow-up article, see Fan research vs official fix – EA Sports WRC decal rendering on GeForce GTX 10 series cards.

Introduction

Ever since the newest WRC game from Codemasters and EA was released on November 3, 2023, I’ve had a lot of fun playing it. Although my GTX 1070 is close to its end of life, I managed to find a good compromise between performance and quality somewhere in the middle ground between Medium and High graphical details, and I’m able to play the game comfortably.

Throughout my playthrough, I’d also post a few screenshots on social media, such as those – you’ll see later why I bring it up.

I had already overheard the news about some people being unable to use the Livery Editor, but I didn’t put too much thought into it until I tried to use it myself. I tried to put a decal on my car, but without much success:

I shared this screen on Discord in hopes of finding someone else with the same issue, and one person pointed out that other than the decal, I am missing something else – the driver number and the driver/co-driver names are completely missing from the side window! Sure enough, all cars were broken for me in one way or another, but I think Vauxhall Nova takes the crown with just how gloriously unusable it had become:

Indeed, it seems that I hit the very Livery Editor bug I was warned about. A thread in EA Answers HQ has entire pages of people reporting this bug, with one interesting point – everyone disclosing their PC specs in that thread is playing the game on GTX 9xx or 10xx series! It would seem that no other GPU vendor and/or generation except for those is affected. While Maxwell (9xx series) cards are not officially supported by the game, Pascal (10xx series) are, as the game’s minimum system requirements list the GTX 1060. Additionally, this issue is partially mentioned in the current version of the Known Issues page, although it’s more widespread than the thread says:

On GTX 1060 GPU the Fanatec and Flag Decals on vehicles have stretching glitch

Now scroll up. See all these weird “scratches” and lines on these cars and rear windshields? Only then did I realize that the broken Livery Editor and these are actually related – the artifacts on rear windshields are the flags and driver numbers, while “scratches” on cars are most likely the rally-specific/Fanatec decals!

Me being me, I didn’t want to just continue playing the game in this state – it was time to set up RenderDoc.

Investigation and debugging

For this investigation, I took a frame capture of the aforementioned Nova. These decals are rendered only once and not every frame, so capturing the exact frame required a few attempts. I then remoted to another PC with RTX 3070 and opened the same capture on it. Usually, RenderDoc captures are not guaranteed to work across different PCs with different graphics cards, especially with low-level APIs like D3D12 used by WRC, but in this case, a capture from the GTX 1070 PC played back on the RTX 3070 PC just fine (the opposite crashes the D3D12 device, though). Not only that, but on that PC the very same capture also… did not display the bug!

Cases like this are always interesting and reminiscent of my Far Cry investigation. RenderDoc captures the record of every single D3D command issued by the game in the frame, together with the input data; then, previewing events in the capture involves replaying the saved sequence of events up to the point of the selected event. In other words, if two PCs show different results on the same capture, the bug is not the matter of the game setting things up differently between hardware, but rather the hardware itself interpreting the given commands and data in a diverging way!

RenderDoc’s Mesh Viewer provides another clue – apparently, these draws take the car’s body mesh as input, and it obviously looks the same across different hardware…

…but the outputs look… let’s just say, drastically different.

The above comparison concerns the body decals, but it’s the same for nameplates on windows. This is how they render:

Or presented in a different view, highlighting one of the draw calls in pink:

I initially feared that this could be a low-level D3D12 issue (missing synchronization, etc.), but the issue persisted when running the game in a D3D11 mode through a -dx11 command line argument. With this in mind, the first obvious culprit is a vertex shader, especially since they are shared between backends. RenderDoc gives an option to preview the shader assembly, and the vertex shader used for these decals is not too long:

vs_5_0
      dcl_globalFlags refactoringAllowed
      dcl_constantbuffer cb0[2], immediateIndexed
      dcl_resource_structured t0, 4
      dcl_resource_buffer (float,float,float,float) t1
      dcl_resource_structured t2, 16
      dcl_resource_structured t3, 4
      dcl_input v0.xyz
      dcl_input_sgv v1.x, vertexid
      dcl_output_siv o0.xyzw, position
      dcl_output o1.xyz
      dcl_output o2.xyz
      dcl_output o3.xy
      dcl_temps 4
   0: imad r0.x, v1.x, cb0[1].x, cb0[1].y
   1: ld_structured_indexable(structured_buffer, stride=4)(mixed,mixed,mixed,mixed) r0.x, r0.x, l(0), t0.xxxx
   2: ushr r0.y, r0.x, l(16)
   3: f16tof32 r1.xy, r0.xyxx
   4: frc r0.xy, r1.xyxx
   5: mov o3.xy, r1.xyxx
   6: mad r0.xy, r0.xyxx, l(2.0000, 2.0000, 0.0000, 0.0000), l(-1.0000, -1.0000, 0.0000, 0.0000)
   7: mov o0.y, -r0.y
   8: mov o0.x, r0.x
   9: mov o0.zw, l(0.0000, 0.0000, 0.0000, 1.0000)
  10: ld_structured_indexable(structured_buffer, stride=4)(mixed,mixed,mixed,mixed) r0.x, v1.x, l(0), t3.xxxx
  11: and r0.x, r0.x, l(0x0000ffff)
  12: imul null, r0.y, r0.x, l(3)
  13: imad r0.xz, r0.xxxx, l(3, 0, 3, 0), l(1, 0, 2, 0)
  14: ld_structured_indexable(structured_buffer, stride=16)(mixed,mixed,mixed,mixed) r1.xyzw, r0.y, l(0), t2.xyzw
  15: mov r2.xyz, v0.xyzx
  16: mov r2.w, l(1.0000)
  17: dp4 o1.x, r1.xyzw, r2.xyzw
  18: ld_structured_indexable(structured_buffer, stride=16)(mixed,mixed,mixed,mixed) r3.xyzw, r0.x, l(0), t2.xyzw
  19: ld_structured_indexable(structured_buffer, stride=16)(mixed,mixed,mixed,mixed) r0.xyzw, r0.z, l(0), t2.xyzw
  20: dp4 o1.y, r3.xyzw, r2.xyzw
  21: dp4 o1.z, r0.xyzw, r2.xyzw
  22: imad r0.w, v1.x, cb0[1].z, l(1)
  23: ld_indexable(buffer)(float,float,float,float) r2.xyz, r0.wwww, t1.xyzw
  24: dp3 o2.x, r1.xyzx, r2.xyzx
  25: dp3 o2.y, r3.xyzx, r2.xyzx
  26: dp3 o2.z, r0.xyzx, r2.xyzx
  27: ret

Nothing seems obviously wrong here, and any attempts at debugging this shader in RenderDoc failed since the shader interpreter did not manifest this issue when stepping through the shader assembly (or in other words, the output positions matched the expected result, not the “broken” result from Pascal cards). However, RenderDoc also gives an option of replacing shaders on runtime, so I could debug this issue by editing the shader in-capture. Unfortunately, re-assembling shaders is not possible in newer APIs (used to be possible back in D3D8/D3D9 days), so to be able to do that, I had to reimplement the entire shader in HLSL. I rewrote it exactly in the way I understood the above shader assembly, and the result was surprising – the bug was gone:

I initially thought I rewrote the shader 1:1 to the original, so I started investigating the differences. The only two different components were the output position and TEXCOORD2, and the shader derives both from the same input. Therefore, I could isolate the changes down to only the writes to o3. In my shader, I declared the t0 sampler as StructuredBuffer<half2>, as that’s what I thought the original shader did. However, this results in the generated code looking slightly different:

   imad r0.x, v1.x, cb0[1].x, cb0[1].y
   ld_structured_indexable(structured_buffer, stride=4)(mixed,mixed,mixed,mixed) r0.x, r0.x, l(0), t0.xxxx
   ushr r0.y, r0.x, l(16)
   f16tof32 r1.xy, r0.xyxx
   mov o3.xy, r1.xyxx

   imad r0.x, v1.x, cb0[1].x, cb0[1].y
   ld_structured_indexable(structured_buffer, stride=8)(mixed,mixed,mixed,mixed) r0.xy, r0.x, l(0), t0.xyxx
   mov o3.xy, r0.xyxx

It’s reasonable to assume that this difference is responsible for my accidental bug fix, but I couldn’t confirm it until I figured out why is the generated code different. I initially thought it was maybe because the original shader was compiled with support for 16-bit floats and mine wasn’t, but then my colleague and I casually chatted about this issue with pointed out that for Unreal Engine games, it’s common to declare their input buffers with type uint and manually extract the half-floats, like so:

uint uvSample = t0[n];
float2 uv = f16tof32(uint2(uvSample, uvSample >> 16));

What is the result of mirroring this approach in the affected shader? This time, the generated shader assembly is line-to-line identical to the original shader, stride of 4 bytes included. And when it comes to rendering, well…

Just to be clear – what the original shader is doing is not always wrong, but in the case of the current setup it is, and I don’t know why it works on the other GPU vendors and architectures. Maybe it’s worked around via a driver-level hack that is not enabled for the Nvidia 9xx and 10xx series.

What is the setup that makes sampling the buffer as uint not work? RenderDoc presents it as a set of four typed buffers:

There are two problems with this approach:

1. When accessing the buffers via StructuredBuffer, it is assumed that the buffer is laid out in an arbitrary structure with a predefined stride. It is explained nicely by János Turánszki in their Dynamic vertex formats post, but the main clue is provided by MSDN:

   The SRV format bound to this resource needs to be created with the DXGI_FORMAT_UNKNOWN format.

   This is clearly not the case with the above setup, as RenderDoc reports the format of the first bound buffer as R16G16_FLOAT. However, even though this mistake is technically a spec violation, it’s not causing rendering issues on my end – StructuredBuffer<half2> and StructuredBuffer<float2> both work “fine”, even though they are incorrect.

2. Another much worse mistake is the buffer format itself. Because the SRV of the first buffer has a predefined FLOAT type, sampling it as uint is forbidden and this is what causes the rendering glitches on my GPU! With typed buffers, it doesn’t matter that the data is technically the same if it is to be read as bytes directly – SRV format and sampler type must match, with no exceptions. The fact it works elsewhere is either due to sheer luck, or an existing driver-level hack.

With this in mind, it is clear that there are two possible fixes for this:

1. Make the SRV typeless by defining the stride explicitly and setting the format to DXGI_FORMAT_UNKNOWN. This approach does not require modifying the shaders.
2. Modify the shader the same way I did, replacing StructuredBuffer<uint> with Buffer<float2>. This way the shader handles the existing input buffer layout correctly, regardless of the GPU vendor/generation, and a current way of accessing the buffers is used.

Are any other shaders broken in the same way? At least one more shader is – in the Livery Editor, the user has an option of painting the roof/bonnet/mirror/spoiler in different colors to the rest of the body. On the below comparison, all these parts should be orange, but due to an identical bug in the paint shader this doesn’t work on the 10 series:

Putting the fix into the game

OK, but now what? I have a theoretical fix for this issue ready, but it’s all isolated to RenderDoc captures. Having technically solved this issue, I wanted to put it in my game to have a stop-gap solution for this bug until it’s been officially fixed.

It then struck me I already released a very similar modification 3.5 years ago – Gold Filter Restoration for Deus Ex: Human Revolution Director’s Cut largely relies on replacing shaders on runtime, much like what I would need to do here. It’s only done for D3D11, but that is not an issue, since I can run the game using this API via a command line argument. Unreal’s D3D11 implementation might be a little bit less performant than D3D12, but that’s fine for the time being – I prefer to trade a bit of performance for correct visuals.

Gold Filter Restoration seems like an ideal base for this fix – it acts as a D3D11 wrapper, no different from ReShade. No code is hooked in the game, so if WRC uses an anti-cheat, it’s extremely unlikely to become upset at this.

In practice, this approach is easy to code and reliable. A wrapper around ID3D11Device lets me intercept the vertex shader creation, so the two broken shaders can just be replaced with my custom implementations, and the game is none the wiser:

HRESULT STDMETHODCALLTYPE D3D11Device::CreateVertexShader(const void* pShaderBytecode, SIZE_T BytecodeLength,
                                ID3D11ClassLinkage* pClassLinkage, ID3D11VertexShader** ppVertexShader)
{
  if (BytecodeLength >= 4 + 16)
  {
    static constexpr std::array<uint32_t, 4> decalShader = { 0x428ffe45, 0x1c518347, 0xb48bed82, 0x25dc2319 };
    static constexpr std::array<uint32_t, 4> paintShader = { 0xfae61074, 0xefbc29b0, 0xa9ec5152, 0x837d0756 };

    const uint32_t* hash = reinterpret_cast<const uint32_t*>(reinterpret_cast<const uint8_t*>(pShaderBytecode) + 4);
    if (std::equal(decalShader.begin(), decalShader.end(), hash))
    {
      return m_orig->CreateVertexShader(FIXED_DECAL_SHADER, sizeof(FIXED_DECAL_SHADER), pClassLinkage, ppVertexShader);
    }
    else if (std::equal(paintShader.begin(), paintShader.end(), hash))
    {
      return m_orig->CreateVertexShader(FIXED_PAINT_SHADER, sizeof(FIXED_PAINT_SHADER), pClassLinkage, ppVertexShader);
    }
  }
  return m_orig->CreateVertexShader(pShaderBytecode, BytecodeLength, pClassLinkage, ppVertexShader);
}

With this one single change, liveries are working in-game as they should 🙂 Additionally, the aforementioned horrible performance of the Livery Editor is resolved – on my GTX 1070, resulting in an uplift of 5 FPS → 55 FPS while editing decals!

One more thing – the fix is technically ready as-is, but I wanted to make extra sure it cannot cause any conflicts if this issue gets fixed officially in the future. If the devs fix this bug by modifying the shaders, their hashes will change, and they will not be intercepted with my replacements. However, if they opt to fix the SRVs instead, it could result in a conflict.

To avoid this, I “gated off” this SilentPatch. If the user attempts to run it on a game build that is newer than what is public at the time of writing this post, they’ll be greeted with a warning message instructing the user to remove my fix and remove the command line argument:

If the next official patch doesn’t address the issue, I will update my fix against that future patch. It may be annoying for the end user, but it’s the only way to be completely sure no unintended side effects occur.

Download

The modification can be downloaded from Mods & Patches. Click here to head to the game’s page directly:

Download SilentPatch for EA Sports WRC

After downloading, you set up the patch with the following:

1. Extract the archive to the game directory, so the d3d11.dll file resides next to the WRC.exe file.
2. On Steam/EA App, add -dx11 to the game’s launch arguments.

Not sure how to proceed? Check the Setup Instructions.

For those interested, the full source code of the mod has been published on GitHub, so it can be freely used as a reference: See source on GitHub

TL;DR: This article is longer than any other blog post I’ve published to date, so be ready for a long read. If you aren’t currently interested in a deep dive through the game’s history, internals and fixes, scroll down to the Changelog and download section for a download link.

• Introduction
• Chapter 1: In search of a perfect executable
• Chapter 2: Regional releases and their oddities
  • Polish (3 CD) release
  • Polish (2 CD) re-release
  • Czech release
• Chapter 3: Fixes, so many fixes
  • Fixes & improvements
  • New options
• Chapter 4: The perfect remaster – adding an HD interface
  • Scaling issues
  • Font filtering
  • Half pixel issues
• Chapter 5: Merging regional releases together
• Changelog and download
• Credits and acknowledgments

Introduction

October 2022 marked the 20th anniversary of Colin McRae Rally 3. A little over two months later, I’m happy to reveal the biggest SilentPatch since GTA San Andreas. In this release, developed together with Bekoha, we deliver more than just a set of fixes – with full widescreen support, numerous compatibility fixes, new technical features, Quality of Life improvements, and a scratch-made high definition UI optimized for 4K displays, we bring an experience comparable to an unofficial remaster of this classic 2002 rally game.

Originally, this project didn’t start as a SilentPatch. Instead, I only intended to document the different releases of the game, but given the anniversary timing and the attention Colin McRae Rally 3 received around that time, it was hard to pass on an opportunity to give it a new life, especially once Bekoha expressed interest in retouching the game’s fonts and UI.

For this reason, this blog post details the entire journey – from scavenging for different versions of the game, documenting them, through the process of fixing the game, and finally merging regional releases together. Feel free to take a break between chapters, as it’s going to be a lot – it’s the longest post published on my blog to date.

This post may get technical at times, but don’t get discouraged; I intend it to be clear and informative for everyone – players, game developers, and reverse engineers.

But first, a few words about the game for the uninitiated. Colin McRae Rally 3 is a racing game from Codemasters, released originally for the PS2 and Xbox on October 25, 2002, later ported to PC by Six by Nine Ltd. and released there on June 13, 2003.¹ It was received well and was succeeded by two more sequels in 2003 and 2004 before the franchise moved on to a Colin McRae DiRT series.

Unlike Colin McRae Rally 2.0, where the game shined on PC, CMR3 was an enhanced console port. Nonetheless, I have fond memories from playing this game as a kid (although they’ve blurred together with memories from CMR04 and CMR2005). Curiously, back in the day, this was considered a sub-par port, and some people did not enjoy the long wait for the PC port, especially since by then CMR04 was just a few months away from release. I find this comment the most amusing…

Unfortunately it’s a sign of the times and it’s sad to see Codemaster’s, once big supporter’s of the PC, becoming member’s of the lazy developer’s club.

…since it sounds like something that could have been said online in July 2022, not July 2003 – I guess some things never change 😜

Chapter 1: In search of a perfect executable

It’s commonly known that DRM on retail discs sucked. The three leading DRM solutions all came with a varying level of breakage, and these days, two of them are intentionally disabled by Windows; furthermore, one of those DRM solutions is so contrived it can make a Windows 10/11 machine unbootable (shout out to TOCA Race Driver 2 & 3). Much like I did for the TOCA Race Driver games, I wanted to know if the trilogy of later Colin McRae Rally games were all released DRM-free somewhere:

• Colin McRae Rally 04 is easy – much like TOCA Race Driver and TOCA Race Driver 2, it was re-released in Italy by FX Interactive, opting for “physical” DRM (ring on the disc’s surface to make copying unreliable and time consuming) instead of a software solution.
• Colin McRae Rally 2005 was released DRM-free on GOG.com, so even though the game has since been delisted, getting a hold of the DRM-free executable is not hard.
• This left only Colin McRae Rally 3 in an unknown state, as at that time all CMR3 discs submitted to Redump had SecuROM DRM – except for the Polish release.

I initially brushed off that hint, since I thought this listing is incomplete or incorrect. After all, I own a Polish CMR3 release from back in the day – it uses SafeDisc², making it impossible to launch without workarounds or a no-CD executable, and it comes on three discs, while this listing only had two.

However, turns out that this wasn’t an error, as a later re-release of the game did indeed come on 2 CDs:

Anyone around with this specific version of Colin McRae Rally 3? I suspect this 2x CD re-release (compared to a 3x CD original) might be DRM-free, or at least might contain just a simple CD check. pic.twitter.com/n7MQIAuTmJ

— Silent (@__silent_) October 8, 2022

With the help of Krusantusz, I got access to this executable for analysis. While it indeed is DRM-free, its usability with assets of the “international” version is limited – with the range of issues ranging from a hardcoded French co-driver (replaced with Polish in the actual release)…

Turns out this release is indeed fully DRM-free, and its executable also works with an English version! Well, almost, and to get what's the catch you need to watch with sound on.

I hope it's patchable, as DRM-free exes > no-CD exes all the way https://t.co/6bABq0Atvy pic.twitter.com/tinKdKicbR

— Silent (@__silent_) October 8, 2022

…various UI issues…

…through crashes on various screens, e.g. Telemetry and Controls. While salvageable, this means that the Polish release has received a non-trivial amount of code changes.

Shortly after that, I also bought my own second hand copy of the eXtra Klasyka release, so now I’m a proud owner of two CMR3 PL copies:

If the rabbit hole of different versions ended here, this would have been a story of how I created an international DRM-free executable by “internationalizing” the Polish one and removing CD Projekt’s modifications to it (more on that later). There is one more version, though – CMR3 was also re-released in Germany on a single DVD. As SecuROM worked with DVDs just fine, we expected this release to have DRM identical to the original – however, Memorix101 proved us wrong. Together with RibShark we tracked down a copy for sale and submitted its metadata to Redump – at which point it became clear that this re-release is so late, its disc was mastered after the release of Colin McRae Rally 2005!

At this point, I’ve already been “internationalizing” the Polish executable, so this work was technically rendered useless (for now). Regardless, thanks to the German version, we got The Perfect CMR3 Version we wanted – an easy to install, DRM-free, future proof release that ensures the game remains accessible indefinitely. My initial goal was done.

Chapter 2: Regional releases and their oddities

Note: Although the DVD version was only sold in Germany, its content is identical to the international release, so I don’t consider it a regional release per se.

Polish (3 CD) release

As mentioned earlier, the Polish release is more than a straightforward text and speech translation. Aside from making Polish the only language in the game, CD Projekt (or Codemasters) introduced several changes to the international version, localizing the game further:

• Localized onscreen keyboard and keyboard typing – the international version displays a basic keyboard regardless of a selected in-game language:

  

• Menu cubes received new graphics to match Polish wording:

  

  

  

• The Secrets screen was modified to refer to CD Projekt’s resources rather than the Codemasters’ ones – this is what resulted in a previously shown “Call your Germany” issue if a PL executable is used with English localization:

  

• By the way, have you noticed how Polish fonts are spaced further apart than international ones? Odd change, but I assume they had a reason to do so.
• Polish introduces 40 new localization strings for texts that were previously hardcoded to English. This is what caused an unpatched PL executable to crash with English localization.
• As other languages have been removed, the Language screen is renamed to “Co-driver’s voice” and gives you a choice between Nicky Grist, the original English co-driver, and Janusz Kulig, the voice of a popular Polish rally driver.

Polish (2 CD) re-release

Around a year after the original release, Colin McRae Rally 3 was re-released in Poland under an eXtra Klasyka label (as you may have noticed above). Aside from being completely DRM-free, it also ships on 2 discs instead of 3. While I initially thought this is solely due to better compression, this isn’t the case – the changes in this release are:

• The removal of Nicky Grist as a selectable co-driver
• The change of the Polish co-driver’s voice from Janusz Kulig to Janusz Wituch

I couldn’t find any in-game comparisons online other than the Polish dubbing wiki, so here is one:

The removal of Nicky Grist explains why the game was now shipped on 2 CDs – while localized co-drivers only use one-shot samples that are played at specific triggers during the stage, Nicky Grist’s pace notes are full audio recordings, created for each stage individually. This makes Grist’s notes sound much more natural than the other co-drivers, at the cost of much higher file size – while each localized co-driver is typically between 1.5 MB and 2 MB in size, Grist’s pace notes are 435 MB!

What about Janusz Kulig, though? We will of course never know for sure if this change was dictated by licensing, but one more plausible reason may be a little clearer for those familiar with the Polish rallying scene. For those unfamiliar, it’s best to show it on a timeline of what I think has happened:

1. June 26, 2003 – The original PL Colin McRae Rally 3 featuring Janusz Kulig gets released.³
2. February 13, 2004 – Janusz Kulig, a Polish rally driver, dies in a road accident after his car collides with a train on a level crossing.⁴
3. After April 2004 – Colin McRae Rally 3 gets re-released in eXtra Klasyka, featuring Janusz Wituch – a prolific voice actor, also starring in TOCA Race Driver and TOCA Race Driver 2.^{3 5}

While there is no definite proof to support that claim, it seems reasonably likely that CD Projekt quickly opted for a new co-driver after Kulig’s death. Their choice to feature Janusz Wituch may or may not have been related to the fact he was presumably recording lines for TOCA Race Driver 2 around that time – as it was released in Poland on June 24, 2004.⁶

Czech release

A Czech release, published by CD Projekt, also exists – albeit the details on it are sparse:

Let's see if I can once again seek help through Twitter - do any of you own this? A Czech release of Colin McRae Rally 3. https://t.co/M2CFIqeCZN pic.twitter.com/fDD4LSOlIz

— Silent (@__silent_) November 3, 2022

Albeit much like the Polish release it was released by CD Projekt in eXtra Klasika, I don’t know if it ever was released outside of it (it likely was, though). From the technical side, this Czech release is much less interesting than the Polish one – compiled on August 31, 2004, it’s not a special version but rather a translated international release replacing Spanish with Czech. None of the changes from CD Projekt are present in this release, although it’s clear that it must have been translated from Polish, not from English – as the Czech translation file contains (now unused) strings introduced in the Polish release!

That said, there is something interesting about this release, and I only noticed it during the final tests of SilentPatch – although the contents of the Czech executable appear to be identical to the international executable, it has at least one unique UI bug, not present anywhere else! I have no idea how this happened, but the results screens for time trials are completely broken in this release.⁷

I’m disappointed, as this screen was not even changed for the localized release – it’s a completely unwarranted regression.

Chapter 3: Fixes, so many fixes

In this section, I want to highlight the most interesting and unusual improvements present in the patch. This is not a full changelog – for that, refer to Changelog and download.

Fixes & improvements

Console versions of CMR3 included a Widescreen option in Graphics Options, switching the aspect ratio from 4:3 to 16:9. While this option is gone from the PC versions, it’s still functional – it’s just that this option is underwhelming to begin with (also in the console versions), as it only corrects the 3D aspect ratio, and the only UI element it corrects is the co-driver arrow. That said, it’s not the worst, as it opts to fix the aspect ratio by increasing the horizontal FOV, rather than by shrinking it vertically:

Curiously, the PC demo did list 16:9 resolutions, unlike the full version of the game – but unlike the console versions, it is Vert-; the co-driver arrow also appears to be broken. In my opinion, it’s possible that because of issues like this it was decided that the full version should limit the available options:

SilentPatch doesn’t rely on the stock widescreen support at all – instead, much like in SilentPatch for Colin McRae Rally 2.0, I scale the game to arbitrary aspect ratios. The entire UI and menus are positioned dynamically, ensuring that everything looks consistent regardless of resolution. This required an obscene amount of work, as literally all the UI and menus had their layouts designed with a constant 4:3 aspect ratio – therefore, SilentPatch takes control of nearly all the UI and menus to keep elements aligned consistently regardless of the aspect ratio:

For more screenshots showcasing widescreen support, check the next chapter.

The PC version of Colin McRae Rally 3 had a strange bug where the sun would flash in random colors (WARNING: rapidly flashing colors) if the FSAA (anti-aliasing) option was enabled. This happens regardless of whether anti-aliasing is enabled in-game, or forced externally; dgVoodoo would also not help resolve it, proving that it’s not a Direct3D 9 bug.

I tracked down this issue to the game’s occlusion queries that would return values much higher than what the game had expected when multisampling is enabled (due to queries returning the number of samples, not pixels). I find it hard to blame the developers for this, as even the official Microsoft docs got it wrong! Since then, I have submitted a pull request to correct the docs, and my proof in form of a fix for CMR3 was enough for the change to be accepted 😃 This link also includes a more technical writeup on this issue, in case you want to learn more about it.

Interestingly, this bug has been “fixed” officially in the sequels, but I was able to verify that it’s not fixed “properly”⁸ – instead of accounting for the value of multisampling, the game now clamps the result of the occlusion query to (0.0 - 1.0). On one hand, this prevents the sun from being miscolored; on the other hand, sun occlusion is now wrong with multisampling enabled, which means the sun visibility increases quicker the higher the multisampling value is.

This isn’t the only issue related to the sun rendering – aside from broken colors, the sun occlusion would cause a consistent and noticeable hitch every time the sun would either appear on screen or go off screen:

This bug, fixed only in Colin McRae Rally 2005, is caused by the game waiting for the sun occlusion query to return its results as soon as it’s finished. I don’t need to provide pseudocode, as the code flow looks nearly identical to this Query State sample code from MSDN. The important memo that the game ignores goes as follows (emphasis mine):

Note that applications should pay special attention to the large cost associated with flushing the command buffer because this causes the operating system to switch into kernel mode, thus incurring a sizeable performance penalty. Applications should also be aware of wasting CPU cycles by waiting for queries to complete.

Queries are an optimization to be used during rendering to increase performance. Therefore, it is not beneficial to spend time waiting for a query to finish. If a query is issued and if the results are not yet ready by the time the application checks for them, the attempt at optimizing did not succeed and rendering should continue as normal.

In this case, the game waits for the query to finish twice per frame, therefore forcibly syncing the CPU with the GPU two times per frame for no reason. With this in mind, it’s strange that this hitch isn’t more consistent than that – the sync is done every frame, and so technically it should be blocking each time. This is exactly what happens when dgVoodoo is used to make the game use Direct3D 11, but I couldn’t get it to ever happen in Direct3D 9 – perhaps due to a runtime or a driver level optimization/hack:

The fix is trivial in theory, but a little harder to implement – instead of always waiting for the latest result, the game should keep the old sun occlusion data (and not start another query) for as long as the new result is not ready. This means that the value of the sun occlusion (and therefore, its brightness) lags behind the camera by 2-3 frames. However, in practice this is not noticeable during gameplay, and resolves any hitches completely:

Something I only noticed just now when writing this post: I don’t know if the huge difference in CPU9 and CPU11 usage is related to this fix. However, it likely is – the old code essentially included a CPU spin lock waiting for the GPU, and the quote from the docs I included above specifically points out “wasting CPU cycles by waiting for queries to complete”.

Thought we’re done with issues caused by anti-aliasing? So did I, but as it turns out – I was wrong.

Car shadows in CMR3 are simple but effective. They are essentially rendered in two phases:

1. Render the car from the sun’s perspective, with depth testing and writing disabled, and with no color – always drawing full white.
2. Take the 256x256 car shadow render target, downsample it to a smaller 128x128 target, and then upscale it again to achieve a blur effect. Repeat this step n times (8 in the stock CMR3).

Although the effect isn’t complex, it seemingly breaks with anti-aliasing enabled – upon starting the game with FSAA, shadows were there but they were too sharp; even worse, changing the display mode with FSAA enabled would make the shadow vanish entirely for that game session:

Turns out the issue lies in the “softening” pass. In theory, both shadow passes should be performed with depth test and depth write disabled; this means that all draws should go through regardless of depth, and depth should not be updated by these draws. Although the game sets up the depth states for shadow rendering correctly, an error in the 2D drawing functions made downsampling perform with a depth test enabled.⁹ Furthermore, in cases where a render target has no depth buffer associated with it, the game’s graphics engine uses a fallback instead and binds the backbuffer’s depth buffer! Therefore, downsample draws used this as depth:

In theory, this should only make draws fail if the top left part of the screen was obscured (making the depth test fail), but with FSAA it gets worse since it resulted in matching a non-multisampled shadow buffer with a multisampled depth buffer. I don’t know exactly if D3D9 is required to handle this mismatch correctly, but seeing how this can break shadows in multiple ways – I suspect the results here are undefined.

Those familiar with GTA San Andreas might have a déjà vu, as this game had an identical bug affecting mirrors.

SilentPatch fixes this issue and goes a step further – admittedly, those “sharp shadows” look kind of nice, but at the same time, I didn’t want to disable the softening pass entirely. Thankfully, Colin McRae Rally 2005 reduces the number of soften passes from 8 to 2, making shadows a little sharper. I “backported” this change to Colin McRae Rally 3, making shadows a little more defined:

If you prefer to keep the stock, blurrier shadows, this change can be disabled from the SilentPatchCMR3.ini file – by adding these lines at the very bottom of the file:

[Advanced]
SHARPER_SHADOWS=0

A few stages in CMR3 run next to lakes or across rivers. At the highest details, those come with a nice cubemap-based reflection and a subtle animation, producing an appearance of a reflective, moving water surface. However, on PC those reflections don’t always look the same:

Depending on your actions, reflections may appear darker or even be completely black. I investigated this issue in detail, and it is caused not by one, but three separate bugs! While one of them is a nitpick and may not even affect visuals, the other two are worth covering.

Presumably for performance reasons, the reflection cubemap is rendered only once, and it contains the sky and the horizon. This creates an issue during a device lost event, i.e. when minimizing a fullscreen game window – historically, a device lost event invalidates all render targets, so they need to be recreated after restoring the game window. CMR3 is aware of that and gracefully recreates most render targets – but not the reflection cubemap! This results in the reflection being pitch black, making the water look horrendous. Making the game re-render the reflection after a device lost resolves the issue.

The other issue is also related to the device lost event, but it happens when the device resets (either due to Alt + Tab or a display mode change) outside of the race. Since reflections are rendered at the start of the race, they should be unaffected by a reset in menus and render just fine. However, they are rendered slightly miscolored:

Because of the one-shot nature of those reflections (and, of course, making them re-render every frame “fixes” this bug), it was extremely hard to catch on a graphics capture. However, once done, PIX provided a hint – one of the lighting render states is different between the “good” reflection render and a “bad” one:

This essentially means that the scene is rendered to the cubemap with incorrect, possibly unpredictable, lighting – but why? The game code correctly sets the emissive source before rendering the cubemap, and yet it’s still wrong.

The answer is slightly complicated, and it boils down to cache coherency. CMR3’s rendering engine has a layer of abstraction over Direct3D 9 designed to cache the state the game wants to put the rendering pipeline at, and ensures that any state changes call reach D3D9 only when necessary. However, sometimes the game cache needs to be evicted or updated, as the D3D9 runtime discards its state. One such event is… the device reset (emphasis mine):

Calling IDirect3DDevice9::Reset causes all texture memory surfaces to be lost, managed textures to be flushed from video memory, and all state information to be lost.

The developers behind a PC port of CMR3 were aware of this, so the game submits all cached render states to D3D9 again after a device reset, therefore making sure that the runtime state matches what the game expects. Except… a few device states have been missed! Those are:

D3DSAMP_BORDERCOLOR - for all 8 samplers
D3DRS_EMISSIVEMATERIALSOURCE
D3DRS_BLENDOP

While I don’t know if the other two are ever used (despite being cached), D3DRS_EMISSIVEMATERIALSOURCE is the exact render state that is incorrect when the reflections are dark. The fact they were not updated after a device reset means that the game thought the D3D9 runtime is in a different state than it truly is, and thus it’s not setting the render state if it thought it’s “pointless” – hence the state cache losing coherency.

Fixing the Reset function to correctly reconcile those 3 missing states fixes the issue, so now water looks the same at all times:

If you’ve played CMR3 on PlayStation 2 or watched any footage of it, you may have noticed that the game looked a little more vibrant there, most prominently when it comes to car reflections. Albeit present on PC and Xbox, they always seemed a little dull. To verify, I ran the same car and stage on PC and in the PCSX2 emulator, and pulled the reflection data before and after it’s been mapped on a sphere:

They have clearly been rendered differently, but the most noticeable difference is in the sky – PS2’s reflection has a normal sky, while on PC it’s always a grey box, except for night stages.

PS2 reflections are rendered in a really simple way:

1. Take the entire rendered frame up to the point of drawing reflections (that’s why the car shadow is present on the reflection).
2. Project that frame buffer on a sphere drawn to a separate render target.
3. Render the lens flare, if applicable.

PC opts for a more involved solution:

1. Clear a separate render target to grey, unless it’s a night stage. Oddly enough, instead of using a camera clear, this is done by drawing a rectangle spanning the entire render target – no idea why.
2. If it’s a night stage, render the sky.
3. Render most of the scene again with a very low draw distance.
4. Project that on a sphere drawn to yet another render target.
5. Render the lens flare, if applicable.

At first, it might seem like the PC reflections are done better, but I believe this change was made purely for technical, not visual, reasons. Unlike on PS2, on PC taking a frame “rendered up to a specific point” is not trivial, especially with older rendering APIs like Direct3D 9. Most games from the era render directly to a back buffer, and using that surface as an input resource for another draw (to project it on a sphere) is virtually impossible without copying it, which can be a costly and/or memory intensive operation.

That’s not to say that doing it the PS2 way is impossible, of course – CMR3 could have rendered to a separate render target that is simultaneously a render target and a texture. That does the trick, but comes with a few disadvantages:

• A color target + depth target the size of a screen is required, which can take a lot of precious VRAM.
• It is not possible to create a resource that is simultaneously multisampled, can be rendered to, and bound as an input resource. To keep multisampling, yet another intermediate render target would be required.

Neither of those two is an issue for modern games (I implemented this exact thing in another game just a few months ago) – but the situation in 2003, when you only had 32-64 MB VRAM to use, was likely very different.

What about the sky on PC, however? Once again it’s hard to say, but it is possibly a performance optimization, allowing reflections to draw less. Curiously, split-screen uses a full sky in reflections – which I found peculiar until I remembered that the Xbox version uses identical reflections and that split-screen on consoles runs at 30 FPS. If this truly was a performance optimization, then it may not have been needed when the target frame rate is lower.

For SilentPatch, I went ahead and enabled sky rendering for reflections at all times:

Not only does this change make the car reflections more vibrant, but it also “fixes” the TV displays in cutscenes – as they reuse the reflection map, they now display the sky correctly!

If for some reason you prefer the stock reflections, this change can be disabled from the SilentPatchCMR3.ini file – by adding these lines at the very bottom of the file:

[Advanced]
ENVMAP_SKY=0

(In)famously, Direct3D has no option of altering the line thickness of draws; therefore, line draws are always 1px thick. CMR3 uses lines widely (pun unintended) – they are used both in 2D (in menus and graphs), and in 3D (for antennas). This wasn’t an issue on consoles, as well as on PC when played at 640x480 – but the larger the selected resolution is, the more noticeable it becomes that those lines become relatively thin and hard to read. SilentPatch resolves this issue by implementing line thickness:

The default CMR3 menus look notoriously inconsistent. SilentPatch fixes many inconsistently formatted texts (e.g. CONTROLS: on one screen, CONTROLS : on another) and imperfect menu elements – with “line boxes” being exceptionally imperfect:

Just like the previous games in the franchise, Colin McRae Rally 3 comes with a split-screen feature. The issue is, on most modern PCs by default it looks like this:

This issue, fixed in Colin McRae Rally 04, can also be worked around by setting the game affinity to just a single core. However, since that’s not a threading issue, this likely only buys the user some time, and in the future, this method might stop working too.

How was it fixed in CMR04? It’s one of the only fixes I’ve admittedly not understood fully, but it seems to be related to the physics update tick ending up at a 0 ms delta value (which means 0 ms have passed between updates). CMR04 seems to correct this by replacing relatively inaccurate timeGetTime functions with a more accurate QueryPerformanceCounter; however, this wasn’t enough to fix CMR3, so I also additionally offset the first physics update tick by one second. This means that the game thinks the very first physics tick took one second, but in practice, this changes nothing, as that one tick is performed just after the cars are spawned – and this happens before the screen starts to fade from white.

CMR3 comes with support for multiple displays and allows the user to specify what display to render the game to, but unless all your displays are identical, your typical multi-monitor experience was likely to look like this:

The addition of a Refresh Rate option in SilentPatch only made this issue worse, so despite using a single-display system myself, I had to take a look. Turns out the issue is simple – although the game correctly refreshes the list of available resolutions as soon as you switch the selected display adapter, it… doesn’t update the number of available resolutions. This, depending on whether the newly selected adapter has more or fewer display modes, could result in either being unable to select the higher resolutions or in an instant crash (as shown above). SilentPatch fixes the issue by updating the display mode counts and makes sure that the selected resolution cannot ever go over the number of listed display modes.

The last issue I wanted to highlight never showed up in the original game, but it’s somewhat fascinating, and could serve as a cautionary tale for other developers.

Initially, after implementing the windowed mode, I’d observe an issue where the game window flashes black every few seconds. This only happened in normal windowed mode, and not borderless, even though the two are technically nearly identical. I initially thought it was an issue caused by NVidia Shadowplay, as the issue seems to have been caused by something sending this series of messages to the game window:

S WM_WINDOWPOSCHANGING lpwp:0019FA8C
R WM_WINDOWPOSCHANGING
S WM_ERASEBKGND hdc:0F01208B
R WM_ERASEBKGND fErased:True
S WM_WINDOWPOSCHANGED lIpwp:0019FA84
S WM_SIZE fwSizeType:SIZE_RESTORED nWidth:1280 nHeight:720
R WM_SIZE
R WM_WINDOWPOSCHANGED
S WM_GETICON fType: True
R WM_GETICON hicon:00000000
S WM_GETICON fType: True
R WM_GETICON hicon:00000000
S WM_GETICON fType:False
R WM_GETICON hicon:00000000
S WM_WINDOWPOSCHANGING Ipwp:0019FA8C
R WM_WINDOWPOSCHANGING
S WM_ERASEBKGND hde:7D0123DE
R WM_ERASEBKGND fErased:True
S WM_WINDOWPOSCHANGED lIpwp:0019FA84
S WM_SIZE fwSizeType:SIZE_RESTORED nWidth:1280 nHeight:720
R WM_SIZE
R WM_WINDOWPOSCHANGED
S WM_WINDOWPOSCHANGING Ipwp:0019FA8C

The key to understanding is the fact those are not position changes, but style changes – and sometimes I’d also see the window border briefly change the style to the one used by windows that are hung. Indeed, the issue was essentially revealed by this feature of Windows:

Traditionally, Windows thinks the window is hung when its window messages are not pumped often enough, typically 5 seconds. However, at no point, the game was truly unresponsive, and so the chain of events that I think has happened there is:

1. The game processes gameplay logic and renders.
2. The game waits for a message to arrive (without pumping).
3. If any messages are present, process them.
4. Repeat from point 1.

The issue lies in point 2. – the game somehow must be waiting for new messages without pumping them. Therefore, Windows thinks the app is hung and sends several messages to indicate that fact via a window style change. This in turn causes the game to spot that new messages are present, and process them; however, processing messages is an indicator of a window that’s working normally, so that backtracks the “app is hung” state! The cycle repeats every few seconds, causing periodic flashes.

The proper fix would be to always pump messages, without waiting for them – but since I wanted to keep the fix non-invasive and at the same time comprehensive, I opted to “poke” the game window with an empty timer message every 2 seconds to keep it always active. Not the cleanest, but makes it impossible to overlook any places in the code to patch, which arguably is the highest priority when retrofitting fixes like this.

That said, please don’t implement this fix in your app – fix it properly instead 👼

New options

Starting with a small one – the game is now fully portable and saves settings to a SilentPatchCMR3.ini file located in the game directory, instead of saving to the system registry. If you wished to put CMR3 on a flash drive and carry it with you, now you can.

Graphics Options have been expanded with several new options. My patches shipped with new options for a long time, both SilentPatch for Colin McRae Rally 2.0 and SilentPatch for TOCA 2 Touring Cars previously included options like FOV control and more. However, this time those options are present in the game options.

The new options are:

• Tachometer (Analog/Digital) – much like in CMR2.0, the tachometer is now customizable. The digital tachometer was previously exclusive to 2 player split-screen.
• Split-screen (Horizontal/Vertical) – another option inspired by CMR2.0. Previously, the game always used a horizontal split-screen when playing in 4:3, and a vertical one when playing in 16:9; this means that the vertical split-screen remained unused on PC. Since the game now adjusts itself to arbitrary aspect ratios, separating this into a new option made the most sense.
• Field of View control – the default field of view for all in-game cameras is 75 degrees, and now I added an option to set your preferred FOV in the range of 30 - 150 degrees. External and internal cameras get their separate options – something not done even in DiRT Rally 2.0.

Advanced Graphics Options have received a set of new options inspired by later CMR games and modern games in general.

Those are:

• Display mode (Fullscreen, Windowed, Borderless) – using the stock game’s windowed mode that remained unfinished in the code, presumably a scrapped idea and/or a debug feature.
• Refresh Rate
• Vertical Sync – the game’s UI has some issues with high frame rates, but the car physics seem to work well even at hundreds of frames per second!
• Anisotropic Filtering – unlike the option in CMR2005, this one actually works⁸ 🤔

  

The new options default to English if you’re using an international or a Czech version, and Polish if you’re using a Polish version. However, the Language Pack comes with translations for all new strings added to the game. Please check Chapter 5: Merging regional releases together for more info.

Chapter 4: The perfect remaster – adding an HD interface

A set of fixes and perfect widescreen support make for a nice patch, but it’s not enough to call this a remaster. However, this changed once Bekoha offered to work on retouching the UI and fonts in high quality. The original assets were clearly made with a 640x480 resolution in mind; so when playing at high resolutions the game itself looked gorgeous, but the UI was lacking.

Bekoha’s HD UI addresses this by replacing most interface assets with faithful high quality recreations:

More comparison screenshots (also showcasing SP’s widescreen support) can be found on Bekoha’s website: CMR3 HD UI Screenshots

Of course, if replacing textures was as easy as just putting them in the game, I wouldn’t be writing about it here, and someone else would’ve likely released HQ fonts/UI years ago. Instead, to get HD textures to look the way we wanted them to, we had to solve not one, but three separate issues.

Scaling issues

Theoretically, replacing textures in CMR3 is easy. Font files are loose DDS files, while the UI textures are DDS files packaged in BigFile archives that have been well understood for nearly two decades. However, a naïve texture replacement produces results that are hardly optimal:

Albeit unusual for PC games, this behavior is perfectly explainable. The original UI design was pixel perfect, with no scaling involved – which means that all UI textures displayed 1:1 to what they are in files. For obvious reasons, this does not translate well to PC where the output resolution is configurable, but there the draws only get linearly scaled, with the setup unchanged. This means that internally, the game still issues UI draws using the texture dimensions as a draw size, producing oversize UI elements (screenshots #1 and #3), or specifying UV coordinates in pixels directly, producing cut off elements (screenshot #2).

The solution here is simple – since the UI has already been “finalized” with specific texture dimensions in mind, scaling can be implemented trivially by lying to the game about the texture sizes, and always pretending the texture dimensions are the same as the original!

static const std::map<std::string_view, TexData, std::less<>> textureDimensions = {
	{ "Arrow1Player", { 32, 16 } }, { "ArrowMultiPlayer", { 32, 16 } }, { "ArrowSmall", { 16, 16 } },
	{ "Base", { 128, 128, true } }, { "certina", { 64, 8 } }, { "Colour", { 128, 128, true } },
	{ "Ck_base", { 128, 64 } }, { "Ck_00", { 32, 32 } }, { "Ck_01", { 32, 32 } },
	{ "Ck_02", { 32, 32 } }, { "Ck_03", { 32, 32 } }, { "Ck_04", { 32, 32 } },
	{ "Ck_05", { 32, 32 } }, { "colin3_2", { 256, 64 } }, { "ct_3", { 64, 64, true } },
	{ "dialcntr", { 32, 32 } }, { "infobox", { 128, 128 } }, { "MiniStageBanner", { 128, 32 } },
	{ "osd_glow", { 32, 32 } }, { "rescert", { 128, 32 } }, { "swiss", { 128, 8 } },
	{ "AUS", { 32, 16 } }, { "FIN", { 32, 16 } }, { "GRE", { 32, 16 } },
	{ "JAP", { 32, 16 } }, { "SPA", { 32, 16 } }, { "SWE", { 32, 16 } },
	{ "UK", { 32, 16 } }, { "USA", { 32, 16 } },
};
auto it = textureDimensions.find(name);
if (it != textureDimensions.end())
{
	result->m_width = it->second.width;
	result->m_height = it->second.height;
}

Because the UV data sent to the rendering API is normalized, this lie allows the game to keep the internal setup unchanged, while the actual rendering stays unaffected and makes full use of the high fidelity resource.

Font filtering

Contrary to a popular belief, upscaling is not always the best solution for a high quality interface. Detailed textures benefit from it the best, but for pixel art there usually is a better solution – nearest neighbor scaling:

For any textures considered pixel art, scaling them via nearest neighbor filtering (as opposed to linear filtering) retains the effect of sharp pixels without the need to ship assets that effectively duplicate pixels multiple times:

SilentPatch opts to always use nearest filtering on a set of textures and fonts predefined by us, so they look sharper than in the stock game even without the HD UI installed.

Half pixel issues

Direct3D 9 comes with a rather annoying texturing phenomenon dubbed “half pixel offset”, where textures display slightly wrong unless the draw is offset by half a pixel. It has finally been corrected on the API level in Direct3D 10 and newer and it has never been an issue in OpenGL, so it’s a commonly overlooked issue – and CMR3 is no different. The issue is documented very well, you can read about it more here:

• Directly Mapping Texels to Pixels from Microsoft
• Solving DX9 Half-Pixel Offset from Aras Pranckevičius

While CMR3 is subject to this issue, with linear filtered textures I couldn’t spot it at any resolution. However, it all changes once nearest filtering is used – textures appear blurry on the edges even though it should be impossible when nearest filtering is used (top image). Applying that specific fix to all UI elements ensures they always stay as sharp as possible (bottom image). Pay attention to the blurred edges, especially on 1, L, and R:

Chapter 5: Merging regional releases together

With all fixes and high definition UI in place, it was time for the icing on the cake – producing a single ultimate package of releases combining the regional editions, not unlike what a real remaster could potentially do. For this, I only consider known official releases, so fan translations are not considered.

The Language Pack includes all 7 official translations (counting English), and 8 co-drivers, including the two Polish co-drivers presented above. The Polish re-release also receives support for Nicky Grist’s pace notes much like the original Polish release, although due to the high file size, Grist’s audio files are a separate download. All regional changes made for the Polish release, such as localized cube textures and the OSD keyboard, are also present; not only that, but the Czech localization also receives its own OSD keyboard, while the official release did not:

Since the regional releases ship their own atlases of fonts, and the Polish release goes as far as updating the codepoints from Windows-1252 (Western Europe) to Windows-1250 (Central Europe), the initial plan was to merge them all and update the game to use UTF-8. However, we ruled against it for several reasons:

• The PCF format is not complicated to reverse engineer, but making a tool that can correctly repack it from a human readable format is another matter.
• Changes like this can be extraordinarily risky and could potentially break compatibility with the existing saves and track records.
• Even if they didn’t break compatibility with “old” records when SilentPatch is installed, it would be highly likely that “new” records would break the stock game.

Therefore, SilentPatch adds support for “regional” fonts for each language. Both Language Pack and HD UI ship Polish fonts in fonts/fonts_P, and Czech fonts in fonts/fonts_C. These alternate sets of fonts are used regardless of whether the Language Pack is installed or not, so the HD UI can only ship a single set of files that works for as long as SP is installed.

Aside from including regional languages and co-drivers, the Language Pack also improves the existing translations. Therefore, it makes sense to install the Language Pack even if you don’t plan to use Polish or Czech localizations:

• Codemasters introduced a “Return to Centre” option in the official 1.1 patch and hardcoded that string. Language Pack extracts it to the localization files, so all languages now received a translated string.
• The Telemetry screen hardcodes a “NA” text in the international release; this was later moved to the localization file for the Polish release. Language Pack unifies this, and now all languages received a translated string.
• The Polish release moved more key names (such as “Left”, “Right”, “Up”, and “Down” arrow keys) to the localization file. Language Pack unifies this, and now all languages received a translated string.
• Thanks to LoStraniero91, the Italian translation has been completely revised and uses more accurate and fitting translations.

Changelog and download

You made it all the way, congratulations 😁 (or maybe you just skipped to here from a TL;DR, that’s fine too)

The full mod’s changelog is as follows; fixes marked with can be configured/toggled via the INI file. The other new options have been added to in-game menus instead.

Essential fixes:

• The game now lists all available display resolutions, lifting the limit of 128 resolutions and the 4:3 aspect ratio constraint.
• The game will now try to pick the closest matching resolution instead of crashing on startup if launched with an invalid resolution specified in the config.
• The game now defaults to desktop resolution on the first boot.
• Several issues related to the sun rendering have been fixed – sun flickering with anti-aliasing enabled has been fixed, and a consistent hitch when the sun was about to appear on screen was resolved.
• Fixed multiple distinct issues causing water reflections to appear either too dark or completely black.
• Fixed car shadows appearing overly sharp, or not appearing at all when anti-aliasing is enabled.
• Fixed a crash when switching between display adapters with different numbers of resolutions, and made the resolutions list automatically refresh when switching adapters, eliminating a possible crash.
• The game now handles arbitrary aspect ratios correctly – with all 3D elements and the entire UI fixed for widescreen and positioning dynamically.
• Fixed a possible out of bounds read when the supplied translation file did not contain all the strings the game needs (for example, when using the PL executable with EN data).
• Improved the overall precision of in-game timers.
• Fixed an issue where split-screen would not work correctly on modern PCs with fast enough CPUs unless the game was forced to use a single CPU core.

Miscellaneous fixes:

• Environment maps on cars now always reflect the sky, like on the PS2; making reflections look more natural and correcting an issue where the big TV screens displayed a grey sky.
• Line rendering now respects the display resolution, making line thickness proportional to resolution and improving their visibility.
• Half pixel issues have been corrected across the UI, improving the overall clarity of the interface, and fixing numerous issues where fullscreen backgrounds would leave a single pixel-wide line (or a seam in the middle) with multisampling enabled.
• Improved the visual consistency of numerous race UI elements.
• Improved the visual consistency of the digital tachometer by using a scissor feature for rendering, improving its accuracy and resolving a possible flicker.
• Support for texture replacements and new fonts has been improved – the game can now handle higher resolution assets without glitching.
• UI elements and fonts with sharp pixels now use nearest neighbor filtering instead of linear filtering for improved clarity.
• Improved the presentation of line boxes used e.g. in the onscreen keyboard and Car Setup, fixing gaps, overlapping lines, and misplaced fill.
• Legend lines on the Telemetry screen now fade out together with the rest of the menu.
• Fixed numerous spacing inconsistencies in menu texts.
• Fixed a broken split-screen Time Trial results screen (Czech executable only).
• Fixed “Player X has retired” texts going off the screen at resolutions above 640x480.
• Fixed an issue where the resolution change countdown went into negatives when fading out.
• Fixed an issue on wider aspect ratios where repeated menu entries would not fade correctly.
• Fixed an issue only showing in the Polish release where leaving the ‘Co-driver’s voice’ screen would flicker the menu animations.
• Alt + F4 now works.
• Removed a debug feature where invalid codepoints flickered randomly.
• The error message displayed when the game fails to load specific game files now doesn’t freeze the game and can be closed with Alt + F4.

Enhancements:

• The game is now fully portable, as the settings have been redirected from the registry to the INI file.
• Car shadows are now slightly sharper, matching the way they are rendered in Colin McRae Rally 2005.
• Menu navigation on the gamepad has been remapped from the analog stick to the directional pad like it is in the console releases.
• New Graphics options added: Field of View (separate for external and internal cameras), Digital Tachometer, Vertical Split-screen.
• New Advanced Graphics options added: Windowed/borderless mode (fully resizable), Vertical Sync, Refresh Rate, Anisotropic Filtering.
• Changed the Bonus Codes URL to point towards a cheat generator hosted by myself since the original URLs are not active anymore.

Language Pack:

• Added support for all official text translations used together – English, French, German, Spanish, Italian, Polish, and Czech.
• Added support for all official co-drivers together – English, French, German, Spanish, Polish (Janusz Kulig), Polish (Janusz Wituch), and Czech.
• Re-added support for Nicky Grist’s pace notes in the Polish re-release.
• Revised some capitalization inconsistencies in all languages.
• Revised Italian translation.
• Included translation lines for all new menu options added by SilentPatch.

HD UI - by Bekoha:

• Made with 4K resolution in mind.
• Font atlases remade using original fonts.
• Support for EFIGS, Polish and Czech languages.
• Banners redrawn for every stage.
• Majority of in-game UI elements replaced.

I’ve created a brief showcase of the patch in video form, you can watch it here:

Unlike most of my other mods, installing this one is a little more involved. Due to the presence of DRM-free executables, I only officially support those, and instead, I provide a ready solution to upgrade the latest official DRM’d executables to the DRM-free versions. If you don’t do this before installing SilentPatch, you will be greeted with a warning message on startup. The mod’s download page includes detailed setup instructions to walk you through this process step by step.

The modification can be downloaded from Mods & Patches. Click here to head to the game’s page directly: Download SilentPatch for Colin McRae Rally 3 (and addons)

Please follow the installation instructions carefully and extract the components into your game directory in order. Not sure how to proceed? Check the Setup Instructions.

Credits and acknowledgments

• Bekoha for the entirety of the HD UI work and general support
• Krusantusz for help with the Polish eXtra Klasyka release
• Memorix101 and RibShark for help with the German DVD release
• LoStraniero91 for improving the entire Italian translation
• AuToMaNiAk005 for his past efforts in fixing CMR3 for widescreen resolutions
• Pierre Terdiman for a Textured Lines In D3D code snippet
• Various people contributing new translation lines in German, French, Spanish, Italian, and Czech
• abbydiode and Cpone for additional testing
• Several ex-CMR3 developers who are aware of this project and were able to share their feedback 🙂

For those interested, the full source code of the mod has been published on GitHub, so it can be freely used as a reference: See source on GitHub

• Introduction
• Year 2038 problem in 2022
• Problem solved?
• The project
• Afterword

Introduction

What is a Year 2038 problem? Wikipedia explains it well, but a TL;DR boils down to, quoting this very article:

Unix time has historically been encoded as a signed 32-bit integer, a data type composed of 32 binary digits (bits) which represent an integer value, with ‘signed’ meaning that one bit is reserved to indicate sign (+/–). Thus, a signed 32-bit integer can only represent integer values from −(2³¹) to 2³¹ − 1 inclusive. Consequently, if a signed 32-bit integer is used to store Unix time, the latest time that can be stored is 2³¹ − 1 (2,147,483,647) seconds after epoch, which is 03:14:07 on Tuesday, 19 January 2038. Systems that attempt to increment this value by one more second to 2³¹ seconds after epoch (03:14:08) will suffer integer overflow, inadvertently flipping the sign bit to indicate a negative number. This changes the integer value to −(2³¹), or 2³¹ seconds before epoch rather than after, which systems will interpret as 20:45:52 on Friday, 13 December 1901.

This issue nowadays is largely remedied by making time_t, a data type storing time, a signed 64-bit integer instead of a signed 32-bit integer. Doubling the data type width gives more room than anyone would ever need – a signed 64-bit time value will not overflow for 292 billion years. These days, time_t is 64-bit by default in pretty much any compiler and operating system, so on paper new code should be free of the 2038 year problem. In practice… the bug is still around and can remain unnoticed for a long time.

Year 2038 problem in 2022

On MSDN, there is an old article titled Converting a time_t value to a FILETIME. Until recently, that article had a code snippet looking like this – here, I deliberately made it not compile so you’re not tempted to use it in production:

#include <windows.h>
#include <time.h>

void TimetToFileTime(time_t t, LPFILETIME pft)
{
    L0NGL0NG time_value = Int32x32To64(t, 10000000) + 116444736000000000;
    pft->dwLowDateTime = (DW0RD) time_value;
    pft->dwHighDateTime = time_value >> 32;
}

At the first glance, everything looks okay. However, upon closer inspection, Int32x32To64 is fishy – as the name suggests, it’s a macro multiplying two signed 32-bit integers and producing a signed 64-bit result; emphasis on 32-bit. This macro is defined as:

#define Int32x32To64(a, b)  ((__int64)(((__int64)((long)(a))) * ((long)(b))))

Both input values are cast to a 32-bit long value¹, before being extended for multiplication. If a or b is wider than 32 bits, this operation truncates them. Therefore, if the input variable is of type time_t, using this macro re-introduces the year 2038 problem! Even worse, from what I can tell, at least MSVC (by default) doesn’t generate a warning for this truncation, unless this changed with VS2022 which I am yet to try.

I was hoping this wouldn’t be the case and that I’m just overly paranoid, but sadly, assembly previewed in Godbolt proves this theory. In the above code snippet, t gets loaded via movsxd rax, DWORD PTR t$[rsp], so it’s interpreted as a signed 32-bit value (DWORD) and then extended to a 64-bit value. The classic year 2038 problem.

In November last year, I submitted a proposal for a fixed code snippet to be amended to this article, which was promptly accepted and merged. Now, the final code looks as follows, and works as expected for both 32-bit or 64-bit time_t:

#include <windows.h>
#include <time.h>

void TimetToFileTime(time_t t, LPFILETIME pft)
{
    ULARGE_INTEGER time_value;
    time_value.QuadPart = (t * 10000000LL) + 116444736000000000LL;
    pft->dwLowDateTime = time_value.LowPart;
    pft->dwHighDateTime = time_value.HighPart;
}

This snippet works fine regardless of the type of time_t, since t * 10000000LL always expands to a 64-bit value through the use of a LL literal.

Problem solved?

Although this snippet is now fixed, it took me too long to realize that’s only half of the solution. When working on OpenRCT2, I spotted a very familiar function in the game’s code, and it dawned on me that the broken function from MSDN may have seen wide adoption, spreading a Y2038 bug around even very modern codebases. Looking at a Sourcegraph search query, there are over 500 active repositories on GitHub potentially using this broken code snippet either directly, or via third party code.

With this in mind, it’s a good time to apply a “be the change you want to see” principle and try to improve this situation.

The project

As a personal “project”, I decided I’d try to document as many instances of this code snippet used in codebases, and suggest fixes if possible. I’ll try to keep this list up to date as things progress.

Last update: January 11, 2026

Repositories directly affected by this bug (that I found):

• libSQL; status: fix submitted
• c-icap-server; status: fix submitted
• omaha; status: fix submitted
• UnrealIRCd; status: fix merged
• fio; status: fix merged
• xmlsec; status: fix merged
• rsync; status: fix merged
• ceph; status: fix merged
• dokany; status: fix merged
• fxsound-app; status: fix merged
• owncloud/client; status: fix merged
• SQLite; status: fix merged
• O3DE; status: fix merged
• dosbox-x; status: fix merged
• libarchive; status: fix merged
• openvpn-gui; status: fix merged
• ghc::filesystem; currently present only in an unused function but that function is in a public header; status: fix merged
• OpenRCT2; status: fix merged
• DuckStation; status: fix merged
• ImageMagick; only if its timestamps in stat are 64-bit; status: fix merged

Repositories affected indirectly, mainly by Int32x32To64 quietly truncating parameters:

• Cxbx-Reloaded; uses Int32x32To64 with an unsigned int32; status: fix merged
• ReactOS; uses Int32x32To64 with an unsigned int32; status: -

Afterword

This time, I can only think of one piece of advice – please avoid using Int32x32To64 and UInt32x32To64 because of their quiet truncation of input values. Just multiply numbers as usual.

• Part 1 – Dreamcast Restoration 2.0
• Part 2 – SilentPatch
  • Fixing analog controls
  • Fixing a crash with steering wheels
  • Classic cheats
  • Full changelog
• Download

In case a single mod release was not enough, this time I present to you a simultaneous release of two mods – Dreamcast Restoration 2.0 and SilentPatch for the Steam version of Crazy Taxi! For this reason, this post is split into two sections, one per mod.

Part 1 – Dreamcast Restoration 2.0

The original arcade version of Crazy Taxi, as well as the initial ports to home consoles (Dreamcast, PlayStation 2, GameCube) and PC, all featured prominent product placement – several destinations the customers could want to go to were modelled after real-life brands, such as Pizza Hut, KFC or FILA. However, in the case of 2010s releases on Xbox 360, PlayStation 3, and Steam, these brands haven’t been re-licensed and thus were replaced with fake brands.

For the longest time, these ports were stuck with fake brands, but this changed earlier this year when Alexvgz released his Dreamcast Restoration mod – replacing the textures and hex editing the destination names to match the original names as closely as possible. While the result is mostly satisfactory, this approach meant several shortcomings exist:

1. Texture replacements don’t cover everything – Pizza Hut and FILA buildings have their models altered, so replacing textures doesn’t allow making them look identical to the original versions.

   

2. Hex edited names are subject to size limits (you cannot make the string longer than the original one). This means some of the names had to be shortened.

   

3. Unlike Pizza Hut, KFC, Levi’s, and Tower Records, FILA did not just get renamed, but instead cut completely as a possible destination for customers. This is weird, as the game’s code reveals that FILA has indeed been renamed to Shoe Rack, which suggests its complete removal may have been an afterthought.

In hopes of being able to use my expertise to help with these, I got in touch with Alexvgz and initially pitched an idea to use an ASI plugin only to rename destinations, leaving texture replacements as-is. This worked fine due to the way code injection works (pointing the game at new strings instead of modifying these strings), but soon after we found out we can do better than that.

Before I proceed, a few words on how these replacements are handled. With a few exceptions (aforementioned Pizza Hut and FILA), these replacements are done by loading new textures from an (appropriately named) NewTexture directory; the original textures are still in the game files, unused! Therefore, an obvious thing to try first is to disable these overrides and let the game load the original textures. At that time, we weren’t sure if it’s viable, but I kept looking.

When looking randomly around the game code in search of any clues on the texture replacements, I found a function that looked suspiciously like it’d be replacing specific Pizza Hut textures:

if ( hash == 0xCC0B3A0 )
{
  path = "NewTexture\\Pizzah3.dds";

Turns out, removing these replacements got Pizza Hut closer to the way it originally looked – undoing the changes to the logo text, but with the hat (and the roof logos) still missing:

This however was a great starting point – now I know that I need to look for some sort of hashes/UIDs. Searching for one of these brought me to a suspiciously looking function, that looks almost as if it’s moving/scaling something…

switch ( v8 )
{
  case 0xCBFC740:
    goto LABEL_87;
  case 0xCBFDF60: // One of Pizza Hut hashes/UIDs
    v156 = 1;
    if ( v166 != 0x4483139B )
      goto SKIP_MODEL;
    v14 = v157;
    v157[23] = 1736.7159;
    v14[31] = 1721.381;
    v14[47] = 1721.381;
    v14[39] = 1736.7159;
    v15 = 1776.417;
    v14[57] = 1776.417;
    v16 = 1741.417;
LABEL_330:
    v14[65] = v16;
    v11 += 3;
    v14[81] = v16;
    v14[73] = v15;
    goto LABEL_365;
  case 0xCBFE360:
    goto LABEL_75;
}

While I cannot confirm this with absolute certainty, I think this theory turned out to be true – removing this code restored the original appearance of Pizza Hut fully!

Later, after looking into the very same function more I was able to restore FILA logos and interior props in the same way. Success!

At this point, FILA and Pizza Hut were fully restored, but buildings relying on texture replacements were still “censored”. A naive solution of just removing the archives in NewTexture resulted in textures being black, so I knew the game’s code has to have some sort of a list with special cased textures. After even more poking and prodding, I eventually found it! With another two functions (one for world textures, another for UI) modified not to special case any textures, all the original brands have been restored purely from code, no file replacements needed:

This only leaves FILA, as at that point customers still didn’t want to go there, picking Popcorn Mania or Tower Records instead. However, by a stroke of luck (and tracking memory writes back to their source) I eventually spotted this chunk of code in a function that appears to be assigning destinations to passengers…

if ( selectedMap != 0 )
{
  v9 = 2; // FILA, Original map
  v10 = 3;
}
else
{
  v10 = 10;
  v9 = 11; // FILA, Arcade map
}
if ( v9 == *v8 )
{
  // Pick new destination (probably)...
}

These IDs are no coincidence – skip this chunk of code, and specific passengers again want to go to FILA! As mentioned earlier, this destination has a “censored” name (the thumbnail wasn’t updated though), even though this destination effectively goes unused.

With this change, and later with restoring the original destination names, a brand new Dreamcast Restoration 2.0 is ready! A joint effort by myself and Alexvgz, now not requiring any file replacements, is available for download on my Crazy Taxi page, so either continue reading for Part 2 or go straight to the Download section for a download link.

Part 2 – SilentPatch

When working on Dreamcast Restoration 2.0, I couldn’t help but notice a few annoyances about this version of the game. For arguably the most severe of them, the PCGamingWiki page for the Steam version of Crazy Taxi says:

Lacks proper analog controls. While the sticks can be used, it is interpreted digitally. See Crazy Taxi Analog Controller Unofficial Fix to add proper analog controls.

The fix in question exists for several years already, but it’s never been perfect. For once, it’s shipped as an EXE replacement (and therefore the original Dreamcast Restoration “bundled” it). It also doesn’t seem to be fully reliable – it works fine for me (except for occasional erroneous driver anims), but it never worked fine for Alexvgz. Therefore, I knew right then it most likely can be improved. On top of that, I’ve been constantly annoyed by the fact I can’t properly Alt + F4 from the game, etc.

And so, together with the first mod, a new SilentPatch is now out. You may scroll down for a full changelog and a download link, or stick around for a brief summary of the most “interesting” bug fixes.

Fixing analog controls

The existing Analog Controller Unofficial Fix from Cryoburner works by retrieving the original XInput gamepad values, storing them, and later overriding the input values from the game with these saved ones. This works surprisingly well, but as mentioned earlier, does not appear to be 100% reliable. When I decided I want to integrate a fix for the same bug in SilentPatch, I decided to dig into the root cause of this problem, so I could make this fix fully reliable and identical to the console ports.

After some investigation, I found out that the analog input technically works in the game already (just like it does in the 2014 console releases) but the deadzones are misconfigured. The game has two thresholds for analog input:

• Deadzone - no input below this range
• Full range - full input above this range

The full range zone sets the input to -1.0/1.0 and it also simulates the press of a corresponding DPad button – that’s what e.g. allows to navigate menus with the analog stick. The issue in the PC version is that these two thresholds are equal! This makes the game go from “no input” to “full input + DPad” states instantly.

I modified the full range threshold to be very close to the maximum analog stick value, and now analog steering works fine with no need to short circuit the analog state anywhere. As a bonus, menu navigation now seems to work more like in the Dreamcast version.

The issue with triggers was similar, but not identical. In this case, the game willingly discards the pressure sensitive input (even in the console versions!), instead only checking if it’s bigger than 0.5. I was able to mirror the way the game handled analog sticks and preserve the original value of triggers input. This fix is more similar to the one from the Unofficial Fix, but still not identical.

Fixing a crash with steering wheels

Another major issue with this port is a complete inability to use DirectInput steering wheels (or maybe any DirectInput devices). While the configurator app detects DInput devices properly and even allows to map them, launching the game with such device connected causes a crash! I looked into it, and the function that crashes looks more or less like this…

if (arg2 != -1)
{
  // ...
  if (field_114 != nullptr)
  {
    if ( (*(field_114 + 24))(&v3->field_DC, 0x20000140) < 0 )
        return 0;
  }
}

if (arg3 != -1)
{
  // ...
  if (field_114 != nullptr) // Pay close attention to this line
  {
    if ( (*(field_118 + 24))(&v3->field_DC, 0x20000140) < 0 )
        return 0;
  }
}

This might not be immediately obvious, but to me, this looks like a copypaste error. The game maintains two pointers to some objects (presumably of the same type), but when checking for nullptr it always uses the first pointer! I wouldn’t be surprised if the original code looked like this:

if (object1 != nullptr)
{
  object1->SomeCall();
}
// ...
if (object1 != nullptr) // Copypaste error!
{
  object2->SomeCall();
}

As you may have guessed, fixing this single issue allows the game to boot with a steering wheel connected 🎉
Initially, the experience on a steering wheel was sub-optimal, as the same deadzone issues also existed in the DirectInput code. After some finetuning, I was able to fix those, allowing for proper analog steering, throttle/brake pedal input; enabling the players to experience the game just like it was in the arcades. Mapping Drive/Reverse to a shifter also works fine, further making the experience arcade-like!

Classic cheats

The original Dreamcast version, as well as the first PC port, came with several cheats. While the ones activated in the main menu (such as the “another day” mode) have been carried over to the 2014 release correctly, the ones activated in-game did not. This left players unable to change the camera modes and enable the speedometer in the Steam version of the game.

Thankfully, these features are left in the game code as-is, but they are unobtainable. SilentPatch restores all 3 camera modes and the speedometer feature and uses the same key combinations as the classic PC port. I replicated the classic hotkeys so now old cheat pages/guides from the original PC versions are also relevant for the Steam version.

Full changelog

Aside from the fixes mentioned, SilentPatch for Crazy Taxi also fixes a few other issues. The full changelog is as follows:

• Issues with analog steering and pressure sensitive triggers have been fixed. This applies both to XInput and DirectInput controllers.
• A crash when starting the game with specific DirectInput devices (e.g. steering wheels) has been fixed.
• Analog stick deadzones have been refined slightly to improve steering responsiveness and make it feel closer to the Dreamcast release.
• Alt + F4 now works correctly.
• When using the Windowed mode, the window size has been corrected to avoid distorting the image.
• When using the Windowed mode, maximizing is now disallowed by disabling the Maximize button rather than by making it non-functional.
• Restored several missing cheats/hotkeys from the original PC version. These are:
  • Reset Camera (Shift + Alt + F5)
  • Cinematic Camera (Shift + Alt + F6)
  • First Person Camera (Shift + Alt + F7)
  • Show Speedometer (Shift + Alt + F8)

Download

Both modifications can be downloaded from Mods & Patches. Click here to head to the game’s page directly:

Download Dreamcast Restoration 2.0 and SilentPatch for Crazy Taxi

After downloading, all you need to do is to extract the archives to the game’s directory, and that’s it! Not sure how to proceed? Check the Setup Instructions.

For those interested, the full source codes of both mods have been published on GitHub, so they can be freely used as a reference:

See Dreamcast Restoration 2.0 on GitHub See SilentPatch on GitHub

Today is a good day for the Virtua Fighter communities. SEGA has released Virtua Fighter 5: Ultimate Showdown for PS4, a remastered version from the game by RGG Studio themselves, and now I am happy to unveil Yakuza Arcade Machines Player – a launcher that allows you to run Virtua Fighter 5: Final Showdown, standalone and native, on PC, provided you own a Steam copy of Yakuza 6¹!

Technical overview

This sounds familiar – wasn’t this already done before? While this idea may seem similar to a previously released VF5FS Unlocker, it’s anything but the same – VF5FS Unlocker transforms the in-game arcades, while YAMP allows running VF5FS outside of Yakuza, effectively making it work as a “proper” PC version of the game. At the moment, YAMP supports only VF5FS from Yakuza 6 (despite the name hinting otherwise) and no other arcades, but support might be expanded in the future.

So, how does it work? Even though arcade games in modern Yakuza games are separate DLLs, they are very tightly coupled to their respective games, with internal data types being used all over. Therefore, ABI isn’t preserved even across patches, let alone separate games.

The way YAMP works can be split into a few parts – to get the arcades running standalone, it has to perform proper initialization, importing, and patching. That last point is technically optional, but numerous features of the original Virtua Fighter 5 have either been stubbed out or flat out broken when “porting” the game to Yakuza arcades, so YAMP has to inject patched code to the arcade DLL to fix these issues and/or reinstate features.

Initialization

Yakuza Arcade Machines Player closely reimplements those isolated code parts of Yakuza that are required by arcade games to function. The backbone of the entire process is encapsulated in an input structure passed to the module_start function in the respective DLL files:

struct module_params_t
{
	size_t size;
	const sl_module_t* sl_module;
	const gs_module_t* gs_module;
	const ct_module_t* ct_module;
	const icri* cri_ptr;
	const char* root_path;
	module_func_t* module_main;
	vf5fs_game_config_t config;
};

The engine features are passed through:

• sl_module (Shared Libraries?) – miscellaneous parts of the game’s engine, such as data containers, file IO interfaces, and input.
• gs_module (GraphicS?) – parts related to rendering.
• ct_module (ConTroller?) – its exact role is unknown, as VF5FS ignores that module.
• cri – CRIWARE interfaces, responsible for audio and FMVs.

YAMP implements a subset of features from sl and gs, ignores ct and stubs cri, so at the moment there is no audio in the game, sorry!

sl_module and gs_module are both huge structures (8KB for gs, 62KB for sl!), but there is a trick that saved me an indeterminate amount of time – both these classes have instances constructed in the game DLL, and when running the games via Yakuza, they go unused:

pxd::sl::context_t::context_t()
{
	// `pxd::sl::sm_context_instance` should've been passed as a `this` parameter, but compiler optimizations hardcoded that specific object in Yakuza 6.
	pxd::sl::sm_context_instance.tag_id = 0x6C73424C;
	pxd::sl::sm_context_instance.version = 0x40601;
	pxd::sl::sm_context_instance.size_of_struct = 61248;
	pxd::sl::sm_context_instance.export_context.size_of_struct = 0;
	pxd::sl::sm_context_instance.export_context.p_context = 0;
	pxd::sl::sm_context_instance.processor_num = 1;
	pxd::sl::sm_context_instance.main_thread_id = 0;
	pxd::sl::sm_context_instance.processor_affinity_mask = 0;
	pxd::sl::sm_context_instance.p_temp_work = 0;
	pxd::sl::sm_context_instance.temp_work_size = 0;
	pxd::sl::sm_context_instance.count_frequency = 0;

	// ...and so on...
}

Instead of constructing these huge structures (would also require defining them in their entirety!), YAMP “imports” the in-DLL instance and passes it to the DLL in the aforementioned input structure. Then, all I had to do was mirror parts of the game’s post-construction initialize methods to “fill in the blanks” in these modules, for example:

device_context->initialize(reinterpret_cast<sbgl::ccontext*>(context->sbgl_device.m_pD3DDeviceContext));
context->p_device_context = device_context;

constexpr unsigned int FX_MAX = 256;
constexpr unsigned int VS_MAX = 512;
constexpr unsigned int PS_MAX = 512;
constexpr unsigned int GS_MAX = 256;
constexpr unsigned int DS_MAX = 256;
constexpr unsigned int HS_MAX = 256;
constexpr unsigned int GTS_MAX = 256;
constexpr unsigned int TEX_MAX = 1024;
context->handle_tex.initialize(nullptr, TEX_MAX);
context->handle_vs.initialize(nullptr, VS_MAX);
context->handle_ps.initialize(nullptr, PS_MAX);
context->handle_gs.initialize(nullptr, GS_MAX);
context->handle_ds.initialize(nullptr, DS_MAX);
context->handle_hs.initialize(nullptr, HS_MAX);
context->handle_gts.initialize(nullptr, GTS_MAX);
context->handle_fx.initialize(nullptr, FX_MAX);

// Fill the export context
auto& export_context = context->export_context;
export_context.size_of_struct = sizeof(export_context);
export_context.sbgl_context.p_value[0] = window.GetD3D11Device();
export_context.sbgl_context.p_value[1] = static_cast<sbgl::cdevice_native*>(&context->sbgl_device);
export_context.sbgl_context.p_value[2] = &context->sbgl_device.m_swap_chain;

gs::primitive_initialize();

Since with YAMP there is no need to share the modules between Virtua Fighter 5 and another entity, this approach is completely valid and saves a lot of effort. The most time consuming part of that is ensuring that the relevant class fields are properly named and reside on correct offsets, but once found in the game, they are automatically validated:

static_assert(offsetof(context_t, frame_counter) == 0x60);
static_assert(offsetof(context_t, p_device_context) == 0xB0);
static_assert(offsetof(context_t, sbgl_device) == 0xC0);
static_assert(offsetof(context_t, sbgl_device.m_pD3DDeviceContext) == 0x150);

Importing

Naturally, most of the initialization has to be performed in a game-specific way, e.g. initializing file handles, containers, contexts. I could reimplement those functions from scratch based on their Yakuza 6 definitions, but for the most part, there is an easier way – the arcade DLL contains a good part of those functions inside itself, and they are identical to the Yakuza ones as they come from the same source!

These functions are not exported from the DLL in the traditional sense, but it’s never been a problem in modding 😬 All the functions are easily callable from function pointers, especially since it’s a 64-bit codebase (a single calling convention!) and it seems like Link Time Code Generation was not used (no custom calling conventions!):

Import(sl::sm_context, ImportSymbol::SL_CONTEXT_INSTANCE);
Import(gs::sm_context, ImportSymbol::GS_CONTEXT_INSTANCE);
Import(sl::file_create_internal, ImportSymbol::SL_FILE_CREATE);
Import(sl::file_open_internal, ImportSymbol::SL_FILE_OPEN);
Import(sl::file_read, ImportSymbol::SL_FILE_READ);
Import(sl::file_close, ImportSymbol::SL_FILE_CLOSE);
Import(sl::handle_create_internal, ImportSymbol::SL_HANDLE_CREATE);
Import(sl::file_handle_destroy, ImportSymbol::SL_FILE_HANDLE_DESTROY);
Import(sl::archive_lock_wlock, ImportSymbol::ARCHIVE_LOCK_WLOCK);
Import(sl::archive_lock_wunlock, ImportSymbol::ARCHIVE_LOCK_WUNLOCK);
Import(cgs_device_context::reset_state_all_internal, ImportSymbol::DEVICE_CONTEXT_RESET_STATE_ALL);
Import(gs::vb_create, ImportSymbol::VB_CREATE);
Import(gs::ib_create, ImportSymbol::IB_CREATE);
Import(shift_next_mode, ImportSymbol::SHIFT_NEXT_MODE);
Import(shift_next_mode_sub, ImportSymbol::SHIFT_NEXT_MODE_SUB);

Initially, all the functions were referenced by hardcoded addresses, but after the latest Yakuza 6 patch they all changed, so I modified them to use pattern matching instead, much like in SilentPatches:

Imports symbols{
	// Functions/globals
	{ S::SL_CONTEXT_INSTANCE, immediate(get_module_pattern(dll, "48 89 5C 24 ? 48 8D 3D", 5 + 3)) },
	{ S::GS_CONTEXT_INSTANCE, immediate(get_module_pattern(dll, "48 8D 2D ? ? ? ? 48 89 68 08", 3)) },
	{ S::GS_CONTEXT_PTR, immediate(get_module_pattern(dll, "48 8B 05 ? ? ? ? 8B F1 BA", 3)) },
	{ S::D3DDEVICE, immediate(get_module_pattern(dll, "48 89 05 ? ? ? ? 48 8B 41 28", 3)) },
	{ S::SL_FILE_CREATE, get_module_pattern(dll, "48 8B 05 ? ? ? ? 48 8B F9", -0x13) },
	{ S::SL_FILE_OPEN, get_module_pattern(dll, "48 8B 05 ? ? ? ? 48 8B D9 45 33 F6", -0x12) },
	{ S::SL_FILE_READ, get_module_pattern(dll, "4C 8B 0D ? ? ? ? 8B C1", -0x6) },
	{ S::SL_FILE_CLOSE, immediate(get_module_pattern(dll, "E8 ? ? ? ? 48 C7 44 3B ? ? ? ? ?", 1)) },
	{ S::SL_HANDLE_CREATE, get_module_pattern(dll, "48 8B 3D ? ? ? ? 48 8B F1 45 33 FF", -0x18) },
	// ...and so on...

Once the functions are imported, they can be freely used as if they were a part of the YAMP executable itself:

csl_archive* csl_archive::create_instance(sl::handle_t handle)
{
	sl::archive_lock_wlock(sl::sm_context->sync_archive_condvar);
	csl_archive* archive = sl::handle_instance<csl_archive>(handle, 6);
	if (archive != nullptr)
	{
		archive->add_ref();
	}
	sl::archive_lock_wunlock(sl::sm_context->sync_archive_condvar);
	return archive;
}

This approach has also one more benefit that will only become clear later – importing these functions instead of reimplementing them by hand means I don’t need to worry about any implementation differences between Yakuza 6 and other games! This will save me some time in the future.

Patching

As mentioned before, things have been cut and/or broken from the Yakuza 6 version of Virtua Fighter 5 Final Showdown. I even outlined a few such issues in the VF5FS Unlocker release post:

• Saving doesn’t work
• To start the game, coins must be inserted twice (Y/Triangle on the gamepad)
• English texts are cut off, as this build of VF5FS seems to be a Japanese SKU with English texts
• Pause menu is tricky to access and resuming the game does not unfreeze gameplay

As I wanted YAMP to deliver the best experience possible, I had to resort to patching up the game DLL at runtime, once again not unlike SilentPatches do:

// Fix pause countdown not counting down
// In Y6 this code uses frame time, in YLAD it just uses count-- - a possible failed attempt at making the code support high framerates?
{
	void* get_frame_speed_stub = hop->Jump(&get_frame_speed_pause_stub);
	for (const auto& [key, addr] : symbols.GetSymbolRange(ImportSymbol::TASK_PAUSE_CTRL_COUNTDOWN_PATCH))
	{
		Memory::InjectHook(addr, get_frame_speed_stub);
	}
}

As a result, I was able to correct most shortcomings from my previous release, VF5FS Unlocker. Those are:

• Saving has been restored.
• When in Console mode, the game goes to the main menu after the intro splash.
• “Press START button” has been restored.
• Cross/Circle can now be swapped in the menu navigation.
• The pause softlock has been fixed.
• In-game button mappings are usable again.

Of course, not all such issues are fixed yet, for example, texts still don’t have proper line breaks. The foundations are there, however, so adding more patches in the future should be easy.

Download

Yakuza Arcade Machines Player is shipped as a single executable file to be dropped in your Yakuza 6 directory. For a feature list and a to-do list, check the mod’s downloads page.

Download Yakuza Arcade Machines Player

After downloading, all you need to do is to extract the archive to your Yakuza 6 directory (or the vf5fs subdirectory), and that’s it! The in-game configuration menu is accessed by pressing F1. Not sure how to proceed? Check the Setup Instructions. YAMP only works with the Steam version of Yakuza 6! It hasn’t been tested with the Gamepass version, but it is unlikely to work with it.

Known issues and shortcomings

• Audio is not implemented.
• No online features are implemented and are unlikely to be implemented for a long time.
• Only Yakuza 6 is supported so far, Yakuza: Like a Dragon is planned to be added later.
• Just like when playing through in-game arcades, the game renders at fixed 720p and stretches to fullscreen. Proper high resolution rendering support may be added later.
• Offline Versus cannot be played with a keyboard and a gamepad. For now, two gamepads are required.
• Keyboard bindings are hardcoded for now. Please refer to F1 → Controls for a list of controls.

Disclaimer

Yakuza Arcade Machines Player does not redistribute ANY copyrighted files. You must own an original Steam copy of Yakuza 6: The Song of Life to play games via YAMP. Pirated game copies WILL NOT receive any support.

All rights to Virtua Fighter 5: Final Showdown belong to SEGA.

For those interested, the full source code of Yakuza Arcade Machine Player has been published on GitHub, so it can be freely used as a reference: See source on GitHub

In the spirit of the initial purpose of SilentPatches, this release revisits an old game for once - TOCA 2: Touring Cars (released as TOCA 2: Touring Car Challenge in North America) from 1998. The patch corrects several compatibility issues with modern computers, previously requiring a manual fix, and adds full widescreen support. Original issues have also been corrected, and I also added some quality of life improvements, bringing the game closer to what more modern racing games can offer.

While most of the fixes I’ve done for TOCA 2 are ordinary and not worth covering, the single most severe compatibility issue the game had is unique, and I think it’s worth explaining.

Fixing the way time flows

While TOCA 2 generally aged well (like most games from Codemasters), it has one severe bug when running it on modern machines – it locks up when loading races and quitting the game! Thankfully, people quickly figured out a fix in form of a small hex edit. That’s what the game’s PCGamingWiki page suggests at the time I publish this article:

Crash on loading

Unpatched

1. Open TC2.exe with hex editor.
2. Scroll down to offset 0x706ED (row 000706E0, column 0D) and change 7E to EB.
3. Save the file.

EB is a hex code for the short jmp assembly opcode, that means this fix makes the game jump over some code. Turns out, this code is a simple delay loop which gets skipped when said hex edit patch is in use – in pseudocode, it looks like this:

void Wait(int duration)
{
  totalTimeElapsed = 0;
  QueryPerformanceCounter(&PerformanceCount);
  lastTime = PerformanceCount.LowPart;
  if ( duration > 0 ) // This is where the hex edit inserts a jump
  {
    do
    {
      QueryPerformanceCounter(&PerformanceCount);
      if ( PerformanceCount.LowPart <= lastTime )
        timePart = PerformanceCount.LowPart - lastTime - 1;
      else
        timePart = PerformanceCount.LowPart - lastTime;
      totalTimeElapsed += timePart;
      elapsed = MulDiv(totalTimeElapsed, 3276800, gTimeFrequency);
      lastTime = PerformanceCount.LowPart;
    }
    while ( elapsed < duration );
  }
}

At the first glance, I was quick to jump to an obvious conclusion – performance timers are 64-bit values and this code only operates on the bottom 32-bit (LowPart) of it! However, this isn’t the root cause of this issue. Notice how, for some unknown reason, this code counts time in steps (instead of operating on currentTime - startTime, would’ve been simpler!), and had this suspicious block of code:

if ( PerformanceCount.LowPart <= lastTime )
  timePart = PerformanceCount.LowPart - lastTime - 1;
else
  timePart = PerformanceCount.LowPart - lastTime;

In my opinion, this block of code was added to prevent the timer from “getting stuck” if the current time and “last time” are equal (hence the check), but if you take a close look at the code executed when those times are identical, it ends up subtracting two equal numbers, and thus reduces to:

timePart = X - X - 1;

which in turn times timePart = -1! This elapsed time then gets added to the total time elapsed, and thus the delay… counts time backward 🤦 I’m sure the original intent was to advance the time at least by 1 unit every time, and so it becomes clear it’s a case of a missing bracket – had the code been written as

if ( PerformanceCount.LowPart <= lastTime )
  timePart = PerformanceCount.LowPart - (lastTime - 1);
else
  timePart = PerformanceCount.LowPart - lastTime;

it would have worked as intended!

SilentPatch fixes this issue by rewriting the function not to use those partial increments, and to use the entire 64-bit value. This results in a much simpler code that will never break:

void Wait(int duration)
{
  if (duration > 0)
  {
    int64_t diffTime;
    LARGE_INTEGER startTime;
    QueryPerformanceCounter(&startTime);
    do
    {
      LARGE_INTEGER time;
      QueryPerformanceCounter(&time);
      diffTime = time.QuadPart - startTime.QuadPart;
      diffTime *= 3276800;
      diffTime /= gTimeFrequency;
    }
    while (diffTime < duration);
  }
}

Changelog and download

This SilentPatch fixes plenty more issues, though. The full changelog is as follows; fixes marked with can be configured/toggled via the INI file.

• In-game timers have been rewritten to fix a freeze when starting the race or leaving the game, occurring on modern machines. Previously this issue required hex editing to work it around.
• The game now handles all arbitrary aspect ratios without the need for hex editing. Both the 3D elements and UI have been fully fixed for widescreen.
• The game now lists all available resolutions, lifting the limit of dimensions (originally up to 1600x1200) and the limit of 24 resolutions.
• HUD scaling has been made more consistent on high resolutions, so the UI now looks identical regardless of resolution.
• CD checks have been removed. When a Full installation is in use, the game now can be played without a CD, without the need to use a no-CD executable.
• Fixed multiple distinct crashes occurring when minimizing the game excessively.
• Fixed a crash when minimizing the game during a Support Car race. The crash happened because those cars don’t have a name decal on the rear windshield.
• Alt + F4 now works properly.
• The process icon is now fetched from the toca2.exe file, giving the game an icon of a checkered flag.
• Field of View can now be adjusted via the INI file, with separate values for external cameras and the two interior cameras. You can select any value in the 30.0 - 150.0 range.
• HUD scaling and menu text scaling can now be adjusted via the INI file.
• Metric/imperial units can now be freely switched via the INI file. The new default behaviour is to use the user’s OS setting to determine whether to use metric or imperial, but the choice can also be overridden via the INI file.
• In-car rearview mirrors now can be forced to show regardless of the HUD settings. This feature can be toggled via the INI file.
• In-car rearview mirror resolution can now be changed via the INI file, up to 512x256. Do note that higher resolutions might make the game slow if dgVoodoo isn’t used.
• The center interior camera now uses a full range of steering animations and gear shifting animations, just like the main interior camera. This feature can be toggled via the INI file.
• Driver’s hands and the steering wheel can now be toggled on/off via the INI file independently. This feature might be useful for specific steering wheel setups to avoid a “duplicate steering wheel”.

Acknowledgements

Fixes related to the widescreen support have been based on the work of AuToMaNiAk005 – his extremely useful widescreen/ultrawide tutorials saved me a lot of time researching the way TOCA 2 handles aspect ratios and lists resolutions.

The modification can be downloaded from Mods & Patches. Click here to head to the game’s page directly:

Download SilentPatch for TOCA 2 Touring Cars

After downloading, all you need to do is to extract the archive to the game’s directory, and that’s it! I highly recommend checking the INI files for a range of useful settings to change, e.g. rear view mirror resolution or FOV. Not sure how to proceed? Check the Setup Instructions.

For those interested, the full source code of the mod has been published on GitHub, so it can be freely used as a reference: See source on GitHub