WIP: Support >60Hz with com_gameHz

[DanielGibson]

Based on @Stradex' "Add com_gameHz to play with higher HZ/FPS" Pull Request, but also integrating fixes from @dezo2's patch (see also) and my own fixes.

Very much WIP, and no guarantees this will work out

---

Potential bugs that have been observed with various attempts of running dhewm3 with >60Hz and that are worth testing:

• Crashes with crane in Alpha Labs Sector 3 (should be fixed by patching GAME_FPS and GAME_FRAMETIME in the scripts)
• Chaingun shooting too fast (should be fixed by patching CHAINGUN_FIRE_SKIPFRAMES in script)
• Flickering particles (happened with com_fixedTic -1, might not be relevant here?)
• Oxygen drainage too slow or fast (should be fixed by modifying the "air" code in idPlayer)
• Switching Mods/game modes can cause black menu for multiple seconds to minutes
  • I can reproduce this bug.
• RoE gravity gun only works after 2 minutes or so (haven't tried this yet, but this is very relevant here as this also happened with @simonedibilio's branch that's also based on Stradex' code)
• I found if I tweak the fps higher than the monitor refresh rate, NPCs and mobs in-game will no longer interact with stairs. I think this is not a bug related to this fork, cause I found it in BFG Edition too. (again from same bugreport on simonedibilio's branch - this sounds extremely weird)
• "There is also a lipsync issue, the animation goes a little slower than it should be." (again from same bugreport as the previous ones)
• Savegames don't work, "Script checksum didn't match" (same bugreport; hopefully fixed by 9cb3fae, though this will happen with all old savegames, but ones created with the latest code should keep working in the future)

[tyuah8]

There is also a bug related to the crouch rate of the player; this crouch rate uses an exponential smoothing logic and doesn't scale with higher FPS, so the player will crouch faster at higher FPS.

The original game code in Player.cpp looks like this:

	if ( EyeHeight() != newEyeOffset ) {
		if ( spectating ) {
			SetEyeHeight( newEyeOffset );
		} else {
			// smooth out duck height changes
			SetEyeHeight( EyeHeight() * pm_crouchrate.GetFloat() + newEyeOffset * ( 1.0f - pm_crouchrate.GetFloat() ) );
		}
	}

The fixed version, which properly considers FPS change for exponential smoothing, is the following:

	if ( EyeHeight() != newEyeOffset ) {
		if ( spectating ) {
			SetEyeHeight( newEyeOffset );
		} else {
			// https://en.wikipedia.org/wiki/Exponential_smoothing#Time_constant
			const float tau = -16.f / idMath::Log( pm_crouchrate.GetFloat() );
			const float a = 1 - idMath::Exp( -gameLocal.msec / tau );
			// smooth out duck height changes
			SetEyeHeight( EyeHeight() * ( 1 - a ) + newEyeOffset * a );
		}
	}

The new code I attached is what I am currently using for my local source code. I don't have Dhewm3's source code locally, so I am unable to contribute.

[tyuah8]

The same can be said about the roll and pitch rate of flying NPCs. The fixed version, in AI.cpp AdjustFlyingAngles(), is the following:

	// https://en.wikipedia.org/wiki/Exponential_smoothing#Time_constant
	static const float tau = -16.f / idMath::Log( 0.95f );
	       const float a = 1 - idMath::Exp( -gameLocal.msec / tau );
	fly_roll  = fly_roll  * ( 1 - a ) + roll  * a;
	fly_pitch = fly_pitch * ( 1 - a ) + pitch * a;

[DanielGibson]

Thank you! :)

[DanielGibson]

oh ffs, why can't you make a PR use a different branch (or rename it) :-/

[DanielGibson]

When investigating the "black screen after changing mod" issue I realized that I don't understand all of Stradex' changes, and even would like to avoid some of them (like breaking the network protocol).

I'll create a new branch (and PR for it) that is closer to @dezo2's work (but still has a CVar like com_gameHz and will modify the scripts on load so I don't have to ship new scripts) + the additional fixes for obvious bugs, but tries to be less invasive than Stradex branch.
I'll port Stradex' features as/if needed.

[DanielGibson]

@tyuah8 By the way, in d3xp scaling with gameLocal.msec might not be exactly what you want (esp. for the player movement case), because that value gets modified for slow motion mode.

[tyuah8]

I forgot to mention, and you could be right, but since I don't personally own Doom 3: Resurrection of Evil, all of my changes so far have been for the base game only.

[DanielGibson]

Ok, trying this again at #585 with a slightly different approach..