Miami highfps: fix several physics & visual issues at high framerates #1205

Req merge in Veyrdite/re3:miami_highfps -> GTAmodding/re3:miami.

All non-style changes wrapped in FIX_BUGS, using a variety of CTimer:: values where most appropriate.

Cosmetic at high FPS:

ocean appearance
fountain particles (look like milkshakes)
small black birds/leaves/"BEASTIES" that spiral around treetops
raindrop rate in world
raindrop rate on camera lens
camera lens raindrops not smearing when rotating the camera
some exhaust particle spam
engine damage fire/smoke particle spam (partially done?)
engine SFX ramp rate - cars top gear (fake "cruise" gear, you don't actually get faster)
engine SFX ramp rate - bike top gear (fake "cruise" gear, you don't actually get faster)
engine SFX ramp rate - boats
car skid SFX progress rate (too sudden at high FPS)
scrolling sign outside bloodring banger racetrack
boat particle spam
boat wake trails being too short (only partially fixed? todo:check after fixing boat speed/physics)
Hud flashing effects (eg flashing stars after pay-n-spray)
Vehicle free-cam auto-centering timer (?)
Camera blur & sway (mission: Boomshine Saigon)
Bloody footsteps timer after walking through corpse.

Boats, cars and bikes at high FPS:

car speed & handling (hooray!)
bike speed & handling (hooray!)
toggling siren
blown/shot tires random turn forces being too mild (confirmed, low fps = more random turning effect. Earlier commits overwritten)
boat throttle ramp rate & steering ramp rate
boat speed & handling (slow at high FPS) (partly fixed!)
stationary vehicles 'creeping' along the ground or rotating very slowly, typically in whatever direction is slightly downhill.
bikes losing health when hitting ramps (or does this always happen, even at lower FPS?)

Peds and collisions at high FPS:

very high damage when vehicle runs over ped (high chances of insta-death)
pushing cars when running
yeeting off peds after jumping on them
yeeting horizontally when moving down steep slopes

Misc at high FPS:

fast Ctrl+B debug camera
Street lights/poles constantly falling down (might be same as cars 'creeping'?)
Ped movement/pathing. Eg "Guardian Angels" mission -> dealing does not reach Diaz -> softlock

Features added:

Pressing F4 at any time during gameplay toggles the framelimiter (added to debug menu code). Ridiculously useful for both fixing FPS related bugs and even to play the game (esp water missions, often the cutscenes softlock due to bad boat performance).

The framelimiter commit is a little bit messy and does not have any text message pop up on hud (dang uint16 strings!) or play a sound. It's solely in debug code, however, and I think it's utility is very high. Suggestions welcome for how I can implement it in a tidier manner.

Req merge in Veyrdite/re3:miami_highfps -> GTAmodding/re3:miami. All non-style changes wrapped in FIX_BUGS, using a variety of CTimer:: values where most appropriate. Cosmetic at high FPS: - [x] ocean appearance - [x] fountain particles (look like milkshakes) - [x] small black birds/leaves/"BEASTIES" that spiral around treetops - [x] raindrop rate in world - [ ] raindrop rate on camera lens - [ ] camera lens raindrops not smearing when rotating the camera - [x] some exhaust particle spam - [ ] engine damage fire/smoke particle spam (partially done?) - [x] engine SFX ramp rate - cars top gear (fake "cruise" gear, you don't actually get faster) - [x] engine SFX ramp rate - bike top gear (fake "cruise" gear, you don't actually get faster) - [ ] engine SFX ramp rate - boats - [ ] car skid SFX progress rate (too sudden at high FPS) - [ ] scrolling sign outside bloodring banger racetrack - [x] boat particle spam - [x] boat wake trails being too short (only partially fixed? todo:check after fixing boat speed/physics) - [ ] Hud flashing effects (eg flashing stars after pay-n-spray) - [ ] Vehicle free-cam auto-centering timer (?) - [ ] Camera blur & sway (mission: Boomshine Saigon) - [ ] Bloody footsteps timer after walking through corpse. Boats, cars and bikes at high FPS: - [x] car speed & handling **(hooray!)** - [x] bike speed & handling **(hooray!)** - [x] toggling siren - [ ] blown/shot tires random turn forces being too mild (confirmed, low fps = more random turning effect. Earlier commits overwritten) - [x] boat throttle ramp rate & steering ramp rate - [ ] boat speed & handling (slow at high FPS) (partly fixed!) - [ ] stationary vehicles 'creeping' along the ground or rotating very slowly, typically in whatever direction is slightly downhill. - [ ] bikes losing health when hitting ramps (or does this always happen, even at lower FPS?) Peds and collisions at high FPS: - [ ] very high damage when vehicle runs over ped (high chances of insta-death) - [ ] pushing cars when running - [ ] yeeting off peds after jumping on them - [ ] yeeting horizontally when moving down steep slopes Misc at high FPS: - [x] fast Ctrl+B debug camera - [ ] Street lights/poles constantly falling down (might be same as cars 'creeping'?) - [ ] Ped movement/pathing. Eg "Guardian Angels" mission -> dealing does not reach Diaz -> softlock Features added: - Pressing F4 at any time during gameplay toggles the framelimiter (added to debug menu code). Ridiculously useful for both fixing FPS related bugs and even to play the game (esp water missions, often the cutscenes softlock due to bad boat performance). The framelimiter commit is a little bit messy and does not have any text message pop up on hud (dang uint16 strings!) or play a sound. It's solely in debug code, however, and I think it's utility is very high. Suggestions welcome for how I can implement it in a tidier manner.

Addendum: now slowly fixing vehicle physics. I thought boats would be easier, turns out I accidentally found one of the causes of bad vehicle turning performance at high FPS instead. Woops.

179450c is the most dramatic change that will probably have effects on other parts of the game too (helis?), too much rotational friction was being applied to all physical entities at high framerates.

Addendum: now slowly fixing vehicle physics. I thought boats would be easier, turns out I accidentally found one of the causes of bad vehicle turning performance at high FPS instead. Woops. 179450c is the most dramatic change that will probably have effects on other parts of the game too (helis?), too much rotational friction was being applied to all physical entities at high framerates.

I believe I've fixed all car physics related problems now. If you feel that physics feels "wrong"/different now then please comment, that means I've made a mistake somewhere.

Do the car physics related changes fix the issue where you can push a car very easily on foot at high fps? Is that covered by the current checklist?

What about very low FPS? I remember some CTimer::GetTimeStepFix-based physics hack was causing some bugs when game was running on very low FPS and it had to be reverted.

What about very low FPS? I remember some CTimer::GetTimeStepFix-based physics hack was causing some bugs when game was running on very low FPS and it had to be reverted.

Yes, 37b6d491e7.

> > > What about very low FPS? I remember some CTimer::GetTimeStepFix-based physics hack was causing some bugs when game was running on very low FPS and it had to be reverted. Yes, 37b6d491e7b9965dd344493f6220a4aca487901e.

I built this to test. Answered my own question from above, looks like cars are still light as air to push on foot at high fps in this fork. Might be worth adding to the todo checklist?
~But I'd also add that it feels like cars move much slower in this fork than they do in the mainline of re3 with the framelimiter on.
i.e., max speed seems lower, and the engine makes high-rev noise much sooner.~

Other than that, super cool. Especially where particles and some basic physics are concerned. Kind of surreal feeling since I've become so accustomed to things being severely broken at high fps.

edit: i see you've already made points about that. All looks good

I built this to test. Answered my own question from above, looks like cars are still light as air to push on foot at high fps in this fork. Might be worth adding to the todo checklist? ~But I'd also add that it feels like cars move much slower in this fork than they do in the mainline of re3 with the framelimiter on. i.e., max speed seems lower, and the engine makes high-rev noise much sooner.~ Other than that, super cool. Especially where particles and some basic physics are concerned. Kind of surreal feeling since I've become so accustomed to things being severely broken at high fps. edit: i see you've already made points about that. All looks good

Braking on bikes is now much slower at higher FPS (almost don't work at all at very high FPS).

I wrote a commit for "Fast Ctrl+B debug camera at high FPS" a week or two ago.

3829e2da1a

There's also another change in src/extras/debugmenu.cpp, which makes the debug menu close when ESC is hit.

I wrote a commit for "Fast Ctrl+B debug camera at high FPS" a week or two ago. https://github.com/Nopey/re3/commit/3829e2da1a03570bad90853c3ac4251d26da7f82 There's also another change in `src/extras/debugmenu.cpp`, which makes the debug menu close when ESC is hit.

Do the car physics related changes fix the issue where you can push a car very easily on foot at high fps? Is that covered by the current checklist?

Sorry not yet. Possibly the ped<->veh collision code is not pushing the ped away enough and is instead always pushing the veh by X force impulse every frame? I was hesitant to include timestep in collision impulse forces (because collisions are probably supposed to be momentary, eg 1 frame long, regardless of the framerate); but it might be called for in this case. Possibly also ped<->ped collisions suffer this same problem (getting catapulted when you jump on peds at the right angle).

Solving these problems to match vanilla FPS behaviors may take some creative thinking, simply adding timesteps everywhere may change the collision physics in other unexpected ways.

What about very low FPS? I remember some CTimer::GetTimeStepFix-based physics hack was causing some bugs when game was running on very low FPS and it had to be reverted.

Yes, 37b6d49.

That particular FIX_BUGS one is gone and I have completely reworked how CTimer:: is used in ProcessWheel(). Not sure if that jitter problem was caused by an actual error or if it's a fundamental instability (undamp) of this physics engine at low FPS; I'll have to look when I get some more time.

N.B. I observed similar vehicles-jitter-and-skid-sideways behaviours when nullifying the velocity-impulses (Fwd & Right) too much in that func, breaking/weaking the physics feedback loops does seem to cause interesting problems.

Braking on bikes is now much slower at higher FPS (almost don't work at all at very high FPS).

I'll take a look, thankyou SonofUgly.

I wrote a commit for "Fast Ctrl+B debug camera at high FPS" a week or two ago.

Nopey@3829e2d

There's also another change in src/extras/debugmenu.cpp, which makes the debug menu close when ESC is hit.

Thanks @Nopey

Question: are all the debug menu code & stuff in the src/extras/ folder new (non-vanilla) stuff? I spot FIX_BUGS in your commit and wonder if the world has gone too far :)

Kind of surreal feeling since I've become so accustomed to things being severely broken at high fps.

Surreal is exactly what I'm going for. I'm now at the point where I get confused whether or not my F4 key is working because mashing it whilst driving doesn't seem to have much effect. Really hoping to get the same for boating soon, then I can test some boating mission cutscenes.

i.e., max speed seems lower, and the engine makes high-rev noise much sooner.

Yeah this is confusing. I believe that the entire top gear is "fake", just a sound effect that slowly rises and you are kept at the same speed. I did some quick timed drag trials with a stopwatch to make sure I have not actually affected the performance of cars, I believe they're still exactly the same but I could be wrong.

Fun side discovery from all of my vehicle investigations: try reversing (at frame-limited FPS) in a sports car. Notice that your throttle pulses rather than staying stable? That's the game going "you're going too fast in reverse, cut the throttle". Turning this off is so much fun (crazy reverse speeds) and sounds ridiculous (whiiiiiiiiiiine). Due to how this is implemented there may be a tiny difference in car top speed too, but you don't notice the pulsing at top speed (probably due to the lower torque and the SFX being completely fake).

> Do the car physics related changes fix the issue where you can push a car very easily on foot at high fps? Is that covered by the current checklist? Sorry not yet. Possibly the ped<->veh collision code is not pushing the ped away enough and is instead always pushing the veh by X force impulse every frame? I was hesitant to include timestep in collision impulse forces (because collisions are probably supposed to be momentary, eg 1 frame long, regardless of the framerate); but it might be called for in this case. Possibly also ped<->ped collisions suffer this same problem (getting catapulted when you jump on peds at the right angle). Solving these problems to match vanilla FPS behaviors may take some creative thinking, simply adding timesteps everywhere may change the collision physics in other unexpected ways. > > What about very low FPS? I remember some CTimer::GetTimeStepFix-based physics hack was causing some bugs when game was running on very low FPS and it had to be reverted. > > Yes, [37b6d49](https://github.com/GTAmodding/re3/commit/37b6d491e7b9965dd344493f6220a4aca487901e). That particular FIX_BUGS one is gone and I have completely reworked how CTimer:: is used in ProcessWheel(). Not sure if that jitter problem was caused by an actual error or if it's a fundamental instability (undamp) of this physics engine at low FPS; I'll have to look when I get some more time. N.B. I observed similar vehicles-jitter-and-skid-sideways behaviours when nullifying the velocity-impulses (Fwd & Right) too much in that func, breaking/weaking the physics feedback loops does seem to cause interesting problems. > Braking on bikes is now much slower at higher FPS (almost don't work at all at very high FPS). I'll take a look, thankyou SonofUgly. > I wrote a commit for "Fast Ctrl+B debug camera at high FPS" a week or two ago. > > [Nopey@3829e2d](https://github.com/Nopey/re3/commit/3829e2da1a03570bad90853c3ac4251d26da7f82) > > There's also another change in `src/extras/debugmenu.cpp`, which makes the debug menu close when ESC is hit. Thanks @Nopey Question: are all the debug menu code & stuff in the src/extras/ folder new (non-vanilla) stuff? I spot FIX_BUGS in your commit and wonder if the world has gone too far :) > Kind of surreal feeling since I've become so accustomed to things being severely broken at high fps. Surreal is exactly what I'm going for. I'm now at the point where I get confused whether or not my F4 key is working because mashing it whilst driving doesn't seem to have much effect. Really hoping to get the same for boating soon, then I can test some boating mission cutscenes. > i.e., max speed seems lower, and the engine makes high-rev noise much sooner. Yeah this is confusing. I believe that the entire top gear is "fake", just a sound effect that slowly rises and you are kept at the same speed. I did some quick timed drag trials with a stopwatch to make sure I have not actually affected the performance of cars, I believe they're still exactly the same but I could be wrong. Fun side discovery from all of my vehicle investigations: try reversing (at frame-limited FPS) in a sports car. Notice that your throttle pulses rather than staying stable? That's the game going "you're going too fast in reverse, cut the throttle". Turning this off is so much fun (crazy reverse speeds) and sounds ridiculous (*whiiiiiiiiiiine*). Due to how this is implemented there may be a _tiny_ difference in car top speed too, but you don't notice the pulsing at top speed (probably due to the lower torque and the SFX being completely fake).

Braking on bikes is now much slower at higher FPS (almost don't work at all at very high FPS).

I'll take a look, thankyou SonofUgly.

@SonofUgly fixed in 763337c255 & cae0a3f402, too many factors of time were being included in the non-handbrake bike brake forces.

There is lots of inconsistency in the arguments given to ProcessWheel() and ProcessBikeWheel(), some include a factor of timestep whilst other do not. I've modified things in FIX_BUGs to try and keep timestep out of the arguments (and instead add it back in only once at the end of the function). This avoids having to modify whole reams of wheel physics code (including time-dependent square terms). Hopefully I have not missed any more variables.

> > Braking on bikes is now much slower at higher FPS (almost don't work at all at very high FPS). > > I'll take a look, thankyou SonofUgly. @SonofUgly fixed in 763337c25508e5c4eb91c87166a346a5141cd6af & cae0a3f4022400d44e1768551f48c5cb3ed9cd08, too many factors of time were being included in the non-handbrake bike brake forces. There is lots of inconsistency in the arguments given to ProcessWheel() and ProcessBikeWheel(), some include a factor of timestep whilst other do not. I've modified things in FIX_BUGs to try and keep timestep **out** of the arguments (and instead add it back in only _once_ at the end of the function). This avoids having to modify whole reams of wheel physics code (including time-dependent square terms). Hopefully I have not missed any more variables.

Boat physics is super-stuffed, the way Rockstar tried to make it timestep-independent (ie not require a fixed FPS) is totally wrong. This is going to require quite a bit of mathematical tomfoorlery to fix.

Take for example the following bundle of happiness:

if((GetModelIndex() != MI_SKIMMER || m_skimmerThingTimer == 0.0f) && !bSeparateTurnForce){
	// No idea what exactly is going on here besides drag in YZ
	float fx = Pow(pBoatHandling->vecTurnRes.x, CTimer::GetTimeStep());
	float fy = Pow(pBoatHandling->vecTurnRes.y, CTimer::GetTimeStep());
	float fz = Pow(pBoatHandling->vecTurnRes.z, CTimer::GetTimeStep());
	m_vecTurnSpeed = Multiply3x3(m_vecTurnSpeed, GetMatrix());	// invert - to local space
	// TODO: figure this out
	float magic = 1.0f/(1000.0f * SQR(m_vecTurnSpeed.x) + 1.0f) * fx;
	m_vecTurnSpeed.y *= fy;
	m_vecTurnSpeed.z *= fz;
	float forceUp = (magic - 1.0f) * m_vecTurnSpeed.x * m_fTurnMass;
	m_vecTurnSpeed = Multiply3x3(GetMatrix(), m_vecTurnSpeed);	// back to world
	CVector com = Multiply3x3(GetMatrix(), m_vecCentreOfMass);
	ApplyTurnForce(forceUp*GetUp(), com + GetForward());
}

That Pow(x, TimeStep) makes it look like they might be trying to solve FPS-related problems, but things go totally wrong after that. If their solution is correct then the sum of all ApplyTurnForce()'s after (eg) 1 second of gameplay should be the same regardless of the framerate. According to my recreational spreadsheeting It's not, by a long shot (note the last column):

time period (seconds)	numsteps	timestep (seconds)	turnresx	turnspeedx	fx	magic	forceUp	integral(forceup, time period)
1	1	1	0.89	0.005	0.8900	0.8683	-.000659	-0.000659
1	10	0.1	0.89	0.005	0.9884	0.9643	-.000178	-0.001785
1	100	0.01	0.89	0.005	0.9988	0.9745	-.000128	-0.012763
1	1000	0.001	0.89	0.005	0.9999	0.9755	-.000123	-0.122520

(I've omitted some unimportant constants in the above equations and chosen some others from an actual boat in-game, but you get the point)

To fix boat physics you need to fix all boat-physics related problems, even small ones, because it's a "closed loop system". Eg a problem with turn forces can make the boat sink too low into the water, increasing its drag and making it slower. A problem with linear thrust forces can make it rise out of the water too much, ruining handling (the rudder needs to be in water). I learned this when trying to fix vehicles: the problem with not being able to drive as fast around corners was because the rear wheels were not entering skid state because the vehicles were too slow and difficult to drift which was because too much aerodynamic drag was being applied every frame. Drag ruined not just speed, but handling too (by a massive amount).

How to fix

I'm going to have to replace their Pow(x, timestep) with something that is only correct at the official framelimited FPS, then concoct a new creative fix using CTimer::GetTimeStepFix() that covers all FPS cases.

EDIT: done, but now boat perf is borked in other ways. I think I'm going to have to flatten the ocean and disable most of the boat physics, so I can test it component by component without breaking the physics loop.

EDIT2: flattening the ocean has helped, along with commenting out and/or replacing most of the boat physics code, but boat handling is still a bit limp at high FPS. My brain be marooned in calm waters.

TL;DR:

Rockstar's choices in their physics equations are unsettling in subtle ways. I've started wondering why they summon time-and-space cthulu just to light a candle. Maybe the craziness in this code is just due to the compiler optimisations & the subsequent reverse engineering, but I can't also discount the chance that a physics programmer at Rockstar was also an evil cultist of inaccurate thermodynamics (and he or she is currently rubbing their hands together in glee).

This is a lot more work than I expected, I think I might go back to bed for now :P

Boat physics is super-stuffed, the way Rockstar tried to make it timestep-independent (ie not require a fixed FPS) is totally wrong. This is going to require quite a bit of mathematical tomfoorlery to fix. Take for example the following bundle of happiness: ``` if((GetModelIndex() != MI_SKIMMER || m_skimmerThingTimer == 0.0f) && !bSeparateTurnForce){ // No idea what exactly is going on here besides drag in YZ float fx = Pow(pBoatHandling->vecTurnRes.x, CTimer::GetTimeStep()); float fy = Pow(pBoatHandling->vecTurnRes.y, CTimer::GetTimeStep()); float fz = Pow(pBoatHandling->vecTurnRes.z, CTimer::GetTimeStep()); m_vecTurnSpeed = Multiply3x3(m_vecTurnSpeed, GetMatrix()); // invert - to local space // TODO: figure this out float magic = 1.0f/(1000.0f * SQR(m_vecTurnSpeed.x) + 1.0f) * fx; m_vecTurnSpeed.y *= fy; m_vecTurnSpeed.z *= fz; float forceUp = (magic - 1.0f) * m_vecTurnSpeed.x * m_fTurnMass; m_vecTurnSpeed = Multiply3x3(GetMatrix(), m_vecTurnSpeed); // back to world CVector com = Multiply3x3(GetMatrix(), m_vecCentreOfMass); ApplyTurnForce(forceUp*GetUp(), com + GetForward()); } ``` That Pow(x, TimeStep) makes it look like they might be trying to solve FPS-related problems, but things go totally wrong after that. If their solution is correct then the sum of all ApplyTurnForce()'s after (eg) 1 second of gameplay should be the same regardless of the framerate. According to my recreational spreadsheeting It's not, by a long shot (note the last column): time period (seconds) | numsteps | **timestep (seconds)** | turnresx | turnspeedx | **fx** | **magic** | **forceUp** | **integral(forceup, time period)** -- | -- | -- | -- | -- | -- | -- | -- | -- 1 | 1 | 1 | 0.89 | 0.005 | 0.8900 | 0.8683 | -.000659 | -0.000659 1 | 10 | 0.1 | 0.89 | 0.005 | 0.9884 | 0.9643 | -.000178 | -0.001785 1 | 100 | 0.01 | 0.89 | 0.005 | 0.9988 | 0.9745 | -.000128 | -0.012763 1 | 1000 | 0.001 | 0.89 | 0.005 | 0.9999 | 0.9755 | -.000123 | -0.122520 (I've omitted some unimportant constants in the above equations and chosen some others from an actual boat in-game, but you get the point) To fix boat physics you need to fix all boat-physics related problems, even small ones, because it's a "closed loop system". Eg a problem with turn forces can make the boat sink too low into the water, increasing its drag and making it slower. A problem with linear thrust forces can make it rise out of the water too much, ruining handling (the rudder needs to be in water). I learned this when trying to fix vehicles: the problem with not being able to drive as fast around corners was because the rear wheels were not entering skid state because the vehicles were too slow and difficult to drift which was because too much aerodynamic drag was being applied every frame. Drag ruined not just speed, but handling too (by a massive amount). **How to fix** I'm going to have to replace their Pow(x, timestep) with something that is only correct at the official framelimited FPS, then concoct a new creative fix using CTimer::GetTimeStepFix() that covers all FPS cases. EDIT: done, but now boat perf is borked in other ways. I think I'm going to have to flatten the ocean and disable most of the boat physics, so I can test it component by component without breaking the physics loop. EDIT2: flattening the ocean has helped, along with commenting out and/or replacing most of the boat physics code, but boat handling is still a bit limp at high FPS. My brain be marooned in calm waters. **TL;DR:** Rockstar's choices in their physics equations are unsettling in subtle ways. I've started wondering why they summon time-and-space cthulu just to light a candle. Maybe the craziness in this code is just due to the compiler optimisations & the subsequent reverse engineering, but I can't also discount the chance that a physics programmer at Rockstar was also an evil cultist of inaccurate thermodynamics (and he or she is currently rubbing their hands together in glee). This is a lot more work than I expected, I think I might go back to bed for now :P

Can you also fix pathfinding at high fps? It makes some missions unplayable.

Question: are all the debug menu code & stuff in the src/extras/ folder new (non-vanilla) stuff? I spot FIX_BUGS in your commit and wonder if the world has gone too far :)

I used a FIX_BUGS wrapper, as Nick007J's commit to the same function also checks FIX_BUGS.
7a71a47f74

Both of these are probably unnecessary, as the entire function body is already behind an IMPROVED_CAMERA check.

> Question: are all the debug menu code & stuff in the src/extras/ folder new (non-vanilla) stuff? I spot FIX_BUGS in your commit and wonder if the world has gone too far :) I used a FIX_BUGS wrapper, as Nick007J's commit to the same function also checks FIX_BUGS. https://github.com/GTAmodding/re3/commit/7a71a47f743b1496c069cf5c4f2765877aea412b Both of these are probably unnecessary, as the entire function body is already behind an `IMPROVED_CAMERA` check.

Noticed you didnt include cosmetic change on to do list - flashing objects on Hud, be it timer, police stars etc.
Great job so far

Noticed you didnt include cosmetic change on to do list - flashing objects on Hud, be it timer, police stars etc. Great job so far

Another thing that might be worth looking into
When you're using freecam with high fps while driving, it takes much longer for the camera to center back behind the vehicle after a turn than it does at 30ps.

Another thing that might be worth looking into When you're using freecam with high fps while driving, it takes much longer for the camera to center back behind the vehicle after a turn than it does at 30ps.

With that latest siren fix: I'm getting close to the goal of having the game 100% playable at high FPS. The last major issue that can't be worked around (ignored) is boat performance: some boat missions softlock during the cutscenes (slow boats never make it from point A to point B) or can't be completed by the player within the mission timer.

Unfortunately the cheat-menu's goto-mission functionality is broken at the moment, segfaulting my game. Time to do some more debug.

EDIT: I have no idea

Thread 1 "reVC" received signal SIGSEGV, Segmentation fault.
0x000055555581f8c9 in CRunningScript::ProcessCommands600To699 (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>, command=667) at ../src/control/Script3.cpp:1265
1265	;		pObj->ObjectCreatedBy = MISSION_OBJECT;
(gdb) bt
#0  0x000055555581f8c9 in CRunningScript::ProcessCommands600To699 (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>, command=667) at ../src/control/Script3.cpp:1265
#1  0x000055555580cd2a in CRunningScript::ProcessOneCommand (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>) at ../src/control/Script.cpp:2546
#2  0x000055555580caaa in CRunningScript::Process (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>) at ../src/control/Script.cpp:2472
#3  0x000055555580c97d in CTheScripts::Process () at ../src/control/Script.cpp:2437
#4  0x00005555556d02a6 in CGame::Process () at ../src/core/Game.cpp:883
#5  0x00005555558e5556 in Idle (arg=0x1) at ../src/core/main.cpp:1540
#6  0x00005555558e5c30 in AppEventHandler (event=rsIDLE, param=0x1) at ../src/core/main.cpp:1784
#7  0x0000555555903b35 in RsEventHandler (event=rsIDLE, param=0x1) at ../src/skel/skeleton.cpp:210
#8  0x00005555558e18d5 in main (argc=1, argv=0x7fffffffdf18) at ../src/skel/glfw/glfw.cpp:2251

Looks like pObj might not exist:

	case COMMAND_CREATE_OBJECT_NO_OFFSET:
	{
		CollectParameters(&m_nIp, 4);
		int mi = ScriptParams[0] >= 0 ? ScriptParams[0] : CTheScripts::UsedObjectArray[-ScriptParams[0]].index;
		CObject* pObj = new CObject(mi, false);
;		pObj->ObjectCreatedBy = MISSION_OBJECT;    <---- line that crashes the game

This isn't physics, I have no clue what's going on in this scripting language :| Eh next weekend.

With that latest siren fix: I'm getting close to the goal of having the game 100% playable at high FPS. The last major issue that can't be worked around (ignored) is boat performance: some boat missions softlock during the cutscenes (slow boats never make it from point A to point B) or can't be completed by the player within the mission timer. Unfortunately the cheat-menu's goto-mission functionality is broken at the moment, segfaulting my game. Time to do some more debug. EDIT: I have no idea ``` Thread 1 "reVC" received signal SIGSEGV, Segmentation fault. 0x000055555581f8c9 in CRunningScript::ProcessCommands600To699 (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>, command=667) at ../src/control/Script3.cpp:1265 1265 ; pObj->ObjectCreatedBy = MISSION_OBJECT; (gdb) bt #0 0x000055555581f8c9 in CRunningScript::ProcessCommands600To699 (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>, command=667) at ../src/control/Script3.cpp:1265 #1 0x000055555580cd2a in CRunningScript::ProcessOneCommand (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>) at ../src/control/Script.cpp:2546 #2 0x000055555580caaa in CRunningScript::Process (this=0x555555d96750 <CTheScripts::ScriptsArray+9072>) at ../src/control/Script.cpp:2472 #3 0x000055555580c97d in CTheScripts::Process () at ../src/control/Script.cpp:2437 #4 0x00005555556d02a6 in CGame::Process () at ../src/core/Game.cpp:883 #5 0x00005555558e5556 in Idle (arg=0x1) at ../src/core/main.cpp:1540 #6 0x00005555558e5c30 in AppEventHandler (event=rsIDLE, param=0x1) at ../src/core/main.cpp:1784 #7 0x0000555555903b35 in RsEventHandler (event=rsIDLE, param=0x1) at ../src/skel/skeleton.cpp:210 #8 0x00005555558e18d5 in main (argc=1, argv=0x7fffffffdf18) at ../src/skel/glfw/glfw.cpp:2251 ``` Looks like pObj might not exist: ``` case COMMAND_CREATE_OBJECT_NO_OFFSET: { CollectParameters(&m_nIp, 4); int mi = ScriptParams[0] >= 0 ? ScriptParams[0] : CTheScripts::UsedObjectArray[-ScriptParams[0]].index; CObject* pObj = new CObject(mi, false); ; pObj->ObjectCreatedBy = MISSION_OBJECT; <---- line that crashes the game ``` This isn't physics, I have no clue what's going on in this scripting language :| Eh next weekend.

Can you also fix pathfinding at high fps? It makes some missions unplayable.

Sorry @yasinkaraaslan , what do you mean by this? AI driver car pathfinding?

FWIW I've had problems with AI drivers being useless in racing missions whilst running with the framelimiter on. I can't remember if things were better on console or not.

Noticed you didnt include cosmetic change on to do list - flashing objects on Hud, be it timer, police stars etc.

Thankyou, added.

When you're using freecam with high fps while driving, it takes much longer for the camera to center back behind the vehicle after a turn than it does at 30ps.

Thankyou, added. Have not tried freecam yet (the self-centering in San Andreas drove me mad, so I've actually been quite fond of the fact Vice City has an OK fixed cam).

> Can you also fix pathfinding at high fps? It makes some missions unplayable. Sorry @yasinkaraaslan , what do you mean by this? AI driver car pathfinding? FWIW I've had problems with AI drivers being useless in racing missions whilst running with the framelimiter on. I can't remember if things were better on console or not. > Noticed you didnt include cosmetic change on to do list - flashing objects on Hud, be it timer, police stars etc. Thankyou, added. > When you're using freecam with high fps while driving, it takes much longer for the camera to center back behind the vehicle after a turn than it does at 30ps. Thankyou, added. Have not tried freecam yet (the self-centering in San Andreas drove me mad, so I've actually been quite fond of the fact Vice City has an OK fixed cam).

I meant pathfinding for peds. They usually get stuck to a car or a wall. Most obvious example of this is "Guardian Angels" mission where dealers must reach Diaz to trigger a dialogue so the mission can continue. But one of the dealers would get stuck if the frame limiter is off and the mission wouldn't continue. This also happens in re3.

Thankyou, I'll give that a go once the mission-select feature in the debug menu is working again.

Perhaps a good way of testing this is by running 2 instances of the game side by side and using a controller to control both of them at the same time. Adding specific teleport points to the debug menu, and then spawning in cars, would make testing everything easier and more consistent too.
Tried it out and it seems like vehicle speed/acceleration is still slower at high fps: Oceanic, The Driver mission
(left is master, right is PR)

Perhaps a good way of testing this is by running 2 instances of the game side by side and using a controller to control both of them at the same time. Adding specific teleport points to the debug menu, and then spawning in cars, would make testing everything easier and more consistent too. Tried it out and it seems like vehicle speed/acceleration is still slower at high fps: [Oceanic](https://files.catbox.moe/5z18zd.mp4), [ The Driver mission](https://files.catbox.moe/0uqdc3.mp4) (left is master, right is PR)

Unfortunately the cheat-menu's goto-mission functionality is broken at the moment, segfaulting my game. Time to do some more debug.

I think that's because missions should be started in the city they're given from. Like Cortez's missions will crash if you're in second city.

I think it's not hard to guess you put so much effort into this PR, thank you =) As you know, it will take some time to review it.

> Unfortunately the cheat-menu's goto-mission functionality is broken at the moment, segfaulting my game. Time to do some more debug. I think that's because missions should be started in the city they're given from. Like Cortez's missions will crash if you're in second city. I think it's not hard to guess you put so much effort into this PR, thank you =) As you know, it will take some time to review it.

I found 2 problems on 60 FPS:

Initial acceleration of Admiral is slower then original acceleration on 30 FPS.
I pressed backward/brake button when I was cruising in a boat, firstly it decelerated, and then stopped for a ~3-4 seconds before starting reversing. I tried this on vanilla, I think it's shorter on it.

Except that, I(and the team, we talked that at the Discord server) think GetLogicalFramesPassed should be in a macro and that macro should always be 1 when FIX_BUGS is not defined. That way we can clean up the code/remove many FIX_BUGS.

Looking forward to approve this PR. :)

I found 2 problems on 60 FPS: - Initial acceleration of Admiral is slower then original acceleration on 30 FPS. - I pressed backward/brake button when I was cruising in a boat, firstly it decelerated, and then stopped for a ~3-4 seconds before starting reversing. I tried this on vanilla, I think it's shorter on it. Except that, I(and the team, we talked that at the Discord server) think GetLogicalFramesPassed should be in a macro and that macro should always be 1 when FIX_BUGS is not defined. That way we can clean up the code/remove many FIX_BUGS. Looking forward to approve this PR. :)

Thanks erorcun.

Car speed problems: I'll take a look once I have some spare time. Thankyou everyone for reporting, I have not been comparing against vanilla builds (only with/without the framelimiter enabled in my own builds) I've assumed that my changes have been mathematically == 1 when the framelimiter is enabled -- clearly not true.

Boat problems: yes boat physics is still wrong. I've fixed a few issues but there is more to do. The last couple of times I looked I ended up head scratching quite a bit, the problem might not be direct references to time but implicit ones in the logic. Flattening the ocean didn't help so I don't think it's instability of % above/below water propeller state when cresting waves repeatedly.

Except that, I(and the team, we talked that at the Discord server) think GetLogicalFramesPassed should be in a macro and that macro should always be 1 when FIX_BUGS is not defined

That shouldn't affect me & this branch, I only ever modify code within #ifdef FIX_BUGS anyway. You can do whatever you want to GetLogicalFramesPassed when FIX_BUGS is not defined. On that note: If you find I've made mods outside of FIX_BUGS then please tell me! I've tidied a few bits in places but not in ways that should affect output binaries.

Thanks erorcun. **Car speed problems:** I'll take a look once I have some spare time. Thankyou everyone for reporting, I have not been comparing against vanilla builds (only with/without the framelimiter enabled in my own builds) I've assumed that my changes have been mathematically == 1 when the framelimiter is enabled -- clearly not true. **Boat problems:** yes boat physics is still wrong. I've fixed a few issues but there is more to do. The last couple of times I looked I ended up head scratching quite a bit, the problem might not be direct references to time but implicit ones in the logic. Flattening the ocean didn't help so I don't think it's instability of % above/below water propeller state when cresting waves repeatedly. > Except that, I(and the team, we talked that at the Discord server) think GetLogicalFramesPassed should be in a macro and that macro should always be 1 when FIX_BUGS is not defined That shouldn't affect me & this branch, I only ever modify code within #ifdef FIX_BUGS anyway. You can do whatever you want to GetLogicalFramesPassed when FIX_BUGS is not defined. On that note: If you find I've made mods outside of FIX_BUGS then please tell me! I've tidied a few bits in places but not in ways that should affect output binaries.

Labels Milestones

Miami highfps: fix several physics & visual issues at high framerates #1205