Spinning Replay Fix [SA]

[Reynard The Fox]

Spinning Replay Fix

Introduction

This should have been fixed a very long time ago, but alas here we are now on the verge of 2023. As many of you may know the replay system in GTA san andreas was a big downgrade from the one in VC. No sparks and moving wheels for the bikes. Although it still functions, it has never looked as great as VC replays.

Getting the wheels to spin in replays has been a goal for many for a very long time. Although I had attempted it before I always got stuck because of multiple factors. Recently I came across gta-reversed-modern, a reimplementation of SA that doesnt strafe too far away from the original source. The replay part had recently been implemented and this gave some fresh insight into what actually happens in SA replays.

It turns out that the saving of the state of the wheels is only implemented for cars. For all other vehicle types, nothing similar is stored in the replays. When encountering a vehicle in a replay a simple check is done to see if it is a car. If it is, it then stores or retrieves the wheel data, wheel orientation and wheel rotation, to or from the replay.

To then implement the same thing for bikes requires us to implement such a routine into the code ourselves. This is exactly what I have been doing the last few days. First I implemented it directly into gta modern reversed, but this turned out to be a little buggy. This didn't seem like a suitable choice because of the bugs and difficult redistribution. I would like to see some general adoption of this and so I implemented it using Plugin SDK. The code is available on Github here.

Results

Here you can see a short clip of me driving an NRG in a replay demonstrating that both front and back wheels are spinning forwards and backwards. In addition, the front and back suspension also work properly.

Here is another comparison between old without fix and with the new fix on the same replay.

https://www.youtube.com/watch?v=TVWyH21dDYc

Compatibility and Bugs

The replays generated when using this fix are able to be played when the fix is not active. It would look exactly the same as before. Conversely, older replays are able to be played, but the wheels of bikes will most likely bug out. There is no actual bike wheel data so it tries to read whatever gibberish is present in the replay. Car wheels should function as normal, in both cases.

The fix should work for all bikes except the quad. A special fix has to be written for the quad. Let me know if any of the normal bikes give any issues.

I have not tested if it is compatible with freeplay or other .asi scripts but I foresee no problems there.

Download

You can download it here

Instructions

Put the .asi script in the GAME_FOLDER/scripts folder and use your favourite .asi loader to load it. I recommend Silent's which you can find here.

Disclaimer

I am not responsible for any corrupt replays if you choose to use this fix.

Thanks

Thanks to Erney for doing some quick testing. I wish you happy stunting with this fix, may your stunts be large and your grinds long. Maybe we can fix sparks someday!

[SyperDimon]

Nice!

[VaNilla]

That's awesome, dope job . I wish to learn programming every time I see cool things like this.

I have a question based on the replay system's source code, I tried to read it but I could only understand so much as someone with zero programming experience. I was once under the impression that SA captures replay data every 40ms (25fps), but later down the line, I compared live footage to replays, and noticed that playing replays at 30fps is often closer to the actual game speed, particularly with FL off replays. This lead me to believe that SA might actually capture replays at 33.3*ms (30fps), and they're simply being played back too slowly due to SA's frame limiter being 25fps. Now that I've attempted () to read the replay system's source code, I'm questioning my conclusions.

static uint32& s_FrameRecordCounter = *reinterpret_cast<uint32*>(0x97FB40); // STATICREF
    if (Mode == MODE_PLAYBACK) {
        PlayBackThisFrame();
    } else if (CTimer::GetTimeInMS() - s_FrameRecordCounter > 26) {
        s_FrameRecordCounter = CTimer::GetTimeInMS();
        RecordThisFrame();
    }

I might be understanding this totally wrong, but I'm guessing it means that with FL on, the game captures 25 frames into the replay buffer per second, and with FL off (26fps or above), it switches from calculating time in frames (25fps) to calculating time in milliseconds (40ms), to get the same amount of frames without suffering VC's variable frame rate replay issues, but without programming knowledge I'm probably just making stupid guesses . The main reason I'm interested is to try and match SA's replay recordings in future videos to game speed as closely as possible, and it seems like you have insight .

Speaking of game and replay speed, I have a second question if I may. It's known that SA's FL off replays are usually slower than FL on replays, but I'm not 100% certain why. I'm guessing they're slower either due to interpolation issues when the frame rate rapidly changes, or when the frame rate isn't a multiple of 25fps or 30fps (depending on which most closely resembles the rate of capture), but is that misguided? Your knowledge would be very helpful .

[Rusch69]

Conversely, older replays are able to be played, but the wheels of bikes will most likely bug out. There is no actual bike wheel data so it tries to read whatever gibberish is present in the replay.

That's very unfortunate to hear. Do you maybe happen to have a visual example of how faulty it can look?
Also, does this count for the spinning wheels only or also the suspensions? Having those work independently could still make a neat lil improvement for older replays.

Nevertheless, awesome work and it's good to see someone finally got this shit figured out! Whoever's still stunting SA beyond 2022 should be using this from now on.

[Reynard The Fox]

That's awesome, dope job . I wish to learn programming every time I see cool things like this.

Just do it.

I have a question based on the replay system's source code, I tried to read it but I could only understand so much as someone with zero programming experience. I was once under the impression that SA captures replay data every 40ms (25fps), but later down the line, I compared live footage to replays, and noticed that playing replays at 30fps is often closer to the actual game speed, particularly with FL off replays. This lead me to believe that SA might actually capture replays at 33.3*ms (30fps), and they're simply being played back too slowly due to SA's frame limiter being 25fps. Now that I've attempted () to read the replay system's source code, I'm questioning my conclusions.

static uint32& s_FrameRecordCounter = *reinterpret_cast<uint32*>(0x97FB40); // STATICREF
    if (Mode == MODE_PLAYBACK) {
        PlayBackThisFrame();
    } else if (CTimer::GetTimeInMS() - s_FrameRecordCounter > 26) {
        s_FrameRecordCounter = CTimer::GetTimeInMS();
        RecordThisFrame();
    }

I might be understanding this totally wrong, but I'm guessing it means that with FL on, the game captures 25 frames into the replay buffer per second, and with FL off (26fps or above), it switches from calculating time in frames (25fps) to calculating time in milliseconds (40ms), to get the same amount of frames without suffering VC's variable frame rate replay issues, but without programming knowledge I'm probably just making stupid guesses . The main reason I'm interested is to try and match SA's replay recordings in future videos to game speed as closely as possible, and it seems like you have insight .

Speaking of game and replay speed, I have a second question if I may. It's known that SA's FL off replays are usually slower than FL on replays, but I'm not 100% certain why. I'm guessing they're slower either due to interpolation issues when the frame rate rapidly changes, or when the frame rate isn't a multiple of 25fps or 30fps (depending on which most closely resembles the rate of capture), but is that misguided? Your knowledge would be very helpful .

It is actually a bit of mystery to myself as well. It seems indeed that the game tries to capture a frame for a replay every 26 milliseconds. Which would make it record at 38~fps, but I'm not sure if this is actually the case. I have experimented before with this changing the value of 26 to other values and I remember that by changing it to 3 ms it would save replays at about 60 fps. However, this does not make much sense. Actually I believe the main game runs at 30 fps, but there is another performance delay that locks the FPS at 25 in the main game idle function. You can manipulate this delay by altering a single byte located at 0x53E94C. You can change it to 1 to have replays to play at 30 fps. You can do this easily with CheatEngine. With some more hacking it should be possible to record and play replays at any framerate, but this would change the way physics is processed and thus counts as modding.

Conversely, older replays are able to be played, but the wheels of bikes will most likely bug out. There is no actual bike wheel data so it tries to read whatever gibberish is present in the replay.

That's very unfortunate to hear. Do you maybe happen to have a visual example of how faulty it can look?
Also, does this count for the spinning wheels only or also the suspensions? Having those work independently could still make a neat lil improvement for older replays.

It counts for both spinning wheels and suspensions. It looks terrible actually, the wheels will jump all over the place moving quite far away from the bike at one frame and then completely on the other side in the other frame. There is no actual bike wheel data in normal replays.

[VaNilla]

This may be foolish, but I think I might have cracked the code . Silent has stated that SA has 14ms of frame delay, which he removes in SilentPatch to lock SA to 30fps with FL on, and unlock the game to an arbitrary frame limit of 1000fps with FL off.

14ms frame delay has been removed. As a result, game now locks properly on 30 FPS instead of 25 FPS.
Game FPS has been limited to 1000 FPS (with Frame Limiter off) to prevent freezing during fadeout moments.

Now based on your reply, SA's source code suggests that SA's replay system captures data every 26ms.

It seems indeed that the game tries to capture a frame for a replay every 26 milliseconds.

I'm guessing (without programming knowledge I don't know for sure) that this line of code supports your conclusion.

else if (CTimer::GetTimeInMS() - s_FrameRecordCounter > 26)

I have a theory, assuming that everything stated previously is correct. We know that 26ms + 14ms = 40ms (25fps). Maybe this suggests that SA's replay system capturing data at 26ms (which ostensibly equals 38.4615384615fps) actually adds up to 40ms (25fps) when SA's frame delay is considered.

This is further supported by the final piece of the puzzle.

I have experimented before with this changing the value of 26 to other values and I remember that by changing it to 3 ms it would save replays at about 60 fps. However, this does not make much sense.

This makes total sense when considered with my theory. We know that 3ms + 14ms = 17ms (58.8235294118fps). Perhaps this explains why changing SA's code to 3ms captures replays at approximately 60fps (you would need to set SA's code to 2.6666666667ms for it to add up to 16.6666666667ms equaling 60fps exactly). GTA SCIENCE!!!!

[Herrarge]

Nice work on the script. Definitely using it from now on. It kind of bugs out when doing wheelies/stoppies with a MTB, though.

[Reynard The Fox]

This makes total sense when considered with my theory. We know that 3ms + 14ms = 17ms (58.8235294118fps). Perhaps this explains why changing SA's code to 3ms captures replays at approximately 60fps (you would need to set SA's code to 2.6666666667ms for it to add up to 16.6666666667ms equaling 60fps exactly). GTA SCIENCE!!!!

That sounds about right. It never occurred to me to add the two time constants together to get the end FPS. I guess we cracked the code.

Nice work on the script. Definitely using it from now on. It kind of bugs out when doing wheelies/stoppies with a MTB, though.

Hhmm I didn't notice that before. In any you can always not use the script the record MTB stunts. It should look normal then.

[Erney]

Nice work on the script. Definitely using it from now on. It kind of bugs out when doing wheelies/stoppies with a MTB, though.

Hhmm I didn't notice that before. In any you can always not use the script the record MTB stunts. It should look normal then.

For me it worked fine with mtb wheels though.