[BHD:TS] Uncap framerate

[mg]

I see the framerate is capped at 64 FPS. Is there any known way to uncap it?

If so, is it known to break certain aspects of the simulation?

[devilsclaw]

The games physics and speed are locked to the frame rate. uncapping it equals speed cheat.

[mg]

Gotcha, that's unfortunate. Thanks for the info!

[mg]

The games physics and speed are locked to the frame rate.

Hmm actually I'd like to challenge that. I just realized the 64 FPS cap is only in place for multiplayer. In single player it is in fact uncapped, and even at ~500 FPS the physics appear fine and the simulation speed is definitely entirely normal.

The only problem I could spot was a sound issue whereby some dialog lines would be repeated multiple times, and maybe some sounds weren't produced when expected (not sure about that last one).

So in theory the game should be capable of handling rendering at more than 64 FPS even in multiplayer without anyone getting an advantage (other than being able to use their hardware fully to optimize input latency of course).

[devilsclaw]

In the past I unlocked the game loop which is what draws when in a map and it equaled a speed cheat. maybe there is another way to do it then that but that is what happened.

[Baldo_the_Don]

I'm 99% percent sure the animations in DFBHDTS are clocked at 60 fps. I mess around with fire rates quite a bit in my mods, and although the speed and lengths of the animations are hard-coded, if you don't mind slight breaks in the animations and take a few ticks off the reload delaystart and delayend entries, you get things moving a little more briskly.

Some weapons need delaystart and delayend tweaks. Reloads usually have a numerical delaystart value, and the delayend is auto, meaning the ammo count does not change and you cannot switch weapons 'til the delaystart is over, and you cannot fire until the reload animation finishes. The one weapon or the other has messed up reload animations where a stupidly long pause is included after everything's done, and if you don't delayend with a number, players will get angry. I do.

Also, if you shorten the delaystart and delayend on the Remington's recoil action, you can get a nice bump up in the fire rate, even if the animation looks janky.

Would I notice a 4 frame difference, though? I can't garantee that, even though I have done firing rate tests with a stopwatch, with all the care I could muster. Do you know something I don't?

[mg]

I'm 99% percent sure the animations in DFBHDTS are clocked at 60 fps.

If by that you imply that they're running at a constant real time speed independent from the (variable) rendering rate, I can confirm from observation as mentioned before (i.e. in SP at 7x the base MP framerate I didn't see animations running at 7x the speed). I'm not sure it makes sense to speak of an animation "framerate" separate from the renderer framerate however -- I don't know how this engine works specifically but typically you'd interpolate animation state on every rendered frame for smooth movement (based on the delta time since the previous frame). I'm only assuming it does so, admittedly.

There most likely is an internal game clock separate from the renderer for other things of course if that's what you're alluding to, possibly running at 60 Hz indeed, though I didn't quite follow how you reached the number from the animation delay tests (I believe you though, it's a common figure!).

[Baldo_the_Don]

Like the shotgun recoil animation, for instance.

Left-click triggers the fire animation, if the weapon's not empty, the recoil animation triggers, if it is empty, the reload animation triggers, and if you're out of ammo, the empty idle (possibly just idle) animation triggers.

In the recoil animation for the Remington, the player raises the muzzle, pulls back the pump grip, returns it forward, then lowers the muzzle back to fire ready position. That animation takes one second, and my testing lead me to conclude there are 60 different positions in that animation.

Oh, yeah! .wac scripting! That's where I solidified my opinion on the 60 ticks per second idea! When you do things with timers or delays in the .wac file, the time is measured in 'ticks' according to the Kyle.wac (or as I like to think of it, the .wac scripter's bible), and I saw it stated somewhere that the game does stuff in 60 ticks per second, and I did some testing that did not prove that wrong, so...

Sometimes, your Uncle Baldo writes replies at ridiculous hours of the night, sometimes disregarding all obvious signs of exhaustion and cognitive impairment, driving through brain-fog and brainstorm alike, and sometimes, not often, but sometimes, it's brilliant, mostly it's weird, but every now and then, it's brilliant, weird, and hilarious, and that's why I don't stop doing that.

But looking at my last reply, I can see what I was going for and how badly the rambles got in my way.

You were denying game framerate's effect on animation speeds, and I was trying to concur after being awake for twenty-some-odd hours. Garbling may have been inevitable.

I also wanted to know how you got to a 64 frame cap since I've been convinced of a 60 frame cap for so long. 'Cause I've done my tests and confirmed my conclusions to my satisfaction, but I really suck at taking notes, I sometimes misremember conclusions, and I often — all too often — have to redo tests.

And do I then take better notes? What do you think?

So I was worried I might be wrong. 'Cause I swear I remember tweaking (the minigun? the CAR15?) a weapon's fire rate (with the delaystart and delayend values) and ammo amount, emptying it several times while running my stopwatch, and taking an average and concluding 60 ticks.

I also vaguely remember doing something similar in Crimson Skies, so I'm not sure about anything now.

Discombobulation in a middle-aged headbanger. Can you imagine?

[mg]

You were denying game framerate's effect on animation speeds, and I was trying to concur after being awake for twenty-some-odd hours. Garbling may have been inevitable.

Cheers! That makes sense, and no worries it seems I did roughly understand where you were going with it!

Oh, yeah! .wac scripting! That's where I solidified my opinion on the 60 ticks per second idea! When you do things with timers or delays in the .wac file, the time is measured in 'ticks' according to the Kyle.wac (or as I like to think of it, the .wac scripter's bible), and I saw it stated somewhere that the game does stuff in 60 ticks per second, and I did some testing that did not prove that wrong, so...

Oh yeah I can totally see that being the case. Thanks for the heads up.

I also wanted to know how you got to a 64 frame cap since I've been convinced of a 60 frame cap for so long.

I wasn't clear myself either: this figure of 64 FPS is specifically from the renderer (measured with Afterburner OSD via RTSS) on an MP game (hosted by myself from the same process as the one I was playing in, for testing purposes). It was so stable that I didn't feel the need to record historical data to analyze later, and given I was getting 7x that in SP, I was pretty satisfied that it was an artificial cap at 64 FPS exactly.

This doesn't invalidate your understanding that the simulation runs at 60 Hz, as we've established the main game loop and the rendering loop run independently (as they should).

[devilsclaw]

One thing that had not been stated is which DF are you talking about. even though they are all evolution of the previous for the most part I know that late 90s to early 2000s that a lot of games did ticks based of the main game loop that would cap its self so that everything would work correctly.

BHD in the main game loop there is a simple jump in the code that one can ether force to always jump or to never jump and the game runs at as fast as your computer will allow. everything is then sped up including animations and if you run to fast over hills you will die due to collisions.

Also Single player Game Loop and multi player may be different. not sure its been a long time.

[mg]

One thing that had not been stated is which DF are you talking about.

Per the thread prefix, I believe we're all talking strictly about BHD/BHD:TS (others are indeed quite different in many regards).

BHD in the main game loop there is a simple jump in the code that one can ether force to always jump or to never jump and the game runs at as fast as your computer will allow. everything is then sped up including animations and if you run to fast over hills you will die due to collisions.

Well, respectfully, my challenge to that claim still stands .

I encourage you to actually test and measure a single player session on modern hardware. I believe you'll be adequately convinced.

I don't doubt that you've observed that effect BTW, just that it must have involved hooking/mutating the process or program binary, and that an uncapped renderer framerate doesn't inherently generate that effect (given they're apparently independent).

Also Single player Game Loop and multi player may be different. not sure its been a long time.

I'm not sure about the main game loop (beyond the obvious differences like netcode and SP/MP game logic differences).

SP has no framerate cap on the rendering loop (by default!) while MP seems to have one (at least when serving) as we've observed above, if that's what you mean.

[Baldo_the_Don]

This was about DFBHDTS. I'm almost always talking about DFBHDTS. Occasionally Comanche 4, sometimes DFX, DFX2. Rarely JO. Once in a while, DF1. I mentioned the DFLW demo once. And except for F-16 Flying Falcon, MiG-29 Fulcrum, and Comanche 3 Gold, I have no experience with any other NL games.