Messages

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.

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.

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.

So the power gear bug, this really hasn't been documented before?

As far as I know, not beyond what's on the wiki article. 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!

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

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?

Stunts seems to be clever enough to always take whatever the lowest value in your model is and make that 0. At least, that's what I remember.

It does no such thing; if it did, my workaround of translating the entire model down 8 units would have no effect.

I've never noticed any floating, I suspect it might have happened because of the size of your wheels, knowing which vehicle you were working on.

Actually that vehicle is so large that a height difference of 8 units is barely noticeable; the issue more strongly affects reasonably sized vehicles. For example, here's the Porsche March Indy demonstrating an unfortunate misunderstanding of how ground effect is supposed to work (F3 camera, left 13, down 5, default zoom). For reference, the Indy's floorpan is at y=0, the bottom of the wheels are at y=-1, and the ground is visibly far lower than that.

Also note that this specifically only affects player and opponent car1/car2 models; for scenery objects (including ghost cars) and the showroom car0 model, the ground is at y=0, as expected.

.x2 is written to, but it should be y2

Oof. Yup, pretty sure that's the bug right there. In what perhaps should have been obvious from the start (but hindsight's 20/20), bugged explosions are indeed distorted they way they are because one of their x coordinates is erroneously set to the sphere's y coordinate.

If you tell me where did you get a Restunts version showing the explosion bug, I can try to trace at which point the bug was removed.

I didn't. I'm just a big dummy and got the executables mixed up during testing, because as far as I can tell the bug is not in Restunts, only in SuperSight and the original DOS executable.

Nevermind, I'm just dumb. It turns out the bug is not present in Restunts, and I don't know why I thought it was. I must have somehow gotten the executables mixed up during testing at some point. The bug is only in SuperSight and the original DOS executable.

Unfortunately this is not my merit/fault. This mod is based on Restunts, a project that aims to rewrite Stunts in C. The fact that some bugs of the original game are missing means that the conversion is imperfect, which is a good thing for players but the Restunts project participants won't be happy to know (the project is not very active however, so this shouldn't ruin their weekend too much).

No, that bug is faithfully replicated in Restunts and all mods derived from it, including SuperSight. It is definitely something you changed in this mod that fixed it. EDIT: I'm wrong.

Here is a freebie for those taking part in the survey. A mystery mod. Better you fasten your seatbelt before you try this one! 

Amazing, you actually fixed the sphere explosion bug! Did you actually figure out the underlying cause or just exclude sphere primitives from the bounding box calculation? EDIT: I was wrong.

As for the camera mod itself, it is somewhat limiting that the camera cannot be rotated at all while set to 90 degrees. It won't even follow the car's orientation. Gimbal lock bug? Also, some custom cars (eg the Silverado monster truck) will crash with an out-of-memory error while attempting to load dashboard graphics. This seems to mainly affect cars with a large dast/dasm covering most or all of the screen.

But other than those issues, the mod seems to work fine. At least, I didn't encounter any other weird surprises.

[sphere primitive]

While working on a new car, I encountered the explosion sprite bug described but never solved in this thread and decided to investigate. After much testing, I am confident the sphere primitive is the culprit. A car model will exhibit the bug if and only if it has at least one sphere primitive; the number, size, location, and orientation of the sphere(s) seems to make no difference. Even a zero-size sphere at the model's origin will produce the bug. Early theories that the bug is related to the size of the car model are unfounded and were probably influenced by the fact that the most common use of sphere primitives is to represent a driver's helmet in small open-cockpit race cars, and also by the fact that, under normal circumstances, the model's bounding box determines the origin and scale of the explosion sprite.

My theory is that the function that determines a model's bounding box in screen space has a bug when it comes to sphere primitives, which was never caught during testing because none of the original car1/car2 models have spheres, nor do the car0 models ever explode. (Come to think of it, I'm pretty sure Indy's car0 is the only model in the entire game to use the sphere primitive, so it wouldn't surprise me if sphere rendering was added to the game at the last minute without any real testing at all.)

[disqualifying any laps that incur penalty time]

I'm not sure this is live race material, but maybe some sort of dump truck challenge?

I obviously never really intended this to be used for serious racing, though it might be interesting on a track designed around the vehicle's limitations (namely, its complete inability to negotiate almost any obstacle at all). Joe's version A is the only original track that really works.

Also, you'll probably want to institute a rule disqualifying any laps that incur penalty time: at its flat top speed, the Cat takes 3.70 seconds to cover a single tile, versus the 3.00 second penalty for skipping each tile, thus the optimum strategy is to just do a U-turn at the starting line and take the penalty for skipping the entire track; it would take a pretty extraordinary combination of ramp boosts and clever shortcuts to beat that time (probably impossible unless the track is specifically designed for such techniques).

Some other random things to keep in mind if you want to take this vehicle seriously:

• The gear ratios are geometric, not progressive, so the ideal shift point is the same for each gear and I was able to tune the auto shift points optimally. I think the only optimisation possible with manual shifting is holding first gear beyond the redline until idle torque runs out. (Air shifting? Power gear? Forget about it!)
• The front track is significantly wider than the rear track, which in real life has a huge impact on handling, but in Stunts, it has almost no effect at all except on how easy it is to drop one tyre on the grass when taking a curve as close as possible.
• Don't worry about tunnel ceilings; I think you need to be going over 50 mph up a ramp to be at risk of hitting them, and it's impossible to go that fast.
• Do worry about the trees on the boulevard: sure, you can't collide with the tree trunks, but you can collide with the tree tops, and the truck is tall enough that it will, if you manage to get it onto the median strip in the first place.

So, I ran an entropy test (results in attached .csv file) on all your .trk files to quickly assess which ones, if any, are indeed just random garbage, and the answer regrettably appears to be "almost all of them". Normal Stunts track files have an entropy of around 2 bits per bytes, while these recovered files average over 6 bits per byte, with many close to the limit of 8 bits per byte (pure randomness). Two files (~F2249.TRK and ~F2265.TRK) have 0 entropy as they are completely blank. There are some files in between these two extremes, indicating that they may be candidates for more advanced recovery, but almost all of them appear to just be blocks of random garbage with strings of null bytes in between. Only one file (~F2323.TRK) seems to contain a "valid" Stunts track, in that it contains valid track pieces and loads correctly in the in-game editor, though it's just a collection of seemingly random track pieces filling two-thirds of the map, with the remaining third of the map completely blank. I don't think you can do much with it.

ETA: Some of these files seem to contain regular data structures aligned to 16-byte boundaries, which appear to be neither random garbage nor track data. Possibly recoverable data from other files entirely? ETA: Confirmed: ~F2269.TRK definitely isn't a Stunts track: it's a perfectly intact fragment of your SYSTEM.INI file! If you had any personal or sensitive information on this PC, some of it may be in these files, so you may want to take it down.

That is quite an achievement on making that "fit" into Stunts, either in terms of performance and appearance!

Thank you! Especially regarding the appearance; getting that damn model under 256 vertices was by far the most difficult part of this project.

As for the vehicle's performance, this whole thing actually began as just a goofy experiment with giant cars, but I decided to get serious with it after implementing the torque curve and gear ratios of a real machine and seeing just how well it works in the game. Torquey engines just hit different, and this one's as torquey as they get. We need more cars with torquey engines in this game, though probably more reasonably sized.

Beatiful!!! I'll make its wiki article as soon as I can!!

I had a feeling you'd like it.

Also, here's the physical parameters page in CarWorks showing just how ridiculous this machine is. (Keep in mind that the mass, drag, and torque values have all been reduced from the realistic values by a factor of 12 to make the torque curve fit while keeping the power-to-weight and drag-to-weight ratios constant.)