Messages

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.

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.)

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?

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 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.

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.

Thanks!

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.

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.

Yes, that sounds consistent with what I can see in both the original DOS game and the port.

Thanks for confirming.

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.

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".)

(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.

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.

Also thanks for the heads up on the aspect ratio! I didn't notice!

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,

I 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!

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.

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

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.

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.

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?

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.:

Code Select Expand

    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.