rec.autos.simulators

I have been playing NASCAR 1 for quite some time and really enjoy it, so
I just bought NASCAR 2.  I have a couple questions.

1. Is the sound in 2 different from 1?  In 1, the engines are really
loud, full of base and very clear.  In 2, they are much quieter, not
clear at all, and lack any base whatsoever.  I'm using the same sound
driver in both games.

2. I have downloaded setups that people say can turn 194 MPH laps, but
the best I can do is 174 MPH.  My car runs alot faster in NASCAR 1.  I
have a Pentium 75 with 40 megs of ram and a 4 meg PCI video card.  I
have an Intel 133 on order.  Will I turn faster laps within the game by
putting in a faster CPU, or doesn't the speed of the CPU actually affect
the speed of the cars?

--
PolePosition#3- IVGA #4882

I think you can figure out the SPAM filter.

Visit my pages:
http://www.geocities.com/MotorCity/4578/index.html

"If you don't believe, you don't belong." -- Alan Kulwicki's Credo

However, the speed of the CPU directly effects your (i.e. the human)
driving environment in terms of frame rate and or graphic detail levels
you find acceptable.

The more info your brain can take in, the better your responses.

Imagine trying to drive a curvey (sp?) road at night while your
headlights are acting like strobe lights.  Techically your car can still
drive at the same speed, but the reduction of visual information caused
you to drive less than optimal.

The real unanswered question (from Papy) is the Joystick sample rate and
Physics computation rate.

Is this effected by CPU speed or is it run at a fixed rate regardless of
"frame rate".

Odds are the sample/computation rate is fixed for any level of CPU.

mykey

I went from a P120 to a P200 MMX, and the most notable improvement for
me was at Sears Point!  I could drive with all the details on, making
the changes in the track more evident, and the frame rate was much
smoother - corners I used to have major problems with, disappeared!
As a result, my laptimes went from so-so to pretty darned good!

[Good explanation of why Jane can drive faster laps on her PPro-200 than
on Joe's 486-66 snipped.]

I hadn't ever seen that specific question asked, but I thought I had
commented on it before...

In any event: The joystick sample rate and physics computation rate are
constant for all machines, and do NOT vary with different CPUs or
motherboards. (even Packard Bells :-) )

---Jim

Does this still hold true for the 486-66 with every graphic option
turned "ON" (not Auto) and achieves a wooping 5 fps.

Could this overhead possibly cause the sample/calculation rate to slow
down?

It's not THAT important, just a theoritcal question.

Also, if you have any idea, can you give us a ball park figure on what
the rate is?

15, 30, 60, etc times per second?

mykey

This info would be useful for Thrustmaster ACM users that have full
control of the calibration range by turning the ACM's external
calibration control.  Besides following thrustmaster's suggestion and
calibrating the ACM with the needle in the middle of their scale, is
there any other logic to use to get the most responsive input?

Of course, trial and error is always available.... :-)

I suspect you do not want a range big enough such that your control
ever twitches or goes backwards on the calibration screen.  Any such
lack of complete control would yield less than optimal control of the
simulation.
--
Best Wishes!!!
Robert Huggins
Raleigh, NC

No, the joystick read is interrupt driven. If the machine is so slow
that it can't service the interrupt in a timely fashion, I believe Papy
sims error out. (Your machine would have to be DAMNED slow for this to
happen...)

The physics calculation rate (and therefore the maximum useful frame
rate) is 30 Hz. The joystick read rate is 15 Hz I think.

---Jim

I don't know, as I've never tried the ACM card. I would imagine that for
current Papy sims, ranges of 200-500 would be sufficient, but your
mileage may vary. In any event, it's much more important to get a good
"center" and good repeatable readings than worrying about what the step
size is.

This is correct, and probably the most important guide to use in control
calibration.

In theory, the smaller the highest number acheivable in the calibration
screen, the faster the joystick read will be, leaving more time to do
the physics and draw the frame. In practice, the time difference is so
small for infrequent joystick reads that it probably doesn't matter. GPL
will probably read the joystick a lot more frequently, so it may be
slightly more important there.

---Jim

---Jim

: > I suspect you do not want a range big enough such that your control
: > ever twitches or goes backwards on the calibration screen.  Any such
: > lack of complete control would yield less than optimal control of the
: > simulation.

: This is correct, and probably the most important guide to use in control
: calibration.

: In theory, the smaller the highest number acheivable in the calibration
: screen, the faster the joystick read will be, leaving more time to do
: the physics and draw the frame. In practice, the time difference is so
: small for infrequent joystick reads that it probably doesn't matter. GPL
: will probably read the joystick a lot more frequently, so it may be
: slightly more important there.

Jim,

Two questions about the above:

1) Does the joystick code perform any smoothing or filtering of the input
   samples or are the samples used as-is?

2) The last paragraph above implies (to me) that the CPU just sits around
   doing nothing while the joystick "times out", thus wasting potential
   computation time.  Previous posts have lead me to believe that the
   joystick code operated on interrupts, using some Pentium instruction
   counter for accurate timing.  I feel that I am misunderstanding
   something here.  Is the CPU actually idling while the joystick is
   being read?

Thanks Jim for your great informative posts.  I save them all.

--Scott

--
Scott Willingham / Hewlett-Packard Laboratories

Yes, the CPU is busy-looping (technical not the same as being idle)
while the joystick is being read.

The Pentium RDTSC issue was an artifact of DMA transfers stealing bus
cycles, causing a programmatic busy-loop's count to be off by a variable
amount, introducing noise into the joystick read. RDTSC reads a version
of "wall clock" time, instead of "CPU time" and is thus almost perfectly
immune to DMA bus-cycle noise. (If the DMA burst happens during the
joystick trigger, there will be a small amount of noise recorded.)

---Jim