OpenJKDF2 reimplements a 2002 game engine function by function

The engine is reimplemented, the assets are not

OpenJKDF2 is described as a function-by-function reimplementation of DF2 in C, and the first thing to understand is the division of labour. The project does not include any original game assets, and a valid copy of JKDF2 is required, which can be purchased from GOG or Steam. The GOG version is recommended because it is DRM-free and includes the soundtrack in Ogg Vorbis format. The project also points at a WebAssembly demo hosted elsewhere, so you can see the reimplementation running before you buy anything. That boundary is what keeps the project on the right side of the law, and it also defines its audience. This is not a game distribution, it is a preservation and platform port effort for the engine, and the people who benefit are the ones who want the game running on hardware it never shipped for, or who want to read the code. The licence is a custom one that GitHub cannot classify, so the LICENSE.md file at the root is the authority rather than the badge.

The port matrix is the map of the project

The platforms table is the most informative section in the README, and it is unusually honest about what exists. The supported configurations are a 64-bit Windows build with SDL2 and OpenAL using OpenGL 3.3, a macOS x86_64 and AArch64 build with the same renderer where all release packages include both Intel and ARM64, a 64-bit Linux build with SDL2 and OpenAL, an ARM64 Android build using OpenGL ES 3, a Nintendo DSi port with hardware rendering and software audio that is extremely RAM-limited and supports emissive palettes, a Dreamcast port on KallistiOS with basic 3D rendering, no emissive palettes, and hardware accelerated audio including soundtrack and cutscenes, and an Emscripten and WebAssembly build with WebGL 2 and OpenGL ES 3 that runs in a browser. The WebAssembly row carries a note worth reading twice, since WASM only supports 32-bit pointers, so that build will likely be less buggy than the 64-bit one but less performant. There are also four configurations in progress or planned that are not started, including iOS with Metal, the Switch libnx target, a 32-bit Windows build with OpenGL 3.3 and a faithful Direct3D 3 decompilation with the original bindings. And three configurations are deprecated, including the 32-bit Linux builds that memory mapped JK.EXE as a binary blob and the Win32 hooked build that patched JK.EXE to load a replacement DLL.

Sources come from another remaster, not from guesswork

The methodology section explains where the knowledge came from, and it is the answer to the question every reimplementation has to face. Files are organized as closely to the original game as possible, based on symbols from the Grim Fandango Remaster Android, Linux and macOS port, as well as scattered assertions from various other games. The bulk of research and documentation occurs in IDA, and every function has been identified to a file prefix, for example stdHashTable_, with a corresponding .c and .h file. RenderDroid functions with the rd prefix and LEC stdlib functions with the std prefix are 90 percent canonically named, based on the symbols from Grim Fandango Remastered. The idea is that a second, already decompiled and cleanly structured codebase supplied the naming and structure conventions, so the Jedi Knight functions could be given a home before their bodies were fully understood. The repository carries the supporting files for that effort, including symbols.syms and several symbol variants, an ida_copypaste_funclist file, an analyze.py script, and a wontimpl.txt listing what is not yet implemented.

Your data directory has to look exactly like this

Because the engine reads the original game files in place, the directory layout is part of the interface, and the README spells it out. At the root you need JK.EXE, a MUSIC directory, an episode directory holding the JK1.gob, JK1CTF.gob and JK1MP.gob files, the openjkdf2-64 executable, a player directory, and a resource directory containing Res1hi.gob, Res2.gob, jk_.cd and a video folder full of SMK files:

├── JK.EXE
├── MUSIC
├── episode
├── openjkdf2-64
├── player
└── resource
    ├── Res1hi.gob
    ├── Res2.gob
    ├── jk_.cd
    └── video
        ├── 01-02A.SMK
        ├── 03-04A.SMK
        └── 57A.SMK

On Linux the README warns that paths and filenames may be case-sensitive, which is the kind of detail that costs an afternoon if you miss it. The soundtrack handling has its own rules. Support for playing the original soundtrack from Ogg Vorbis files is primarily for the GOG and Steam versions of the assets, original disk soundtracks can be loaded from MUSIC/1/Track<2..8>.ogg and MUSIC/2/Track<12..12>.ogg for each disk, and if files are missing the engine falls back to a GOG track number from MUSIC/Track<12..32>.ogg. Dumping the soundtrack from the discs at install time is planned for a future release and is not currently implemented.

What is still missing, and how you contribute

There is a short section titled what is not implemented yet, and it is short enough to quote in full because it says more about the project's honesty than a long list would. Load Configuration and Save Configuration in Setup, Controls, Options is not done, and using plus or minus to resize the screen is not done, with the note that with SDL2 the resolution auto-resizes to the window size instead. Contributions in the form of code cleanup and documentation are highly welcomed, and CONTRIBUTING.md is said to list what kinds of cleanup tasks still need doing, which is a useful signal about where the project wants help. The project is not currently accepting monetary donations, although detailed bug and crash reports are always appreciated, including bugs or crashes involving mods. The repository carries a wide set of per-platform build and packaging scripts, build_linux64.sh, build_win64.sh, build_android.sh, build_dreamcast.sh, build_ios.sh and the matching build_run variants, along with distpkg scripts for each platform and a Nix flake, so building a given target is a matter of running the right script.

Maintenance state and the scale of the effort

The project is not archived and the last push was on 2026-10-13, with releases v0.9.9 on 2026-07-05, v0.9.8 on 2025-12-06 and v0.9.7 on 2025-12-03. The version numbering is worth reading carefully, because a project with a long list of platforms and a function-by-function reimplementation is not going to reach 1.0 in any conventional sense. There is also a note that Linux building works on AArch64 with a Raspberry Pi 4 using llvmpipe, but that V3D GLES has trouble with palettes, which is the kind of constraint that only appears when someone actually runs it on that hardware. The tree itself shows the scale, with 3rdparty/ holding vendored dependencies, byacc/ and flex/ carrying the original versions of those tools used for COG script parsing, cmake_modules/ and cmake_modules_linux/ for the build system, packaging/ for platform packages, lib/ and src/ for the code, and a scripts/ directory. A separate HOOKS.md covers running with the original JK.EXE and DirectX through hooks, which is the older approach the deprecated builds used.

Editorial conclusion

Adopt OpenJKDF2 if you want to run or study the Jedi Knight: Dark Forces II engine on a modern platform, or on hardware the original never ran on, and you own a copy of the game. Do not adopt it expecting the game itself, since no original assets are provided and a valid copy is required. Verify first that your copy of the assets has the directory layout the README describes, including the episode and resource folders and the MUSIC directory for the soundtrack, that your platform configuration exists rather than being listed as not started, and that you have read the licensing terms in the LICENSE.md file before redistributing a build.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. shinyquagsire23/OpenJKDF2 on GitHub