Introduction

A few years ago, iRacing was a name reserved for a hardcore, subscription-based sim. Since then, they’ve expanded into publishing different racing games – first ExoCross and World of Outlaws, then NASCAR 25, and now iRacing Arcade. This cartoony simcade spin-off, developed by Original Fire Games, previously known for Circuit Superstars and Karting Superstars, releases on Steam on March 3rd, with console releases following later this year.

I initially didn’t plan to cover this game, but iRacing Motorsport Simulations reached out with a review key, most likely due to my NASCAR 25 coverage, so here we are. I played iRacing Arcade for several hours over the past week, and progressed through multiple seasons of the single-player career, submitted several bug reports and impressions, and benchmarked it.

It is Arcade, but is it iRacing?

Let’s get a few things out of the way: this is not a serious racing game with simplified physics, like TOCA or GRID. What we get here is an experience similar to Circuit Superstars, with a chase camera first introduced in Karting Superstars; whether that’s a good thing or not depends on how much you vibed with the way CS handles. It is best to think of iRacing Arcade as Circuit Superstars 2 with licensed content – and on that front, it delivers.

Coming from Circuit (or Karting) Superstars, you might have a bit of deja-vu: the entirety of the race UI and most UI sounds are reused straight from that game. The overall experience, however, is significantly expanded: a questionable Grand Prix mode with fixed championships is gone; instead, iRacing Arcade provides a brand new calendar-based Career Mode with team management.

The career experience is hands down the best part about this game, and I enjoyed it greatly. The career appears to consist of 7 seasons, although I only finished two so far; I don’t know if the seasons are going to loop after that, or if the career just ends. With each season, more championships open up to the player, and they can choose to participate in them directly, or expand the team with hired drivers and send them to race. There are no restrictions whatsoever: you can participate in all championships personally, delegate them all to the rest of the team (provided you can hire enough drivers, that is), or simply skip championships you are no longer interested in. You can invest in your own fleet of cars or rely on rentals, in exchange for a part of the prize money. The game gives you all the freedom you need.

When you’re not racing, you’re left to explore another interesting addition to the career loop: campus building. In this mode, stylized not unlike a very simplified version of a Two Point game, players get to expand their team campus with bigger garages, workshops, R&D teams, and more.

Decorations and the road layout are only for show, as this map is not interactive, and the player cannot visit it on foot or in a car. Building better facilities lets the player hire more drivers, buy extra cars, and provides better Boosts. Boosts are yet another addition in Circuit Superstars 2 iRacing Arcade, and they work as “perks” for the player: providing benefits like a permanent or a temporary increase of grip or engine power, more leeway regarding time penalties, extra fuel given at the last lap, or… the big head mode.

I wish things were different

So far, I’ve been really positive about the game, because at the core level, iRacing Arcade delivers exactly on what it promises: lighthearted, yet not simplistic racing in a cartoony setting. The gameplay loop keeps me engaged as I get to alternate between multiple different racing classes, and the driving model clicks. But…

If you played Circuit Superstars, you probably remember how varied the car selection was. Compacts, touring cars, muscle cars, stock cars, buggies, race trucks… iRacing Arcade throws that all away in favour of 8 cars. Yes, eight: two licensed road cars, a generic touring car, three generic open wheelers, a generic LMP, and a generic Hypercar. When the iRacing acquisition was announced, the hope was that their reputation and influence could help Original Fire Games integrate more licensed content in their games, but the result seems to have been the opposite – the car selection was the best part of Circuit Superstars, and it’s the worst part of iRacing Arcade.

It’s an abysmal decision, and one I can’t understand at all: if most of the vehicles in the game are not licensed, why are we not seeing more of them? Why don’t we get an opportunity to race stock cars, muscle cars, or trucks? This is not an Early Access release or a solo-dev indie game made on a shoestring budget – so this car selection is simply not enough. And even that is not a good excuse: for comparison, the recently released Super Woden: Rally Edge is a solo-dev indie game with no licensed vehicles, but it has 90 cars.

At least the track selection is more varied: 12 licensed courses, including some tracks less commonly seen in games, and two fictional circuits returning from Circuit Superstars. They each offer only a single layout, but still, it’s not the worst.

There are a few other things that didn’t sit right with me. Just like in Circuit Superstars, difficulty is all over the place: sometimes I struggle to finish in the Top 3 on a Pro difficulty, while in other races I comfortably win on Master. The AI competitiveness seems to vary wildly per class: they are just right in Fiat 500s and Porsches, really easy in Touring Cars, a little too difficult in open wheelers. Building a “team brand” is difficult, as the game lacks any presets for car and driver colors; if you want consistency in your fleet, you are in for a lot of manual color adjustments. The campus feature is interesting, but a little underutilized: the decorative elements are pointless, scrolling around this area with a gamepad is unintuitive, and there isn’t much you can do with that campus; is it too much to ask for to be able to drive around it, or have people walk around it? There is no photo mode or even an ability to hide the UI in replays, so you can’t take nice screenshots easily. There is no split-screen either, even though a game like this is an ideal candidate for local multiplayer. It is said that split-screen is going to arrive with the console versions, but it’s unconfirmed whether it’s going to be available on PC too.

None of those drawbacks make iRacing Arcade feel like an unfinished experience, but it could have been something more. I’ll keep my fingers crossed for post-launch support, as most of my complaints could be addressed in future updates. To my knowledge, there was no official communication on whether the game will be expanded or not, so all we can do is wait and see.

The technicalities

iRacing Arcade is in a slightly different league from the other games I’ve reviewed in the past. It runs on Unity 6, so none of my usual technical comments apply here. The game is significantly simpler and more lightweight because of this, and the minimum requirements indicate that the Steam Deck LCD is considered to be a minimum spec machine that they support. I threw the game at two setups:

• Intel Core i9-12900K with an NVIDIA GeForce RTX 5070 Ti.
• Intel Core i7-6700K with an NVIDIA GeForce GTX 1070.

For my impressions, I’ve been using exclusively the primary PC. However, for benchmarking, I used both. All screenshots in this article were taken on the max details, unless stated otherwise.

Graphics options and presets

iRacing Arcade goes beyond a single “Low/Medium/High Details” selection commonly found in Unity games:

There are no upscalers or any “fancy” options, but honestly, this game doesn’t need any. That said, I wish the Anti-Aliasing options were better described, as I don’t know what kind of an AA solution the game uses, and even on High, it can appear a little jagged. It also appears to always run in a borderless window and caps the resolution at a desktop resolution, so I was unable to use DSR.

iRacing Arcade doesn’t have presets; instead, most options can be individually turned on/off and changed between Low/Medium/High. For Lowest, I turned everything as low as possible. For Medium, everything is on Medium. For High, everything is maxed. Those “presets” correspond to what I later used in benchmarks.

Disabling the Volumetric Fog and Bloom makes the biggest visual difference and is the reason why the Lowest screenshot looks so lifeless. Other options simply increase the quality of particular effects like shadows and Anti-Aliasing, so they should only be reduced if you need to reclaim performance. However, with this being a Unity game, you’re unlikely to need to turn down the details, unless you’re using a Steam Deck or another handheld.

Benchmarks

For my benchmark, I utilized the in-game Replay option and recorded a race closely resembling a setup from the public demo of the game; this way, you may easily compare my results with yours if you try that demo. The benchmark sampled 30 seconds of data from the very start of a race in a Porsche 911 GT3 Cup on Tsukuba Circuit.

Since I was unable to use DSR, I ran the benchmark at 1080p on the RTX 5070 Ti machine and at 720p on the GTX 1070 machine. I ran the benchmarks with the following settings:

To be fair, looking at these results, benchmarking this game feels like a pointless endeavour. These results tell me something important, though: the official minimum requirements of i5-7500 and GTX 1070 Ti are most likely too conservative, and the game can run just fine on lower-end hardware. If it wasn’t for one important detail, I suspect that a GTX 1050 could have reached 1080p at 60 FPS on the highest details without much trouble…

…except the game does something strange on the initial startup: it seems to preload all the assets to VRAM, loading over 8GB of data!

I haven’t noticed any issues caused by this on the 8GB GTX 1070, but I imagine it might make 4/6GB VRAM cards rather unhappy. I’m not sure if this is intentional or if it’s simply a mistake in the resource management, so I forwarded this as a bug report.

Steam Deck

At the time of writing this review, iRacing Arcade is not Deck Verified yet, but it’s clear that it was developed with Deck in mind, as the minimum system requirements state:

Additional Notes: LCD Steam Deck equivalent or higher.

Launching the game on a Deck, it defaults to a mix of Low and Medium details, and that preset reaches 60 FPS with ease and some headroom. I did spot one spot where performance tanked to 40 FPS, but I forwarded this to the developers as a bug report, as this spot seems to be a clear outlier. Notice that VRAM usage hovers around 8GB, just like I remarked in the previous section.

If you need more battery life, the game can target 30 FPS and 40 FPS with no issues, making it an excellent game to play on the go. Steam Cloud is not used, but a cloud sync is set up – the game uses some sort of a custom solution (possibly PlayFab).

To buy or to skip?

I liked playing Circuit Superstars, and I like playing iRacing Arcade. I try not to lock myself to a specific sub-genre of racing games and enjoy experiencing different approaches, and both those games are very much different than a typical racer. That said, with the game launching with such a narrow range of cars, I’d not blame anyone for thinking that $24.99 is too steep for the amount of content it offers. Diverse championships in the career mode can only help so much if you keep using the same few cars over and over, after all.

Introduction

On November 25th, Project Motor Racing was released on PC and consoles. From the player’s perspective, it’s just yet another racing sim like many others. But, from my perspective, this game attempts something exceptional: initially started under the name GTRevival and developed largely by the same people as the Project CARS games, powered by Unreal Engine 5, the project got restarted once Straight4 secured a publishing deal with GIANTS Software (of the Farming Simulator games); the project got renamed to Project Motor Racing, and instead of UE5, it uses… the GIANTS Engine.

I can’t think of many (if any at all) other racing games that used UE5 and moved away from it, so obviously, I couldn’t pass on the opportunity to dive into it. Last week, I received a review copy from GIANTS Software, so I can check it and see what came out of this unorthodox switch.

Gameplay impressions

As the game is already out and you’ve likely seen the other reviews, that are generally strongly unfavourable, I will flip the structure and start this section with my final impression – I don’t think anything in PMR is “terrible” (with one exception, to be outlined below), but the problem is that too many parts feel unfinished, untested, or partly broken; in my eyes, the game’s current bad reception is a textbook definition of “a death by a thousand cuts.”

When I checked the game out on Friday, I felt like I’m beta testing a game that is finished in design and content, but months away from release: UI bugs are rampant, some options flat out don’t work and you can’t reset some of them them back to default after changing, menu controller navigation is lacking in many aspects, AI behaviour seems inconsistent and unbalanced between races. With a day 1 patch, I know at least some of those issues have been fixed, but the overall vibe of “everything is a placeholder” remains.

To give you an example: PMR is advertised as a sim racing game with a strong single-player career and progression. With wording like this, you would expect the Career Mode to be crafted in a way that rewards the player and lets them get immersed in the rituals of motorsports, right? In reality, this is how PMR rewards you for winning a race, for “progressing through the game”:

We will never have another TOCA Race Driver 3, I know that much. But come on, this isn’t even trying; we can do much better than settling on this “programmer art” of user experience.

To give credit where it’s due, my overall experience wasn’t hopelessly bad. I played the game on PC exclusively on the Xbox One gamepad, only in single player, and I settled on playing the career mode starting from the slowest cars. Personally, I thought the gamepad controls are fine – not great, as they make countersteering too difficult, but good enough that someone like me, who isn’t exactly high skill in simulation games, can play the game and have fun. As with practically everything in this game, there is a clear room for improvement, but I wouldn’t call it unplayable.

Graphically, the game looks OK at best: it can look extremely dated in some aspects, but not to the level of being distracting, and at least it’s free of upscaling artifacts (by default). Since Unreal Engine 5 was dropped, the entire rendering pipeline is naturally raster-based (no raytracing), and it shows: daytime looks flat and uninspiring, but at least the sunsets can make the lighting pop. It’s no coincidence that this is also the setting of most of the game’s official promotional material…

I enjoyed my time throwing Porsche 964s and the GT4 and GTO cars on various tracks, so I was very close to saying that my driving experience was “very good”, BUT…

What’s with this AI!?

As I mentioned before, I’m not a particularly skilled player in the sim games. When I “fear the AI”, most of the time I mean they are prohibitively fast and beyond my skill level. In PMR, I found that I can match them at around 80% difficulty, but I feared them in another meaning of that term – in the current game build, they actively want to murder the player:

Before the release, a few people behind the game swore how lifelike the AI is and how it’s the best they’ve ever seen in a video game. The current version of the game shows the polar opposite – these bots are good at driving their cars (sometimes a little too good), but they obsessively stick to the racing line and have no qualms about ramming you if you’re in the way. It’s like we are back to how things looked in Gran Turismo 2, but back then, the stakes were much lower, and you could freely trade punches with the AI without fear of damaging your car and forfeiting the race.

I even posted some of these clips online and asked better racers than me: “Did I do anything wrong here? Did I divebomb too much and give no chance for the AI to react?” Nope, at least in the examples I showed above, I was in the clear, and it’s the AI behaviour that in real life would have gotten them kicked out of the track. Oh, and did I mention that if you get pushed out of the track by the AI car, you end up getting a penalty for exceeding the track limits? Apparently, the race marshals are in cahoots with these bots.

This has likely been the most prominent problem with Project Motor Racing so far, and practically everyone is outspoken about it. As of the time of writing this review, the developers have acknowledged that AI needs more spatial awareness and will be working on improving that, so maybe soon we’ll see some change.

What about mods?

There is one aspect of PMR I can’t criticize at all: it’s been designed with moddability in mind. Every relevant parameter is out there in plain text, mod tools (based on the tools for Farming Simulator) are already available, and we will even see mods on consoles delivered through the ModHub, just as in FS25. At the time of writing this review, a few official mods are already available, and they serve as examples of what people can achieve.

With everything being out in the open, everyone peeked into the files straight away and discovered something interesting: despite the claims of “AI using the same physics as the player” (which appears to be technically true), AI cars seem to be given different tire and engine data. People suspected that the AI generally has more grip than the player, as their starts and cornering on the cold tires are inhuman.

I modified one of the vehicle’s Hadron definition data files to give myself the AI tires, and I accidentally turned PMR into a thoroughly enjoyable arcade racer:

If you use the AI tire data on the player car and disable tire wear, @projectmracing turns into Forza Horizon and I think that's fun as hell. pic.twitter.com/lpl6eGErzm

— Silent (@__silent_) November 23, 2025

I genuinely enjoyed trying out a few cars in this “Project CARS 3 Mode,” and I would love for it to eventually appear in the game as a separate mode. It wouldn’t make sense for the Career or Ranked Online, of course, but an ability to set up an Arcade Race Weekend and an Arcade Online lobby could be great. The data is there already, after all. And if it doesn’t happen, we can always mod it in.

The technology

All analysis (except for Steam Deck) and benchmarks were done on the 1.4.0.1 PC version, dated November 21, 2025. The Day 1 Patch bumped the game up to 1.5.0.0 and should provide some minor CPU performance optimizations, but I did not re-time my benchmarks with it.

Game engine and system requirements

As mentioned earlier, PMR is no longer using Unreal Engine 5. We’re looking at GIANTS Engine 10.0, previously used in Farming Simulator 25, used as a base, with Straight4’s in-house Hadron vehicle dynamics model. Just like with NASCAR, I threw PMR at two setups:

• Intel Core i9-12900K with an NVIDIA GeForce RTX 5070 Ti. This rig sits well above the recommended system requirements.
• Intel Core i7-6700K with an NVIDIA GeForce GTX 1070. This rig is under the minimum requirements, so I can’t expect miracles.

For my impressions, I’ve been using the primary PC. However, for benchmarking, I used both. All screenshots in this article were taken on the Ultra quality level, unless stated otherwise.

In general, I did not encounter too many tech issues while trying the game. I did have the game crash around three times and reported them, but it wasn’t anything consistent and reproducible. The game ran at well over 60FPS at 1080p during the races, although I was heavily CPU-bound even on my i9, while the GPU seldom maxed out, even with VSync disabled. In the current build, Vertical Sync appears to be broken, and it instead engages an inaccurate frame limiter that introduces jitter, but the game also doesn’t tear frames while in the windowed mode, so a combination of VSync off + Borderless Fullscreen allowed me to play without issues. Earlier review copies reportedly also suffered from intense stutter, but we have received an update just before I got my hands on the game, and this issue must have been resolved, as I encountered none of that.

The GIANTS Engine has one more upside to it that is quite unusual – debug visualizations and performance metrics are freely available even in public builds! Hidden behind a single change in an XML file are some interesting tools:

Some of them ended up being useful for this review!

In-game graphics options

Project Motor Racing features a set of options similar to Farming Simulator 25:

It’s good to see a good range of options you would expect from a modern game, and all options can be adjusted on the fly during the race. Some highlights include:

• Multiple post-processing anti-aliasing options – TAA, DLAA, FSRAA. Anti-aliasing can also be disabled, which is very welcome. The review version also listed Intel XeSS as a valid AA option, but it’s gone for me in 1.5.0.0; maybe it was locked off on NVIDIA cards.
• Multiple upscaling options – FSR1, FSR3, DLSS4. Similar to AA, review copies had Intel XeSS, but 1.5.0.0 does not.
• DLSS and FSR3 Frame Generation are available, but personally, I don’t see much point in using frame generation in a game like this.
• The game scales down very well, going beyond the typical “Low” settings. The best example of that is the SSAO Quality option, where Low/Medium/High/Very High gets you XeGTAO, but there is also a Mobile option, which gets a bog standard SSAO:

  

  

  

The only significant option I am missing here is proper multimonitor support – not even spanning the game across multiple displays, as that is officially confirmed to be coming in the future, but there isn’t even an option to select the output monitor! You’re stuck to playing the game on whatever your primary screen is.

Graphics presets

The game comes with four graphics presets: Performance, Balanced, Quality, and Ultra. They cover most of the options available in-game, but there is more configuration the user can do:

• The lowest preset is not as low, and the highest preset is not as high as the game can go. Users can tweak graphical fidelity further.
• Every preset enables TAA, so those who want to use a different anti-aliasing solution, upscaling, or framegen need to manually correct it afterwards.
• Every preset leaves Depth of Field disabled.

The presets look as follows:

• On Performance, the game lacks any shadows, has the most basic AO, and a low draw distance. Honestly? That’s good, we need more games where the lowest details go really low.
• On Balanced, shadows get introduced, particles look denser, proper clouds appear in the sky at night, object draw distance increases, and cars generally are shaded nicer.
• On Quality, shadow quality, particle density, and objects draw distance increase further.
• On Ultra, screen-space reflections are introduced, shadow quality and objects’ draw distance increase even more.

But hey, this time we have the profiling data available in the game, so we don’t need to settle for comparing only by eye! I won’t be breaking down every single metric here, but you can compare how the CPU and GPU costs of options increase with the details going up. If you’re struggling to hit satisfactory frame rates, this may provide useful insight on what options to turn down.

CPU metrics:

GPU metrics:

Benchmarks and performance

I benchmarked the game on both PCs, on all graphics presets, with TAA and no upscaling. My benchmarking environment is also the same I used for the above nighttime preset comparisons:

• Porsche 911 GT3 Cup (992).
• Lime Rock Park Road Course.
• 31 Opponents.
• 20:00 race start time.
• Autumn, Rainfall.
• In each benchmark, I started at the back of the pack and followed the AI closely without overtaking them.

Both benchmarks were performed on the 1.4.0.1 version of the game. 1.5.0.0 made a few performance fixes to particles and adjusted the draw distances of some objects, so you may expect to see performance slightly better than what I had.

The results on the primary PC look… acceptable, but not mindblowing. It’s not immediately evident on the benchmark, but the lower presets were CPU-bound, as for some reason the game struggles to submit the render commands to the GPU efficiently, and bottlenecks on a single CPU thread are commonplace. On higher detail levels, GPU usage rose drastically, but so did the CPU load on the render thread, as draw distances also increased. I think only on Ultra I reached the point where the GPU became the obvious bottleneck, hence the sharp decline in the frame rates.

Results on the secondary PC are abysmal, but this PC is under the minimum system requirements, both CPU and GPU-wise. Those results don’t surprise me.

In my subjective opinion, the GPU performance of the game satisfies me, but the CPU performance leaves plenty of room for improvement, especially since you can’t easily reduce the CPU bottleneck through the existing options in the game. Even though Hadron is the main contributor to the game’s overall CPU load, in my tests, the heaviest strain was always on the render thread, and in some spots on specific tracks, I couldn’t even maintain a stable 60 FPS on Ultra in 1080p:

On this shot, you can see that the GPU is hardly busy at all, yet the frame rate is poor, and a few CPU threads work overtime. The in-game CPU profiler clearly shows the culprit – rendering the scene takes over 17.6 milliseconds, with nearly half of this time spent on generating the command buffers for the GPU to render!

Steam Deck

This time, this section is going to be very brief! If you want to play PMR on a Steam Deck, my advice is: don’t.

The issue with the Steam Deck is that even though the game is very scalable on the GPU front, you can’t do much to save yourself if your CPU isn’t up to scratch. In this case, Deck’s CPU is way underpowered to deal with the game’s physics engine, so the game doesn’t even run at a normal speed – instead, if Hadron is unable to perform the calculations it wants, the game slows down. On Deck, you’re effectively stuck to driving in slow motion, even on the very lowest details, upscaling, and when you’re alone on the track. While it is possible to lower the physics processing rate through modding, this most likely leaves you unable to play multiplayer, and I am not even convinced it would be enough if the game bottlenecks on a render thread.

None of this is a surprise given the game’s system requirements, but at least this test proves the game works fine on Proton. I suspect it will be performing quite well on Steam Machines, or at least I hope so.

What’s next?

I won’t lie – I think that, in the current state, Project Motor Racing simply isn’t good. The developers already acknowledged the issues and promised fixes, but will it be enough, or will people simply move on to other games? I want to believe they can turn this around, because nothing in the game is fundamentally broken and simply needs time. This leads to my main point, though: PMR is currently simply unfinished, and I don’t say that often.

Something clearly went wrong, and the game got hit by an immovable, rushed release date. Looking at how many issues I reported over a single weekend of trying the review copy, I think it’s a reasonable conclusion. Over just a few days, I ended up with a direct line to the dev team, and stumbled upon multiple issues that likely haunted other, less tech-oriented reviewers.

Personally, I have to give credit to PMR for recognizing the importance of letting different people try the game early – in this case, giving me a review copy evidently paid off 🙂 The main reason I reach out for early copies nowadays is to break them in a controlled environment, and PMR proves it best so far that this is mutually beneficial for both my services and for the game.

That said, those reviews are not going to become a regular thing; after NASCAR 25, this is most likely my last review for 2025.

Introduction

It’s been slightly over a month since NASCAR 25 released on consoles on October 14th. As announced a few months back, we had to wait one more month for the PC release, and it got released according to plan, on November 11th.

Although I’m not big on NASCAR, I wanted to cover this game ever since I learned it’s developed on Unreal Engine 5 by the legendary Monster Games – the same studio that gave us Viper Racing, NASCAR Dirt to Daytona, and Test Drive: Eve of Destruction. In the 2010s, they’ve been busy working on the new NASCAR Heat games, and after a disastrous NASCAR 21: Ignition from Motorsport Games, Monster Games got a chance to work on a NASCAR game again, this time under iRacing.

iRacing Motorsport Simulations supplied a review key for the purposes of this review, and so over the past several days, I played through NASCAR 25 and documented my technical findings. As the game is locked down way more than a typical UE5 game, it was more difficult than expected, but not impossible. While I can’t give you an informed opinion on how accurately this game portrays stock car racing, I will voice my thoughts on the technicalities, as I tend to do in my reviews.

Gameplay impressions, aka car go left very well

NASCAR 25 features four racing series:

• ARCA Menards Series (replacing the fictional Xtreme Dirt Tour series, introduced in NASCAR Heat 3)
• Craftsman Truck Series
• Xfinity Series
• NASCAR Cup Series

It’s no secret that I’m a tourist when it comes to NASCAR games – after dabbling with the demos of excellent NASCAR Racing 3 and NASCAR Legends as a kid, during my adult years I’ve only played NASCAR Heat 2002 on the PS2, and Heat 2, and Heat 3 on PC (NASCAR Rumble doesn’t count in this context); thus, I lack much insight on how the games have been progressing over the years, and I have no interest in this sport IRL either, to the point that three-segment races featured in Heat 2 completely caught me off guard.

This is all to say that my opinion of the game’s gameplay loop is that of an outsider’s. For this piece, I’ve almost exclusively played the Career Mode and have not advanced past the ARCA Series or touched the online mode. During that time in the Career Mode, I got to manage my own car, personnel, itinerary, and reputation. None of those gameplay mechanics are particularly in-depth, and are usually limited to reacting to a message from a team member and making a hiring decision, or selecting what event to attend. Managing the car has slightly more nuance, as the player needs to balance upgrading the car and keeping it in good shape, and resources are quite limited. So far, I have always found myself with more than enough money to buy upgrades, but not enough time to get my car in good shape. Maybe this means my driving is too reckless.

Initially skeptical about the prospect of turning left for 15 minutes at a time (as I played at a 25% race length and 4x the fuel usage/tire wear), I think I now see the appeal. For the first few races, I was slightly too careless, punting AI along the way as I wrestled for better positions, and burning through fuel way too fast. This not only led to me finishing very far down the pack due to me having to pit more often than the rest, but also the in-game social media coverage of my driving was dire.

But then, I started figuring things out. Smoother lines, less aggression, and higher awareness of my car’s dimensions, and coasting around the corners – each next race in the season was cleaner and more satisfying. I started seeing a shift in perception both in the social media coverage, but also on the track, as I collided with AI much less – I’m not sure if I simply got better at avoiding contact, or if the AI respected me more and gave me space. As much as I’d like to believe it was the AI, it’s probably all on me predicting the AI lines better.

Then, the very last race before I sat down to write this review, my pitting strategy and a lucky yellow flag from the AI crashing independently of my actions, I won the race.

Unfortunately, the game didn’t give me a chance to celebrate my win by doing a victory lap or a burnout. This is still done in real-life races, and the older NASCAR Heat games from Monster Games included that, so I’m not sure why NASCAR 25 completely omits it. Oh well.

Regardless, I’ll keep playing NASCAR 25 more. I want to progress in the career at least far enough to enter the Craftsman Truck Series. Career progression is reputation-based, so the better my driving is, the sooner I’ll get invited.

The technicalities

Now, for the main reason I’m looking into this game. All analysis and benchmarks were done on the launch PC version of the game, dated November 10, 2025. A small patch was released during the writing of this review, but it didn’t contain any performance changes or fixes to issues I outline here. Since the time I published my previous game review, I upgraded my main PC and retired my aging graphics card to a secondary PC. This makes my benchmarks more meaningful and “true to life”, and I can try the game on both setups!

Does it work fine? Does it scale? Does the PC port go above and beyond, since it was released a month after the consoles? Let’s find out.

Game engine, graphics, system requirements

NASCAR 25 runs on Unreal Engine 5.5, although unlike the other games I’ve covered, it’s been heavily UE4-ified. You won’t find any signs of Nanite or Lumen in here; they’ve been permanently disabled at the project level, and no amount of INI tweaks will get you any ray-tracing. For this game, I am going to completely ignore the minimum requirements, as they’ve been copy-pasted straight from iRacing, and I don’t trust them to be meaningful. I threw NASCAR 25 at two setups:

• Intel Core i9-12900K with an NVIDIA GeForce RTX 5070 Ti.
• Intel Core i7-6700K with an NVIDIA GeForce GTX 1070.

For my impressions, I’ve been using exclusively the primary PC. However, for benchmarking, I used both. All screenshots in this article were taken on the Highest quality levels, unless stated otherwise.

Graphically, I feel like NASCAR 25 caught the bug of a typical annual sports game – it doesn’t look “bad”, but it’s far from impressive. To my knowledge, tracks come straight from iRacing, and they certainly show their age. Lighting is basic and relatively dull, and effects like the lens flare appear to be similar to stock Unreal Engine 5 effects.

This decision makes sense to me, though – in the absence of ray-tracing and heavy upscaling, the game looks reasonably sharp, and doesn’t require a top-end PC. Additionally, since it’s obviously not open world, in my experience, it’s free of any Unreal hitches: I don’t think I have seen a shader compilation stutter even once. The game doesn’t seem to be shader-heavy in the first place – even though it doesn’t ship any precompiled PSOs, at the time of writing this review, my gathered PSO cache file sits at around 760KB, which is not a lot for Unreal standards.

That said, even before I started inspecting the graphics options, I couldn’t help but notice how blurry the cinematics are:

These aren’t temporal artifacts or anything like this – these cinematics are simply out of focus! I have no idea if this is a bug or if cinematics neglect to set the focus points correctly, but I reported it to the developers with an assumption that it’s an oversight, as I can’t imagine the camera focusing on a random cameraman is intentional.

The port’s disappointments

With this PC port arriving a month after the console releases, I was hoping the game would be well-adapted for PCs and offer a wider range of options. Unfortunately, the reality couldn’t be further away from the truth, and we instead were given a simple, straightforward PC port that works, but doesn’t offer anything of note either.

On the first boot, the game defaults to disabled VSync, so first-time players see the intro FMV with frame tearing and maxing 100% of their GPU. The system mouse cursor doesn’t ever hide, and the mouse can’t be used to navigate menus, so it’s on you to tuck it away somewhere. Keyboard prompts are nonexistent, so it’s up to you to figure out the keyboard menu controls. Even then, you’ll soon find out that some actions, like opening the driver name text input field, require using the gamepad (and then you need to use the keyboard to type the name, of course).

On the upside, all input controls are customizable. Unfortunately, they are presented in such a disorganized way that I initially suspected some of the mappings were listed by mistake, as the game’s enormous Input Mapping list includes game actions, followed by… remappable gamepad buttons.

Later, I realized that those are mappings for menus, and so they correspond to the legends of the UI actions.¹ While this does make some sense, I feel like they should have been at least separated into a distinct sub-list, just like the axes (throttle/brake/steering) are. To top it off, there is no way to reset bindings back to the defaults! The only way to do that is by deleting the input configuration file.

The game also lacks any sort of customizable FOV. It’s not as much of a port issue, but it would have been welcome to see, especially since ultra-wide monitors are supported. However, the biggest indicator of this port’s simplistic nature is the Display menu.

In-game graphics options

If you were like me and expected this port to have reasonably extensive graphical options, I have bad news. NASCAR 25 features only the most fundamental options typical of UE games:

Missing something? Yes, a lot:

• Instead of an option to select and/or toggle upscalers, or at least a fixed Render Scale option, Dynamic Resolution is listed, reminiscent of typical scaling mechanisms in the console games.
• Multi-monitor is not a thing at all, so you’re out of luck if you want to play on anything else but your primary monitor. You can, of course, move the game window, but the game fails to list resolutions appropriate for the other screens and doesn’t play nice with high DPI scaling.
• For Anti-Aliasing, only a typical UE5 scalability option is exposed, adjusting the AA quality. Otherwise, the game always uses TSR and doesn’t give the player any alternatives. On the upside, when Dynamic Resolution is disabled, TSR seems to work with a 100% screen scaling, effectively becoming a slightly better TAA. You can’t, however, use FXAA or disable AA entirely.
• While omitting some UE scalability options (like Foliage Quality) makes sense, Reflection Quality would make sense in a game like this, yet it’s not exposed in menus.

Let me demonstrate: with a simple Engine.ini change, I can make the game look better than the default max details, by disabling forced TSR, and setting the resolution scale to 200%:

[/Script/Engine.RendererSettings]
r.AntiAliasingMethod=0
r.ScreenPercentage=200

The result maxes out my GPU, but looks far better than the default anti-aliasing:

If users were given an option to use DLAA and/or FXAA, or an option to disable AA entirely, they could rely on DSR configured externally, without the need for any INI tweaks like this.

Graphics presets

The game comes with a set of 5 presets that correspond directly to the scalability levels in Unreal: Low, Medium, High, Very High (renamed Epic), Highest (renamed Cinematic). Interestingly enough, Epic discourages developers from exposing Cinematic in games as it’s only meant for offline rendering (e.g. movies or FMVs), and yet NASCAR 25 uses it. From what I can tell, those scalability options are mostly left untouched from Epic’s defaults, although since Lumen is globally disabled, higher Global Illumination options have barely any noticeable differences.

The presets look as follows. The differences are very subtle, so you’ll likely want to click on the images to open them full screen:

I’ll be honest: with the game not letting me change options in-race (so the comparison screens are not identical), and with differences this small, pointing out the differences is difficult. Perhaps presets affect more under different circumstances, for example, during the night races, but during the day, there isn’t much to talk about.

• On Low, shadows are grainy and have a short draw distance, and textures are low resolution.
• On Medium, a vignette effect appears, and textures get a quality bump. Shadows look smoother and more detailed.
• High and Very High further increase the quality of shadows and draw distance, but I’m not sure if they do anything meaningful in the main menu.
• On Highest, shadows draw from afar, and props appear to have “infinite” draw distance.

Overall, the differences seem quite miniscule, other than shadows and the texture resolution. Not sure if they warrant 5 distinct presets, but my guess is that it was done so they “automatically” benefit from the overkill settings of the Cinematic detail setting.

Benchmarks

As mentioned before, I benchmarked the game on two PCs, on all graphics presets. For the benchmark, I selected a night race setup and tried my best to drive as consistently as possible. I selected:

• NASCAR Cup Series.
• Bristol, Bass Pro Shops Night Race.
• Started at the back of the pack and stayed there for the duration of the benchmark.
• Raced in the chase camera.
• Kept the rear-view mirror enabled.
• Started the benchmark directly after taking control of the car, and sampled 30 seconds of data.

For the RTX 5070 Ti machine, I performed the benchmark at 1440p, as otherwise all presets had nearly identical readings due to a CPU bottleneck. On the GTX 1070 machine, 1080p was enough.

The results look somewhat acceptable: similar Low 1%’s and Low 0.1%’s show that the game’s performance is stable and consistent. Both machines started by being CPU-bound, before becoming GPU-bound on the higher details. The claim of a CPU bottleneck on an i9-12900K might sound strange, but it’s a bottleneck on a single thread performance: it doesn’t show up in Practice or Qualify sessions, so I suspect it’s caused by the AI and physics simulation happening on one or just a few threads for all 40 cars. A game of this type being more CPU-heavy than GPU-heavy makes perfect sense.

With those results, I could draw those conclusions about my hardware:

• Not even an i9-12900K has single-thread performance good enough to achieve 120 FPS.
• RTX 5070 Ti blasts through the game with ease.
• i7-6700K is slightly too slow for stable 60 FPS.
• GTX 1070 should be fine at Low and Medium details, but it needs to be paired with a more powerful CPU.
• GTX 1070 may benefit from disabling TSR.

Steam Deck

When I started this review, this section was intended to be very short – at launch, the game instantly crashed on the Deck (and on Wine/Proton) in general, and a rather sparse official disclaimer was published shortly after launch:

Steam Deck Compatibility Information

NASCAR 25 does not support Steam Deck.

The game crashed instantly while attempting to execute an illegal processor instruction. I investigated it and found that it was due to the block of code being… encrypted. On Windows, this same block of code was not encrypted in-memory, yet it was encrypted on-disk, so it looked like under Proton, decryption was either failing or deliberately not running at all. Just to be sure, I reported this incompatibility in the Proton repository, and just before this review was finalized, I heard back – the game crashed as it exposed an API implementation bug in Wine! Proton Bleeding Edge has since been updated with a few fixes, and suddenly, encryption was no longer an issue, and the game boots!

As the game has anti-debug measures, I was not able to troubleshoot the exact cause properly, and thus my conclusion was incorrect – encryption was not the root cause of this issue, and instead, a failure to create a resource executed code that was not decrypted yet. If, for any reason, this resource fails to be created on Windows, the same crash would occur – and maybe it does, as some people report that the game crashes on launch instantly even on Windows.

That said, you probably can tell that the performance on Deck leaves a lot to be desired. Similar to my desktop benchmarks, a severe CPU bottleneck appears in races, while big, open courses (like Chicago) are GPU-bound. With a full grid of cars on a small oval track, the CPU bottleneck is so significant that it leaves the GPU starving for power, downclocked to less than half of its maximum frequency!

I wasn’t able to get the game to maintain a stable 30 FPS no matter what, so I wouldn’t consider it Deck playable. However, those findings benefit all users of Wine/Proton, and are good news for the future owners of a Steam Machine – the game will probably run great on it. I was able to squeeze a few more frames per second by disabling the rear view mirror and TSR (via the INI tweak), but it’s still underwhelming:

iRacing, please let us disable TSR and mirrors in the cockpit cameras!

Conclusion

Overall, I’m content with the state of NASCAR 25 as it is now. Sure, I would have preferred if the game scaled better, offered better graphics, and more PC customization. However, none of those were ever a priority for NASCAR games, and I need to acknowledge that it’s treated more like an annual sports game than a beefed up racing game – with games of this kind, their absolute priority is to capture a wide range of fans of a particular sport or motorsport, and those folks don’t necessarily have to be gamers.

In the long run, a decision to aim lower might be a better one, as it means more “casual gamers” can enjoy the game.

TL;DR: If you are not interested in an overview of my new Gran Turismo 2000 cheat codes, go to the Download section for download links.

• Introduction
• The main goals
• Published mods
  • Car Select
  • Widescreen fix
  • No time limit
  • Trigger control mappings
  • Automatic DualShock mode
  • Throttle/brake on the right stick
• Download

Introduction

Over the past few weeks, I’ve been researching Gran Turismo 2000. If that rings no bells for you, that’s okay – before Gran Turismo, Polyphony Digital’s initial idea was to launch a new, smaller Gran Turismo game for the PS2 before the end of 2000. However, as the release slipped into 2001, it eventually became Gran Turismo 2000: A-Spec, then Gran Turismo 3: A-Spec. We do, however, have a single build of GT2000 publicly available – a small, 2-minute-long demo given away during a PlayStation Festival in early 2000.

You might ask, what makes this limited demo so interesting, other than the name? While it’s true that this game eventually formed what we know as Gran Turismo 3, it’s also essentially a different game. Gran Turismo 2 and Gran Turismo 2000 were developed side by side for most of 1999. At first GT2000, was likely supposed to be “GT2 on the PS2” (just like Gran Turismo HD was initially thought to be “GT4 on the PS3”). This is evident in the festival demo’s visuals, sounds, and code: distant car LODs use GT2 models as-is, and big chunks of the game’s code (like physics) strongly hint at being ported straight from the PS1!

This is further backed by pre-release interviews with Kazunori Yamauchi himself:

Originally conceived as nothing more than a fancy-shmancy update of Gran Turismo 2 with pretty graphics, this is now a fully fledged sequel. “My original plan for this title was to be released close to the PS2 launch, when it would feature 50 different cars and four racing tracks,” project leader and producer Kazunori Yamauchi tells us. “It would have been positioned as a digest or demo version of the GT series for the PS2. That’s why it was titled as GT2000 and not the formal name, GT3.”

Official U.S. PlayStation Magazine Issue 40, January 2001¹

This is why I dove into the GT2000 demo despite its extremely limited content. Unless more prototype builds show up online in the future, this is our only chance to peek at what Gran Turismo 2 on the PlayStation 2 would be like. Documenting this demo and understanding how it works provides us with a unique opportunity to see Gran Turismo in a very scaled-down, intermediate state of development.

The main goals

When I dove into this demo, I wanted to see how far it could be pushed content-wise. By default, the experience it offers is extremely limited – the player gets to race around Seattle Circuit against 5 AI cars for 120 seconds, driving a Mitsubishi Lancer Evo V, and they can only choose the Lancer’s color and the handling model, much like in Arcade Mode in the PS1 GTs. The “race” itself is also extremely barebones: it doesn’t count laps or split times, and the race cannot be finished; instead, the game automatically switches to a replay after the time limit expires.

The tracks are immediately a lost cause: while some earlier public previews of GT2000 showed Special Stage Route 5, the festival build doesn’t feature any usable leftovers; the only highway files that are left behind are in the formats this build doesn’t care about.

The situation with cars is a little better, since the AI opponents drive different cars with their distinct sounds and characteristics. Xenn765 has also looked into GT2000 a long time ago and created ARMax codes allowing the player to take control of the AI cars, so the player can “swap seats” with AI and drive their cars. What I wanted to know was – could these findings be used to create a “complete” car selection, where the player sees a different car in the main menu and starts the race in it?

This curiosity sent me down a rabbit hole that resulted in a collection of cheats I’m sharing here with you today.

Published mods

Car Select

The existing car select cheat proves those cars are drivable, but I wanted to break down how to switch the player’s car without affecting AI. I discovered that this build, unlike the final GT3, still uses GT2’s parts data, down to the vehicle identifiers and code using fixed-point values, like a PS1 game would, proving that this code is likely identical to GT2!

Matching the vehicle identifiers to their names from Gran Turismo 2, the six cars available in this build are:

• m2g6n – Mitsubishi Lancer Evolution VI GSR ‘99; oddly enough, the actual car available is a Lancer Evolution V GSR ‘98, but using Evo VI’s parts data.
• t291n – Toyota Altezza RS200 ‘98
• s2lgn – Subaru Legacy B4 RSK ‘98
• a28sn – Mazda RX-7 Type RS ‘98
• n24vn – Nissan Skyline GT-R V-spec (R34)
• hnsnn – Honda NSX Type S ZERO (J)

Unlike any “full” Gran Turismo, menus in GT2000 are fully hardcoded and laid out only through code. Thanks to this and to RTTI data being left behind, I was able to understand how the menus are structured and how to expand them.

My Car Select mod:

• Lets users select the car in-game with DPad left/right.
• Features all available colors for each car. Although AI drivers always used fixed colors, all car models feature a selection of colors taken straight from Gran Turismo 2. Notably, Honda NSX has 12 available colors, which is quite a bit compared to Evo V’s 5 available colors!
• Keeps the starting grid unchanged, so the player starts in the 6th position regardless of their car of choice.
• Remembers the selected car after the race, like the stock game does with the selected color.
• Makes the selection look fully native by including a fade-out effect when selecting cars, much like in Gran Turismo 3.
• As UI assets for other cars are not present in the files, Lancer Evo badges, performance characteristics, and color names are hidden for other cars.

Currently, I only offer this mod as a PNACH patch. I might also release it as an xdelta patch later so it can be used like a romhack.

At this time, Car Select is not compatible with the RetroAchievements set for GT2000. I will ensure it either gets updated as soon as possible, or earning achievements gets blocked when Car Select is active.

Widescreen fix

GT2000 is technically the only Gran Turismo on the PlayStation 2 not to support 16:9 widescreen. A widescreen hack exists for it already, but I wasn’t satisfied with how it adjusts the FOV and does nothing to the UI, so I created my own. In my widescreen fix:

• The game FOV is switched to Hor+ everywhere, including the menus and replays; FOV is no longer manually increased to match the original game’s 4:3 vertical FOV.
• All menu and HUD elements, except for the fonts, have been adjusted for widescreen. This also includes the intro movie.

Fonts proved to be impossible to rescale for widescreen – GT2000’s font rendering is taken straight from Gran Turismo 2, and that system does not support resizing the fonts, as the PS1 did not support sprite scaling at all.

While currently I only offer a patch for 16:9 widescreen, in the future I may publish an online generator similar to the Bonus Codes that can automatically create PNACHs for arbitrary aspect ratios specified by the user. I have no ETA on this, but it’s something I’d like to offer for multiple games, like GT2, GT2000, and Juiced!

No time limit

In theory, the 120-second time limit of this demo was lifted years ago, and even removed from the UI. In practice, all the existing cheats are flawed, as the game has two timers managing the playtime:

1. The timer visible in the HUD that ends the race shortly after 120 seconds elapse.
2. The replay recorder is limited to 121 seconds, and it will also switch the game to play the replay back once the recorder fills up fully.

Until now, all cheat codes available online only lifted the first timer, and they did nothing to the automatic replay playback, so in practice, the time limit was still there, just hidden. With my cheat, both timers are lifted, so the race is now truly endless.

Trigger control mappings

Much like GT4 Prologue, GT2000 lacks remappable controls. As I was working with the input code for the Automatic DualShock mode cheat, I figured remapping the controls to the modern triggers-based scheme should be easy, especially since the game already opts in to use pressure-sensitive buttons.

With this cheat, control mappings reflect the default modern controls scheme from Gran Turismo 7:

• R2 – Accelerate
• L2 – Brake
• O – Handbrake
• X – Shift Up
• ☐ – Shift Down
• △ – Reverse

Triggers are given the correct sensitivity, too, so they work equally across the full range of inputs.

Automatic DualShock mode

Many people who have played Gran Turismo 2000 previously (especially in PCSX2) may be unaware of the fact that it does support analog controls, but unlike any other PS2 Gran Turismo (and most other racing games on the platform), they are not enabled by default and the user needs to enable them every time by pressing the Analog button.

On real hardware, this is obvious, as the LED on the DualShock 2 is off, but it’s way less clear in PCSX2; on top of that, software like Windows Game Bar and Steam Big Picture like to “take control” of the Guide button on modern gamepads and make using it in PCSX2 annoying.

With this patch, the game automatically enables the Analog mode on startup and locks it.

Throttle/brake on the right stick

If controlling the car with face buttons or triggers isn’t your cup of tea, most Gran Turismo games also offer an alternative – throttle and braking can also be controlled with the right stick. With this patch, GT2000 also gets this feature.

This patch can be used alongside Trigger control mappings, but doesn’t require it.

Download

All listed cheats can be downloaded from Mods & Patches. Click here to head to the game’s page directly:

Download cheat codes for Gran Turismo 2000

Introduction

There is a new kid on the block – 2025 seems to be a year of independent racing games set in Japan, and now, nearly two years after the first public demo, JDM: Japanese Drift Master released on May 21st:

My Tokyo Xtreme Racer analysis from a few months ago was received well, and so a few days ago I was given a review key for JDM, so I could look into it and share my thoughts. With both games revolving around the Japanese car culture, and both running on Unreal Engine 5.4, comparisons are to be expected.

I spent the past several days playing the game, tinkering with settings, reporting bugs, running benchmarks, and simply cruising around. In this review, I’m focusing on the technical experience, scalability, options, and performance. Are you interested in this game but are on the fence due to your PC specs? Do you have doubts about some of its technical aspects? Or maybe you want to see how it progressed from the 2023 demo? My findings may help you make a decision.

What is Japanese Drift Master about anyway?

If you’d rather jump to reading the technical overview of the game right away, go ahead and skip to The technicalities.

If you’re not following this particular sub-genre of racing games closely, you may not have heard of Japanese Drift Master earlier. JDM is an open-world, story-driven racing game set in Guntama, a fictional mountainous region of Japan that focuses but doesn’t limit itself to drifting. Sounds familiar? Parallels to media like Initial D aren’t a coincidence – the game tells its story through manga comics, drawing clear inspirations from this cult Japanese manga.

Right from the get-go, the game puts you in a drift spec Nissan Silvia S15, and from the very first moment, it’s clear that the focus is on drifting. After a brief intro limiting the player to a predefined course, we are thrown into the open world and given the chance to buy and tune their car. From there, the game opens up and the player may either concentrate on going through the races or just forget it and cruise on the winding Japanese roads.

Before now, the game first had a proof-of-concept demo released back in mid-2023, followed by a prologue approximately a year later, in mid-2024. They both were generally well received, although they pale in comparison to the current state of the game – those older previews, especially the first demo, had a bit of a “default Unreal game” feel to them, but now it’s all gone. It’s immediately noticeable that a lot of work was put into making the game look and play like a fully featured product. This is further emphasized by the fact the two preview versions ran on Unreal Engine 4, while the final game runs on Unreal Engine 5 – if you feel like the following screenshots look a generation apart, that’s because they are.

When I wasn’t gathering data for the review, I loved my time with JDM. I played through two of the five chapters available to reviewers, during which I raced in numerous drift and grip events, and explored the map quite a bit. With JDM’s starter selection of 27 cars (to be expanded later), 7 radio stations, and tons of visual and mechanical tuning options, this might just be my favorite racing game of 2025 so far. It hits all the notes that made Test Drive Unlimited great, albeit without supercars – the cars I got to drive feel uniquely mine, and I had to earn the right to get them. Or, true to TDU’s spirit, I could just take any car for a test drive and trash it around those narrow, twisty roads.

Full disclosure – at the moment, this feature (rolling down windows) doesn’t work correctly as the action is not bound to the keyboard. I reported this to the developers.

The technicalities

Japanese Drift Master is cool, but does it work well? I’ll try to answer that based on my expertise and the data I gathered while playing the pre-release versions 1.0.17.1 and 1.0.21.1, as well as a release build 1.1.40.1. The game updated ahead of its launch, but most of my observations still apply to the current public build.

Game engine and system requirements

The final version of JDM runs on Unreal Engine 5.4, which is the same UE version as Tokyo Xtreme Racer. Unlike that game, my rig partially falls under the minimum requirements – they list an Intel Core i5-9400F and an NVIDIA GeForce GTX 1660, while I still use an Intel Core i9-12900K with my NVIDIA GeForce GTX 1070. On the CPU front I am set, sitting well above even the recommended specs, but this GPU is pushing it – as the GeForce GTX 16 series is a slightly downgraded 20 series, a 10 series card is under the minimum requirements.

Thankfully, my experience wasn’t all that miserable. In this case, I opted to go for the highest details I could get reasonably stable 60 FPS on, which the game was hitting most of the time, but not always. For this review, my settings of choice are:

• 1080p with TSR Quality.
• Frame generation Off (obviously).
• Mirrors Off.
• Motion Blur On.
• Anti-Aliasing, Shadows, and Global Illumination on Medium (Lumen Global Illumination disabled).
• Textures on Ultra (although I might need to reduce that, given I have 8GB VRAM).
• All the other options are on High.

For Shadows, I additionally tweaked my settings with a script, but I’ll elaborate on that later in a separate subsection. The script changes I made in the pre-release version are now mostly reflected in the current public build, so ironically enough, they made my pre-release screenshots look more like the build you’ll be playing.

All screenshots in this post are taken at these detail settings unless stated otherwise.

Starting with some negatives:

• Unfortunately, JDM does exhibit shader stutter, and as of the time of writing this review, the game does not precompile shaders on the first boot. This might change later, but during my testing, I had to put up with the stutter – it wasn’t unbearable, but it certainly was noticeable, and it soured the experience. Unreal Engine’s worst contribution to the gaming landscape handicaps yet another game.
• Anti-aliasing is forced and necessary for the game’s art style to look right. Forcing AA off from the console makes the game look grainy.
• Although upscaling is optional, it’s enabled by default. Keep this in mind when configuring the game’s settings.
• As of the time of writing this review (at the game version 1.1.40.1), the game has trouble remembering some graphics options and resets them every launch, even though they appear to be set correctly in the settings. Right now, this is known to affect the Mirrors option. This bug has been reported and acknowledged by the developers. Should I be notified that this bug is fixed, I will edit this point accordingly.

In-game graphics options

On the surface, Japanese Drift Master has a standard set of UE5 graphical options and upscalers:

• Even though most options conform to the standard scalability groups from Unreal, they are not used at all and instead, all options tweak the specific detail variables directly from the code. This means that many INI tweaks will simply not work, as changes done from code take precedence over the project settings.
• Unfortunately, the benchmark is simply a simulation running on an empty screen and not a live demo.

Graphics presets

JDM comes with a set of 5 presets: Low, Medium, High, High Plus, and Ultra. From my observations, High Plus is close to default UE5’s High preset, while High slightly scales back compared to the default, for example by deactivating Lumen. Presets are independent of the resolution scaling, so for my comparisons, I settled on the highest available resolution scaling option in the review build, TSR Quality.

The presets look as follows. Click on the images to open them full screen:

• On Low, shadows and reflections are basic and low resolution, props have an extremely low draw distance, and any lights outside of the ambient lighting practically do not exist. The game still looks acceptable, but it’s clearly missing “something”. It’s also way too dark at night.
• On Medium, screen-space Global Illumination activates, giving the day environment a slightly darker, more planted look. Shadows and props are rendered further away, and at night, some dim light sources appear. More props are placed on the map. In the current build, the volumetric fog is also enabled (in the review build I took those screenshots from, it enabled on High instead).
• On High, lights are fully featured, volumetric clouds are enabled, draw distance is significantly increased (notice the trees on the far away mountain), and shadows are higher resolution, have more cascades (so they draw at a farther distance), and show more self-shadowing (like on the rearview mirror in the day scene). Even more props appear.
• On High Plus, Lumen Global Illumination and Lumen Reflections kick in, giving the scene a better-lit, more realistic look. Draw distance of small props is further increased.
• Ultra introduces a flare effect and further increases the GI quality. The day scene looks slightly darker as it should according to the weather, and the night scene gains a more pronounced bloom effect from the light sources. Shadows seem to be softer and blend with the ambiance better. Self-reflections are also introduced.

Resolution upscaling options

JDM comes with a standard selection of up-to-date upscalers:

• DLSS4
• TSR
• XeSS 2.0.1

Curiously, DLSS is selectable even on hardware that isn’t supposed to support it – in this case, Unreal falls back to TSR.

All upscalers share the same set of presets:

• Native/Ultra (100% resolution scale)
• Quality (66%)
• Balanced (58%)
• Performance (55%)
• Ultra-Performance (50%)

The review build I tested lacked the Native scaling option, so all my testing was done on TSR Quality. Native was added just before the public launch – it’s way too much for my GTX 1070, but players using more modern GPUs might be up for it.

Individual options and the effects of Lumen

I won’t be comparing every single graphics option in the game, as this time there are too many of them, so I encourage you to experiment if you need to reclaim some performance from your game. That said, there are a few outliers I would like to cover.

• Detail Quality and Environment Quality options alter the complexity of the scene by adding more foliage and props, as you could notice on the preset comparisons above. These two options require restarting the game to take effect, but they have a huge impact on the GPU load, so if you’re looking for performance, don’t hesitate to experiment with those options.

• Effects improve the shading of props and foliage and enable volumetric clouds on High and above. I only observed a very minor visual difference otherwise, yet the performance hit is noticeable, so if you don’t care about volumetric clouds too much, you can get some performance out of this option.

  

  

  

• Shadows increase the resolution of shadows, the number of cascades, and their draw distance. On High Plus and Ultra, more props cast shadows too (such as the signage). On Medium and above, volumetric fog is added. This option also affects lighting in a weird way, which I consider a bug. I elaborate on this more at the very end of this review, in Unreal Engine bugs, in my game?

  

  

  

  

• Global Illumination controls the lighting of the entire scene. At Medium, Screen-Space GI enables, although I struggled to see any improvement on the scenes I used for testing – perhaps other scenes show more improvements on higher details. At High Plus, Lumen Global Illumination enables, giving the entire scene RTGI. It’s probably the single most impactful option in the game, both in terms of performance, and visual improvement.

  

  

  

  

• Reflections are relatively self-explanatory. On Low/Medium/High, screen-space reflections of progressively better quality are used, while on High Plus and Ultra, Lumen reflections kick in.

  

  

  

  

  Lumen Reflections requires Lumen Global Illumination to be active. If screen-space GI is used, reflections are screen-space even on Ultra.

  

  

Regarding the usage of Lumen, I’m satisfied with JDM’s direction – ray-traced Global Illumination improves the game’s visuals drastically, but they’ve also been obviously crafted with screen-space effects in mind. Lower details look worse, but they don’t look bad or incomplete.

Naturally, ray-traced effects require considerable horsepower and even powerful GPUs might struggle to maintain high frame rates at higher resolutions, which is why many modern Unreal Engine 5 games (including this one) enable resolution scaling by default. It’s up to you to decide if you wish to deal with this in return for more natural lighting and reflections.

Benchmarks

Is benchmarking the game on a GPU under the minimum requirements a sensible idea? Probably not, but I believe it can still help – because realistically speaking, those values can be treated as an absolute baseline showing that the game will perform at least this well on supported hardware. I suspect the relative performance between presets might be similar on more powerful hardware too.

I ran all the benchmarks on a pre-release version 1.0.17.1, running at 1920x1080 with TSR Quality – as of the time of writing this review, the public version 1.1.40.1 has performance figures within the margin of error compared to my earlier samples. In all those benchmarks, I started the game around noon, in the first garage the player gains access to, then I turned right and continued driving along the road for the entire duration of that 30-second benchmark.

As with Tokyo Xtreme Racer, I also benchmarked the two highest detail presets with Global Illumination set to High, to disable Lumen. Whether you need performance or simply don’t want your GPU to heat up too much, it’s an option worth exploring.

Personally, I consider those results satisfactory. Considering those benchmarks are done on a 2016 GPU that is under the minimum requirements, the fact the game is evidently playable on Medium details is a pleasant surprise. With lower-spec PCs I imagine some CPU bottlenecks may start appearing, but due to the obvious imbalance of my home setup, I am not able to pinpoint those effectively.

Steam Deck

I also tested the game on my LCD Steam Deck for some time. The experience isn’t ideal, but it works. I tried the game on Medium details with TSR Balanced, but the Deck cannot sustain a stable 30 FPS at these details, even if at first glance it seems that it can. On Low with TSR Balanced, the framerate oscillates between 30 and 40 FPS, so locking the game to 30 FPS is reasonable.

The good:

• On the Deck screen, even the lowest details with TSR Balanced look acceptable.
• The game doesn’t slow down under 60 FPS, so locking to 30 or 40 FPS is perfectly fine.
• The game autosaves frequently, so it’s good for short sessions.
• The developers have promised future performance optimizations for the Deck and a Steam Deck preset. At the time of writing this review, this preset doesn’t yet exist.

The bad:

• The battery drains incredibly fast – on a Deck LCD, you’re likely looking at under 1 hour of playtime.
• At one point, my Deck ran out of VRAM, and the game locked up the entire console, putting it at one frame per half a minute. At that point, I was playing on Medium textures, so I strongly recommend sticking to Low textures.
• There are a few UI bugs on 16:10 displays. I have reported them directly to the developers, so they are aware of those issues.
• The game misdetects Deck’s resolution as 800x1280, and an attempt to change it breaks the resolution permanently for that session.

Overall, do I think it’s a good experience on Deck? Definitely not if you plan to play on the go due to the extreme battery drain, but if you play at home or docked, you can have some fun. It’s not an optimal way to play JDM, though.

Unreal Engine bugs, in my game?

Can my blog post be complete without highlighting obscure bugs? Of course not 🙃

While tailoring the settings to my liking I noticed that my game was annoyingly dark. I narrowed it down to the Shadows Detail setting – on High, the game is properly bright, but that setting is too much for my GPU. On Medium, I have good performance, but everything is dark.

Lowering Shadows details lowers their draw distance, and so lights draw at a lower distance too – this makes sense. However, they clearly shouldn’t be dimmer even at a close range! For this, I could leverage the fact that JDM uses Unreal Engine 5, and dive into the code directly.

The light draw distance is controlled by a r.LightMaxDrawDistanceScale cvar. Medium Shadows set this value to 0.5, while High and above leave it at the default 1.0. This value is then used to calculate the final brightness of the light source in GetLightFadeFactor (comments added by me)

float GetLightFadeFactor(const FSceneView& View, const FLightSceneProxy* Proxy)
{
  FSphere Bounds = Proxy->GetBoundingSphere();

  const float DistanceSquared = (Bounds.Center - View.ViewMatrices.GetViewOrigin()).SizeSquared();
  extern float GMinScreenRadiusForLights;
  float SizeFade = FMath::Square(FMath::Min(0.0002f, GMinScreenRadiusForLights / Bounds.W) * View.LODDistanceFactor) * DistanceSquared;
  SizeFade = FMath::Clamp(6.0f - 6.0f * SizeFade, 0.0f, 1.0f);

  extern float GLightMaxDrawDistanceScale; // r.LightMaxDrawDistanceScale
  float MaxDist = Proxy->GetMaxDrawDistance() * GLightMaxDrawDistanceScale; // Max distance is decreased
  float Range = Proxy->GetFadeRange(); // Fade range is not
  float DistanceFade = MaxDist ? (MaxDist - FMath::Sqrt(DistanceSquared)) / Range : 1.0f; // Does this make sense??
  DistanceFade = FMath::Clamp(DistanceFade, 0.0f, 1.0f);
  return SizeFade * DistanceFade;
}

Do you see something wrong? FadeRange and MaxDist are both configurable per-light, yet only one of them is decreased as details decrease. As FadeRange indicates the area where the light should start fading down to zero intensity, this creates a noticeable problem – in an extreme case, where an artist sets FadeRange and MaxDist to equal values as they want the light to fade from 100% to 0% smoothly throughout its entire draw distance, this will cap the light at 50% intensity! I believe this is exactly what’s happening in JDM.

Funny enough, in Unreal Engine 5.5, Epic noticed this issue, and then… left it as-is to preserve “legacy behavior”.

// NOTE: Feels like we should scale fade range by GLightMaxDrawDistanceScale as well, but would change legacy behavior
float Range = Proxy->GetFadeRange();

Clearly, they haven’t thought of a case like this, where the “legacy behavior” is undesirable and visually broken.

As usual, the fix is trivial - simply scale Range by GLightMaxDrawDistanceScale, and the bug should be resolved! I reported this issue to JDM devs and it has been acknowledged, and might potentially be fixed in the future. I might also report this issue to Epic directly and showcase that their insistence on preserving the wrong behavior hurts games that don’t expect it.

What’s next for JDM?

The developers of Japanese Drift Master have published a roadmap for the next 9 months, promising more cars, features, and bug fixes. I enjoy the game in its current iteration a lot already, but there are a few technical things I’d like to see addressed:

1. Resolution scaling should be exposed as a slider, not only presets. This is what Tokyo Xtreme Racer does, and everyone is happy.
2. A lot of folks, myself included, end up accidentally running out of VRAM when ramping up the settings too high. A VRAM usage indicator in the menus would be nice.
3. With some tweaks, JDM could be a great Deck-ready game. I hope the promised performance updates deliver on that.

Personally, I’m glad to see a brand new contender in the racing games scene that is ambitious and (mostly) delivers on the promise, and on top of everything, it comes from my home country 🙃 Happy drifting!

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

This is a Research-style post – as I go through more games, I will keep updating it with new findings.

• Loyalty career bonuses
  • NFS Most Wanted (including Black Edition)
  • NFS Carbon (including Collector’s Edition)
  • NFS ProStreet
  • NFS Undercover (PS2)
• NFS Underground Magazine 22
• Post changelog

Loyalty career bonuses

Most games from the Black Box era grant a cash bonus if saves from the previous games are found. However, online information about this feature is incomplete, and games themselves have some bugs and leftovers related to that.

NFS Most Wanted (including Black Edition)

$10.000 is awarded if a save from NFS Underground 2 is found. On the PS2, the game checks for the following set of serials depending on the current build configuration:

• SLES-52725 in the European build.
• SLUS-21065 in the American build.
• SLPM-65766 in the Japanese build. Seems like Sha-Do Underground 2 does not give bonuses, unless this has been specifically addressed in the Japanese releases.
• SLKA-25241 in the Korean build.
• SLAJ-25054 in the Asian build.

NFS Carbon (including Collector’s Edition)

$10.000 is awarded if a save from NFS Most Wanted is found. On the PS2 (other platforms unconfirmed), this feature has a bug – by default, this feature only works with base Most Wanted saves, as the NTSC-U versions check for Most Wanted Black Edition using a wrong serial (SLAJ-25075), while PAL-E versions do not include a BE serial at all! I submitted a patch to the PCSX2 patch database to fix this.

The game also has a function to list Underground 2 saves that uses the same list of serials as Most Wanted, so it may have been planned to grant bonuses for either UG2 or MW saves. However, those remain unused, either intentionally or through an oversight.

NFS ProStreet

Carbon’s bug has been fixed in NTSC-U (but not PAL), and the game (at least in the old-gen releases) grants the player 3 Repair Markers and 1 Totalled Marker when saves from any of the following games are found:

• NFS Most Wanted
• NFS Most Wanted Black Edition (fixed in the PAL release with my above fix)
• NFS Carbon
• NFS Carbon Collector’s Edition

Once again, the game can detect Underground 2 saves, but this functionality remains unused.

This feature has a caveat – creating a new profile and starting the career through the START option will NOT grant you loyalty bonuses. You must start a new career through the NEW CAREER option.

NFS Undercover (PS2)

Exient’s PS2/Wii version of NFS Undercover is NFS Carbon in disguise, and so the code carries over all the checks from Carbon (including a wrong serial for MW Black Edition). However, these go unused, and the game grants no loyalty bonuses at all.

NFS Underground Magazine 22

For my NFS Underground playthrough, I looked into the infamous Drift Score magazine unlock conditions. Turns out they were bugged, and I now released a SilentPatch for PC and PS2 versions of the game fixing this bug, as well as a few others.

Due to the significance of this bug fix, I detailed it in a separate post.

Post changelog

• March 12, 2025 – NFS Underground Magazine 22 issues researched.
• February 22, 2025 – initial version. Later edited to clarify missing MW Black Edition serials in PAL releases of Carbon and ProStreet.

Introduction

It’s been 18 years since the last release of a Tokyo Xtreme Racer game outside of the two not-so-well-received mobile installments. This is about to change, as Genki is releasing a new TXR game in Steam Early Access on January 23rd:

A few days ago, I received a review key for the game and was given a free hand to play and inspect it however I wish; a press kit was also sent to me (thanks, folks!), but as of the time of publishing this review, it’s stuck in transit 😬. I spent some time playing the game (and trying to break it, of course), and I ran a few benchmarks to determine how well my PC could handle the game in this state. Needless to say – I am more than satisfied with how well the game treated me.

If you are interested in a more gameplay-focused review, you might want to check Adam’s review of the game on The Drive before continuing with my post. In my review, I’m taking a different approach: I will focus on the technical experience, scalability, options, and performance. I’m no Digital Foundry, but my findings should still help players pick the optimal settings to play the game smoothly on their PCs. Believe me – this game is extraordinarily scalable, much more than I initially expected.

The game

If you’d rather jump to reading the technical overview of the game right away, go ahead and skip to The technicalities.

Let’s get back to the basics. What is Tokyo Xtreme Racer anyway? Perhaps you know this series under a different name, as throughout the years, different publishers gave it many, many different titles:

• Tokyo Xtreme Racer is the US title, most widely used out of all.
• Shutokō Battle is the original Japanese title.
• Tokyo Highway Battle is the name given to a 1996 PS1 game published internationally.
• Tokyo Highway Challenge is the name given to the two Dreamcast games published in Europe.
• Street Supremacy is the name given to a 2005 PSP game published internationally.
• Import Tuner Challenge is the name given to a 2006 X360 game published internationally.
• Like a cherry on top, the two Tokyo Xtreme Racer: Drift games are technically not part of the Shutokō Battle series. Instead, they belong to a spin-off series, called Kaidō Battle.¹

Not confusing at all, right? Thankfully, this upcoming release is free of this mess: it’s simply called Shutokō Battle in Japan and Tokyo Xtreme Racer everywhere else. Phew.

Fret not, though, as moving forward things are not this complicated. In fact, the core gameplay loop in all TXR games is simplistic: you cruise at night around the highways located (for the most part) in Tokyo, flash your headlights at the rival cars to challenge them to a race, then overtake them and stay in front for long enough to win. If you’ve ever seen any of the “highway battle”-esque mods for games like Assetto Corsa, Tokyo Xtreme Racer is the series that inspired them all.

My personal experience with TXR isn’t too broad: I only started playing these games recently and only got up to the first PS2 game, TXR Zero, so I wouldn’t be able to tell you yet how well the newer games (especially ITC) play. Regardless, the 2025 Tokyo Xtreme Racer delivers much of the same qualities as the classic games: you start with a bunch of money and a few cars to choose from, you defeat a few easy rivals, upgrade your car (and eventually get a new one), and make your way to defeating new teams with progressively faster drivers.

The core of the game is exactly as simple as it sounds, but it’s presented in a way that doesn’t get old and makes you want to race more. I started my playthrough in a tiny Suzuki Swift that defeated the first few teams of rivals on the famous C1 Route without much trouble, before unlocking the Shinkanjo, Wangan, and Yokohane routes. As the game is in Early Access, it’s not yet content complete: it currently features 50 cars, and about half of the game’s planned rivals, at the moment sitting at around 200. Much like in the older games, each rival has their backstory you get to learn as you defeat them – the game is light on a concrete “story”, but those rival backstories are the one thing tying the lore of the series together.

What makes this game (and the series in general) tick is the vibe. Much like NFS Underground is remembered for its immaculate representation of the tuner culture, Tokyo Xtreme Racer immerses you in the environment of the infamous Japanese highway racers. You find yourself looking for the best way to tune your car for each segment of the highway, make it look and drive well, and constantly wondering what car you’ll be challenging on your route next.

Or, if you want to just cruise on the Wangan and soak in the energy of a wide, mostly-empty highway at night, you can – in the 2025 Tokyo Xtreme Racer this is made even easier by the addition of a toggleable autopilot. It’s a bit of a missed opportunity that the game doesn’t currently feature a Photo Mode or any sort of customizable camera, as it could go very well with the automatic cruising. But hey, we are still in Early Access: other than the other half of the game, those are the exact kinds of things that perhaps can make their way into the game during this period.

The technicalities

Enough on the gameplay itself, as I don’t intend this to be a review of how the game plays: I wish to focus on how the game works. The main point of this review is to detail my experience with the game in its current state. The version I tested is the 0.10.0 Early Access Version. It has also been updated during the weekend as I was writing this review, but all benchmarks were done on the most up-to-date version. The build I am testing may or may not be the same as the launch build once the game releases on the 23rd.

Game engine and my experience on an underpowered GPU

The 2025 Tokyo Xtreme Racer is built on Unreal Engine 5.4, which has initially been met with a lot of skepticism; for a good reason, considering that numerous recently released games using Unreal Engine 5 are plagued with stutter and subpar performance even on the top end GPUs. I had my own reasons to worry – the game’s minimum system requirements list an Intel Core i7-7700 and an NVIDIA GeForce GTX 1050Ti. On the CPU front, I was more than ready with my Intel Core i9-12900K, but not so much on the GPU front with my NVIDIA GeForce GTX 1070. A few Unreal Engine 5 games I tried ran terribly, so I was ready to be miserable. I also remembered my adventures with EA Sports WRC showing artifacts on my GPU, even though the GeForce 10 series was within the minimum system requirements.

Considering the minimum requirements state they target Low graphics options at 1080p, I expected to be confined to a mix of Low and Medium settings. Instead, I am running the game at a stable 60 frames per second at:

• Native 1080p (no upscaling)
• FXAA
• Global Illumination on Medium (which disables Lumen Global Illumination)
• Textures on Ultra
• All the other options on High

All screenshots posted above were also taken at these detail settings, so albeit not maxed out, they still look great.

Needless to say, when I shared that news online, people were positively surprised and the perception of the engine of choice shifted immediately. Turns out, not every UE5 game has to run poorly on older graphics cards. Not only that, but I did not observe practically any shader compilation stutter or traversal stutter!

This news also benefits those with more modern cards – after all, if a GTX 1070 from 2016 can run the game comfortably on High details, anything newer can likely max the game out without much trouble.

In-game graphics options

Tokyo Xtreme Racer comes with a fairly standard set of Graphics Settings that conform to the default Unreal’s scalability options. A few additional options are present though:

In this section, I will provide a comparison between all available presets, and elaborate (with examples) on the graphical settings that make the most difference. Some of the options seem to make no difference, so it’s good to isolate the meaningful ones!

For now, I will be only showcasing the visual differences. For benchmarks, scroll down.

Anti-Aliasing and Upscaling

Most notably, Anti-Aliasing options are not like a typical UE5 game: you can select between None, FXAA, TSR, and (on supported hardware) DLSS. There is no forced TAA, and upscaling options are independent of Anti-Aliasing, which means the game can have a perfectly sharp and stable image! Unfortunately, the upscaling options cannot go above 100%, only below – so supersampling is not possible without the config file changes. DLSS can be used as both an upscaler and an anti-aliasing solution: setting the AA mode to DLSS, and keeping the Upscaling Quality at Native will effectively give you DLAA.

Graphics Quality presets

The game comes with a standard set of 4 presets: Low, Medium, High, and Ultra. They act as a good baseline for further configuring the game to your liking, with one nasty caveat – while these options do not affect Anti-Aliasing, they do affect Upscaling, setting the scales to 50%, 58%, 67%, and 100% respectively! This makes for a pretty poor representation of how the options truly look, so in my comparison below, and later in the post, I will always stick to using FXAA and 100% resolution scaling. This way, the screenshots and benchmarks will be consistent and more representative of how the options affect the game.

The presets look as follows. Click on the images to open them full screen:

• On the Low preset shadows, reflections, and post-processing practically do not exist. The game doesn’t look bad, but something is definitely missing.
• On the Medium preset dynamic shadows, reflections, and a subtle vignette effect appear. The draw distance is also visibly boosted.
• High preset introduces Lumen Global Illumination and Lumen Reflections, giving more light to the entire scene, and replacing sharp screen-space reflections on cars and in the tunnels with software ray-traced reflections that account for the material roughness. Shadows are also even higher resolution. Bloom is now applied to distant light sources like lamposts and building windows.
• Ultra preset further bumps up the draw distance and shadow resolution, and introduces self-reflections: you can see that on the first comparison, the third brake light reflects in the rear windshield.

Individual options and recommended settings

For each option, I’ll explain what it does (if I managed to figure it out), and my recommendation on the setting to use. Of course, your mileage may vary depending on your PC specs.

• Draw Distance – self-explanatory, higher settings make further objects draw on-screen. Option I recommend: As high as you can.

• Post Processing – higher settings enable a vignette filter and bloom on the light sources. However, I did not see any differences past High, visual or performance. Option I recommend: High.

  

  

  

  

  

  

• Shadows – at Low, only static shadows exist. At higher settings, shadow resolution is bumped up, and seems like more light sources cast shadows too. Ultra shadows appear to be very heavy, although they look the best. Option I recommend: High, or Ultra if you can handle it.

  

  

  

  

• Global Illumination and Reflections – at Low/Medium, these options use screen-space effects. At High/Ultra, Lumen ray-tracing features enable, impacting the look of the entire scene at the cost of performance. These two options are closely related to each other and also the ones my non-RTX card could not handle right. I’ll be elaborating on Lumen separately in the next section. Option I recommend: High or Ultra if want Lumen, otherwise Medium GI and High Reflections.

• Effects – this option appears to change the way the sky looks, perhaps switching between a pre-rendered image and volumetric clouds. However, the change is so subtle I struggled to see any difference. Option I recommend: High if you want peace of mind, Low if you’re looking for performance.

• Shading – this option, undocumented even in Unreal docs, appears to change the used shader quality. I couldn’t spot any difference between the options, visual, or performance. Option I recommend: Any.

• Texture – makes the game load higher resolution versions of textures, and enables progressively higher Anisotropic Filtering. Option I recommend: You will probably be fine with Ultra, even on Steam Deck I use that without issues.

More about Lumen

The Global Illumination and Reflections options appeared to be a source of confusion, but thankfully, they actually follow the default behavior of Unreal Engine 5:

• Lumen Global Illumination toggles at Global Illumination High.
• Reflections use screen-space reflections at Low/Medium and Lumen (ray-traced) Reflections at High/Ultra. However, Lumen Reflections require Lumen GI, so they are enabled only if Global Illumination is also set to High/Ultra.

To clarify – Lumen is the Unreal’s implementation of ray tracing. Unsurprisingly, it is also the main performance hit in the game: for example, I run the game just fine with Global Illumination Medium and Reflections High, because then Lumen is inactive. This effect is done purely in software (in compute shaders), that’s why it works on my non-RTX GPU and is just very demanding. As far as I can tell, there is no hardware ray tracing in the game.

Is ray tracing worth the performance hit in this game? The effects seem to be negligible in open spaces, but quite noticeable in tunnels and on car reflections. Lumen GI makes the light bounce off all surfaces and contribute to how nearby objects are lit, which is most noticeable when two cars are close together and under a strong source of light. With Lumen Reflections on top, screen-space reflections are disabled and replaced with ray-traced reflections, so even off-screen objects can contribute to the final look. Material roughness is also accounted for, so reflections like the ones in the tunnels are no longer crystal clear; instead, they are realistically fuzzy and scattered.

In some cases, possible minor oversights surface when playing without Lumen. For example, the road in this tunnel is correctly lit when not using Lumen GI, but the walls are not:

How well does the game run? Benchmarks

I said earlier that my GeForce GTX 1070 handles the game more than fine at native 1080p, but how is that reflected in metrics? I benchmarked the four graphical presets (at 100% Scaling, as I mentioned at the beginning of the previous section) in a 45-second long drive around the C1 Inner Loop, starting outside and heading through multiple tunnels.

The results show the game is quite scalable, as was said earlier:

Low and Medium are obviously playable and they fare great, High and Ultra are both noticeably slower. However, since both these presets include Lumen, I ran two more tests, where I kept the preset as-is, but turned the Global Illumination down to Medium in order to disable Lumen GI and Reflections:

IMO these results are great and show exactly why I considered the game playable on High details. Ultra is still quite slow on this machine (yet still faster than High with Lumen), but as noted in the detailed options breakdown, it’s mostly due to Ultra Shadows being demanding. Obviously, on PCs with newer and beefier GPUs, Lumen will not drop the performance down to unplayable framerates, but the performance hit will be measurable regardless of the GPU.

Out of sheer curiosity, I also attempted to run the game on an older PC I have access to, with Intel Core i7-6700K (one generation under the minimum requirements) and NVIDIA GeForce GTX 550Ti (half a decade under the minimum requirements), and… it works! I would not call it playable, but it’s hard to expect that from a 2011 GPU. Although 60 FPS is achievable on the lowest details and with upscaling, cars exhibit graphical artifacts, and Unreal warns the user about outdated drivers on every launch (since NVIDIA stopped supporting Fermi cards in 2018).

Steam Deck experience

Like numerous other people who got the game early, I also took the opportunity to test TXR on my Steam Deck. Looking at the above benchmark, it shouldn’t be a surprise that the game works fine! On the lowest details, the game runs without any issues whatsoever and never dips under 60 frames per second. It has enough headroom to accommodate a few options (like Global Illumination, Draw Distance, and Textures) to be bumped up to Medium, too.

The good:

• On the lowest details, Deck has no issue keeping stable 60 FPS.
• 1280x800 is supported out of the box, so there are no black bars on the top and bottom of the screen.
• The game handles touch and gamepad input just fine, although, at the time of writing this review, no official presets were present yet. However, manually selecting a gamepad preset worked well.
• Native Steam Deck prompts are present!

The bad:

• The biggest issue of them all – at the moment, the game slows down when it’s running at under 60 FPS. This makes the 40Hz mode on the Deck unusable but also means that those with lower-end PCs do not have the option to target 30 FPS.
• The UI is a bit small for the Deck, although it’s still readable if you squint.
• Unsurprisingly, the game drains the battery pretty fast.

Overall, would I recommend getting the game to play on Deck? Yes! The game already runs very well on this device, and it can only get better over time. In fact, its performance on Deck already got better between the time I first tried it last week, and now, as the latest pre-release patch noticeably improved the game’s performance.

What’s next for TXR?

Once TXR launches on Steam on the 23rd, it’s expected to stay in Early Access for four months. During this time, we may expect to see the second half of the game completed, and more cars added. The console ports were not ruled out, but their existence depends on how well the game will be received on PC.

As for my personal wishlist? I would love to see an option to import custom decals in the Livery Editor. The selection of decals is already quite wide (and it will likely expand later in the EA phase), but, given my modding spirit, I already could not help but take advantage of the fact it’s an UE5 game:

For now, I’ll continue racing! I’ll keep my fingers crossed for this game’s success, as it delivers exactly what you would expect from a Tokyo Xtreme Racer game. It’s old school at heart, and in the age of enormous live-service games, it’s a great thing.

As a new Tokyo Xtreme Racer is just around the corner, I spent some time playing the classic TXR games. As I go through the games in order, I wanted to note some things I encountered.

This is a Research-style post – as I go through more games, I will keep updating it with new findings. This post is reserved for the “classic” games only; I will most likely have another post about the 2025 Tokyo Xtreme Racer in the future!

• Tokyo Xtreme Racer (Dreamcast)
  • Faulty car unlocks
• Tokyo Xtreme Racer 2 (Dreamcast)
  • Aspect Ratio inconsistencies
• Tokyo Xtreme Racer: Zero (PlayStation 2)
• Post changelog

Tokyo Xtreme Racer (Dreamcast)

Faulty car unlocks

When localizing Shutokō Battle for the West, Crave also changed several gameplay aspects of the game. Unlike in the Japanese release, in Tokyo Xtreme Racer you unlock several cars by beating the opponents who own them. One of those rivals is Midnight Cinderella, whose TYPE-FDD can be purchased after you win the race.

Even though I obviously beat this rival, the car never unlocked for me. I never ended up figuring out the exact cause of this, but I know I wasn’t the only one. Other people also encountered this issue, others had the rival cars unlock too early before they defeated the rival driving them.

This doesn’t surprise me in the slightest – considering how this aspect of the game has been changed by the publisher during the localization process, it is highly likely they implemented it wrong and introduced a few rare bugs.

Tokyo Xtreme Racer 2 (Dreamcast)

Aspect Ratio inconsistencies

While TXR2 has a “native” widescreen option, named Wide TV, its behavior is strange. When Dreamcast (real or emulated) uses a VGA output, this option doesn’t work at all. In VGA, the game always outputs a 4:3 image, and it looks exactly how you would expect:

When using Composite or RGB outputs, the option works, but the results are rather strange:

I did not get the chance to look into the game’s code, so I started experimenting with stretching the images instead, using the formulas from the Pixel aspect ratio page on Wikipedia. Treating Dreamcast’s output signal as 720x480 and rescaling from there, I was able to get better results:

So what’s going on with Normal TV? I initially couldn’t figure out the maths behind it, but then I figured I’d try to scale it, incorrectly, with an inverse of the scaling used for Wide TV: \({720 \over 853} \approx 0.844\). This… gave me an exact match!

This makes me suspect that the game scales for Composite output more or less like:

float arCorrection = 853.0 / 720.0;
if (WideTV)
   AR *= arCorrection;
else
   AR /= arCorrection;

If this is true, it’s completely incorrect and is likely producing incorrect image on CRT TVs. If I look into the game’s code in the future, I might be able to confirm or deny this suspicion properly, but as of the time of writing this post, I haven’t tried to disassemble any Dreamcast games.

My conclusion: When emulating, don’t bother with the in-game widescreen option. Just use VGA output and a widescreen cheat.

Tokyo Xtreme Racer: Zero (PlayStation 2)

Nothing here yet, but I published a few PCSX2 patches for this game! Head over to Tokyo Xtreme Racer: Zero if you want to take a look.

Post changelog

• January 13, 2025 – initial version.