atmos
@atmossig.bsky.social
July 5, 2025 at 5:14 AM
P.S my bad if wording sucks or I got anything wrong lmao. I tried my best to explain it.
July 5, 2025 at 5:13 AM
P.S my bad if wording sucks or I got anything wrong lmao. I tried my best to explain it.
Thanks for reading! More to come soon. Gonna tackle fixing some other bugs e.g., cloth freaking out at high fps and general choppiness at high fps, incl a bug with Franklin using his special ability too fast and it pauses dialog for too long.
July 5, 2025 at 5:13 AM
Thanks for reading! More to come soon. Gonna tackle fixing some other bugs e.g., cloth freaking out at high fps and general choppiness at high fps, incl a bug with Franklin using his special ability too fast and it pauses dialog for too long.
-and we got higher refresh rate monitors and we could run older titles at higher frame rates, it pushes beyond the 60FPS target, so it leads to the bug.
July 5, 2025 at 5:13 AM
-and we got higher refresh rate monitors and we could run older titles at higher frame rates, it pushes beyond the 60FPS target, so it leads to the bug.
It was set as 60 since the game would never go above it, it couldn't even reach it, they probably had internal PC versions that would play it on a 60hz monitor (refresh rate lock) so this issue would've never happened to them.
When newer monitors came out and as hardware improved-
When newer monitors came out and as hardware improved-
July 5, 2025 at 5:13 AM
It was set as 60 since the game would never go above it, it couldn't even reach it, they probably had internal PC versions that would play it on a 60hz monitor (refresh rate lock) so this issue would've never happened to them.
When newer monitors came out and as hardware improved-
When newer monitors came out and as hardware improved-
-which is the correct state. This remains true for any framerate.
== HOW IT MIGHT'VE SLIPPED THROUGH ==
Easy, fixed development hardware, this game was made originally for the PS3/XENON hardware (Xbox 360), which ran the game at around 30fps~, dipped lower but still, target fps was 30.
== HOW IT MIGHT'VE SLIPPED THROUGH ==
Easy, fixed development hardware, this game was made originally for the PS3/XENON hardware (Xbox 360), which ran the game at around 30fps~, dipped lower but still, target fps was 30.
July 5, 2025 at 5:13 AM
-which is the correct state. This remains true for any framerate.
== HOW IT MIGHT'VE SLIPPED THROUGH ==
Easy, fixed development hardware, this game was made originally for the PS3/XENON hardware (Xbox 360), which ran the game at around 30fps~, dipped lower but still, target fps was 30.
== HOW IT MIGHT'VE SLIPPED THROUGH ==
Easy, fixed development hardware, this game was made originally for the PS3/XENON hardware (Xbox 360), which ran the game at around 30fps~, dipped lower but still, target fps was 30.
-there is a 42.8& chance that the number will be less than the fraction, causing iAmmoToDeplete to become 1.
Over the course of 140 frames in one second, this will approx happen 42.8% of the time (140 * 0.428 ≈ 60).
The total ammo depleted in that second will be ~60 units-
Over the course of 140 frames in one second, this will approx happen 42.8% of the time (140 * 0.428 ≈ 60).
The total ammo depleted in that second will be ~60 units-
July 5, 2025 at 5:13 AM
-there is a 42.8& chance that the number will be less than the fraction, causing iAmmoToDeplete to become 1.
Over the course of 140 frames in one second, this will approx happen 42.8% of the time (140 * 0.428 ≈ 60).
The total ammo depleted in that second will be ~60 units-
Over the course of 140 frames in one second, this will approx happen 42.8% of the time (140 * 0.428 ≈ 60).
The total ammo depleted in that second will be ~60 units-
The fix works by calculating the ideal depletion ratio as a float. For Example, at 140 FPS, the ratio is (1/140) / (1/60) which is approx 0.428
The integer part (0) is taken as the base amount to deplete.
The fractional part of (0.428) is used as the chance
A random number is generated-
The integer part (0) is taken as the base amount to deplete.
The fractional part of (0.428) is used as the chance
A random number is generated-
July 5, 2025 at 5:13 AM
The fix works by calculating the ideal depletion ratio as a float. For Example, at 140 FPS, the ratio is (1/140) / (1/60) which is approx 0.428
The integer part (0) is taken as the base amount to deplete.
The fractional part of (0.428) is used as the chance
A random number is generated-
The integer part (0) is taken as the base amount to deplete.
The fractional part of (0.428) is used as the chance
A random number is generated-
Now testing again once we recompile it...
Yep, it's fixed! We can pour the gas can at 60FPS perfectly fine, and when we go-to 240FPS (way higher than 60FPS) we pour the same amount of fuel as before!
Yep, it's fixed! We can pour the gas can at 60FPS perfectly fine, and when we go-to 240FPS (way higher than 60FPS) we pour the same amount of fuel as before!
July 5, 2025 at 5:13 AM
Now testing again once we recompile it...
Yep, it's fixed! We can pour the gas can at 60FPS perfectly fine, and when we go-to 240FPS (way higher than 60FPS) we pour the same amount of fuel as before!
Yep, it's fixed! We can pour the gas can at 60FPS perfectly fine, and when we go-to 240FPS (way higher than 60FPS) we pour the same amount of fuel as before!
== CORRECTED CODE ==
To solve this, the logic had to be replaced entirely lmao, it has to handle fractional depletion values that occur at high frame rates. The final solution was to use a probably-based approach to ensure the avg. depletion rate is always consistent.
To solve this, the logic had to be replaced entirely lmao, it has to handle fractional depletion values that occur at high frame rates. The final solution was to use a probably-based approach to ensure the avg. depletion rate is always consistent.
July 5, 2025 at 5:13 AM
== CORRECTED CODE ==
To solve this, the logic had to be replaced entirely lmao, it has to handle fractional depletion values that occur at high frame rates. The final solution was to use a probably-based approach to ensure the avg. depletion rate is always consistent.
To solve this, the logic had to be replaced entirely lmao, it has to handle fractional depletion values that occur at high frame rates. The final solution was to use a probably-based approach to ensure the avg. depletion rate is always consistent.
So when at any FPS above 60, e.g., 140, it is behaved as if it was at 60FPS, it calculated iAmmoToDeplete as 1, but since it is doing this for every single one of those 140 frames per second, the can drains at a rate of 140 units/sec, more than twice as fast it should normally.
July 5, 2025 at 5:13 AM
So when at any FPS above 60, e.g., 140, it is behaved as if it was at 60FPS, it calculated iAmmoToDeplete as 1, but since it is doing this for every single one of those 140 frames per second, the can drains at a rate of 140 units/sec, more than twice as fast it should normally.
At any FPS above 60, the fwTimer::GetTimeStep() becomes smaller than the 60FPS baseline. The MAX function then incorrectly discards the real (and smaller) delta time, and instead uses the larger fBaseTimeStepSeconds.
July 5, 2025 at 5:13 AM
At any FPS above 60, the fwTimer::GetTimeStep() becomes smaller than the 60FPS baseline. The MAX function then incorrectly discards the real (and smaller) delta time, and instead uses the larger fBaseTimeStepSeconds.
HOWEVER! The line
const float fCurrentTimeStep = MAX( fwTimer::GetTimeStep(), fBaseTimeStepSeconds );
Introduces a bug.
At 60FPS or below, it works correctly, fwTimer::GetTimeStep() will be 1.0/60.0 or greater, so the MAX function chooses the correct delta time.
const float fCurrentTimeStep = MAX( fwTimer::GetTimeStep(), fBaseTimeStepSeconds );
Introduces a bug.
At 60FPS or below, it works correctly, fwTimer::GetTimeStep() will be 1.0/60.0 or greater, so the MAX function chooses the correct delta time.
July 5, 2025 at 5:13 AM
HOWEVER! The line
const float fCurrentTimeStep = MAX( fwTimer::GetTimeStep(), fBaseTimeStepSeconds );
Introduces a bug.
At 60FPS or below, it works correctly, fwTimer::GetTimeStep() will be 1.0/60.0 or greater, so the MAX function chooses the correct delta time.
const float fCurrentTimeStep = MAX( fwTimer::GetTimeStep(), fBaseTimeStepSeconds );
Introduces a bug.
At 60FPS or below, it works correctly, fwTimer::GetTimeStep() will be 1.0/60.0 or greater, so the MAX function chooses the correct delta time.
So for example, draining the can in 10 seconds regardless of FPS.
== ORIGINAL FLAWED CODE ==
Formatted to fit, not what it looks like in og.
Whoever was developing this correctly identified the need for the baseline fBaseTimeStepSeconds and to use the actual time per frame fwTimer::GetTimeStep()
== ORIGINAL FLAWED CODE ==
Formatted to fit, not what it looks like in og.
Whoever was developing this correctly identified the need for the baseline fBaseTimeStepSeconds and to use the actual time per frame fwTimer::GetTimeStep()
July 5, 2025 at 5:13 AM
So for example, draining the can in 10 seconds regardless of FPS.
== ORIGINAL FLAWED CODE ==
Formatted to fit, not what it looks like in og.
Whoever was developing this correctly identified the need for the baseline fBaseTimeStepSeconds and to use the actual time per frame fwTimer::GetTimeStep()
== ORIGINAL FLAWED CODE ==
Formatted to fit, not what it looks like in og.
Whoever was developing this correctly identified the need for the baseline fBaseTimeStepSeconds and to use the actual time per frame fwTimer::GetTimeStep()
-to emit a continuous stream of "effect", which, the Petrol Can does.
The primary job of it is to handle this continuous action and most importantly deplete the weapon's ammo over time as the player holds the fire button.
The goal of the depletion is to happen at a constant rate of course.
The primary job of it is to handle this continuous action and most importantly deplete the weapon's ammo over time as the player holds the fire button.
The goal of the depletion is to happen at a constant rate of course.
July 5, 2025 at 5:13 AM
-to emit a continuous stream of "effect", which, the Petrol Can does.
The primary job of it is to handle this continuous action and most importantly deplete the weapon's ammo over time as the player holds the fire button.
The goal of the depletion is to happen at a constant rate of course.
The primary job of it is to handle this continuous action and most importantly deplete the weapon's ammo over time as the player holds the fire button.
The goal of the depletion is to happen at a constant rate of course.
In "Weapon.cpp" the code that controls the jerry can pouring logic is a method called CWeapon::FireVolumetric
This methods determines how a weapon behaves when used. Other weapons use FireDelayedHit or FireProjectile, for this, it uses FireVolumetric, it's a special case designed for weapons-
This methods determines how a weapon behaves when used. Other weapons use FireDelayedHit or FireProjectile, for this, it uses FireVolumetric, it's a special case designed for weapons-
July 5, 2025 at 5:13 AM
In "Weapon.cpp" the code that controls the jerry can pouring logic is a method called CWeapon::FireVolumetric
This methods determines how a weapon behaves when used. Other weapons use FireDelayedHit or FireProjectile, for this, it uses FireVolumetric, it's a special case designed for weapons-
This methods determines how a weapon behaves when used. Other weapons use FireDelayedHit or FireProjectile, for this, it uses FireVolumetric, it's a special case designed for weapons-
The code for the weapons is stored in "game\Weapons\Weapon.cpp" along with tons of other code for things like debugging, accuracy, bullet, explosion, etc.
== ABOUT THE CODE ==
== ABOUT THE CODE ==
July 5, 2025 at 5:13 AM
The code for the weapons is stored in "game\Weapons\Weapon.cpp" along with tons of other code for things like debugging, accuracy, bullet, explosion, etc.
== ABOUT THE CODE ==
== ABOUT THE CODE ==
As you can see in the 2nd clip, when I go to 240fps, it pours WAYY faster, like WAYY too fast. Let's fix it, since that should NOT be happening...
July 5, 2025 at 5:13 AM
As you can see in the 2nd clip, when I go to 240fps, it pours WAYY faster, like WAYY too fast. Let's fix it, since that should NOT be happening...
In Grand Theft Auto V, when your fps is anywhere above 60FPS the gas can will pour faster than if you were on 60FPS
Video of issue attached, 1st is at 60, 2nd is at 240 fps (my monitor refresh rate)
Video of issue attached, 1st is at 60, 2nd is at 240 fps (my monitor refresh rate)
July 5, 2025 at 5:13 AM
In Grand Theft Auto V, when your fps is anywhere above 60FPS the gas can will pour faster than if you were on 60FPS
Video of issue attached, 1st is at 60, 2nd is at 240 fps (my monitor refresh rate)
Video of issue attached, 1st is at 60, 2nd is at 240 fps (my monitor refresh rate)
hey!! i’d like to be friends!! :))
December 30, 2024 at 12:00 AM
hey!! i’d like to be friends!! :))
do you need somebody to talk to?
December 11, 2024 at 1:24 PM
do you need somebody to talk to?