Dink Smallwood HD: Native Linux (and Mac) Port – Collaboration & Testing
Hi everyone!
I’m Mateus Bentes, a long-time fan of Dink Smallwood and a Linux user. I’ve been working on a native Linux port of Dink Smallwood HD (no Wine/Proton required!), leveraging the recent changes in the codebase—like the removal of FMOD in favor of SDL_mixer. My goal is to make the game run smoothly on Linux and Mac, and I believe it would be amazing if GOG could offer official versions for these platforms in the future.
What’s Done So Far:
Removed FMOD and replaced it with SDL_mixer (thanks to the recent updates from RTSoft!).
The game now compiles on Linux, but I’m still working on a few challenges:
Compressed data files: The game uses a custom format for these, and I’m analyzing how to handle them properly.
Testing on different distros: I need help testing on Ubuntu, Arch, Fedora, etc.
Mod support: Ensuring compatibility with existing mods.
How You Can Help:
Developers: If you’re familiar with the game’s codebase (especially file handling), your insights would be invaluable!
Testers: Try the build on your system and report bugs or performance issues.
Modders: Let me know if mods work as expected (or if there are issues).
Why This Matters:
This port will make Dink Smallwood HD fully open-source and native on Linux and Mac, aligning with the game’s spirit. It’s also a great opportunity to bring this classic to more players who prefer these platforms for privacy, performance, and freedom.
Next Steps:
Once the port is stable, I’d love to see it on GOG as an official Linux/Mac version. Until then, I’ll keep working on it with the community’s help!
Let’s make this happen together! Feel free to reply with questions, suggestions, or test results. Thanks in advance for your help!"
I’m Mateus Bentes, a long-time fan of Dink Smallwood and a Linux user. I’ve been working on a native Linux port of Dink Smallwood HD (no Wine/Proton required!), leveraging the recent changes in the codebase—like the removal of FMOD in favor of SDL_mixer. My goal is to make the game run smoothly on Linux and Mac, and I believe it would be amazing if GOG could offer official versions for these platforms in the future.
What’s Done So Far:
Removed FMOD and replaced it with SDL_mixer (thanks to the recent updates from RTSoft!).
The game now compiles on Linux, but I’m still working on a few challenges:
Compressed data files: The game uses a custom format for these, and I’m analyzing how to handle them properly.
Testing on different distros: I need help testing on Ubuntu, Arch, Fedora, etc.
Mod support: Ensuring compatibility with existing mods.
How You Can Help:
Developers: If you’re familiar with the game’s codebase (especially file handling), your insights would be invaluable!
Testers: Try the build on your system and report bugs or performance issues.
Modders: Let me know if mods work as expected (or if there are issues).
Why This Matters:
This port will make Dink Smallwood HD fully open-source and native on Linux and Mac, aligning with the game’s spirit. It’s also a great opportunity to bring this classic to more players who prefer these platforms for privacy, performance, and freedom.
Next Steps:
Once the port is stable, I’d love to see it on GOG as an official Linux/Mac version. Until then, I’ll keep working on it with the community’s help!
Let’s make this happen together! Feel free to reply with questions, suggestions, or test results. Thanks in advance for your help!"
This is great , you can also reach out to seth on twitter
Thanks for the patch - I applied your patches and did some other tweaks.
You can do:
curl -sL https://raw.githubusercontent.com/SethRobinson/RTDink/master/linux_setup.sh | bash
from a linux desktop terminal to download and build everything ready for play.
Besides from the security risk of running a script directly it also does something else weird:
It downloads the windows .exe installer and pulls all the assets out of it to use. A bit hacky but hey.
There is no reason it can't compile its own version of the proton packer utility and build its own rttex/etc assets (well, unless assets are missing from the repo which is possible), but this lazy way solves the problem for now.
You can (well, according to my quick test in ubuntu):
* Play in a 1024x768 window with dink with audio, mp3 and midi
* Use its internal dmod system to browse/install/play dmods from the dinknetwork
* Save state and all that
* Launch URL
You can't (this can be fixed mostly by work on the Proton SDK side, I just never bothered to add these features as I don't daily drive a linux desktop):
* Use a controller
* Resize the window
* Anything screen related in the options menu like toggle fullscreen, set a specific resolution
Untested:
* Cut and paste? I didn't try it but I assume it doesn't work, only useful
if you want to paste in a dmod filename directly into the dmod browser
* Command line parms to run dmods directly or in other directories or do other things? Not sure.
So yeah, the native linux version could use some loving care, but hey, at least Dink HD runs on it natively.
Oh, I cleaned up the repo a bit and added some missing stuff so now the full iOS, Android and HTML5 versions can compile out of the box.
Now anybody can release their own Dink on Android or iOS very easily if they wanted.
You can do:
curl -sL https://raw.githubusercontent.com/SethRobinson/RTDink/master/linux_setup.sh | bash
from a linux desktop terminal to download and build everything ready for play.
Besides from the security risk of running a script directly it also does something else weird:
It downloads the windows .exe installer and pulls all the assets out of it to use. A bit hacky but hey.
There is no reason it can't compile its own version of the proton packer utility and build its own rttex/etc assets (well, unless assets are missing from the repo which is possible), but this lazy way solves the problem for now.
You can (well, according to my quick test in ubuntu):
* Play in a 1024x768 window with dink with audio, mp3 and midi
* Use its internal dmod system to browse/install/play dmods from the dinknetwork
* Save state and all that
* Launch URL
You can't (this can be fixed mostly by work on the Proton SDK side, I just never bothered to add these features as I don't daily drive a linux desktop):
* Use a controller
* Resize the window
* Anything screen related in the options menu like toggle fullscreen, set a specific resolution
Untested:
* Cut and paste? I didn't try it but I assume it doesn't work, only useful
if you want to paste in a dmod filename directly into the dmod browser
* Command line parms to run dmods directly or in other directories or do other things? Not sure.
So yeah, the native linux version could use some loving care, but hey, at least Dink HD runs on it natively.
Oh, I cleaned up the repo a bit and added some missing stuff so now the full iOS, Android and HTML5 versions can compile out of the box.
Now anybody can release their own Dink on Android or iOS very easily if they wanted.
Hey Seth, thanks for merging the patches and setting up the linux_setup.sh script! That's a clever workaround for the assets. I tested the build on Ubuntu and everything you listed works great — playing the base game, browsing/installing DMODs, save states, audio with MP3 and MIDI. Regarding the things that don't work yet, I'd like to take a crack at some of them: Window resizing. The key pieces are:
An UpdateViewport() function that recalculates the OpenGL projection matrix to maintain the 4:3 aspect ratio with letterboxing/pillarboxing
Hooking into SDL_WINDOWEVENT_RESIZED to update the viewport and the engine's screen info (SetPrimaryScreenSize + SetupScreenInfo + SetupFakePrimaryScreenSize) so mouse coordinates stay correct after resize
Calling UpdateViewport() from OnScreenSizeChange() as well
Fullscreen toggle (F11) — I also had this working. The approach was:
OnFullscreenToggleRequestMultiplatform() using SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP) for borderless fullscreen
Using SDL_GetKeyboardState() to poll F11 since the Proton BaseApp doesn't have a GetKeyState() method on non-Windows platforms
The hotkey handlers needed to be moved outside the #ifdef C_DINK_KEYBOARD_INPUT block in CheckForHotkeys() since that macro is only defined for _WIN32
Controller support — I haven't looked into this yet but I see the GamepadManager and SDL2 gamepad code is already in the Proton SDK. Might just need some wiring up on the Linux side. I can submit PRs for the resize and fullscreen fixes if you're interested. Should I base them on the current master now that you've cleaned things up? Also great news about iOS, Android and HTML5 compiling out of the box — that lowers the barrier a lot for the community.
An UpdateViewport() function that recalculates the OpenGL projection matrix to maintain the 4:3 aspect ratio with letterboxing/pillarboxing
Hooking into SDL_WINDOWEVENT_RESIZED to update the viewport and the engine's screen info (SetPrimaryScreenSize + SetupScreenInfo + SetupFakePrimaryScreenSize) so mouse coordinates stay correct after resize
Calling UpdateViewport() from OnScreenSizeChange() as well
Fullscreen toggle (F11) — I also had this working. The approach was:
OnFullscreenToggleRequestMultiplatform() using SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP) for borderless fullscreen
Using SDL_GetKeyboardState() to poll F11 since the Proton BaseApp doesn't have a GetKeyState() method on non-Windows platforms
The hotkey handlers needed to be moved outside the #ifdef C_DINK_KEYBOARD_INPUT block in CheckForHotkeys() since that macro is only defined for _WIN32
Controller support — I haven't looked into this yet but I see the GamepadManager and SDL2 gamepad code is already in the Proton SDK. Might just need some wiring up on the Linux side. I can submit PRs for the resize and fullscreen fixes if you're interested. Should I base them on the current master now that you've cleaned things up? Also great news about iOS, Android and HTML5 compiling out of the box — that lowers the barrier a lot for the community.
For anyone who wants to try out the above build script, keep in mind it will only work on Debian distros. It's not enough to edit the build script to remove the lines that reference apt, as it redownloads itself and starts anew. I managed to get around it by installing Distrobox and making a distrobox-assemble ini with the following contents:
Save it as distrobox.ini then run distrobox assemble create, and then distrobox enter rtdinkbuild. After it eventually builds, you'll have to cd to the "bin" dir (not build) and run ./RTDinkApp as it won't run from any other path. Do be aware that it's extremely rough (no resampling among other things).
[rtdinkbuild] image=ubuntu:latest additional_packages="build-essential cmake libgl1-mesa-dev libx11-dev libpng-dev zlib1g-dev libbz2-dev libcurl4-openssl-dev libsdl2-dev libsdl2-mixer-dev wget" init_hooks="wget https://raw.githubusercontent.com/SethRobinson/RTDink/master/linux_setup.sh" init_hooks="chmod +x linux_setup.sh" init_hooks="bash linux_setup.sh --dir=/absolute/path/of/your/choosing/so/it's/not/in/home"
Save it as distrobox.ini then run distrobox assemble create, and then distrobox enter rtdinkbuild. After it eventually builds, you'll have to cd to the "bin" dir (not build) and run ./RTDinkApp as it won't run from any other path. Do be aware that it's extremely rough (no resampling among other things).
* Ok, I've merged the PR ( https://github.com/SethRobinson/RTDink/pull/16 ) with some fixes so the other platforms aren't changed.
I also attempted to get AI to fix the install script to support more than Debian (hoping this works for you directly, yeoldetoast), no idea if it works, but Ubuntu still does so I guess if it doesn't nothing lost.
I just noticed some things like clicking screen resolutions in the dink Options (linux) don't actually do anything, I'm going to attempt to get that going. And make Alt-Enter also toggle fullscreen, I know F11 works but.. both can do it, right?
PS: Ok, updated both proton and rtdink repos, screen handling works better now.
Oh, btw before I said gamepads don't work, but as mateusbentes mentioned, I'd forgotten SDL2 handles gamepads so who knows, it might already work on linux?
I also attempted to get AI to fix the install script to support more than Debian (hoping this works for you directly, yeoldetoast), no idea if it works, but Ubuntu still does so I guess if it doesn't nothing lost.
I just noticed some things like clicking screen resolutions in the dink Options (linux) don't actually do anything, I'm going to attempt to get that going. And make Alt-Enter also toggle fullscreen, I know F11 works but.. both can do it, right?
PS: Ok, updated both proton and rtdink repos, screen handling works better now.
Oh, btw before I said gamepads don't work, but as mateusbentes mentioned, I'd forgotten SDL2 handles gamepads so who knows, it might already work on linux?
Thanks a lot for merging the PR, Seth! I really appreciate the fixes and improvements, especially the broader Linux distro support and the fullscreen toggle updates. I’ll test the install script on Ubuntu and other distros (like Arch and Fedora) and let you know how it goes. If there are any issues, I can help tweak it further.
About the screen resolution options in the Linux menu, it’s great that you’re working on it! Let me know if you’d like me to test that part—I’d be happy to help.
For now, I’m focusing on polishing the Linux desktop support even further (like fixing any lingering input or resolution quirks). If you’ve got any specific areas you’d like me to prioritize or test, just say the word!
Thanks again for all your work on this—it’s amazing to see Dink HD getting even better cross-platform support!
About the screen resolution options in the Linux menu, it’s great that you’re working on it! Let me know if you’d like me to test that part—I’d be happy to help.
For now, I’m focusing on polishing the Linux desktop support even further (like fixing any lingering input or resolution quirks). If you’ve got any specific areas you’d like me to prioritize or test, just say the word!
Thanks again for all your work on this—it’s amazing to see Dink HD getting even better cross-platform support!
Thanks mateusbentes, I merged the new PR!
Also, I think you'll probably get more issue resistant PRs if you add something like to your tool prompting for future changes:
********* (add this to your prompt) ********
CRITICAL CONSTRAINT: This is a multi-platform codebase that builds for Windows, iOS, Android, HTML5/Emscripten, macOS, and Linux. Your changes MUST NOT break compilation or behavior on any existing platform. Follow these rules:
1. Never remove or modify code inside existing #ifdef guards (WINAPI, PLATFORM_IOS, PLATFORM_ANDROID, PLATFORM_HTML5, etc.) unless you fully understand what every platform path does.
2. When adding platform-specific code, use #if defined(PLATFORM_LINUX) || defined(PLATFORM_OSX) or similar narrow guards. Never use #else after a platform #ifdef as a catch-all -- it will hit every other platform including iOS, Android, and HTML5. Use #elif with explicit platform checks instead.
3. Before calling any function, verify it actually exists in the codebase or framework. Do not assume APIs exist -- search for their declarations first.
4. New functions and globals must be wrapped in platform guards so they only compile on platforms where they are needed.
5. Do not change the behavior of existing platforms as a side effect of adding new platform support. The goal is to ADD Linux/macOS support, not to refactor or "improve" working Windows/iOS/Android/HTML5 code.
6. All comments must be in English.
7. After making changes, mentally trace through compilation for each platform (Windows, iOS, Android, HTML5, Linux, macOS) and verify no platform hits an undefined function, missing symbol, or changed behavior.
Also, I think you'll probably get more issue resistant PRs if you add something like to your tool prompting for future changes:
********* (add this to your prompt) ********
CRITICAL CONSTRAINT: This is a multi-platform codebase that builds for Windows, iOS, Android, HTML5/Emscripten, macOS, and Linux. Your changes MUST NOT break compilation or behavior on any existing platform. Follow these rules:
1. Never remove or modify code inside existing #ifdef guards (WINAPI, PLATFORM_IOS, PLATFORM_ANDROID, PLATFORM_HTML5, etc.) unless you fully understand what every platform path does.
2. When adding platform-specific code, use #if defined(PLATFORM_LINUX) || defined(PLATFORM_OSX) or similar narrow guards. Never use #else after a platform #ifdef as a catch-all -- it will hit every other platform including iOS, Android, and HTML5. Use #elif with explicit platform checks instead.
3. Before calling any function, verify it actually exists in the codebase or framework. Do not assume APIs exist -- search for their declarations first.
4. New functions and globals must be wrapped in platform guards so they only compile on platforms where they are needed.
5. Do not change the behavior of existing platforms as a side effect of adding new platform support. The goal is to ADD Linux/macOS support, not to refactor or "improve" working Windows/iOS/Android/HTML5 code.
6. All comments must be in English.
7. After making changes, mentally trace through compilation for each platform (Windows, iOS, Android, HTML5, Linux, macOS) and verify no platform hits an undefined function, missing symbol, or changed behavior.
Thanks for merging the PR, Seth! I’ll keep the multi-platform constraints in mind for future changes—really appreciate the guidelines.
About gamepad support, it’s still a work in progress (WIP) on my end. I’m testing SDL2’s gamepad handling on Linux, but I’ve hit a few snags (e.g., button mapping inconsistencies across different controllers). I’ll keep digging and update you once I’ve got something stable. If you’ve got any tips or existing gamepad code I should reference, let me know!
About gamepad support, it’s still a work in progress (WIP) on my end. I’m testing SDL2’s gamepad handling on Linux, but I’ve hit a few snags (e.g., button mapping inconsistencies across different controllers). I’ll keep digging and update you once I’ve got something stable. If you’ve got any tips or existing gamepad code I should reference, let me know!












