NBA Live 2005 in 2026

Senior year of college, my friends and I played an enormous amount of NBA Live 2005. Not casually. We ran franchises, simulated whole seasons, argued about trades that existed only in our save files, and talked trash for hours around one PS2. Somewhere in there I finished a month ranked in the top five on PS2 online, back when the ladder reset every month and that number meant something to exactly six people.

The game is why RetroLive exists. The 2004-05 season is frozen for us: Garnett in his prime, Iverson and Carmelo being themselves, a young LeBron starting to take over, and Nash winning MVP in Phoenix the season after leaving Dirk in Dallas. That era belongs to a specific stretch of my life, and building a sim around it was the only way I could think of to keep visiting.

So when I found my original CD, I wanted the real thing, not an emulator and not a memory. I wanted the disc I bought in 2004 running on the laptop I own in 2026. It took four hurdles to get there.

A laptop running NBA Live 2005, showing LeBron James in a Cleveland All-Star jersey, with an external USB optical drive and the original boxed CD on the desk beside it. — The strip across the top is a modern gaming overlay, dutifully reporting network throughput for a game with nowhere left to connect.

It Would Not Boot

Installation was completely ordinary, which was the last ordinary thing that happened. I put the disc in, ran setup, watched a 2004 installer draw a 2004 progress bar, and got a working install in about two minutes. Then I launched it and nothing happened at all.

NBA Live 2005 ships with SafeDisc, the copy protection of its era, and SafeDisc depends on a Macrovision kernel driver called secdrv.sys. Microsoft blacklisted that driver years ago because it carried privilege-escalation vulnerabilities, and it has been absent from Windows since 10. The disc check has no driver to talk to, so it fails, and the game refuses to start no matter what compatibility settings you throw at it.

A security fix did this. Closing a real vulnerability quietly bricked every legally owned SafeDisc game on the planet.

The fix is not a crack. SafeDiscShim answers the calls that used to go to the driver, from user mode, installing nothing into the kernel. The copy protection still runs and still wins: the original CD has to be spinning in a real drive, and a mounted ISO fails exactly as it should. It restores the compatibility Microsoft removed and nothing else, which is the whole reason I was willing to use it.

The Controller That Was Never Missing

I wanted two players, so I bought two Logitech F310 pads. The first one worked immediately. The second one did not exist as far as the game was concerned, while Windows itself listed both without complaint.

The first thing to get right is the little switch on the underside of an F310, which selects D or X. It has to be on D, for DirectInput, because NBA Live 2005 predates XInput by a year: that arrived in 2005 with the Xbox 360 controller. In X mode the pad reports itself as something the game has never heard of and is simply invisible. In D mode the game recognizes it instantly, because it ships a profile for that exact controller.

The second thing took longer. DirectInput titles of this vintage enumerate every attached device once, at process startup, and never look again. I had been plugging in the second pad after launching, which in 2004 terms is asking the game to notice something that did not exist when it started. Connect both pads first and both work with zero configuration.

It was not a bug. It was a twenty-year-old assumption about when people plug things in.

The Flicker

This was the hard one. The game ran, both controllers worked, and the screen flickered badly enough during play to be unusable. I went through the obvious suspects in order: dropped the panel from 144 Hz to 60, turned off HDR, disabled variable refresh rate, disabled fullscreen optimizations, forced the game onto the integrated GPU so it was not rendering on one chip and displaying on another. Five changes, five restarts, no improvement at all.

Then I learned why. A Direct3D 9 game creates its device and latches the display mode at launch, and never rebuilds it. Change a display setting while the game is running and it has no effect whatsoever, which means every test has to be run against a full restart or it proves nothing.

I had not been ruling suspects out. I had been running the same invalid experiment five times.

With the display genuinely eliminated, the remaining suspect was the legacy Direct3D 9 path itself, which on modern Windows is a thin layer of nostalgia sitting on drivers that have moved on. DXVK replaces it by translating Direct3D 9 into Vulkan. It drops in as a single d3d9.dll next to the executable, patches nothing, and therefore coexists with the copy protection instead of fighting it. The flicker disappeared completely and has not come back. The nice irony is that DXVK exists to run Windows games on Linux, so I fixed a Windows game on Windows with a Linux compatibility layer.

Better Than I Remembered

The game was running at roughly 640x480, which in 2004 was fine and in front of a 4K panel is not. I set it to 1280x720, because 1280x720 multiplied by three is exactly 3840x2160, so every game pixel maps to a clean three-by-three block with no interpolation smearing across it. It is also true 16:9, so nothing stretches.

The larger win was anisotropic filtering, which the original engine never asks for. Court lines, floor logos, and crowd textures all blur badly at shallow angles without it, and forcing it to 16x through DXVK is a bigger visible improvement than the resolution change was. That and a handful of other settings live in a dxvk.conf sitting next to the executable:

# Borderless presentation rather than exclusive fullscreen, so
# alt-tab and minimize behave.
dxvk.allowFse = False

# 16x anisotropic filtering on every sampler.
d3d9.samplerAnisotropy = 16

# Sharpens textures slightly, without much shimmer.
d3d9.samplerLodBias = -0.5

# Vsync here rather than in the driver too, so it happens once.
d3d9.presentInterval = 1

# Physics and animation were authored around 60Hz, so running
# unbounded destabilizes gameplay timing.
d3d9.maxFrameRate = 60

# The engine handles Reset poorly, a common alt-tab crash.
d3d9.deviceLossOnFocusLoss = False

My favorite discovery is buried in DXVK’s defaults. It reports Intel GPUs as AMD, deliberately, to get around restrictions that early Intel integrated graphics used to trigger. In 2004, integrated Intel graphics were weak enough that games routinely gated their nicer effects behind a vendor check, and this game would likely have quietly dropped to a reduced path on my laptop’s Iris Xe. Twenty years later, a translation layer lies about the hardware on my behalf and the effects come back.

The modding community has a widescreen and windowed-mode plugin that would genuinely look better. It requires a no-CD patched executable, so I turned it down. Taking it would have meant giving up the one thing I actually cared about, which was that this remains my disc, running the way it was sold to me, with the copy protection intact and satisfied.

The Servers Are Gone

So it works. It looks better than it did on a CRT in 2004, both pads respond, and the whole setup is reversible: delete two files, uninstall one shim, and the machine is exactly as it was. Then I clicked into EA Sports Online, the PC version of the ladder I used to climb, and of course there is nothing there. Those servers were switched off a long time ago, and no amount of local configuration brings back a hostname that stopped resolving before some of my coworkers finished high school.

Which sounds like a challenge. I have started pulling the lobby apart to see what it actually needed, and the early finding is more encouraging than I expected: it was never really a game server. It authenticated you, showed you rooms, handed each side the other’s address, and then got out of the way while the two machines played each other directly. Reviving that does not mean reimplementing basketball.

To be continued.

TL;DR

A retail copy of NBA Live 2005 runs on Windows 11 with four fixes. SafeDisc fails because Microsoft removed the kernel driver it depends on, so a user-mode shim restores the compatibility without touching the copy protection, which still requires the real disc. Two DirectInput gamepads both work as long as the switch is on D and both are connected before launch, since games of this era enumerate devices only at startup. Screen flicker comes from the legacy Direct3D 9 path and is solved by dropping in DXVK, which translates it to Vulkan. Set the resolution to an integer fraction of the panel, force anisotropic filtering, and it looks better than it ever did.

Domain Language

Direct3D 9: The 2002-era Microsoft graphics API most Windows games of this generation were built against, still supported on modern Windows but no longer a first-class path.
DirectInput: The input API that preceded XInput. It enumerates attached devices once when a process starts and does not rescan, which is why a controller connected mid-game is invisible.
DXVK: A translation layer that implements Direct3D 8, 9, 10, and 11 on top of Vulkan, built for running Windows games on Linux and equally usable on Windows.
SafeDisc: A Macrovision copy protection scheme common in retail PC games of the 2000s, which depends on a kernel driver Microsoft has since blacklisted.
XInput: The controller API introduced alongside the Xbox 360 in 2005, and therefore one year too late for this game to know anything about it.