Replay recording and limits

[dreadnaut]

Posts collected from the ZakStunts shoutbox in May 2018, for easier reading.

Afullo
About the time limitations, I'm trying with MS1.1 and I can go past the 10 minutes replay limit (with the correct displaying of the truncation message):



Note that the replay starts at 0:30.00 and ends at 10:20.30, so the older recording is progressively discarded. Now I'm going to proceed through the 25 minutes limitation, and to see what will happen...

Afullo
I just hit the 25 minutes limit, and the game simply returns the replay screen, like pressing ESC; trying to continue driving from the menu, which is still an active option (written in white and not in blue, differently from "save replay" which becomes inactive after 10 minutes), will result in the replay screen disappearing for a fraction of second, and then reappearing still stucked at 25:00.00... Maybe it has something to do with possible overflow errors: you can theoretically complete a track with a time higher than 25 minutes if you collect proper penalties, but I remember at least once to have seen a minus sign in the total time (elapsed+penalty), which was with all chance caused by a low number of bits for the integers involved...

Afullo
Indeed, in this example (units are 0.05):



I skipped 898 tiles, so I was charged with a penalty of 2694 seconds, or 53880 units. Modulo 2^16 = 65536 this equals -11656 units, or -582,8 seconds, or -9:42.80. This is consistent with the limit: 25 minutes are 1500 seconds, or 30000 units; 16-bit signed integers range from -32768 to 32767, so it would be possible to reach safely 27.18:35, I guess 25.00:00 is simply the nearest "sufficiently rounded" lower number.

Afullo
Just a minor remark: with the terminology used in Stunts Wiki: Penalty_time , I skipped *896* tiles, it is the chain to be 898 elements long.



By leaving the track on tile 1 (I count them from 1, don't knowing whether there is an internal counting starting from 0), i.e. very close to the start/finish line, I rejoined it on tile 898, i.e. the one in position (3,30) on the grid; so the tiles from 2 to 897 were skipped, tile 898 is the re-entry element, and tile 899 is the element coming immediately after it, closing the penalty chain. Note that intersecting another nearby tile, e.g. tile 58 which is one step east to the s/f line, does not result in the chain interrupting, since (by quoting directly from the wiki) if, after performing a penalty-inducing shortcut, one returns to the track and then leaves it immediately, without closing the penalty chain, penalty will be calculated as if all elements between the first leaving of the track and the final re-entry had been skipped, even those crossed upon the temporary rejoining of the track.

Cas
This is very interesting. I think it would deserve a good forum thread so it can be accessed easily. I hadn't sat to think about when the 32767 cycle limit would be exceeded. I think I never drove that long. What calls my attention is that the "last minutes" are kept instead of the first. We know Stunts records the key presses, not the physical status, so the only way to conciliate these two facts would be that Stunts uses an inverse function when going backwards, but this seems to contradict the fact that you can immediately warp to the beginning of the replay. Maybe this is only the case when it's not truncated, or maybe Stunts does memorise the replay initial conditions. Then if the replay could be saved, we'd see an additional field in it, but the key presses are clearly saved right after the track data in memory.

[Cas]

Thanks for placing this here, Dreadnaut!

Well, yes, it looks like the different versions of Stunts behave quite differently when one takes the game to the extremes. I can say, because I've seen this in the past, that the memory region where Stunts places the keypresses begins just after the 1802 track bytes. If you create a TRK file with more than those bytes, then the extra bytes will be loaded onto that region. Because Stunts is ready to accept up to 10 minutes of replay info, this means 600 seconds, at 20 Hz, that is 12000 bytes. There doesn't seem any initial condition information anywhere.

[afullo]

Probably the initial condition is not stored at all: it is kept during runtime, but Stunts does not allow to save a replay starting not from zero, although it is possibile to view (part of) it, but when you start a new race it will be lost.

[Cas]

Yes, if you're allowed to set back at the beginning immediately, then it means there's no backward calculation and the only explanation would be that the starting conditions are set somewhere in memory. On the other hand, notice how the speed at which Stunts calculates when you fast-forward does not increase with faster computers. It's the same today under DOSBox as it was on a 286 and I've run Stunts on my current computer in FreeDOS purely and it's still slow to fast-forward. This means that there's a delay somewhere in the code. Maybe the code for racing was reused for replaying and the delay was already there and removing it would've changed the results.

[afullo]

It could be so, there are some known limitations of that kind. For example if you press ESC before having got down completely from the truck (in the first second), and then you continue driving, you can start from the lorry, but then the pattern would not fit the standard of starting properly from the line, and while the replay is re-run it would show in general a different path for your car. Some parameters seem to be fixed regardless of the environment and the initial conditions in which the race is taking place...

[Duplode]

For example if you press ESC before having got down completely from the truck (in the first second), and then you continue driving, you can start from the lorry, but then the pattern would not fit the standard of starting properly from the line, and while the replay is re-run it would show in general a different path for your car. Some parameters seem to be fixed regardless of the environment and the initial conditions in which the race is taking place...

The rolling out of the truck is performed through a special purpose auto-driving mode. Quoting this thread:

Quite a few branches of update_car_state are skipped if a certain "input mode" flag is not in its usual, waiting-for-driving-input, state (that is e.g. what makes it impossible to crash after crossing the finish line). If you track down the places in which this flage is not in its usual state, one nice thing that will be revealed is how the car is rolled out of the truck -- that is, the mechanics of accelerating it a little bit and then slowing down so that it stops at the right place.

Pressing ESC and then continuing driving allows you to escape this mode before you are supposed to.

The proper initial position is indeed specified somewhere else (I don't remember where). If you look closely, you'll note the staring position (where "Fasten your seatbelt" shows up) is, in general, not exactly the same one where the car stops after rolling out of the truck. One car for which that is relatively easy to see is the McLaren.

[Cas]

Being able to locate the memory area and the format where the initial position is could allow creating a tool to allow special tracks that can start from slopes. Also, if the region where the car current vector can be located, a TSR tool under Stunts could detect when the car passes through other positions, allowing to set checkpoints and things like that. It'd be a lot of work, though.

In the past, working on the Vizcacha project, I found that creating TSR wraps for Stunts often has conflicts with the DRM-crack system (it may get disabled, thus reactivating the DRM). If we had more knowledge on the memory regions, maybe we could ditch that crack and use something that allows plug-ins instead. It'd be all DOS code.... beautiful XD

[dreadnaut]

It'd be all DOS code.... beautiful XD

Oh my, it must be 20 years since I last wrote a TSR program. They were a giant mess, but hey, magic!