Gizmo's Grand Prix 2 FAQ
Frequently Asked Questions (with answers)


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): 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.

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: 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.