NFSIISE: a C wrapper for Need For Speed II SE with 3D acceleration

What the wrapper replaces and what it adds

NFSIISE is a cross-platform wrapper for the Need For Speed II SE game with 3D acceleration and a TCP protocol. In practical terms it takes the original 1997 game and swaps its executable for a C implementation that talks to SDL2 and OpenGL instead of the period-specific DOS-era stack.

The features the README lists as working are the concrete change. Game controllers, with the note that reconnected controllers should be the same. Force feedback, tested on Linux. TCP and UDP connection, which replaces the original modem play. Serial port connection, kept for anyone with the hardware. Brightness control. And sound.

One feature is explicitly gone. Modem connection will never work again, because the feature has been removed from the assembly code. That is an honest limitation rather than a bug, and it matters for anyone who wants the original network mode.

The function keys are mapped to gameplay toggles, which tells you how much of the original control scheme the wrapper preserved. F1 toggles rain, F2 changes car detail, F3 the view distance, F4 the horizon, F5 and F6 toggle the HUD for players one and two, F7 the mirror, F8 music, F9 sound effects, F10 brightness, and F11 and F12 reset the car for the respective player.

The repository is small in terms of what it contains: a src directory, a compile_nfs script, a gitmodules file and a directory holding the game files themselves.

Cloning and the 32-bit build on Linux

The clone step has one instruction that people miss, because the README puts it as a reminder rather than a step.

git submodule update --init --recursive

Building on x86 needs a compiler that can generate 32-bit code for x86, set through the CC environment variable, plus 32-bit OpenGL development files and drivers, 32-bit SDL2 development files, and the Yasm assembler. That is a specific and dated dependency set, and it is the price of keeping the original data formats and the original binary layout intact.

On Debian and Ubuntu the 32-bit side has to be enabled first, and the README gives the commands to run as root.

dpkg --add-architecture i386
apt-get update
apt-get install libsdl2-dev:i386 gcc-multilib yasm

Then the build is a single script. Editing the compile_nfs script is how you change what gets built, and executing it produces the executable inside the Need For Speed II SE directory. The script takes an argument that selects the target.

./compile_nfs

That is the native build for Unix-like systems, and the README names Linux and macOS up to Mojave. A Windows build is a cross compilation.

./compile_nfs win32

For that path on Arch, the README says to install mingw-w64-gcc and mingw-w64-sdl2 from the AUR. The WSL route works too, with mingw-w64 installed inside the subsystem.

The WSL cross-compile path and the SDL include fix

The README has a long section on building for Windows from WSL, and the reason it is detailed is that the SDL packaging is the part that trips people up.

Two packages go in.

sudo apt install mingw-w64
sudo apt install gcc-multilib

The instruction that catches people is not to install SDL through apt-get. Instead you take the package from the official SDL releases page, get the build with the mingw suffix, and inside the package folder use the one called i686-w64-mingw32. You then either copy the include, bin, lib and share directories into your system files, which the README says is not recommended, or you edit the compile_nfs script to point at them.

The edit is three lines. On line 27 the flags line is changed to add an include directory before the closing quote.

      C_FLAGS="$COMMON_FLAGS -O2 $CPU_FLAGS -I/path/to/include/folder"

The same include parameter goes on line 23. On line 39, in the linker invocation, a library path is added after the SDL2_test flag, so the linker can find the 32-bit import libraries.

The README then explains the runtime step. Windows will report a missing DLL when you launch the executable, and you take that DLL from the same SDL package link, this time the win32-x86 package, and copy it next to the game's executable.

This is the least pleasant part of the project, and it is worth knowing before you start: the cross-compile is not a turnkey script, it is a script you edit.

ARM, Android and the Clang and lld requirements

The non-x86 story is where the project is unusual, because it means running a 1997 game on a Raspberry Pi or an Android phone.

The constraints are stated clearly. The game can run on ARM devices and on Android, but only 32-bit little-endian CPUs are supported. Performance is a bit lower than the original assembly code, and the code may be less stable than the assembly due to possible translation bugs. That is a fair description of what a translated binary can be.

The requirements for the non-x86 build are SDL2 in 32-bit and OpenGL in 32-bit, with a Clang compiler and the lld linker, and the linker must generate 32-bit output.

On Linux the build is a different argument to the same script.

./compile_nfs cpp

The cpp argument selects the Clang path rather than the GCC one. On Android the steps are longer: install the SDK and NDK for the chosen SDL2 version, set the ANDROID_HOME and ANDROID_NDK_HOME environment variables, download the SDL2 source and unpack it, create a symlink to the unpacked SDL2 directory at src/Android/app/jni/SDL, and then run the script with the android argument, or android install to add the install step.

./compile_nfs android

The separate cpp target is the interesting engineering decision. Rather than trying to make the original assembly run on ARM, the project recompiles from a C translation, which is why the lld linker and the Clang compiler are hard requirements there.

Supplying the game data and the configuration file

The wrapper does not include the game, and it needs the data from the Special Edition release. You copy the fedata and gamedata directories from the original CD-ROM into the Need For Speed II SE directory, and the README is emphatic that the game needs data from Need For Speed 2 Special Edition, otherwise you get a MOVIE FILE NOT FOUND message.

There are several filesystem details that matter on Unix-like systems. The files copied from the CD-ROM must have small letters, and the README provides a convert_to_lowercase script for that. You can delete unnecessary files such as the fedata/pc/text/text.* set, because the TCP version uses new files in the root directory. The language is set by editing the first line of the install.win file with an editor that does not modify the last line or the line endings, leaving the 4nn in place and changing only the language name, with english, french, german, italian, spanish and swedish listed as the choices.

The settings live in ~/.nfs2se, or %AppData%\.nfs2se on Windows. On the first run the nfs2se.conf.template is copied there, and on Windows there is an open_config.bat that opens it in notepad.

For Android, the files go into /sdcard/NFSIISE or /storage/emulated/0/NFSIISE, which you create first, and the config file has to be renamed from the template to nfs2se.conf before copying. The list is gamedata, fedata, install.win, text.* and nfs2se.conf.

The README also documents a Batocera Linux path in detail, since that is a real use case for the project: take the Windows build from the releases, unpack it, copy the original data directories in, create an autorun.cmd containing the CMD line for the executable, rename the directory to the .pc suffix, place it under the Batocera roms directory, and update the gamelists from the controller. The result is emulated through Wine, tested with Batocera version 39.

Where NFSIISE is the wrong choice

The first limitation is the 32-bit requirement, and it is not going away. Everything about the build assumes a 32-bit x86 or 32-bit little-endian ARM target, which on Linux means multilib packages and 32-bit SDL2 and OpenGL development files. On a modern distribution the older the release, the more of that stack has to be sourced by hand, and the README's own advice for older Linux releases is to use the Flatpak or build from source, which for this project means assembling the 32-bit toolchain yourself.

The second is that you must own the game. The wrapper ships the engine and the tooling, not the data, and the Special Edition data is required rather than optional. Anyone hoping for a self-contained download will not find one.

The third is the macOS ceiling. The README names macOS up to Mojave for the native build, which is an old operating system relative to the last push on 2026-05-01, and there is no mention of Apple Silicon. A macOS user on current hardware is effectively in the cross-compile or virtualisation case.

The fourth is the build scripts. The Windows path is documented as a set of manual edits to compile_nfs, with specific line numbers, which is fragile in a way that a maintained script would not be. Line numbers shift when the script changes.

The fifth is the project shape. There are no GitHub releases beyond v1.4.0 dated 2024-03-16, with v1.3.0 from 2022 and v1.2.4 from 2018, and the release names are self-deprecating, calling them the fifth, fourth and third stable release. The last push was on 2026-05-01, so the repository is alive, but the release cadence is slow and the numbered releases suggest an occasional-maintainer model rather than a team.

Licence, maintenance and what you inherit from the original game

The wrapper code is under the MIT licence, with the LICENSE file at the root, and the language is C. The topics list names the game and the technical angle rather than a general category.

What the MIT licence covers is the wrapper, and it is worth being precise about the boundary. The original game code, its data files, its music and its artwork are not relicensed by this repository, and the Special Edition data comes from your own CD. The result is a tool distributed on permissive terms that lets you run a commercial game you already own, which is a different proposition from a port of a freely licensed game.

The maintenance picture is modest. The repository is not archived and the last push was on 2026-05-01, and the release history is v1.4.0 from March 2024, v1.3.0 from March 2022 and v1.2.4 from May 2018. The number of years between the last release and the last commit suggests the project gets attention when its author needs it, which for a wrapper around a fixed piece of software is arguably the right level of activity.

The running cost is also modest. There is a Linux package in the AUR, and the Windows build is distributed as a zip under Releases, with the Batocera instructions pointing at a file named nfs2se-win32-v1.4.0.zip. Neither route needs a server or an account, and the whole thing runs offline once the data is in place.

Editorial conclusion

NFSIISE suits someone who owns Need For Speed II Special Edition and wants it running on a modern machine with a controller and a network game, since the wrapper adds 3D acceleration and TCP where the original had neither. It does not suit a 64-bit only workflow, because the whole build is 32-bit and needs multilib packages on Linux. Verify that you have the Special Edition data rather than the plain release first, because the game refuses to start on the base edition and you need the original CD to supply it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zaps166/NFSIISE on GitHub