| Any cheat codes | Browse by game: A B C D E F G H I J K L M N O P Q R S T U V W X Y 0-9 |
|
Need for Speed, The cheats / Need for Speed, The hints / Need for Speed, The faqs / Need for Speed, The solutions Need for Speed, The hints ====================================================================== THE UNOFFICIAL NEED FOR SPEED FILE FORMAT SPECIFICATIONS - Version 0.2 ====================================================================== A - GAMEDATA directory ================== A.1 GAMEDATA\CONFIG\PATHS.DAT ------------------------- This file contains 18 null-terminated strings of 80 characters each (total 1440 bytes), describing the paths where NFS looks for its files. For minimum install, here are the contents (with hex offset): 000 gamedata/config/ 2D0 F:\simdata\misc\ 050 gamedata/savegame/ 320 F:\simdata\trackfam\ 0A0 F:\frontend\speech\ 370 F:\simdata\slides\ 0F0 F:\simdata\soundbnk\ 3C0 F:\simdata\carFams\ 140 F:\frontend\music\ 410 F:\simdata\soundbnk\ 190 F:\frontend\art\ 460 F:\simdata\carspecs\ 1E0 gamedata/modem/ 4B0 F:\simdata\dash\ 230 F:\frontend\movielow\ 500 F:\simdata\misc\ 280 gamedata/replay/ 550 F:\frontend\show\ Note that simdata\soundbnk and simdata\misc are present twice. Also note that in the CD-ROM, directories whose name starts with a 'G' correspond to the German version of the game. Don't know why the car dashboards had to be translated, though :) Modify these entries if you want to copy some of the CD files to your hard disk, for example if you want to modify them. Remember that modifying the files can be hazardous, and that because the file formats are not fully known it is better to modify an existing file than to create one from scratch. A.2 GAMEDATA\SAVEGAME\*.SAV ----------------------- These are the tournament save files (840 bytes each). - Offset 0 : your name (null-terminated string followed by zeros) - Offset 28 : 'Opponent' (") - Offset EC : 'Player 2' (") - Offset 114 : 'Opponent 2' (") - Offset 1D8 : name of the tournament (") - Offset 20A : 'REPLAY.RPL' (") - Offsets 23C-26F : ??? - Offset 270 : name of the tournament (") - Offsets 30E-337 : ??? - Offsets 338, 33A, 33C, 33E, 340, 342, 344 : these contain 01 if the corresponding race has been won, otherwise 00. The first three bytes are for open-road races, while the other correspond to closed tracks. For instance, in order to access the bonus track, save a tournament, then set all these bytes to 01 except 33E to 00 (Rusty Springs), then reload the tournament and win Rusty Springs. The odd offsets 339 to 345 are zeros. - Offsets 346-347 : ??? The other offsets contains zeros. A.3 GAMEDATA\CONFIG\CONFIG.DAT -------------------------- This file (25552 bytes) contains all the relevant configuration data (current car, track, display & sound options, ...), as well as the current scores (best times, top speeds, laps, ...). It also describes whether you have access to the bonus track and the bonus car, etc... Anybody got anything more detailed to put here ? B - SIMDATA directory ================= B.1 SIMDATA\CARSPECS\*.PBS ---------------------- These files (one per player car) describe the car performance. Usually, installing these files to the hard disk (by editing PATHS.DAT) makes Need for Speed inoperable (no acceleration is possible) because the game modifies SIMDATA\CARSPECS\BY_R&T. However this can be prevented by making the check file read-only (run ATTRIB +R BY_R&T). Note that copying one of these files on top of another one will affect the car performance and handling, but not the engine sound. So if the max rpm's of the two engines are not the same, the sound can get badly altered because the correct sound sample is not available. These files are somehow compressed, because by modifying a single byte in the file one can reach various results such as : an instant system crash ; a car that materializes under the road and cannot move, with 11 gears (!) ; a car without front wheels, that keeps spinning at its initial position... B.2 SIMDATA\DASH\*.FMM ------------------ These small files (two per player car, corresponding to the hi-res and low-res dashboards) describe the shape of the car's windshield in each display resolution. The files are slightly different for 320x200 and 640x480. a) Low-res .FMMs (*DL.FMM) : The file structure is the following : first a 24-byte header, then four chunks. The header format is the following : offset len data ------ --- ---- 00 4 'wwww' 04 4 4 (number of chunks) 08 4 18h (offset of the first chunk) 0C 4 offset of the second chunk 10 4 offset of the third chunk 14 4 offset of the fourth chunk The chunks in low-res .FMMs have the following header (22 bytes) : offset len data ------ --- ---- 00 4 'BAMF' 04 2 length of the chunk in bytes, minus two 06 4 ? (usually equals 10000h or 8000h : maybe an image size) 0A 2 maximum "length" value in the chunk's records 0C 4 ? (usually equals 10000h or 8000h : maybe an image size) 10 4 ? (usually equals 10000h or 8000h : maybe an image size) 14 2 number of records in the chunk (length minus 18h, div 8) This header is in each chunk immediately followed by the 8-byte records. Each record has the following structure : offset len data ------ --- ---- 00 4 baddr 04 2 vaddr 06 2 length The last record is followed by a 16-bit value (purpose unknown). The vaddr and length values are interpreted as follows : starting from address "vaddr" in video memory (i.e. of the form 320y+x for pixel (x,y)), "length" pixels do not belong to the dashboard, and must instead be drawn because they correspond to screen portions where the player must see the road through the windshield. The baddr field corresponds to an internal buffer offset, describing where the data to be displayed at "vaddr" are to be found in the buffer where NFS draws the view. - The first chunk corresponds to high detail : vaddr and baddr are equal, and each line corresponds to 320 bytes in the buffer (every pixel is stored). - The second chunk corresponds to medium detail : each line corresponds to 320 bytes in the buffer, but only half of the pixels are stored, thus only the first 160 bytes contain relevant data, the following 160 being unused. To vaddr=320y+x corresponds baddr=320y+(x>>1) : the horizontal resolution is decreased. - The third chunk corresponds to low detail : two consecutive lines have the same baddr values, and these two lines correspond to 320 bytes in the buffer. As before, only half of these 320 bytes are used. Only a quarter of the pixels are stored. vaddr=320y+x corresponds to baddr=320.(y>>1)+(x>>1) : both horizontal and vertical resolutions are decreased. - The fourth chunk corresponds to the interlaced mode : only half of the screen lines are referenced ; as in low detail, two screen lines correspond to 320 bytes, half of which are unused. vaddr=320y+x still corresponds to baddr=320.(y>>1)+(x>>1), but only the even-numbered lines are present. b) Hi-res .FMMs (*DH.FMM) : The chunk format is slightly different because the video memory is now segmented in several 64K pages. (Note that the values at offsets 06, 0C and 10 in the chunk header are now larger, e.g. 40000h and 10000h) Offset 14h in the chunk now contains, instead of the total number of records in the chunk, only the number of records that correspond to the first page of video memory (i.e. the first 64K). It is followed by the corresponding records. After these records, another 16-bit value describes the number of records that are located in the second page of video memory (the following 64K); the records for the second page follow (note that the 32-bit baddr values at last become useful ; only the 16 last bits of the vaddr are stored, since it is known to be located in the second page). The chunk continues with the following pages, until the number of records for a given page is zero. This zero value is followed by a 16-bit value (purpose unknown) as in the low-res files. The four chunks correspond respectively to high, medium, low and interlaced detail levels, as described above (but the lines are now each 640 pixels long ; when not in high resolution, only 320 of the 640 bytes are used). B.3 SIMDATA\DASH\*.FSH ------------------ These store the different bitmaps that make up the dashboard. The 16-byte header format is the following : offset len data ------ --- ---- 00 4 'SHPI' 04 4 length of the file in bytes 08 4 number of objects in the directory 0C 4 directory identifier string The directory identifier is 'GIMX' in .FSH dashboard files. This header is followed by the directory entries, each consisting of a 4-byte identifier string, and a 4-byte offset inside the file pointing to the beginning of the corresponding data. Each entry in the directory represents a piece of the dashboard. There are gaps between the directory and the first bitmap, and between consecutive bitmaps (significance unknown). Each directory entry points to a bitmap block with the following structure : offset len data ------ --- ---- 00 1 7Bh 01 3 size of the block (= width x length + 10h) 04 2 width of the bitmap in pixels 06 2 heigth of the bitmap in pixels 08 4 ? 0C 2 x position to display the bitmap 0E 2 y position to display the bitmap 10 w.h bitmap data : 1 byte per pixel Note that the object called 'dash' in the directory takes the whole screen (320x200 or 640x480, at position x=0, y=0)." The various objects, depending on their 4-letter identifier, represent : the dashboard itself, the steering wheel in various positions, the radar detector lights, the gauges, and also pieces of the steering wheel to redraw over the gauges when necessary. Note that value FF in the bitmaps stands for the background : this is useful when a bitmap is drawn on top of another one. Also note that some SHPI bitmap directories contain entries that actually describe the palette to be used with the bitmaps. Typically, entries with names like '!PAL', and with bitmap dimension 256x3, correspond to palettes. The palette data consists of 256 3-byte records, each record containing the red, green and blue components of the corresponding color (1 byte each). B.4 SIMDATA\CARFAMS\*.CFM --------------------- These files describe the exterior look of the cars during the race. There seem to be two different kinds of files : - full CFMs that can be used to describe any car - restricted CFMs that can only describe traffic or opponents - note that yourself and your head-to-head opponent must have full CFMs, whereas "single race" opponents can be either full or restricted CFMs. a) Full CFMs on the CD : Standard cars : ANSX.CFM, CZR1.CFM, DVIPER.CFM, F512TR.CFM, LDIABL.CFM, MRX7.CFM, P911.CFM, TSUPRA.CFM, TRAFFC.CFM (Warrior) More or less bugged previous versions of these cars : F512M.CFM, P911T.CFM, WARIOR.CFM, WARRIOR.CFM b) Restricted CFMs on the CD : Vans/jeeps/pickups : JEEP.CFM, PICKUP.CFM, RODEO.CFM, VANDURA.CFM Station-wagons : AXXESS.CFM, WAGON.CFM Usual cars : BMW.CFM, JETTA.CFM, LEMANS.CFM, SUNBIRD.CFM Sports cars : CRX.CFM, PROBE.CFM The cop's car : COPMUST.CFM Restricted versions of the player cars (loaded for single race opponents): MANSX.CFM, MCZR1.CFM, MDVIPER.CFM, MF512TR.CFM, MLDIABL.CFM, MMRX7.CFM, MP911.CFM, MTSUPRA.CFM, MTRAFFC.CFM Bugged versions of the player cars : LDIABLO.CFM, MF512M.CFM, MP911T.CFM, TESTA.CFM These files are 'wwww' files containing four chunks. The header is as in .FMM files (see B.2). The first and second chunk correspond to high-detail car structure, while the third and fourth chunk correspond to low-detail. The first and third chunks have header 'ORIP', and describe how the car is to be drawn (position and orientation of each car element). The second and fourth chunks are 'SHPI' bitmap directories (see B.3), with directory identifier 'WRAP'. They provide the bitmaps referenced by the ORIP chunks. Note that the offsets specified in the bitmap directories are relative to the 'SHPI' header. An 'ORIP' chunk consists of a header followed by nine blocks. The header has length 112 (70h) and the following structure : offset len data ------ --- ---- 00 4 'ORIP' 04 4 chunk length in bytes 08 4 2BCh (=700) 0C 4 0 10 4 size of block 8 in 12-byte records 14 4 ? the previous minus 10h 18 4 offset of block 8 in the ORIP (in bytes) 1C 4 size of block 2 in 8-byte records 20 4 offset of block 2 24 4 size of block 1 in 12-byte records 28 4 offset of block 1 (=70h) 2C 12 identifier string 38 4 size of block 3 in 20-byte records 3C 4 offset of block 3 40 4 size of block 4 in 20-byte records 44 4 offset of block 4 48 4 size of block 5 in 28-byte records 4C 4 offset of block 5 50 4 offset of block 9 54 4 size of block 6 in 12-byte records 58 4 offset of block 6 5C 4 size of block 7 in 12-byte records 60 4 offset of block 7 64 4 0 68 4 70h 6C 4 0 The first block consists of 12-byte records and describes the polygons that are used to draw the car: offset len data ------ --- ---- 00 1 83h for triangle, 84h for quadrangle, 8Ch when quadrangle/null 01 1 ? 02 1 texture number 03 1 ? 04 4 polygon offset for pol1 08 4 polygon offset for pol2 The texture number corresponds to a record position in block 3, which is converted to one of the textures in the SHPI chunk that follows the ORIP. The polygon offsets correspond to positions in the last block, where the polygons are listed consecutively (first pol2 and then pol1, for each record). The first polygon has pol2 starting at 0. (The polygon offsets are given in 4-byte units). In the last block, vertices belonging to a pol1 are expanded to 3D points by lookup in block 8, while vertices belonging to a pol2 are expanded to 2D points by lookup in block 2. The portion of the relevant texture corresponding to pol2 is mapped onto the 3D polygon pol1. When the first byte is 83h, pol1=pol2+3 and next polygon's pol2 equals pol1+3. When it is 84h, pol1=pol2+4 and next pol2 equals pol1+4. When it is 8Ch, pol1=pol2 and next pol2 equals pol1+4. The second block is made of 8-byte records, which describe the (x,y) coordinates inside the textures referenced by pol2. offset len data ------ --- ---- 00 4 x coordinate 04 4 y coordinate Third block (20-byte records): offset len data ------ --- ---- 00 8 identifier string 1 08 4 identifier string 2 0C 8 ? 00 00 00 81 F5 00 00 00 This block describes the link between the texture numbers of block 1 and the textures stored in the SHPI chunk. Identifier string 2, when non-void, corresponds to one of the SHPI directory entries. Fourth block (20-byte records): offset len data ------ --- ---- 00 8 identifier string ('left_tur', 'right_tu') 08 4 number of vertices 0C 4 polygon offset (in block 9) 10 4 ? Fifth block (28-byte records): offset len data ------ --- ---- 00 12 identifier string ('NON-SORT', 'inside', 'surface', 'outside') 0C 4 ? 10 4 polygon offset (in block 9) 14 4 number of vertices 18 4 0 Sixth and seventh blocks (12-byte records): offset len data ------ --- ---- 00 8 identifier string 08 4 ? The eighth block consists of 12-byte records which describe the position in space of each vertex (using signed long ints, centered at (0,0,0)). offset len data ------ --- ---- 00 4 x coord. (x axis is lateral) 04 4 z coord. (z axis is vertical, z increases when going up) 08 4 y coord. (y axis is longitudinal, increases when going forward) The last block is a succession of long integers, each representing a vertex number. This block describes the vertices each polygon consists of, and is referenced by the index tables of the first, fourth and fifth blocks. Each vertex number referenced in a pol1 polygon is converted to a point in space using block 8, while each vertex number referenced in a pol2 polygon is converted to a position in a texture bitmap using block 2. B.5 SIMDATA\MISC\*.QFS, SIMDATA\SLIDES\*.QFS, ... --------------------------------------------- This seems to be EAC's favorite bitmap format... Basically, it is similar to the .FSH files described in B.3, however the data are now compressed using some kind of Huffman algorithm. Outside of this compression thing, the file still contains a 'SHPI' header, and a directory. The directory itself is much shorter than in the dashboard FSH's : usually one entry (the bitmap itself), sometimes two (when a palette is specified). The big trouble is in finding the details of the decompression algorithm. The directory header is 'LN32', indicating 32768-color mode. (see C.2). B.6 SIMDATA\MISC\*.TRI ------------------ Don't know why these are in the MISC directory... they are quite important indeed ! They describe the track itself, including the shape of the road and the position of the scenery items. The objects are referenced by numbers which correspond to entries in the corresponding file in SIMDATA\TRACKFAM. Their structure is fairly complex, so I recommend you play with the files in order to get acquainted with their subtleties. The information contained in this section was used to develop the first NFS track editor, called TRACKED, and available at the following URL : http://www.eleves.ens.fr:8080/home/auroux/nfs/tracked.zip In order to understand the structure of TRI files you have to know that a track is the superposition of three structures : - first, a 'virtual road' : this is a sequence of points in space, which will be called 'nodes'. These points correspond to successive positions along the track, and all the cars have to pass near each of these positions. During the game, the virtual road is invisible, but you have to stay close to it. - second, the scenery : this is a collection of points in space, which will be called 'vertices', together with textures which are mapped onto the polygons defined by consecutive vertices. These textures are used to draw the road, the roadside and part of the landscape. Thus it is of course preferable that the scenery remain close to the virtual road ! - and last, the objects : points in space together with bitmaps, which are used for road signs, buildings, trees, etc... Some of them are plain 2D bitmaps, but others have a more sophisticated polygonal 3D structure. The 3D coordinates x,y,z will always be used with the following meaning : - x is an axis which is transversal to the starting line. Positive x values correspond to points which are on the right of the starting position. (i.e. if you start looking to the north, x points to the east) - y is an axis which is parallel to the starting line. Positive y values correspond to points which are ahead of the starting position. (i.e. y points to the north) - z is a vertical axis. Positive z values correspond to points higher than the starting position. a) TRI files begin with 12F8h bytes of headers and index tables. These are as follows : offset len data ------ --- ---- 00 4 ? 04 8 ? 0C 4 x coordinate of the first node 10 4 z coordinate of the first node 14 4 y coordinate of the first node 18 4 ? 1C 4 ? 20 4 ? 24 4 length of the scenery data (in bytes : 554h per record) 28 4 ? 2C 960h first index table 98C 960h second index table The first index table is a succession of 32-bit offsets. It follows an arithmetic progression by 548h as a general rule. This means the first value is 0, followed by 548h, A90h, etc... On closed tracks, when the end is reached, the offsets start again with 0, 548h, A90h, etc... (so that the end of a lap is connected with the beginning of the following one !). The table is filled to 960h bytes (600 entries) with zero values. This table is probably only used as a lookup table in memory during the game, since there are no 548h-byte structures in the file. The second index table is also a succession of 32-bit offsets, but these offsets are inside the TRI file. This one follows an arithmetic progression by 554h. It corresponds to the offsets of the successive records for scenery data, which starts at offset 1B000h in the scenery file. So this table starts with 1B000h, 1B554h, 1BAA8h, etc... until the end of the TRI file is reached. It is filled to 600 entries with zero values. b) The virtual road data follows, and is constituted of 36-byte records (one for each node). The first record is at offset 12F8h, and the last allowed record is at offset 16468h (this leaves room for 2400 records, and since a scenery block corresponds to four nodes, both capacities are equal). The unused records (after the last node) are filled with zero values. The structure of each record is the following : offset len data ------ --- ---- 00 1 a0 01 1 a1 02 1 a2 03 1 a3 04 1 b0 05 1 b1 06 1 b2 07 1 b3 08 4 x coordinate 0C 4 z coordinate 10 4 y coordinate 14 2 slope 16 2 slant-A 18 2 orientation 1A 2 0 1C 2 y-orientation 1E 2 slant-B 20 2 x-orientation 22 2 0 - a0,a1,a2,a3 are 8-bit values whose purpose is unknown : possibly the width of the road on each side ? - b0,b1,b2,b3 are 8-bit values of unknown purpose. - x, z and y coordinates are signed long values. - slope is a value indicating the slope at the current node, i.e. the difference between the z coordinates of two consecutive nodes. A good approximation is : slope(i) = (z(i+1) - z(i))/152. However, to complicate things, it is stored as a signed 14-bit value, complemented to 4000h. This means -1 is stored as 3FFFh, -2 as 3FFEh, ... So in fact you must perform a logical and with 3FFFh before storing ! - slant-A is a value indicating how the road is slanted to the left or to the right (as in the turns in Autumn Valley or Lost Vegas). It is a signed 14-bit value, like slope. The value is positive if the road is slanted to the right, negative if it is slanted to the left. - slant-B has the same purpose, but is a standard signed 16-bit value. Its value is positive for the left, negative for the right. The approximative relation between slant-A and slant-B is slant-B = -12.3 slant-A (remember that slant-A is 14-bit, though) - orientation is a 14-bit value, and is equal to 0 for north (increasing y), 1000h for east (increasing x), 2000h for south (decreasing y), 3000h for west (decreasing x), and back to 3FFFh for north. - y-orientation is a signed 16-bit value, which is proportional to the y coordinate variation. Meanwhile, x-orientation is proportional to the *opposite* of the x coordinate variation. This means that the couple (-xorientation,yorientation) gives the orientation of the track. The norm (square root of xorient^2+yorient^2) is usually around 32000 (a little less than 8000h, to avoid numeric overflows), but can fluctuate with the only condition that (-xor,yor) gives the correct orientation. c) The objects data comes next. There are first several distinct zones, many of which seem to be unused (?) : offset len data ------ --- ---- 16478 708h 3-byte records (there are 600... as many as scenery blocks ?) 16B80 4 40h (?) 16B84 4 3E8h = 1000 (size of the main block in records) 16B88 4 'OBJS' 16B8C 4 428Ch (total length of the remaining blocks) 16B90 400h 16-byte records (unknown purpose) 16F90 4 ? 16F94 3E80h object data : 1000 records of 16 bytes (one per object) 1AE14 1ECh 0 The object data itself consists of a 16-byte record per object. The record structure is the following : offset len data ------ --- ---- 00 4 reference node 04 1 bitmap number 05 1 flip 06 4 flags (unknown purpose) 0A 2 relative x coordinate 0C 2 relative z coordinate 0E 2 relative y coordinate Each object is related to a reference node in the virtual road. The x,z,y coordinates are then expressed as signed 16-bit values relative to the coordinates of the reference node. Beware that the axes are simply translated but not rotated ! (i.e. the x and y axes are still pointing east and north) The objects are sorted in the order of increasing reference nodes. A reference node value of -1 indicates that the record is unused (i.e. after the end of the used records). Also note that the coordinates are not expressed in the same unit as the 32-bit absolute coordinates seen above (the units are much larger, so that the value fits in 16 bits). The 8-bit flip value is equal to 0 for an object that is perfectly perpendi- cular to the track (e.g. a road sign), larger values for objects that are slightly turned, until 64 for an object that is mapped along the track (e.g. an ad on the side of the road), then up to 128 which is the perfectly reversed position (since the objects have no "back", this is the common way of reversing a road sign for a turn in the other direction), then up to 192 which is again longitudinal mapping (the other way) and until 255 which is back to the normal position. The bitmap number corresponds to a texture in the corresponding .FAM file (see B.8). The relevant bitmaps are in the second chunk of the .FAM file. Two cases can occur : - closed tracks : the second chunk is a 'wwww' structure containing a single subchunk which is in turn a SHPI directory where the entry corres- ponding to bitmap #n is called "nn00" where nn is n written in decimal. (e.g. bitmap #18 is "1800"). Furthermore the object called "!pal" or "!PAL", when it exists, is the corresponding palette (256 3-byte entries) ; FFh is transparent. - open roads : the second chunk contains a subchunk per bitmap, and each subchunk is a SHPI containing at least the object "0000" (the bitmap), and possibly a palette ("!pal" or "!PAL"). Object #n is then the bitmap "0000" in the subchunk #n (the first subchunk is #0). One must add to these 2D objects (plain bitmaps) the 3D objects described in the fourth chunk of the .FAM file. They usually correspond to numbers above the last 2D object ; however it happens, in closed tracks, that some of the 3D objects are given numbers inside the range used by 2D objects. In that case, the numbers describing 2D objects are shifted upwards. (i.e. the bitmap "4400" corresponds to object #45 or #46). This phenomenon apparently does not occur for open roads, where the 3D objects always follow the 2D objects. Furthermore, certain consecutive bitmaps represent successive states of an animated object. In that case, the game will display successively the relevant bitmaps. Note that if the second bitmap is given instead of the first, the animation does not occur. d) The scenery data starts at offset 1B000h. It is made up of records of size 554h, each corresponding to four nodes in the virtual road. The records are consecutive and the last record ends the .TRI file. Each record has the following structure : offset len data ------ --- ---- 000 4 'TRKD' 004 4 548h = length of the record contents 008 4 number of this record (0 for the first, then 1, etc...) 00C 2 ? 00E 10 textures 018 12 reference point 024 12 ? 030 12 point A0 03C 12 point A1 ... .. ........ 09C 12 point A9 0A8 12 point A10 0B4 12 ? 0C0 12 point B0 0CC 12 point B1 ... .. ........ 12C 12 point B9 138 12 point B10 144 12 ? 150 12 point C0 15C 12 point C1 ... .. ........ 1BC 12 point C9 1C8 12 point C10 1D4 12 ? 1E0 12 point D0 1EC 12 point D1 ... .. ........ 24C 12 point D9 258 12 point D10 264 12 ? 270 12 ? 27C 12 point E0 288 12 point E1 ... .. ........ 2E8 12 point E9 2F4 12 point E10 300 516 ? unused (room for 43 points) 504 80 ? unused Each point is given by three signed 32-bit absolute coordinates (x,z,y as usual). The coordinates are the same as in the virtual road data. The reference point is unused in the game and usually equal to point A0. The points A0,...,A10 in record #n (starting with 0) correspond to the node #4n (starting with 0) in the virtual road data. B0,...,B10 correspond to node #4n+1, C0...C10 to node #4n+2, D0...D10 to node #4n+3 and E0...E10 to node #4n+4. Thus the points E0...E10 are identical to the points A0...A10 of the following record. The eleven point series (0 to 10) are arranged as follows : A0-E0 are near the middle of the road, and thus close to the corresponding nodes. A1-E1 are a little to the right, A2-E2 further right, ... until A5-E5. A6-E6 are a little to the left, A7-E7 further left, ... until A10-E10. (In tunnels, the points A5-E5 and A10-E10 get back to the center, consti- tuting the ceiling). To each record correspond ten textures (coded at the beginning), each given by a 8-bit value, T1,T2,...,T10. T1 is used between A0-E0 and A1-E1, T2 between A1-E1 and A2-E2, ..., T5 between A4-E4 and A5-E5 ; meanwhile, T6 is used between A0-E0 and A6-E6, T7 between A6-E6 and A7-E7, ..., T10 between A9-E9 and A10-E10. This is summarized on the following diagram : E10---E9---E8---E7---E6---E0---E1---E2---E3---E4---E5 node 4n+4 | | | | | || | | | | | | | | | | || | | | | | D10 D9 D8 D7 D6 D0 D1 D2 D3 D4 D5 node 4n+3 | T | T | T | T | T || T | T | T | T | T | | | | | | || | | | | | C10 C9 C8 C7 C6 C0 C1 C2 C3 C4 C5 node 4n+2 | 10 | 9 | 8 | 7 | 6 || 1 | 2 | 3 | 4 | 5 | | | | | | || | | | | | B10 B9 B8 B7 B6 B0 B1 B2 B3 B4 B5 node 4n+1 | | | | | || | | | | | | | | | | || | | | | | A10---A9---A8---A7---A6---A0---A1---A2---A3---A4---A5 node 4n ^ the nodes are here | The texture numbers are converted to bitmaps in the first chunk of the .FAM file (see B.8). There are two different cases : - closed tracks : the first chunk is a 'wwww' structure which contains a single subchunk which is in turn a SHPI bitmap directory, possibly with a palette '!PAL' or '!pal'. There is also often a bitmap called 'ga00' or 'GA00' (unknown interpretation). The names have the structure "xxls", where xx is a decimal value indicating the texture group, l is 'A', 'B' or 'C', and s indicates a scale ('0' is the largest, while '3'&'4' are very small). The various scales are here to speed up the texture-mapping algorithm, anyway the only texture that is always present is with s=0. The xx and l values correspond to a texture number n in the following way : n=3xx if l='A', 3xx+1 if l='B' and 3xx+2 if l='C'. Note that there are holes in the numbering : many numbers do not have a bitmap. Examples : bitmap "03C0" corresponds to texture #11 (3x3+2) at the largest scale; bitmap "14A1" corresponds to texture #42 (3x14) at the second scale available. - open roads : the first chunk contains a subchunk per texture group (i.e. the xx value is now the number of the subchunk, starting with 0). Each subchunk is a SHPI directory containing potentially a palette, and bitmaps labelled "l00s", where l is 'A','B' or 'C' and s is the scale. As before, n=3xx if l='A', 3xx+1 if l='B', 3xx+2 if l='C', and there are holes in the numbering. Examples : texture #11 at scale '0' is now the bitmap "C000" in subchunk #3. Texture #42 at scale '1' is now the bitmap called "A001" in subchunk #14. B.7 SIMDATA\SOUNDBNK\*.BNK ---------------------- These file store the sound samples for the engines, the crashes, etc... The filenames ending with 'W' correspond to 16-bit sound, while 'B' stands for 8-bit sound. Logically, 'S' should stand for stereo and 'M' for mono, but it seems that, at least for cars, the file that gets loaded in 8-bit mono mode is the one whose name ends with 'SB'. I don't know why. I'm beginning to think that EAC recruited Microsoft programmers ;-) Also remember that the 8 bit sound samples are signed data. If you plan to use WAV files as samples, don't forget to change this. The file format is the following : - the first 512 bytes contain 128 long integers, which are either zero if the corresponding sample is not present, or the offset of a sample header. Car files contain four samples with header offsets 200h, 248h, 290h and 2D8h, declared at offsets 04, 08, 0C and 80h respectively. The two first samples are the engine sound, the third is the car horn, the fourth is the sound that gets produced when you change gears. - each sample header consists of 72 bytes (48h). The format is the following: offset len data ------ --- ---- 00 4 ? flags (for 8-bit car sounds, these are 1, 2, 4000h and 10h) 04 4 header's offset + 28h (i.e. offset of the 'EACS' marker) 08 4 ? (0 for cars) 0C 4 ? (0 for cars except gear change) 10 4 ? (0 for cars) 14 1 ? 15 1 ? (80h for cars) 16 1 ? (0 for cars) 17 1 ? 18 4 ? (7F40h for cars) 1C 4 ? (0 for cars) 20 4 ? (0 for cars) 24 4 ? (0 for cars) 28 4 'EACS' 2C 4 3E80h (sampling rate : 16 kHz) 30 1 8/16 bit flag : 1 for 8-bit, 2 for 16-bit 31 1 mono/stereo flag : 1 for mono, 2 for stereo 32 1 ? (0 for cars) 33 1 ? (FFh for cars) 34 4 beginning of the repeat loop (in samples : 1, 2 or 4 bytes) 38 4 length of the repeat loop (in samples) 3C 4 length of the sound (in samples) 40 4 offset of the raw sound data in the .BNK file 44 4 ? (0 for cars) B.8 SIMDATA\TRACKFAM\*.FAM ---------------------- These files contain the bitmaps that are used for displaying the correspon- ding track or track segment. They make use of the 'wwww' file format, using the usual header (see B.2) : first 'wwww', then the number of chunks (as a long integer), then the offsets of each chunk header (long integers). The .FAM file itself is a 'wwww' file containing four chunks. The first chunk corresponds to the background bitmaps, making up the terrain and the road, while the second chunk is devoted to foreground bitmaps (road signs, etc...) Each of these two chunks is itself in 'wwww' format, containing sub-chunks. Note that the offsets of the sub-chunks listed in the headers are relative to the beginning of the chunks. In the open road .FAM's, the chunks are very subdivided and contain many small subchunks, while in the closed tracks, there is only one big subchunk. Now the subchunks in each of the first two chunks are themselves 'SHPI' bitmap directories (see B.3), whose elements are a palette and several bitmaps. Keep in mind that the offsets in the directories are relative to the beginning of the subchunk (i.e. the 'SHPI' header). The third chunk of the .FAM file is a SHPI file describing the horizon : the SHPI directory contains two entries, one for the palette and one for the bitmap itself. The fourth chunk describes the three-dimensional objects in the scenery. It is a 'wwww' structure, containing a subchunk per object. Now each of these subchunks is quite similar to a .CFM file (see B.4) : it is itself a 'wwww' structure containing two subsubchunks ! The first subsubchunk is an 'ORIP' structure describing the shape of the object, while the second is a 'SHPI' structure containing the bitmaps referenced by the 'ORIP' part. If you didn't catch everything, don't worry... look at NFSVIEW.PAS (see D.1) C - FRONTEND directory ================== C.1 FRONTEND\ART\*.QFS, FRONTEND\SHOW\*.QFS : see B.5 --------------------------------------- C.2 FRONTEND\ART\*.INV ------------------ These files describe how to reduce the palette from hi-color mode to 256 colors. The corresponding .QFS files (compressed SHPI bitmaps) have directory identifier 'LN32', indicating the bitmaps are in 32768-color mode (each red, blue and green component is coded on 5 bits (0 to 31), and the 15 bits describing the color are stored in a 16-bit word). Since many video cards do not support these modes, information is provided for palette reduction to 256-color modes. This information is partly stored as a palette object in the QFS file, describing the RGB components of the 256 colors. In order to help Need for Speed with the palette conversion, the .INV file (length 32768 bytes) stores, for each 15-bit value, which palette entry is relevant. Displaying the 'LN32' bitmaps in 256-color is thus done by first expanding the .QFS file, then setting the specified palette, and converting each 15-bit pixel in the bitmap to the 8-bit value located at the corresponding offset in the .INV file. C.3 FRONTEND\MUSIC\*.ASF -------------------- These files contain the music for the front end. The 40-byte header is as follows (note a consistency with the EACS structures described in B.7) : offset len data ------ --- ---- 00 4 '1SNh' 04 4 ? 08 4 'EACS' 0C 4 3E80h (sampling rate 16 kHz) 10 1 2 (16-bit mode flag) 11 1 2 (stereo mode flag) 12 1 ? (0 usually) 13 1 ? (0 usually) 14 4 length of the wave data (expressed in 4-byte samples) 18 4 beginning of the repeat loop (in samples) 1C 4 length of the repeat loop (in samples) 20 4 0 (the start offset is not specified : should be 28h) 24 4 ? Signed 16-bit stereo wave data follows. C.4 FRONTEND\SPEECH\*.EAS --------------------- These file contain the speeches, as an EACS structure (see B.7 and C.3). The 32-byte header is now as follows : offset len data ------ --- ---- 00 4 'EACS' 04 4 3E80h (sampling rate 16 kHz) 08 1 1 (8-bit mode flag) 09 1 1 (mono mode flag) 0A 1 ? (0 usually) 0B 1 ? (FFh usually) 0C 4 length of wave data (expressed in 1-byte units) 10 4 FFFFFFFFh (no repeat loop) 14 4 0 (no repeat length) 18 4 20h (offset of the wave data) 1C 4 ? Signed 8-bit mono wave data follows. D - Appendix ======== D.1 NFSVIEW.PAS ----------- {NFS file viewer : recurse into 'wwww' structures and view 'SHPI' bitmaps} uses crt; var f:file; scr:array[0..199,0..319] of byte absolute $A000:0; pal:array[0..767] of byte; s:string[5]; procedure setpalette; assembler; asm mov dx,3c8h xor cl,cl mov si,offset pal cld @bcl: mov al,cl out dx,al inc dx lodsb out dx,al lodsb out dx,al lodsb out dx,al dec dx inc cl jnz @bcl end; function st(x:longint):string; var s:string[20]; begin str(x,s); st:=s; end; procedure viewshpi(pre:string;off:longint); {process a SHPI} var ni,i:integer; w,h,xp,yp,y:word; l:longint; foundpal:boolean; begin seek(f,off+8); blockread(f,ni,2); writeln(pre,'SHPI ',ni,' bitmaps'#10#13'Looking for a palette...'); foundpal:=false; for i:=0 to ni-1 do begin {look for a palette} seek(f,off+20+8*i); blockread(f,l,4); seek(f,off+l+4); blockread(f,w,2); blockread(f,h,2); if (w=256) and (h=3) then begin blockread(f,pal,8); blockread(f,pal,768); foundpal:=true; end; end; if foundpal then writeln('Found !') else writeln('No palette.'); readkey; asm mov ax,13h int 10h end; if foundpal then setpalette; for i:=0 to ni-1 do begin {display the bitmaps} fillchar(scr,64000,0); seek(f,off+20+8*i); blockread(f,l,4); seek(f,off+l+4); blockread(f,w,2); blockread(f,h,2); blockread(f,l,4); blockread(f,xp,2); blockread(f,yp,2); if (w<>256) or (h<>3) then begin if (xp+w>320) or (yp+h>200) then begin yp:=0; xp:=0; end; for y:=yp to yp+h-1 do blockread(f,scr[y,xp],w); readkey; end; end; asm mov ax,3 int 10h end; end; procedure viewwwww(pre:string;off:longint); {process a wwww block} var n,i:integer; l:longint; s:string[5]; begin seek(f,off+4); blockread(f,n,2); for i:=1 to n do begin {process each chunk} seek(f,off+4+4*i); blockread(f,l,4); s[0]:=#4; seek(f,off+l); blockread(f,s[1],4); {read 4-char id} if s='wwww' then viewwwww(pre+'chunk '+st(i)+'/'+st(n)+' sub',off+l) else if s='SHPI' then viewshpi(pre+'chunk '+st(i)+'/'+st(n)+' ',off+l) else begin writeln(pre,'chunk ',i,'/',n,' unrecognized header ',s); readkey; end; end; end; begin if paramcount=0 then begin writeln('Need For Speed wwww/SHPI Viewer 1.0 (c) Denis Auroux 1995'); writeln('Syntax : NFSVIEW filename'#10#13); exit; end; clrscr; assign(f,paramstr(1)); reset(f,1); s[0]:=#4; blockread(f,s[1],4); {read 4-char id} if s='wwww' then viewwwww('',0) else if s='SHPI' then viewshpi('',0) else writeln('Unrecognized header ',s,#10#13); close(f); end. Other Need for Speed, The cheats hints faqs solutions: 1. Need for Speed, The cheat codes 2. Need for Speed, The cheat codes 2. Need for Speed, The hints |