Hey guys, I'm new here.
I have a working port (faithful from disassembly) of the original Stunts to modern Linux using SDL3, written in C.
I'm very concerned with all the features being faithfully implemented and I've only added features that can be toggled and aren't on by default. E.g. I have a feature to disable the "power gear" bug, but it is just on by default.
I guess the most interesting features to you guys might be:
* Supports up to 8 players simultaneously racing over UDP/IP
* 2x larger maps (optional!) than the original Stunts
Is this project of any interest to you guys? I've included a screenshot just showing three cars at the same time.
Edit 1: I also have a "lobby and game creation application" in the works where people can make rooms, join rooms, race, see results, etc. Is that of interest to the community?
Edit 2: Maybe I didn't explain it very well, but this could obviously be quite easily made to work on modern Windows, macOS, already works on Linux. It is modern C and SDL3, so it is easy to get running.
The reason I ported it is that I took a look at the original DOS disassembly and for features that I wanted, such as eventually integrating Stunts with an open world Test Drive 3 style game (basically merging the two games), adding proper network support, much larger maps, and brand new (all optional) features, it is just too painful to hack the original game. It can be done, but once you have everything written from scratch it becomes easier to both play the game without needing Dosbox (with all respect) and modern features become much more manageable.
are you CommonLoon102? there are so many devs lately that doing stuff around stunts - with serveral nicknames on the different platforms - hard to keep track who is who
can you explain in more detail how you port over to C - manually, by AI help, how you kept features/bugs/behavior the same etc.
is also upgrading the 3d engine on your list?
will your project be open source?
Quote from: llm on August 29, 2026, 09:54:20 PMare you CommonLoon102? there are so many devs lately that doing stuff around stunts - with serveral nicknames on the different platforms - hard to keep track who is who
can you explain in more detail how you port over to C - manually, by AI help, how you kept features/bugs/behavior the same etc.
is also upgrading the 3d engine on your list?
will your project be open source?
No, I don't know who that is.
The port was done through a combination of IDA Pro, manual work, heavy use of AI (on the "agentic coding" side, not on the vibe coding side, I have a CS degree).
I've also used Restunts as a starting point.
What I don't have: I don't have a super nice, polished C port that is easy to understand.
What I do have: A flat 64-bit C faithful port, not a reimplementation. Not a "this is what I think Stunts should have been", and also not "this is what feels right to me" take on Stunts.
It is Stunts. Because it just faithfully uses the original logic present in the original disassembly. I've leveraged repldump and pixel by pixel comparison with AI assistance, and my own testing.
Why is my own testing valuable at all? Because when porting over blocks of code and preserving the logic faithfully it is harder to introduce slight differences in car handling, and a lot easier to introduce (through your own bugs) something that causes either a huge difference, or that is exactly right.
And yes, obviously, there are almost certainly still quirks, weird things, etc. Hopefully not with the physics and handling of the car though. I can assure that I can trigger the power gear just as before on loops and on jumps and the car handles as it should.
A lot of the code is just literally translated directly into C, without it even being that clear what is happening, this makes it really ugly, e.g.:
if (framespersec != 0x14)
goto loc_17A8E;
var_2 = 6;
goto loc_17A93;
loc_17A8E:
var_2 = 0xC;
loc_17A93:
if (arg_carState->car_engineLimiterTimer == 0)
goto loc_17AA1;
arg_carState->car_engineLimiterTimer--;
loc_17AA1:
arg_carState->car_speeddiff = arg_carState->car_speed2 - arg_carState- >car_lastspeed;
arg_carState->car_lastspeed = arg_carState->car_speed2;
arg_carState->car_lastrpm = arg_carState->car_currpm;
if (arg_carState->car_transmission != 0)
goto loc_17AE6;
if (arg_carState->car_changing_gear != 0)
goto loc_17AE6;
if ((arg_carInputByte & 0x10) != 0)
goto loc_17B0F;
if ((arg_carInputByte & 0x20) != 0)
goto loc_17B2E;
goto loc_17B86;
I have a soft spot for the aesthetics of the 3D engine so updating that is low on my list of priorities.
I'd be happy to share the code, but I'd like to polish it first some, if there's genuine interest in it.
So in other words, if there would be some interest in e.g. maybe trying out some multiplayer action with 8 (or more) cars in Stunts, maybe with a lobby management application, then that would be motivation for me to polish it enough.
I'd rather avoid releasing something that comes across as just "80% but not enough to spark any interest", if that makes sense.
But yes: Open source, working on Windows, macOS, and Linux. I have it working on Linux already.
As a cute feature, I can also drive on the "intro disc" in the beginning, the one that floats in the universe with the stars, etc.
Hello and welcome, x29retaliator!
Thanks for your message! As much as I am getting fatigued by the deluge of retro ports in the post-Codex era, the presentation of your project is very tasteful and makes me curious. I do not take part in live races, but offering 8-way multiplayer as main feature shows to me that you have a good feeling for the game, where to improve it and where not to.
I'm quite sure the community could make good use of the multiplayer. Leaving DOS behind is not necessarily a progress (because with emulators I can play with my beloved huge rectangular pixels, Alain with his CRT-like shaders and Spoonboy with his phone) but I know how much easier is to work in a flat addressing space.
I'll take the freedom to advertise your project on the chatbox in the front page; this should get it more visibility.
Hello my friends,
Thank you for sharing this — it is a very interesting project.
I doubt that 8-player multiplayer alone will suddenly attract far more people than the handful of racers who sometimes take part in live events with the original game. However, quoting Indy, this code definitely belongs on GitHub and deserves to be preserved and documented.
Even beyond multiplayer, a faithful C port based on the original disassembly could become an extremely valuable reference for the Stunts community. It could help the next person climb another step on the Stunts reverse-engineering ladder — especially if the original behaviour, bugs and quirks have been carefully preserved.
The Stunts Wiki could then document the project and link to the repository.
So yes, I would definitely be interested in seeing the code released.
Looks promising for live races. Is this mod played with a server or local?
Thanks for the interest, guys!
"Is this mod played with a server or local? "
So, to clarify, this isn't really a mod. It isn't something you install on top of the original game, it doesn't need Dosbox, it doesn't use the original game.
It is a "line by line" implementation of the original game, on a modern system. But it doesn't feature any new graphics engine, new physics engine, it is the same original Stunts logic---resulting in the same original handling of the car, physics, graphics.
So you get just a modern binary you execute, which launches the game, yes, pixelated and just like the original game, not a modern graphics high resolution variant, or anything like that (you can get it full screen, but it becomes just as pixelated as it would in Dosbox).
The multiplayer feature is just baked into the game itself, you can select it from the options.
But I also have a modern launcher that just launches the game. The map rendering preview is just a placeholder for now.
some more questions:
-did you used the partially ported C-source of restunts or is your port only based on the restunts-assembly source?
-does you port also support sound (pc-speaker, adlib and mt32 emulation?)
-are you interested in integrating the SuperSight mod (https://wiki.stunts.hu/wiki/SuperSight) of HerrNove? Video: https://marnetto.net/assets/2026-01-27--camel/ss-200x.mp4
-github release would be great
-can you release your linux binaries?
-i could help doing a windows port, if needed
Quote from: llm on August 30, 2026, 06:18:44 AMsome more questions:
-did you used the partially ported C-source of restunts or is your port only based on the restunts-assembly source?
-does you port also support sound (pc-speaker, adlib and mt32 emulation?)
-are you interested in integrating the SuperSight mod (https://wiki.stunts.hu/wiki/SuperSight) of HerrNove? Video: https://marnetto.net/assets/2026-01-27--camel/ss-200x.mp4
-github release would be great
-can you release your linux binaries?
-i could help doing a windows port, if needed
Yes, I think I mentioned that initially in my opening post, I used Restunts as part of the starting point.
It does support sound, but I've only done Adlib so far, and it is a super cheap hack so far: I tried doing it by hand-porting over the audio code but it never sounded right. Basically just "recording audio" and replaying it on-demand programmatically. This is the most shaky part of the port yet, but I intend to get it done right. I have a plan to get this done properly too though. Should have both all supported sound devices just in-game selectable and configurable from command-line arguments.
I already have SuperSight implemented, actually! It was one of my initial goals, and then I discovered SuperSight. SuperSight can be toggled on/off in the options.
Binaries, I can provide that also later at some point for Windows (and Linux) but I don't have a setup right now that does it while preserving my own privacy (binaries leak a lot of metadata from the developer's system).
OK, I'll try for a Github release at some point then.
Quote from: x29retaliator on August 30, 2026, 03:03:43 PMYes, I think I mentioned that initially in my opening post, I used Restunts as part of the starting point.
no clear enough - did you base on the assembler code only or did you also used already ported C code from the restunts project
Quote from: x29retaliator on August 30, 2026, 03:03:43 PMIt does support sound, but I've only done Adlib so far, and it is a super cheap hack so far: I tried doing it by hand-porting over the audio code but it never sounded right. Basically just "recording audio" and replaying it on-demand programmatically. This is the most shaky part of the port yet, but I intend to get it done right. I have a plan to get this done properly too though. Should have both all supported sound devices just in-game selectable and configurable from command-line arguments.
look at the dosbox-staging code for PC-Speaker, NukeOLP2/3 for Adlib and Munt for MT32 - best of class :)
Quote from: x29retaliator on August 30, 2026, 03:03:43 PMI already have SuperSight implemented, actually! It was one of my initial goals, and then I discovered SuperSight. SuperSight can be toggled on/off in the options.
super nice!
Quote from: x29retaliator on August 30, 2026, 03:03:43 PMBinaries, I can provide that also later at some point for Windows (and Linux) but I don't have a setup right now that does it while preserving my own privacy (binaries leak a lot of metadata from the developer's system).
due to the includes tool-chain and original game data in the restunts repo?
you should only have the C code in github and build Linux+Windows with github action (and githubs compilers) - then you're safe
Just a quick reply: Yes, I am basing it off of everything that Restunts had to offer, some of it has been changed but a lot of it is identical in terms of the C code.
If I were to release it I'd obviously give credit to both Restunts and SuperSight, etc.
This is amazing, please release as soon as you feel it is ready!
Though one issue that's immediately obvious from your screenshots is that the port isn't doing aspect ratio correction. That is, the 320x200 framebuffer should be vertically stretched 1.2x to fit a 4:3 aspect ratio, which is how it was originally displayed on CRT monitors at the time (and still is displayed, if using DOSBox with the option aspect=true). Note that the game's 3D camera projection is already warped to compensate for this, which is very obvious when rotating a top-down F3 camera (see attached screenshots, which also demonstrate that at least some of the 2D artwork also takes this into account - note that the elliptical steering wheel and gauges become almost perfectly circular with aspect ratio correction). This also means that if you ever implement high-resolution modes using square-pixel aspect ratios, you'll need to adjust the camera projection while adding aspect-ratio correct scaling for 2D elements (this is how most modern Doom ports work, for instance).
Also, can players collide with each other's cars and wreck in multiplayer? If so, how does latency compensation and prediction work? (Not that there's no benefit to latency compensation even if players can't wreck each other, it's just less critical in that case.)
Oh, and just one more thing,
Quote from: x29retaliator on August 29, 2026, 07:00:51 PMI have a feature to disable the "power gear" bug,
Come on, you can't just drop a bombshell like that without giving details. Does this mean you actually know specifically what causes the bug, or did you just implement an alternative (presumably more physically accurate) algorithm for determining car acceleration that happens to be free of the bug?
Quote from: Foxpup on September 01, 2026, 04:12:51 AMThis is amazing, please release as soon as you feel it is ready!
Though one issue that's immediately obvious from your screenshots is that the port isn't doing aspect ratio correction. That is, the 320x200 framebuffer should be vertically stretched 1.2x to fit a 4:3 aspect ratio, which is how it was originally displayed on CRT monitors at the time (and still is displayed, if using DOSBox with the option aspect=true). Note that the game's 3D camera projection is already warped to compensate for this, which is very obvious when rotating a top-down F3 camera (see attached screenshots, which also demonstrate that at least some of the 2D artwork also takes this into account - note that the elliptical steering wheel and gauges become almost perfectly circular with aspect ratio correction). This also means that if you ever implement high-resolution modes using square-pixel aspect ratios, you'll need to adjust the camera projection while adding aspect-ratio correct scaling for 2D elements (this is how most modern Doom ports work, for instance).
Also, can players collide with each other's cars and wreck in multiplayer? If so, how does latency compensation and prediction work? (Not that there's no benefit to latency compensation even if players can't wreck each other, it's just less critical in that case.)
Oh, and just one more thing,
Quote from: x29retaliator on August 29, 2026, 07:00:51 PMI have a feature to disable the "power gear" bug,
Come on, you can't just drop a bombshell like that without giving details. Does this mean you actually know specifically what causes the bug, or did you just implement an alternative (presumably more physically accurate) algorithm for determining car acceleration that happens to be free of the bug?
Glad to hear it seems interesting!
So the power gear bug, this really hasn't been documented before?
Keep in mind though, as I mentioned earlier, that a lot of the port boils down to just being able to understand how assembly translates into C, and that this can be done without necessarily understanding exactly how the engine works.
Basically, as long as you know C and assembly (I do), and as long as you can verify incremental steps and have played the game enough to notice if it is "right or completely wrong" (I can), then that's really most of the work right there. Just iterate over this primitive.
For the power gear bug, I believe I do understand it though:
It is a signedness/truncation bug, not just a simple overflow.
Basically, certain small reductions in speed (such as driving up an inclined plane, or driving in a loop), the game intends to reduce the speed. This is represented as a small, negative products. This negative change is multiplied and shifted, by Borland's unsigned 32-bit division routine (?). The problem is that the quotient is enormous but the game only rtains the low 16 bits and does an arithmetic shift. This results in a significant *positive* speed change.
In my port I have:
if (g_power_gear_bug) {
var_deltaSpeed = (short)((short)(unsigned short)((unsigned long)((long)var_deltaSpeed * 0x19)
/ (unsigned short)arg_simd->car_mass) >> 1);
} else {
var_deltaSpeed = (short)((((long)var_deltaSpeed * 0x19)
/ (long)(short)(unsigned short)arg_simd->car_mass) >> 1);
}
I'll give an example:
Speed is 45822 (around 179 MPH), the game calculates a "force" of -44. The mass of the car is 15 in this example.
(-44 * 25) / 15 / 2 = -37
So decelerate by -37. This is the intended result.
In original Stunts, we get:
(-44 * 25) -> 4,294,966,196 (because -1100 is represented as unsigned 32-bit)
Then / 15, keep the low 16 bits, shift right by one -> +2147 speed units.
Might be some mistake in the math here, but this should be the correct idea.
Edit: Yes! Players can collide with each other, I'll give a post about how that works too, just not right now, sorry!
Also thanks for the heads up on the aspect ratio! I didn't notice!
Quote from: x29retaliator on September 01, 2026, 02:31:01 PMSo the power gear bug, this really hasn't been documented before?
As far as I know, not beyond what's on the wiki article (https://wiki.stunts.hu/wiki/Power_gear_bug). It is well-known that the specific behaviour of the bug depends on the remainder of (65536/mass) and that it is further influenced by physical forces such as aerodynamic drag, so the bug obviously results from an inaccurate force/mass division to calculate acceleration/deceleration, though until now I've never seen an explanation of exactly how this division operation in performed or why it goes so badly wrong for certain values of force and mass. This is very useful information, thanks!
Quote from: x29retaliator on September 01, 2026, 02:31:01 PMYes! Players can collide with each other, I'll give a post about how that works too, just not right now, sorry!
This port just got even more interesting! Please keep us posted!
Just some testing. In the attached picture we can see that 8 cars are present on the track in a live game.
It is quite painful to do this kind of testing, but it does work.
The car in the top-left drove down the road a bit, turned, and headed back towards the finish line going the wrong way. Just like the original game it then assumes you "finished" and gives you a huge penalty. So the blue car already finished.
Anyway, thought this screenshot might be a bit cool.
I didn't forget about the collision detection, I thought I'd explain how it works but uncovered some problems with it, so I'll deal with that first.
Quote from: x29retaliator on September 03, 2026, 06:26:34 PMIt is quite painful to do this kind of testing, but it does work.
Reminds me of a time where I had to start six instances of an unstable version of VMWare. It took some attempts before I managed to keep all the VMs alive for the few minutes I needed for my experiment.
Quote from: x29retaliator on September 03, 2026, 06:26:34 PMAnyway, thought this screenshot might be a bit cool.
It's very cool to me! Congratulations, I think for many veterans this is a dream coming true!
---
(some minor glitches in the speedometer of Jaguar and Corvette: maybe a bug when processing the .PVS files? Sorry for raising an issue now, but I cannot keep myself :) )
Quote from: x29retaliator on September 03, 2026, 06:26:34 PMThe car in the top-left drove down the road a bit, turned, and headed back towards the finish line going the wrong way. Just like the original game it then assumes you "finished" and gives you a huge penalty.
It really shouldn't though, if all you did was drive the wrong way. I guess you changed the way the start/finish line functions in order to account for cars starting on the previous tile, because in the original game, the start/finish line must be approached from the correct direction to count as completing the race.
Also, it looks like you're unnecessarily truncating the cars' full names to 4 characters depsite cars already having a 4-character short name (the gsna resource in the car*.res file) for exactly this purpose. It is used in the original game to identify the opponent's car on the scoreboard, when a high score is recorded while racing against an AI opponent. (This short name is not to be confused with 4-character filename code used to identify cars, which is often the same but may be different. For example, the Porsche March Indy has a short name of "INDY" and a filename code of "PMIN".)
Quote from: HerrNove on September 03, 2026, 08:36:48 PM(some minor glitches in the speedometer of Jaguar and Corvette: maybe a bug when processing the .PVS files? Sorry for raising an issue now, but I cannot keep myself :) )
Yeah, I've seen that issue too when converting car files, though I never bothered to investigate the cause.
QuoteBasically, certain small reductions in speed (such as driving up an inclined plane, or driving in a loop), the game intends to reduce the speed. This is represented as a small, negative products. This negative change is multiplied and shifted, by Borland's unsigned 32-bit division routine (?). The problem is that the quotient is enormous but the game only rtains the low 16 bits and does an arithmetic shift. This results in a significant *positive* speed change.
Stunts itself was originally written using Microsoft C 5.1 (~1988) and assembler
restunts switched to the Borland compiler
Quote from: Foxpup on September 04, 2026, 03:44:28 AMQuote from: HerrNove on September 03, 2026, 08:36:48 PM(some minor glitches in the speedometer of Jaguar and Corvette: maybe a bug when processing the .PVS files? Sorry for raising an issue now, but I cannot keep myself :) )
Yeah, I've seen that issue too when converting car files, though I never bothered to investigate the cause.
I think the error is in the treatment of the `ins2` bitmap of the `STDA` file. For Jaguar and Vette, the bitmap is stored in a special format, as shown by the fact that the high nibble of the third byte of the "Channel bitmasks" has some bits set. Probably the bytes are transposed (i.e. the pixels are stored in column-major order).
The screenshot is taken with my fork of stressed (https://github.com/AlbertoMarnetto/stressed/tree/add-gpega-support), but the regular stressed is also able to process the data just fine. One just need to integrate its handling of special cases: see bitmapresource.cpp#L183 (https://github.com/AlbertoMarnetto/stressed/blob/c5f6d58ca3870dc3a88f13b01065089538d37e43/src/bitmap/bitmapresource.cpp#L183) and following lines.
Screenshot_20260904_090649.png
Quote from: Foxpup on September 04, 2026, 03:44:28 AMQuote from: x29retaliator on September 03, 2026, 06:26:34 PMThe car in the top-left drove down the road a bit, turned, and headed back towards the finish line going the wrong way. Just like the original game it then assumes you "finished" and gives you a huge penalty.
It really shouldn't though, if all you did was drive the wrong way. I guess you changed the way the start/finish line functions in order to account for cars starting on the previous tile, because in the original game, the start/finish line must be approached from the correct direction to count as completing the race.
Also, it looks like you're unnecessarily truncating the cars' full names to 4 characters depsite cars already having a 4-character short name (the gsna resource in the car*.res file) for exactly this purpose. It is used in the original game to identify the opponent's car on the scoreboard, when a high score is recorded while racing against an AI opponent. (This short name is not to be confused with 4-character filename code used to identify cars, which is often the same but may be different. For example, the Porsche March Indy has a short name of "INDY" and a filename code of "PMIN".)
Quote from: HerrNove on September 03, 2026, 08:36:48 PM(some minor glitches in the speedometer of Jaguar and Corvette: maybe a bug when processing the .PVS files? Sorry for raising an issue now, but I cannot keep myself :) )
Yeah, I've seen that issue too when converting car files, though I never bothered to investigate the cause.
Thanks for the help!
Are you sure it doesn't work like that? I tested this against the original DOS version (although with SuperSight) with DOSBox, and I got the same behavior.
Maybe I did something weird though. I should test again.
After further testing, I discovered something interesting: the start/finish line behaves normally only if at least some portion of the track has been driven in the correct direction (merely driving forward from the starting line until reaching the next tile is sufficient to prevent any weird behaviour). If you initially leave the start/finish tile in the wrong direction, and subsequently never drive any part of the track in the correct direction, the start/finish line either will not work at all, or will instantly end the race when the start/finish tile is entered without actually crossing the line.
Judging from your screenshots, it looks like you triggered the latter behaviour, as the Audi appears to be on the boundary of the start/finish tile rather than the start/finish line itself.
Quote from: Foxpup on September 05, 2026, 05:39:00 AMAfter further testing, I discovered something interesting: the start/finish line behaves normally only if at least some portion of the track has been driven in the correct direction (merely driving forward from the starting line until reaching the next tile is sufficient to prevent any weird behaviour). If you initially leave the start/finish tile in the wrong direction, and subsequently never drive any part of the track in the correct direction, the start/finish line either will not work at all, or will instantly end the race when the start/finish tile is entered without actually crossing the line.
Judging from your screenshots, it looks like you triggered the latter behaviour, as the Audi appears to be on the boundary of the start/finish tile rather than the start/finish line itself.
Yes, that sounds consistent with what I can see in both the original DOS game and the port.
Thanks for confirming.
Collision: It works simply by walking every remote car in the update function. Iterate over the cars in the race, put it in the "opponent slot" (the original game also has something like this, for its AI opponent). We effectively end up reusing the old code simply by iterating over the opponent cars we have, there is already collision checking code, and code for the actual collision (the broken glass, explosion that we all love), we just ensure that we check multiple cars this way.
The important thing to understand is that there's no shared collision resolver at all, and the design still supports e.g. multiple collisions happening simultaneously because every client is fully authoritative over its own car. So yes, a simple way to cheat with this system is to just run a malicious client that ignores crashes.
But it is a starting point.
Welcome
@x29retaliator! What you've posted so far looks very promising. I'm keen to see your work in action, so I'd be very interested in a Windows version. :)
Quote from: KyLiE on September 09, 2026, 01:40:37 PMWelcome @x29retaliator! What you've posted so far looks very promising. I'm keen to see your work in action, so I'd be very interested in a Windows version. :)
Thanks!
Quote from: x29retaliator on September 08, 2026, 01:01:56 AMThe important thing to understand is that there's no shared collision resolver at all, and the design still supports e.g. multiple collisions happening simultaneously because every client is fully authoritative over its own car.
So there's no prediction of any kind? That could be problematic for high-latency connections.
Quote from: Foxpup on September 13, 2026, 06:54:05 AMQuote from: x29retaliator on September 08, 2026, 01:01:56 AMThe important thing to understand is that there's no shared collision resolver at all, and the design still supports e.g. multiple collisions happening simultaneously because every client is fully authoritative over its own car.
So there's no prediction of any kind? That could be problematic for high-latency connections.
It seems to work well on low-latency settings. I haven't injected any artificial latency for testing yet as I'm still working out other things.
Collision detection can be tricky, in Stunts it isn't trivial to do just some extrapolation, either, because in Stunts we have loops and corkscrews and jumps, and it isn't obvious for an extrapolation function exactly where the car will end up. I'd need to basically simulate where the car would be (including that it can start driving up a ramp, or up a loop).
I think the important thing should be to just get something testable and playable out there and then have the community improve upon it.
Quote from: x29retaliator on September 13, 2026, 04:18:35 PMI think the important thing should be to just get something testable and playable out there and then have the community improve upon it.
This 👆 Doesn't need to be perfect right away, and it's fun to be part of the development process!
I would like to be respectful towards the original game/license (and also avoid legal trouble), I don't know if they sell it on GOG or similar places, still.
How much of the original game can I just keep in the source code and how much do I need to extract from the original game?
I think what some open source projects in terms of "engine recreations" do is that they don't include graphical assets and just require the user to provide the original game, which they then extract graphical assets, levels, sound, etc. from---so that what they release is essentially not a working game.
Are there any examples I can go by?
Consider that
* Stunts has not been commercially available for decades (GOG, Steam etc. never had it)
* Some of its original devs said they were okay with the game being distributed for free.
* The current legal rightsowner is unclear (Encore Software maybe?). No company has claimed to own Stunts's copyright in the last 20+ years.
I think you should have no problem, either legal and moral, by distributing the full game. The possibility that somebody complains cannot be mathematically excluded but it seems almost totally theoretical. In cases where companies wanted to claim back the rights of long-forgotten games they usually just kindly asked the modders to take down their projects before the new edition came out.
Which is why, even if I am strongly pro-copyright and pro-respecting the authorship of the developers of old games, I feel ok in publishing my mod of Stunts, under my real name even.
If you want to feel safer, your idea of making the mod depend on the user providing the original assets is good: that's what the XWVM project does, and they're dealing with Star Wars, one of the most precious IPs of one of the most copyright-aggressive companies on the planet.
Obviously no method can give perfect assurance of being 100% in the clear: but, retrogaming is a dirty job, and one must accept to get their hands a little stained.
Hello my friends,
The more time pass, the more chances we get to erase the original "spirit" of the game we cherished as teenagers. French philosopher and sociologist Jean Baudrillard had a word for what happens when the copy slowly takes the place of the original: the simulacrum.
Take, say, a fish. He will swim freely in the open water and have a beautiful livery, even sometimes for some species reswim the stream of his own birthplace to give birth again.
Now alter the fish just a little bit. Cook it and serve it in a plate. This is the stage when we alter the code of Stunts.exe with a small skidXXX.exe launch file. The code masks basic reality enough to make the cooked fish, even if better tasting, a distortion of reality.
But there are more stages of alteration: the resuls of what we altered now is "a beast". It makes us question the basic reality of what somebody else knew was called "Stunts". "Stunts without multiplayer? It never existed!"... "We are playing the ORIGINAL game!" Let's call it stage two of Stunts simulacrum. The fish is now sold precooked, in a form of a breaded fish fillet, designed in a shape of a fish. Oh! The irony!
Final form of tampering: The code of the game has no relation to the reality whatsoever, it's his pure simulacrum, in a sea of simulacra, in a simulation, in an ocean of simulations. For a fish, let's call it a chocolate treat out of a silicon matrix molded in the shape of a fish.
And this is where the paradox becomes beautiful.
At the end of the process, nobody remembers the fish.
We argue about whether the chocolate tastes right, whether the silicone mold has the correct proportions, whether the artificial scales are faithful to the original ones. We may even become extraordinarily good at reproducing them industrially. And one day, somebody who has never seen a river will look at our sweet creation and say:
"This is what a fish is."
Perhaps the greatest danger for Stunts is therefore not that we modify it. Games have always survived because people hacked them, studied them, extended them and loved them far beyond what their creators imagined.
The danger begins when the modification erases the memory of being a modification.
When the multiplayer version becomes Stunts.
When the rewritten physics become Stunts.
When our reconstruction becomes more authoritative than the strange, limited, imperfect 1990 program from which everything started.
Final Baudrillardian twist!
We wanted to preserve Stunts forever.
So we improved it so perfectly that we no longer needed Stunts at all.
A new simulation survived.
The original disappeared.
And somewhere, forgotten on an old DOS disk after 35 years of physical preservation, a lifetime for a preindustrial homo sapiens, a tiny 1990 executable is still waiting to remind us that some pipsqueaks could once do wonderful circus tricks, jumping out over the water tiles.
Yours, Alain il Professore.
Quote from: Alain il professore on September 20, 2026, 06:54:47 AMWe wanted to preserve Stunts forever.
there is currently a port ongoing that targets DOS and tries to keep everything as original as possible (not a full reconstruction aka binary equality, not possible due to assembler-parts) but very near to the original so a vanilla/chocolate port, to keep the old spirit
but nothing will ever replace the original bits :)
What exact version of Stunts do you guys use? I'm working on (among other things) an installer that will auto-detect the different versions, but I think I'll just do most of the testing against the version that you guys use.
So which is it?
(Edit: Yes, I still plan to release it with the full source on Github.)
ZakStunts uses Brøderbund Stunts 1.1, but other competitions might use 1.0 to avoid the "left corner bias" bug.
Related article: https://wiki.stunts.hu/wiki/Game_versions
I'm very sorry guys, I've been sufficiently scared now to not publish the source code. Just the fact that Restunts exists (which I based the work on) wouldn't protect me from the legal issues that could arise.
I didn't think this was a big deal at first, but the line-by-line direct transliteration from copyrighted machine code -> disassembly -> C with a 100% faithfulness to the original game of the port is the very thing that makes it a legal problem (I'd basically be redistributing the game executable without permission, which is not okay, even if I leave out all of the data assets). Just because others are bolder than me doesn't mean I won't get into trouble.
It seems that if I were to do it the wrong way, do a rewrite of Stunts, without directly using the disassembly then it might have been a different situation legally. This is really a shame.
I'm sorry. I just thought I should say something instead of making someone keep holding their breath.
With the rate of development of agentic tools though I think it is only a matter of time before what I did (which also heavily used agentic tools, but was a major pain nevertheless at this level of agentic tool sophistication) becomes trivial.
I guess I am overly cautious and cowardly. :'(
If I could get permission from the IP holder then I'd be happy to do it.
Broderbund 1.0 is not an option because the slow management of the replay system and other important stuff like the "accelerating in the air" effect which it's not BB 1.0 version. Also no driving on the tunel's roof... BB 1.1 is an improved version over BB 1.0 for many reasons.
Quote from: x29retaliator on September 25, 2026, 01:09:11 AMIf I could get permission from the IP holder then I'd be happy to do it.
I think this community has been trying to find out who the IP holders are for two decades, without success. Companies buying companies, studios going bust, etc, the trail has gone cold. You'll find various historical threads on this forum.
The result is that Stunts falls squarely in the grey bucket of
abandonware no-one seems to care about. ZakStunts has dared hosting a downloadable zip, and it's been there for a quarter of a century 🤷