I was under the impression that by using dgvoodoo and keeping 'always wait for at least on vertical sync' checked, that I wouldn't have to mess around with slowing the CPU down. I think I might be wrong in that assumption.

After recently getting the game to work on my Vista32 laptop (Single Core Intel Celeron 2.20GHz) I started to realize that either my piloting skills had seriously atrophied, or the flight dynamics engine was producing way to much responsiveness because the physics engine is running too fast. I could barely pull up while flying downhill without a catastrohic blade stall -- the chopper falling straight out of the sky. Forget about trying to land in some of those valley FARPs in Fallen Cresent!

After downloading an older copy of Turbo, I came up with a method to test the frequency of blade stalls. I needed to figure out how frequently they occur under various CPU speeds so that I could choose the CPU speed that most closely matches the way the game is supposed to run.

Experiment:
Go to Instant Action, immedietly climb straight up to between 600-650 feet, put collective to 0% to intiate a dead fall, moniter 'Rate of Climb Scale' and at various 'tick marks' put collective back to 115%, observe whether this produces a catastrohic blade stall where the chopper losses all lift and plummets out of the sky, or whether the rotor can recover lift and prevent you from hitting the ground, repeat this under various CPU speeds.

Here's my results:
(Notice that the Rate of Climb Scale is in feet per minute of descent or ascent, and that each tick mark is equal to 100 ft/min)

BLADE STALL Vs. CPU SPEED CHART

CPU . . .Frame Rate . . . . . . . . . . .Stall Frequency/Descent Speed
====. . .===============. . . . ====================================================
25% . . . Very Choppy. . . . . . . . . .Completely impossible to stall even at max free fall
50% . . . Somewhat Choppy. . . . . .Nearly impossible, except near total free fall
75% . . . Somewhat Smooth. . . . . .Infrequent, >500 ft/min descent (>5 tick marks)
100%. . .Smooth . . . . . . . . . . . . . Constant, >250 ft/min descent (>2.5 tick marks)

I am going to assume that 75% CPU speed is a good match to what I remember the game being like when I was playing it on my Win98 machine. Some blade stalls but only when performing ridiculous maneuvers, or not watching my airspeed when pulling up hard. Obviously for every rig this value might be different, and some ppl may not even have this issue. That said, I am wondering what the correct amount of stall might be, which is why I am trying to formalize where and to what degree (how many tick marks) stall happens.

Does this sound about right? Is your game running at more or fewer stalls?

~Victor1-9er

Wow, nice bit of analysis here. At ONE point enabling the 'vsync' option in dgVoodoo cured this, but since faster graphics cards and multi-core processors have come out - you can forget it!

I think your table looks pretty good, I don't know the exact math but it seems to pan out about right... the slower the CPU the more laggy the game but less low rotor RPM stalls.

Also notice how yaw is completely useless now, unless you use Turbo or similar.

I actually only had problems with yaw if I used the keyboard rudder controls ('[' or ']') As long as I left the yaw control up to my Saitek CyborgX joystick 'twist' everything worked fine. But then again, I also didn't have any of the other 'too fast' problems like HE rockets missing their targets.

Glad you got LB2 back up and running!

Nicely done Victor. I have this issue too and can confirm your tests.

Previously I ran an E8400 @ 3.6/9800GTX+, and the low RPM stalls were manageable save an usually violent/extreme maneuver. On my current system (sig), I can't perform basic maneuvers without plummeting like a rock. I never made a rubric, but it got insanely bad on my current system so the problems obviously scale in relation to clock speed.

Threat launch time getting ridiculously short, hellfires missing moving targets, rockets missing, stalls...all speed related from what i've seen.

This would make an interesting addition to your study though: IIRC, someone had this running on an i5 or i7 though. I'm curious why they wouldn't suffer even worse with faster HW.

Victor, nice analysis. One suggestion:

Try unplugging your joystick and use keyboard keys only and repeat the assays. Also, double check your key board key repeat rate. Make sure it is not too high. Remember, this sim was designed to run with analog joysticks and peripherals not USBs and firewires.