Gizmo's Grand Prix 2 FAQ
Frequently Asked Questions (with answers)
Introduction
What is this all about?
I've written this FAQ specifically to address GP2
issues which I'm frequently asked about. It gravitates towards technical
issues, and particularly those which affect HOF2Lap.
If you're after details of the internal workings of GP2 and its files,
I'm not free to dvulge what I know because of agreements with those who
have found much of the information.
But what is Grand Prix 2?
It's a Formula 1 simulation written by Geoff Crammond and published by
Spectrum Holobyte-MicroProse. GP2 is an evolution of his original F1 simulation,
Formula 1 Grand Prix, which was also known as World Circuit.
Frame rate and occupancy
To explain the relationaship between the speed of your machine, the frame
rate, and the reported occupancy during game play, it is necessary to understand
how the game's simulation engine works.
How the simulation engine works
First, given f, the frame rate in frames per second, let i
be
1/f, the inter-frame gap in seconds. (For example, if the frame
rate is 10FPS, the inter-frame gap will be 0.1s.)
Now we start our imaginary game engine running. For each frame it does
the same things (draw the display, use the AI and player's inputs to set
the control inputs and move the cars, communicate with the other machine
during linked play). It measures t the time it takes to do everything
and compares it to i. Ideally, we want the two to be equal, which
means that the game is running at full speed with no CPU wastage. If t
is less than i, it's running at full speed but there's some CPU
time left over, during which we sit idle waiting for the right time to
start the next frame. If t is greater than i, the simulation
will be running slower than reality, since no attempt is made to catch
up; the start of the next frame is simply set back by whatever amount the
last overran.
Finally, we say that o, the occupancy, is t/i, expressed
as a percentage. So, if o is 100%, we're running at the currect
speed; if
o is less than 100%, there's wasted CPU, and if o
is greater than 100%, the game is trying to do too much.
The consequences of GP2's simulation engine design
Time slows under heavy load
If there's a sudden increase in the amount of time it takes to do each
frame, the occupancy shoots up to 200-300% (each frame takes 2-3 times
as long to produce as it should). This is typical of the game if you crash
and plough off into the gravel. 1 second of game time takes 2-3 seconds
of real time, resulting in the simulation running much slower than reality.
Occupancy should be kept below 100%
When choosing your frame rate, you should aim to have the occupancy
never
go above 100%. Why? Because as long as you stay at or below 100% ocupancy,
the game will be running at a consistent speed. If the occupancy is jumping
up above 100% some of the time (for example, during a part of the circuit
with a lot of scenery, at at the start of a race with lots of cars in front
of you), the speed at which the game runs will be inconsistent and make
car control more difficult.
Is there a better way to design a real-time simulator?
Yes; in my opinion, the correct way for a simulator to behave is to produce
frames as quickly as possible, and vary the inter-frame gap on the fly
so that the simulation really does run in real-time regardless of how long
each frame takes to do. This also means that as hardware gets faster, it
isn't constrained by the maximum selectable frame rate if it is capable
of going much faster. (This became a real issue with F1GP.)
Saved files
Hot laps (.HLx)
What's in a hot lap file?
How is a hot lap structured?
A hot lap contains the following things (possibly more; the format isn't
totally understood yet and probaly never will be):
-
The frame rate, level, and other global information.
-
Qualifying and race setups for each circuit. These setups may or may not
be the same as the actual setup used for the hot lap.
-
The power and grip levels of the computer cars.
-
Information for each car which is on the track, giving it's position, speed,
power, setup, and so on. (We've dubbed these the "car structs", and they
appear to be a direct dump of information from the running game.)
-
A second set of car structs giving each car's state when the hot lap was
saved. Note that this may or may not be at the end of the hot lap.
-
A record of all the control inputs during the lap.
-
The lap and split times of the best and last lap. Note that the hot lap
which has been saved may be neither of these.
I am occaisionally asked for a detailed description of the format of hot
lap
files. I'm afraid I can't oblige because much of the information was provided
by fellow hackers who would rather the information was not passed into
the public domain. All I will say is that you should attack the
.NAM
files first and crack the compression algorithm; after that it's much easier.
Is it possible to extract performance data directly from a hot lap?
No. A hot lap stores the initial state of the simulation engine, along
with the control inputs for that lap. When you load a replay into the game,
it simply runs the game as "normal", except that it uses the control inputs
stored inside the hot lap, rather than those from the user.
As a consequence, you can't extract the performance data from a hot
lap because there isn't any performance data in the hot lap.
So how does the game do it? Well, think about where the performance
data comes from normally; it gets logged as the game is being played. So,
all the game has to do is replay the hot lap to recover the performance
data. What it
doesn't do is display the graphics, so whilst it looks
as if te game is "extracting" the data from the replay, really it's actually
replaying the hot lap to get the data. (That's also why it takes so long
to do.)
There are some other consequences of this method of operation.
-
If any updates to the game are released, they won't be able to change the
existing tracks without preventing other replays from working properly.
-
It isn't possible to remove the performance data from a replay. The game
may claim to do so, but all it really does is to set a flag in the replay
which tells the game to prevent the data being saved. With reudimentary
knowledge of the format of hot lap files it's very easy to recover the
data even if the lap was saved "without" it.
Can the setup information be removed from a hot lap?
If you followed the above discussion, you should
understand that altering any property of the car will prevent the replay
from being viewed correctly. (The simulation engine is being fed the same
inputs, but the car they're controlling is different, so it will probably
run off the road in the first corner.) So, if we try and remove the setup
from the hot lap file, when the file is loaded back into the game it will
not replay correctly.
What happens if someone tries to cover up cheating by editing a hot lap?
The same as what happens if they try and remove
the setup information. Let's say that this devious person uses an editor
to boost their BHP to 800. It's not so much higher than the normal value
and
might not be spotted from just viewing the replay. This person
wants to submit the lap to a competition and uses something like my HOF2Lap
program to do so. Now, HOF2Lap will tip the organizer of the competition
off that the person has cheated, so he or she decides to alter the hot
lap file to cover his or her tracks, by reducing the BHP as stored in the
hot lap to a normal value. HOF2Lap now produces a perfectly good authentication
code from an apparantly valid lap. So far it seems like our cheater has
gotten away with it, but they forgot one detail; when everyone else sees
how fast their lap is, they all think, "that's so fast I think they cheated!"
and the organizer asks for the hot lap so that they can check it. At this
point, the cheat is caught, because they can only do one of three things:
-
Submit the uneditied hot lap, which will show the edited BHP.
-
Submit the edited lap, which will not replay correctly.
-
Withdraw the illegal lap.
This example also demonstrates an important principle; the actual hot lap
itself is the only reliable way to check laps. Tools like HOF2Lap are useful
in that they provide a way to check some internal details in a hot lap,
details which can't be seen using the game itself, and because they provide
an easy way to submit and process laps, but they can't check the actual
consistency of a hot lap.
Are there any limits on what can be checked?
Yes, the lap times themselves. As mentioned previously, the times from
the hot lap may not be stored in the hot lap itself (the game does not
use the stored times when replaying the lap, but instead recreates the
times using the simulation engine.) Let's examine a hypothetical situation
to see what the consequences are.
Bob is driving a race and sets the fastest time on lap 31. On lap 33
he sees a spectacular crash in front of him, but drives on until lap 35,
after which he decides that his friend Alice really ought to see that crash,
so he saves lap 33 as a hot lap and sends it to Alice. This hot lap has
recorded Bob's fastest lap time from lap 31, and his last lap time, from
lap 35, but the only way to find out Bob's lap 33 time is to actually view
the replay with paper and pen to hand.
This also has implications for the ability of programs like HOF2Lap
to detect cheating. Here's another hypothetical situation.
Bob's evil twin, Charlie, decides that he wants to cheat in a hot lap
competition, so he uses a game editor to increase his BHP to 950. Now he
goes and drives a really fast lap with this added power, returns to the
pits, and saves the game. Then he exits GP2 and uses the editor to restore
the default 779 BHP (some editors show it as 780). Now he returns to GP2
and loads the game he saved, exits the pits, and drives a slower lap, which
he saves as a hot lap. Now Charlie runs HOF2Lap, which records the fastest
lap time (which was set with illegally high BHP). (If HOF2Lap used the
"last lap" time, you would have to save each hot lap immediately after
crossing the line, which would exclude otherwise valid laps, and prevent
effective usage on race laps).
The good news is that of course Charlie will be caught out when he has
to produce the actual hot lap file; when viewed, it will clearly show that
the lap doesn't match the time he submitted. The same goes for edited track
files.
Another thing which cannot be detected by HOF2Lap but which will result
in an invalid replay is editing the grip level of the player's car.
One thing that it is not possible to check and which cannot be caught
any other way at present, is a lap driven in slow motion
(which would in principle provide a player with more reaction time). But
this problem is solved if you're using GP2Lap.
Races (saved games; .RAx)
Saved games are stored in a format almost identical to that of hot laps.
That's why HOF2Lap can provide some basic information about such files.
Gizmo