Jazz2 Resurrection is a C++ reimplementation that still needs the 1998 game files

A rewrite of the game, without the game

Jazz2 Resurrection is a reimplementation of Jazz Jackrabbit 2, the game released in 1998, written from scratch in C++ and described in the repository as a fully rewritten game with better performance and many improvements. It supports several versions of the original: the Shareware Demo, Holiday Hare 98, The Secret Files and Christmas Chronicles, and it partially supports some features of the JJ2+ extension and of MLLE. What it is not is a self contained game. No original assets ship with it, and on every platform the documented setup step is to copy the contents of your original Jazz Jackrabbit 2 directory into a Source folder next to the executable. That split is the defining constraint of the project and the thing to understand before anything else, because it means the download you install is an engine and the game data comes from your own copy of the 1998 release.

Three Windows executables and an OpenGL 3.3 floor

On Windows the setup is short. Install the Microsoft Visual C++ Redistributable, download the game, copy the original game directory into a Source folder, and run Jazz2.exe, Jazz2_avx2.exe or Jazz2_sdl2.exe. Three executables means three build variants, and the naming tells you the axes: a default build, an AVX2 build for processors that support those instructions, and an SDL2 build that goes through SDL rather than the native windowing path. The hardware floor is stated plainly. The game requires Windows 7 or newer and a GPU with OpenGL 3.3 support, and the documentation adds that game files should not be copied into Program Files, which is a hint that the game writes next to its data. There is also a first start quirk worth knowing before you think something is broken: the cache is recreated during the intro cinematics on the first startup and cannot be skipped, and because the intro sound effects need that cache, they are missing the first time the game runs.

Linux packages cover the major distributions

On Linux the game is available as a package, and the README lists coverage across the ecosystem: an Arch User Repository package, Debian and Ubuntu packages, a Flathub entry, a Gentoo package, a NixOS package, an openSUSE build and an XtraDeb listing. The dependency list for a manual install is given as a single apt command that pulls in libcurl4, libglew2.2, libglfw3, libsdl2-2.0-0, libopenal1, libvorbisfile3 and libopenmpt0.

Alternatively you can install the provided .deb or .rpm package and the dependencies come with it. The asset layout differs slightly depending on how you installed, because packages put the files in the system data directories while a manual install keeps them beside the binary, and the documentation is careful to note that installations predating that layout still work since the old Jazz2 Resurrection directory in the user's home is still detected. The GPU requirement is the same as on Windows, with the addition of OpenGL ES 3.0 for ARM machines, and the two executables are jazz2 and jazz2_sdl2.

macOS through a disk image or Homebrew, iOS only from source

The macOS instructions are the shortest. Download the game, install the provided .dmg application bundle, copy the original game directory into the Source folder under the user's Application Support directory for Jazz2 Resurrection, and run the installed application. There is also a Homebrew route, and it needs an explicit trust step before the tap will serve the build, with `brew trust deathkiller/jazz2` followed by `brew install deathkiller/jazz2/jazz2`.

iOS is the odd one out. The game is not on the App Store, so you build the application bundle from source and install it on the device from Xcode, or you sideload the built jazz2.app. The original game files are then copied in through the Files app, under the On My iPhone or On My iPad heading, or through file sharing in Finder or iTunes. That last detail is the real constraint on iOS: there is no package manager and no automatic content delivery, so the same manual copy that every platform needs becomes a more fiddly operation on a phone.

The dedicated server runs as a container with the data kept outside

The repository includes a Docker setup for a dedicated multiplayer server, and the design point is that the image contains only the engine. The original game files are not part of it and have to be provided by the operator as a volume, exactly as for a local installation. The image is published for both amd64 and arm64, with a latest tag for the latest release and an edge tag for the current state of the master branch. Running it directly looks like this:

#   docker run -d -i --name jazz2-server \
#       -p 7438:7438/udp -p 7438:7438/tcp \
#       -v "$PWD/Source:/app/Source:ro" \
#       -v "$PWD/Config:/app/Config" \
#       -v jazz2-cache:/app/Cache \
#       jazz2-server

The compose file spells the same thing out declaratively, and its comment block is the best documentation of the setup steps:

#   1. Put the original Jazz Jackrabbit 2 files (Anims.j2a, *.j2l, *.j2t, …) into "./Source/".
#      They are converted into the "jazz2-cache" volume on the first start, which takes a while,
#      every following start reuses it.
#   2. Copy "Docs/Snippets/ServerConfiguration.json" to "./Config/Jazz2.Server.config" and edit it ---
#      at the very least the playlist, so that the levels exist in "./Source/".
#   3. mkdir -p ./Config/ && sudo chown 1000:1000 ./Config/     (the server runs as uid 1000)
#   4. docker compose pull && docker compose up -d               (published image)
#      docker compose up -d --build                              (built from these sources instead)

Two operational details are easy to miss. The server console reads commands from standard input, so the container has to be started with an interactive session, and the console is opened with docker attach, where Ctrl-P Ctrl-Q detaches and Ctrl-C would shut the server down. And the container runs as uid 1000, which is why the configuration directory has to be created and chowned before the first start.

Several servers on one host need their own port and directory

The compose file goes further and documents running more than one instance on a single machine. Each instance needs its own configuration directory, its own port and its own Compose project name, which keeps the container names and the cache volumes apart, and the instance is described in an environment file:

#   JAZZ2_INSTANCE=jazz2-battle
#   JAZZ2_CONFIG=./Config-battle
#   JAZZ2_PORT=7439

and then started as its own project from the same directory:

#   docker compose -p jazz2-battle --env-file ./battle.env up -d

The port is deliberately not remapped, and the reason is worth remembering: the server announces the port it is bound to, so a remapped port would be announced wrongly and clients would try to reach the wrong place. Two separate settings in the instance configuration file, ServerPort and WsPort, have to agree with the JAZZ2_PORT value. That is a specific trap, and it is the kind of detail that costs an evening if you assume the usual Docker port mapping behaviour applies.

The source tree mixes engine, content, tooling and packaging

At the top level the repository holds a CMakeLists.txt, a cmake directory, a Sources directory for the engine, a Content directory, a Docs directory, a Dockerfile, a docker-compose.yml, a Jazz2.sln solution file for Visual Studio and a helper property file for the VC-LTL runtime library. The build metadata in the Dockerfile shows what a headless server actually needs, and the list is short: no graphics or audio libraries at all, because libcurl is the mandatory HTTP backend for the online server list, OpenSSL is the TLS backend for the WebSocket transport and zlib handles packet and asset compression. The topic tags cover the wider ambition of the project, listing Android, emscripten, ncine, OpenGL, UWP, Steam Deck and multi-platform work, and the project homepage at de4th.dev/jazz2 carries the rest of the information. The repository itself has no GitHub releases, since the tagged builds live in a separate jazz2 repository, which is where the release badge in the README points.

Running the original is the alternative, and it is not equivalent

The alternative to a reimplementation is running the 1998 game itself, and the difference in approach is what you are optimising for. The original runs on the platform it was written for, needs no asset conversion, no cache build on first start and no OpenGL 3.3, and it is the only option that behaves exactly as shipped. What it cannot do is run on a current Linux distribution, on macOS, on a phone, or as a headless server container, and it does not get the rewritten engine's performance work. Jazz2 Resurrection also offers the features a modern community expects around a game this old, with a dedicated server image, packages for the distributions people actually use, and a supported set of retail versions in one binary. The trade is simply whether you are prepared to supply the original data and accept a first start that rebuilds a cache, in exchange for a native build that keeps working on current hardware.

Editorial conclusion

Adopt Jazz2 Resurrection if you own a copy of Jazz Jackrabbit 2 and want a modern native build with better performance, an AVX2 variant, an SDL2 variant, Linux packages across the major distributions and a containerised dedicated server. Do not adopt it as a standalone product, because no game data ships with the project and the original assets remain a hard requirement on every platform. Before you plan around it, check that your GPU supports OpenGL 3.3 or OpenGL ES 3.0, confirm which of the supported retail versions your copy is, and read the server configuration notes before hosting, since the server port has to match two separate settings in the configuration file.

Frequently asked questions

Official sources

1. deathkiller/jazz2-native on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README