SDLPAL re-runs a 1995 RPG on SDL without shipping the game's data

The reimplementation ships no assets, and says so plainly

SDLPAL is an SDL-based cross-platform reimplementation of the classic Chinese RPG Legend of Sword and Fairy, also known as PAL. The licensing section is the part that matters first.

This program does NOT include any code or data files from the original game, which are proprietary and copyrighted by SoftStar Inc.

The recommendation follows immediately. We recommend purchasing the original game from Steam to obtain the required data files.

So the division is clean. The code is open and licensed under the GNU General Public License, version 3, and the game content is not distributed at all. A user buys the game and points the reimplementation at the data, which is the arrangement that lets a project like this be legally distributable.

The Running the Game section says the same thing operationally. Resource files are not included. You must copy the original game data files into a directory, place the built SDLPAL executable in that same directory, and then run it.

And there is a sharp practical warning that would cost a Linux user an afternoon if it were missing. On case-sensitive filesystems, like Linux and macOS, ensure all game data filenames are in lower-case.

That last one is a genuinely specific piece of knowledge, the kind that only comes from having ported a game that was written for a case-insensitive filesystem. The project ships a Gitee mirror for users in mainland China, updated hourly, and a web demo that runs in the browser, and the demo note says to prepare a ZIP file containing the original game resource data.

The audio stack is the interesting engineering

The libraries list is where the reimplementation work actually shows, and the audio section is the most substantial part of it.

- SDL / SDL_mixer - libmad, libogg and libvorbis, libopus and opusfile - FLTK, TinySoundFont - OPL player from Adplug - OPL emulation cores from DOSBOX, MAME, and Chocolate Doom projects - Audio resampler from foo_input_adplug - AVI player from FFmpeg - Image decoder from stb

That is a long list and each entry is a decision. The original game of this era had its own music format, so the modern replacement has to decode whatever the original data contains, and the project uses libmad for MPEG audio, libogg and libvorbis for Ogg, and libopus and opusfile for Opus. TinySoundFont covers the soundfont side, which is the standard way to render MIDI in a game without a system synth, and FLTK is the GUI toolkit for the launch window.

The OPL lines are the most interesting. An OPL player from Adplug, and OPL emulation cores from DOSBOX, MAME, and Chocolate Doom. The OPL is the Yamaha sound chip that gave 1990s PC games their distinctive sound, and emulating it faithfully is a research project in itself. The project takes the core implementations from three separate emulator projects rather than writing one, which is the sensible approach and explains the credit to the PAL Research Project for the concepts and to Baldur and louyihua for parts of the code.

The repository top level listing shows the vendored libraries as directories, libmad/, liboggvorbis/, libopusfile/, adplug/ and 3rd/, alongside the game source with the original structure, audio.c, battle.c, fight.c, map.c, font.c, input.c, game.c and main.c, and the font headers for the three regional variants in fontglyph_cn.h, fontglyph_jp.h and fontglyph_tw.h. There is also an emscripten/ directory for the web build, a libretro/ directory for the libretro core, an incomplete_ports/ directory for targets that are not finished, and a 3ds/ directory.

Eleven target platforms, each with its own build recipe

The supported platform list is unusually wide for a project of this age.

- Desktop: Windows, Desktop and UWP, GNU/Linux, and macOS. - Mobile: Android, iOS, and Windows Phone/Mobile. - Consoles: 3DS, Wii, PSP, and others, some of which may not be actively maintained.

The build recipes are given per platform, and they are short, which tells you how portable the codebase is.

On Windows, Visual Studio 2017 or later opens win32/sdlpal.sln for the desktop and winrt/SDLPal.UWP.sln for UWP. MinGW has three variants, a Windows CMD build with make -f Makefile.mingw, an MSYS build with plain make, and a Linux cross-compile with make HOST=i686-w64-mingw32-, or x86_64 for 64-bit.

On Linux and Unix it is cd unix && make, with the SDL 2.0 development files installed, and the executable sdlpal is produced in the current directory. There is a detail there worth reading, that by default it uses FLTK for the launch GUI and to disable this you define PAL_NO_LAUNCH_UI in the Makefile.

macOS opens Pal.xcodeproj in Xcode with the SDL framework installed in /Library/Frameworks. iOS uses CocoaPods, with pod install in the iOS/SDLPAL directory and then the workspace opened in Xcode. Android opens the android directory in Android Studio, with two warnings attached: the android/app/src/main/java/org/libsdl/app path is a symlink so your Git client has to handle symbolic links correctly, and on Windows you should keep the repository path short, at the drive root, to avoid path length issues.

Those two Android warnings are the kind of detail that only appears in a project that has been built on every platform by people who hit the failure modes. The Windows path length one is a classic Android Studio problem and the symlink one is a classic cross-platform checkout problem.

The clone step also needs the submodules.

$ git clone https://github.com/sdlpal/sdlpal.git
$ cd sdlpal
$ git submodule update --init --recursive

The .gitmodules file at the root and the vendored library directories are the other end of that.

Configuration decides which version of the game you are playing

SDLPAL supports various versions of the original game through configuration, and the README gives two ways to set it.

The first is a GUI. On the first launch a configuration window will appear, and you can access it later via the in-game menu or after a crash. The parenthetical note is that it is currently unavailable on macOS.

The second is manual. Create a sdlpal.cfg file in the game directory, and refer to sdlpal.cfg.example for the format.

So the game data determines which variant you are running, and the configuration is how you point the engine at the right one. This is the structural difference between a reimplementation and a port. A port adapts the original binary to a new platform, so the game code is fixed and the platform layer changes. A reimplementation writes a new engine that reads the original data files, so the data is the variant selector and the engine has to understand the differences between the releases.

That is why the resource data is genuinely required rather than a convenience. The engine reads the same formats the original did, including the different text encodings, which is why the font headers are split by region, fontglyph_cn.h for the Chinese text, fontglyph_jp.h for the Japanese and fontglyph_tw.h for the Traditional Chinese, and there is a codepage.h for the code page handling.

MIDI support is another configuration-dependent thing, and the platform list is specific. It is officially supported on Windows, Android, iOS and macOS, the GNU/Linux support is preliminary and requires the timidity package, and other platforms do not currently support MIDI.

So on Linux, MIDI means installing timidity and accepting a preliminary implementation, which is the kind of detail that decides whether a port is a pleasant experience on a given platform.

Where SDLPAL is the wrong choice

The first wrong case is a player who does not own the original. The data files are proprietary and copyrighted by SoftStar Inc, the project distributes none of them, and the README recommends buying the game on Steam. Everything else in this project is downstream of that, and any route to the data that does not involve a purchase is a question of legality rather than of software.

The second wrong case is a team that wants to improve the game rather than preserve it. This is a reimplementation of a 1995 design, with the structure, the balance and the interface of the original. Modernising it means changing the engine's assumptions, and the codebase is arranged around the original's structures, from the battle and fight modules to the font and codepage handling. A from-scratch engine is a different project.

The third wrong case is a console homebrew developer expecting a maintained libretro core. The libretro/ directory is one of many target directories alongside 3ds/, win32/, winrt/, ios/, android/ and macos/, and the console list comes with the caveat that some may not be actively maintained. A team shipping a console product cannot rely on any of it.

The fourth wrong case is a Linux user who does not read the case sensitivity note. The game data filenames must be lower case on a case-sensitive filesystem, and a mismatch produces a missing-resource failure that looks like a corrupt install rather than a case problem.

How it differs from a straight port of the original

The comparison worth making is with the DOSBox and Wine approaches, and the difference in approach is where the platform adaptation happens.

A DOSBox configuration runs the original executable. It needs an emulated DOS environment, the original executable, and the original data, and it gives you the original game with the original behaviour, including the original's own bugs and its original input handling. It is the most faithful option and the least integrated one, because the game runs in a window with its own keyboard handling and its own scaling.

SDLPAL re-implements the game in C on top of SDL. The consequence is that the game runs natively on the platform, with the host's own windowing, input and audio, and the code can be compiled for a platform the original never ran on, which is why a 3DS and a PSP build exist at all. The other consequence is that faithfulness becomes a maintenance problem, because every behaviour of the original has to be re-derived from the data files and from research, and the PAL Research Project documents are cited as the conceptual source for much of it.

The third difference is the licensing. A DOSBox configuration needs the original executable, which is the same legal constraint, but the reimplementation is a GPL-3.0 program that anyone can read, build and modify, and that is what makes the console ports and the web demo possible. The web demo is the clearest example, because the original game in a browser is not something a compatibility layer could do.

The fourth difference is the platform coverage. A DOSBox configuration works wherever DOSBox works, which is a lot of places, but SDL gives the project a direct line to modern platforms, to touch input, to high resolution displays, and to the modern audio APIs, and the OPL emulation is what preserves the original sound while the rest of the pipeline is modern.

Editorial conclusion

SDLPAL fits a player who owns a legitimate copy of the original game and wants to play it on a modern platform, on a handheld or in a browser, and it fits a developer who wants to study how a 1990s Chinese RPG is structured in C. It does not fit anyone who does not own the original, since the data files are proprietary and the project ships none of them, and it does not fit a team that wants a modern engine, since the code is a period-faithful reimplementation rather than a redesign. Before building it, note that the game data filenames must be lower case on case-sensitive filesystems, and that the newest tagged release is v3.0.2025.0616 from 2025-06-15 with the last push on 2026-10-18.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sdlpal/sdlpal on GitHub