GB: As far as I know there are two version of the game for the PC, F1GP on floppies, which is supplied on 4 high density disks with optional upgrade disks, and F1GP on CD, which is EXACTLY the same game but on a silver disk. Do not buy this unless you don't have a floppy drive, since it costs more and has no extra features. Quite what MicroProse is playing at is unknown, but the CD version represents bad value for your money.
The game is now reissued by Digital Integration on the PowerPlus budget label.
DG: Having played both the Amiga and PC versions, I noticed some important differences. First, some of the tracks are physically different, Monaco and Imola at least. Second, perhaps because of the low frame rate or different control routines, the car is much, much harder to set up on the Amiga than the PC; it's very hard to feel whether the car has any under- or oversteer. It's also much harder to time the turn-in points properly, as Ivanhoe's explanation of frame rates above predicts.
CPU MHz Memory Detail Occupancy FPS ----------------------------------- P5 100 8MB 4d T 33% 25fps (Squirty's w/ D.Stealth 24 2MB VRAM) P5 90 24MB 4d T 37% 25fps (Gizmo's tower of power w/ PCI K64) P5 90 24MB 4d T 90% 50fps (Gizmo's tower of power w/ PCI K64) 486DX2/66 8MB 4d T 70% 25fps (Gizmo's Linux box w/ VLB CL5428) 486DX2/66 4MB 4d T 60% 25fps 486DX2/66 32MB 4d T 53% 25fps (Pete F's Dan4Win w/ Spea V7 VLB) 486DX2/66 ? 4d T 70% 25fps (MBP's under OS/2) 486DX 33 ? 4d T 90% 25fps (Graham A's) 486DX2/66 16MB 4d NT 35% 25fps (Nigel Bovey's) 486SX 33 4MB 4d NT 66% 25fps 486DX2/50 24MB 4d NT 95% 25fps (Paul Smyth's w/ ISA ET4000-W32) 486SX 25 4MB 4d NT 100% 25fps (a DELL) 486SX 25 ? 4d NT 80% 25fps (Nightshade's oldie) 486SX 25 4MB 4d NT 100% 23fps (Ben Lester's) 486SX 25 2MB 4d NT 100% 21fps 386DX 40 4MB 4d NT 100% 20fps 386DX 40 2MB 4d NT 100% 20fps (possibly optimistic) 486DX2/50 24MB 4d NT 100% 18fps (Paul Smyth's w/ ISA S3-924) 386DX 33 8MB 4d NT 100% 17fps (Gizmo's old faithful w/ T8900CL) 386SX 20 2MB 1d NT 100% 15fps (Max Behara's) 386SX 25 2MB 4d NT 100% 14fps (Stingray's) 386SX 20 2MB 4d NT 100% 8fps (Max Behara's)It appears that as long as you have at least 2mb of RAM, the actual amount makes absolutely no difference. The difference between the DX2/66s above is attributable to graphics card alone; see the difference between Paul Smyth's machine with two different graphics cards installed. DG: IMHO if you have a 486SX/25 or better with a VLB or PCI graphics card you should be able to crank the frame rate right up without texture; a 486DX2/50 or better will add texture without any penalty. A 486DX2/66 should be able to do linked play at 25fps, possibly with detail cranked down a bit, and a Pentium 75 or faster is pure heaven. (Lots of memory is useful, for logging data to a RAMdrive when using the GPPerf and GPLap TSRs.)
The details level is shown by the amount of detail around the track, 1d being the lowest level and 4d the highest, the other detail option is the track shading, this is shown by T (track shading on), NT (no track shading). The average processor occupancy is as you go around any track. This is just a rough estimate, since tracks can vary quite a lot (Phoenix and Hockenheim are quite stressful, with lots of buildings and tress), but the occupancy really shouldn't go above 100% very much. The final column show the speed in frames per pecond that this set-up allows.
Even on similar machines, several things will affect speed. A machine with some external cache will outperform one without; the actual amount of cache is probably not going to make much difference. Graphics card performance also makes a big difference; a local bus card will run much faster that an ISA card, and some cards have better DOS performance than others (Cirrus Logic based cards are good, ET4000 and derivatives are even better; VLB and PCI cards will be much faster than ISA ones).
The general consensus seem to be that people would rather have it running smoother, but with less detail, this shows one of the main advantages of F1GP over IndyCar, in that it runs quickly on a slow machine and smooth graphics are possible quite easily.
The Amiga version runs at a similar speed regardless of the machine's capacity, about 3-8 fps, depending on circuit and level of detail, even in the fastest 68060 system. (The latest F1GP-Ed and also F1GP-Patch can alter this, at a compatability cost.)
Does the performance vary on an ST? Mail me if you know.
Long answer: it doesn't... directly. DG is in the fortunate position of having both a P90 and a 486DX/66 on his desk and a 386DX/33 under it, and loaded identical copies of the game up on both machines. The first and most obvious difference was that the game does not do a good job of matching "real time" (measured on a stopwatch during laps on qualifying tyres at Monaco). The first tests were done on the 386. With 100% to 130% occupancy, the game's timer runs slow, being about three seconds behind reality. With all the detail turned off and the occupancy down to about 70% to 110%, it was about three seconds ahead of reality. With the frame rate reduced and occupancy between 45% and 75%, it was about 4 seconds behind. Then testing moved to the P90. With maximum detail and about 33% to 44% occupancy, the timer was about 4 seconds fast.
Now, here's the crunch. Despite these differences, the lap times reported by the game were very close, all in the 1:14.4 range. The game was noticeably easier to play at higher frame rates and lower occupancies. However, with very high occupancies (more than 200%, such as on the 386 with texture turned on), the difference from real time becomes very noticeable; the whole game runs in slow motion, and is potentially easier to play as you get much longer to react. Ivanhoe Vasiljevich came up with the superb (and very lightly edited) explanation below.
[...] a high frame rate [as opposed to occupancy] may have its advantages (my opinion, not proven!):However, since the game's physics model is imperfect (after all, it's just a model), playing at different frame rates will reveal slight differences in certain circumstances. Here's a short test done for the LFRS championship:
Using a frame rate of 25 fps means that you have 25 possibilities to perform an action (eg. braking, accelerating) every second, whereas driving with 16 fps only allows you 16 `slots' per second, to brake, for example.
Assuming that a typical braking maneuver begins at 300 km/h (188 mph), this equals a speed of 83 m/s, so that at 25 fps you can take action (brake) every 3.3 m as opposed to every 5.2 m when using 16 fps. (Using an even lower frame rate naturally worsens the situation. At 8 fps the distance between two points of action is 10.3 m!) During a normal lap including many braking maneuvers, this may affect the overall performance, not to mention techniques like pulsing the throttle.
In my opinion it would be best to turn off as much detail as necessary and increase the frame rate as high as possible. (It may not look as cool, but honestly, who has got the time to enjoy the beautiful panorama when chasing a new lap record?)
I ran three tests, each consisting of two laps round Mexico City. Each test was at a different frame rate, and each lap was consistent with the other. I looked at the entry and exit speeds for the Peralta (the final, awesome corner). All tests were done using GPLap 5 to remove any randomized BHP or AI grip effects, under version 1.05, on a 90 MHz, 24MB Pentium, with a 1MB DRAM Orchid Kelvin 64 PCI graphics card.Probably one could also find example situations where 13 FPS or 18.7 FPS were optimal and 25 FPS went slower. This is what happens when you simulate a continuous system with a discrete model; you get rounding errors.
Test 1. Frame rate: 25 FPS. Entry: 189 mph, exit: 190 mph. Gain of 1 mph in corner.
Test 2. Frame rate: 18.7 FPS. Entry: 189 mph, exit: 188 mph. Loss of 1 mph in corner.
Test 3. Frame rate: 13 FPS. Entry: 188 mph, exit: 186 mph. Loss of 2 mph in corner and 1 mph before entry.
Another potential problem pointed out to me is that the game copies all the Data files onto hard disk before decompressing them, and this effectively doubles the amount of space it uses at installation time, so make sure you have plenty of free hard disk space, as this will cure both this problem and the one above.
Windows 95 is a common culprit. Bill Gates has chosen to deliberately mislead users, telling them that Windows 95 will solve all their DOS memory management problems. He lied. The good news is that the vast majority of users can solve the problem themselves, by editing their config.sys and autoexec.bat files to ensure that DOS device drivers aren't loaded if Windows 95 can supply protected mode equivalents; this usually means CD-ROM and network drivers.
As an example, here are my configuration files. My (sanitized) config.sys is:
SWITCHES=/f DEVICE=C:\WINDOWS\himem.sys DEVICE=C:\WINDOWS\emm386.exe noems ram LASTDRIVE=z FILESHIGH=60 DOS=high,umb DEVICEHIGH=C:\WINDOWS\COMMAND\ansi.sysMy (again sanitized) autoexec.bat is:
@echo off path C:\WINDOWS;C:\WINDOWS\COMMAND;c:\bin;c:\dos;c:\usr\bin;c:\game\f1gp\bin set MIDI=SYNTH:1 MAP:E set SOUND=c:\sb16 set BLASTER=A220 I5 D1 H5 P330 T6 c:\sb16\diagnose /S c:\sb16\sb16set /p /q
On the PC, keyboard seems to be preferred by many of the top drivers, with analog joystick coming a close second. DG: The professional wheel systems (such as the T1 or ACP) don't seem to work wonderfully. I've had a few success stories but many people go back to the keyboard!
Javier Vizcaino provided the following information about using radio control units with the game.
It is [...] possible to change a transmitter used in radio control (R/C) to turn it into a PC joystick, and play F1GP. I've modified a few, and let me tell you that there is nothing similar to drive with these devices.He also provides some information about PC game ports which help a few folks out. Note that if you're going to play games on a PC with a joystick, you really should invest in either a decent soundcard with credible joystick ports [DG: my Gravis UltraSound is pretty good, and my SoundBlaster 16 also seems reliable a drift-free] or a dedicated game card.
About the game port, this is what happens. Game ports on the PC can be full (the initial good ones with a 558, still found on SB cards at least, four pots and four buttons), or half (cheaper chinese solution, two pots and two buttons, simple joysticks). F1GP goes well on a half port. The problem is that there are a lot of multi I/O boards with Winbond chips including a half game port which presents the missing buttons pressed. When F1GP starts calibrating the joystick, it stops till seeing the four buttons released (it can't know if your game port is full or half); with the above board, calibration doesn't start, and you have to abort it with the ESC key. So if calibrating the joystick the game seems to freeze till you press ESC, may be you have this problem. Check with DEBUG: i201; if you see bits 7-6 at 0, the game port presents the third and fourth buttons pressed.
DG: The Amiga sounds good even through a TV. The PC with 1.05 and a SoundBlaster is okay if you turn it up real loud, but not a patch on the Amiga. A PC with MT-32 or other MIDI is pathetic, but the music is better. *sigh* I don't know about the ST, but I'd guess it's better than a PC speaker and nowhere near as good as the Amiga.
Several top Hall Of Fame drivers, both on the PC and Amiga, report that driving with Traction Help off, whilst harder, also improves lap times at many circuits.
One of the areas in which to pay most attention is the pit lane, since the computer cars will quite happily pull out in front of you as you do 150 mph down the lane and so cause a collision. Conversely, watch your mirrors as you pull out since they appear quite quickly if you are in the last pit.
On the track, they basically follow the ideal line unless slipstreaming. If you can get your front wheels ahead of theirs they do move over so perfect your drafting technique!
Race Qualifying Total 1 Monte Carlo 41 1 Monte Carlo 40 1 Monte Carlo 81 2 Magny Cours 34 2 Mexico City 36 2 Mexico City 68 3 Spa 33 3 Hockenhiem 35 3 Imola 64 4 Imola 32 4 Adelaide 34 4 Hockenhiem 51 ==Mexico City 32 5 Imola 32 ==Magny Cours 51 6 Monza 31 6 Silverstone 23 6 Spa 50 7 Interlagos 20 7 Suzuka 20 7 Monza 49 8 Suzuka 19 8 Monza 18 8 Adelaide 47 9 Hockenhiem 16 9 Spa 17 9 Suzuka 39 10 Adelaide 13 ==Magny Cours 17 10 Silverstone 35 11 Silverstone 12 11 Montreal 12 11 Interlagos 21 12 Phoenix 10 12 Estoril 7 ==Montreal 21 13 Montreal 9 13 Phoenix 5 13 Phoenix 15 14 Barcelona 3 14 Hungaroring 3 14 Estoril 7 15 Estoril 0 15 Interlagos 1 15 Barcelona 3 ==Hungaroring 0 16 Barcelona 0 ==Hungaroring 3Scoring: the top four tracks score 5, 4, 3, 1 points, with the most hated getting a 1 point penalty.
He then wrote Stunt Car Racer for the Amiga/ST (and the PC, although the conversion is reported to be poor: 4 color EGA only; the port was apparantly not done by Crammond) which was as it's name suggests was a stunt car racing game. The main aim of the game was to race another stunt car around an elevated circuit, trying not to fall off. Getting in your way were large gaps in the circuit which had to be jumped by hitting a ramp at the right speed. Too slow and you went down the hole, too fast and you cracked the chassis. When the chassis was fully cracked, your race was over. The best part about this game was the two player serial option which allowed you to push your mates off the track.
The rest of the programming team seems to be members of his close family! The only other name that jumps out is that of Pete Cook who wrote some of the best games on the Sinclair ZX Spectrum. Interestingly he was involved with the game Grand Prix from CRL, which attempted to simulate the management of a GP team. It was very simple but great fun.
Outside of auto racing games, Crammond also made an excellent 3D game called The Sentinel, for Spectrum, C64, Amiga, Atari, etc, and it was a very nice idea. You were in a landscape, absorbing some objects, teleporting from one place to the other, always trying to be out of sight of a sentinel that was guarding the landscape. The goal was to have enough energy to climb higher then the sentinel (you were able to build little platforms) and absorb him and take his place. There were people who didn't like the game, but those who liked it were addicted to it. It would be nice to see the game in Virtual Reality, it would be easy to write.
"Because part of the circuit is on the public road, Oliver couldn't practice on the circuit", explains Geoff, "so he used F1GP to learn the track, took pole position and won the race."Derek Warwick on the other hand drove for the F1 team Arrows/Footwork (who helped write the game!) and gave it a glowing write up in Autosport Magazine, just before the Canadian GP (the 10 June 1993 issue). There was also an interview with the Footwork engineers. He gave some lap times but they were very poor, and he had to drive with full help. This provoked a spate of letters to the magazine from people asking for his job, including the following, from the 17 June 1993 issue:
GIZAJOBAlso, a Canadian driver contacted him to say how accurate the Montreal course was.
I read last week's Canadian Grand Prix preview - about Footwork Formula 1's computer game - with interest.
I have been playing the game for several months now and was delighted to read how accurate it is. Allen McDonald claimed he could lap Montreal in 1m19s. Well I can lap in 1m17.627s so does this mean I can take Derek Warwick's place if ever he feels like having the weekend off.
One correspondant reports that he is working on a patch to alter the pit-bay allocation.
One correspondant reports:
I've overshot the pit at Monza. The pit entrance is very straight and you can build up enough speed so that the game won't actually stop you.
There is no modem support on the first version (1.01) but this was added on the updates 1.04 and 1.05, the link option needs two quite fast machine to work well, on 386SX it is almost unplayable, and the slowest machine dictates the speed of the other machines; on a 386DX you'll probably need a 16550 UART to get acceptable performance. If the game seems to pause a lot or you get regular (but not constant) link data mismatches, try reducing the frame rate on the slower machine by 30% or more.
You should also be aware that if one of you has altered your gp.exe in anyway (either by a patch or a TSR), then you must both be running identical games. This means that:
If you have a dialup connection to the Internet, you may be able to use the Internet Head-to-Head Daemon (IHHD) to play with someone on the net. You can find more details in ftp://cactus.org/pub/IHHD/.
In theory, one could use a null-modem cable to loop the COM ports on two machines together, and write a TSR which would transfer bytes between the network card and the COM port which isn't selected in the game. So far, nobody has reported trying this.
There is a bug in the linked code that is a real bitch. It involves having only one or none drivers (ie. human) in the race.
In other words, both human drivers must be actively racing or you will get a data mismatch error when the game is reloaded. Obviously, this is only if you reload the game during a race and one or both of the human drivers have crashed out.
This nasty little [bug] bit my friend and I over the past weekend. It was Monza and we were both trying to catch Schu who was running away with the championship (we have the AI turned up quite a bit). My friend crashed out real early. My car had so much oversteer that I was run down by the AI and passed for the lead [...]. I got really frustrated and crashed myself out as well.
Just as I crashed out, the modem link disconnected. I dutifully saved the game as I exited the screen. When we reloaded this game later, it gave us a mismatch error. There goes the season. The latest saved game we had was for Belgium, but we had both crashed out of that as well (however, the race finished, therefore, the mismatch bug was eluded).
Well, we tried to reload the bad game with the mismatch from Monza, but it still had the error. We then selected to restart (the race in Monza), however, the 2nd bug came about. This time, he was me and I was he. This was quite interesting because both of our files said we were selected as ourselves. What was more strange was that, obviously, I was in his car and he was in mine. In other words, my joystick controlled his car and his mine. When I hit N on my computer, it said I was him.
Well, we tried to drive each others cars and ended up crashing out anyway. Needless to say, we just accelerated the rest of the season, handing the title over to Schu.
The moral of the story: if one, or both, human drivers crash out, make sure that you finish the race! Do not save a game with only one human driver or else when it is reloaded, you will get mismatch errors.
You can play F1GP (and other games) through a direct connection, informing the game you are connected "Direct", and having a modem at each end. You establish the connection through a communication package, or from the DOS prompt, before entering the game. The link is done from modem to modem, through a direct telephone cable, with RJ-11 connectors at each end. This has some advantages:
This is the where you can push the computer cars to their limit, and they literally explode. What I can figure out is the program never expects the AI cars to go over a limit of 394 km/h, but if this occurence happens their speed is instantaneously reset to zero. So think about this scenario your happily pushing Nigel Mansell down the straights of Hockenheim at around 400 km/h, he hit's WARP SPEED! but your still doing 400km/h so the logical thing for the program to do is destroy his car. Funny maybe for the first time but thats about it.
Also it's interesting to go up alonside a driver while doing over 400km/h and clipping their wheels just enough to make them hit warp speed and make them dissapear into distance.
[DG: I believe the exact speed is 411km/h, which is 256mph, since 255 is the largest value a single byte can hold, so 256 becomes 0.]
Next, the game will not let you avoid some things by restarting a race. For example, if the race is wet, reloading, even before free practice, will not avoid the rain. (It is possible to do something about this with some of the Amiga editors, but not yet on the PC.)
Also, one correspondant has reported that pit stop times stay constant too. If you are in a race, save the game, then pit, and get a bad stop time, reloading will not help you.