GPL Track Creating - FPS Optimization

GPL Track Creating Optimizing FPS

The Golden 36 FPS

Without 36 frames per second, GPL can be a very difficult beast to master (if it wasn't already ;-) In order to achieve 36FPS on low-end systems, you should consider everything here:

4bit vs. 16bit

While 16bit textures look so much nicer than 4bit textures, they also occupy more texture ram, and on older graphics cards/software rendering, they slow things down quite significantly. *Wherever* possible, use 4bit textures. Another point to consider is the total size of your textures - if you use a different texture for every house, dozens of grass textures etc., you could easily have more than 4 or 8mb of textures. A Voodoo2 12mb graphics card (old technology!) has 8mb of texture ram - if you exceed 8mb, then the textures will have to be swapped in and out of system ram, causing a bottleneck.

Start/Finish Line

With 20 cars and all their associated physics & graphics, you don't want an over-complicated track adding to the CPU load.  Keep the start/finish area simple - only use a few TRK walls, avoid pit garage buildings with individually modeled flag poles, air hoses, etc.

TRK Complexity pt I - Walls

You can usually have as many different walls as you like (up to a reasonable limit - 20 or so). What you should try and avoid, however, is vertical walls - armco, hedges, etc.  These add to the CPU load much more than ground-level walls - 3 times as many polygons, as well as additional physics calculations. In FPS-heavy areas of the track you should consider removing some walls. Whatever you do, don't have walls of zero-thickness, and don't 'layer' walls to make a stepped wall going back from the track. You can do this occasionally, but a 20 step embankment would be silly!

TRK Complexity pt II – Sections

Straight sections are not a problem, corner sections are. When you create a single corner section, it seems just like a bent straight section.  It is actually created from *at least* 4 sections, and depending on your <trackname>.set Corner_Error value, it will be created from 4, 8, 12, 16, etc. sections. This is not good! If you have a blocky looking corner, consider increasing the number of polygons using Unknown4 flags, not changing the Corner_Error value. [Unknown4 + 65536, 2048, 4096 are the flags to use]. Although the additional polygons will slow things down, they do not slow things down as much as the extra sections. A very good example of this is a chicane, where you typically have 4 corner sections and some straight sections. When you look at that part of the track when driving, you are looking through a large number of sections, all at different angles. GPL does not like doing this!

Polygon Count pt I – Track

More polygons = better looking track, worse FPS. Fewer polygons = worse looking track, better FPS. You can decrease the number of polygons using the Unknown4 flags and <trackname>.set. Ideally you want to start with a very low polygon-count track and gradually increase the number of polygons until everything look acceptable.

Polygon Count pt II – Objects

In general, trackside objects are much better in terms of polygon count than the track. You should only see FPS hits if you add very large (in terms of dimensions) objects, or if you add a lot of objects (e.g. 100 trees down one straight).

Polygon Overlapping

Drive around Crystal Palace and you will see a lot of large trees down each side of the track (in places). A lot of these trees overlap each other, so the same area of screen is being filled over and over again. This is not good, but often unavoidable.

Racing Groove

The racing groove, when turned off, can boost FPS by 33% on low-end systems (thanks Niels!). Do you need racing groove around the entire track? If not, set the transparency level in <trackname>.GRV to 0 - trk23dow will not create any polygons then. Also, there are some Unknown4 flags that will let you reduce the number of groove polygons (flags 8192, 16384).

Updated 1-Jan-2001

Transfered to the wiki: 19.04.2009