Wacky Wheels Game data file description --------------------------------------- All data files are packed in the "wacky.dat" file "wacky.dat" byte 0-1: number of files in the file, # of entries in table of contents Table of contents consist of entries of the form struct { 8bit title[14]; // Name of file 32bit size; // Size of file in bytes 32bit start; // Position where file starts in bytes, relative to start of table of contents, ie add 2 to get relative to start of file } *.pcx: images in pcx format *.mid: midi sound format *.voc: voc sound format *.klm: guessing a to me unknown sound format, or wacky special soundrelated files *.sp: raw image (animation) data (only color indexes), use palett from level textures. The image data is ordered in vertical lines. [row,col]: [0,0][1,0][2,0]... Open in PSP as raw with width=subimgheight, height=subimgwidth*count, then rotate 90 degree right and mirror Finally load palette from one of the *.pcx files, keep indexes, I used a pallette saved from a_f1.pcx. Panda, Pelican, Ringo, Shark, Tiger, Camel, Elf and Moose is animation images (38x28 x(Filesize/(38*28))) of respective driver (Uno, Peggles, Ringo, Razer, Tigi, Sultan, Blombo and Morris). Crack is the cracked windshield when a driver smash, 84x62. Cars are all cars+drivers images, height 28, subimages 38x28 x96 Digger: Anim img of the ducks in shot-out zones, height 28, subimages 38x28 OB1: Pile of four black tires, 28x28 OB2: Small clump of reeds, 14x28 OB3: Brown pole with white-red stripes from middle and up, 14x28 OB4: Green cactoo, 14x28 OB5: Red barrel, 28x28 OB6: Yellow barrel, 28x28 OB7: Green barrel, 28x28 OB8: Pile of three tires whith pole in middle, 28x28 OB9: Large clump of reeds, 28x28 OB10: Yellow-Grey striped pole, 14x28 OB11: Yellow-Red striped pole, 14x28 OB12: Green bush, 32x24 OB13: Brown pole, 14x28 H#*: various hogs and shoots H#1,2,5,6,7,12,15,16,20,25: 32x24 x2 fireshot, newspaperreaderhog, ?hog, drillhog, toilethog, blackbomb, redbomb, oil, upsidedownhog, beachhog H#4,8,9,10,11,14,18: 32x24 x4 broomhog, wavehog, candyhog, gunhog, jumphog, hammerhog, bouncingballhog H#24: 32x24 x5 detectivehog H#17,19,22,23: 32x24 x6 patrolhog, golfhog, heavylifthog, volthog H#21: 32x24 x7 footballhog H#3,13: Thoose two files does not exist BRONZEM, SILVERM, GOLDM, BONUSB, BONUSS and BONUSG is minimap of respective levels, 78x50 x5 WFONT1: 15x13 x42 (A-Z,0-9," ./-!",'TM' chars shaded white->yellow->brown from top to bottom) HOGMIS: 18x13 x26 (icecubes, explosions, dustclouds, bombs) ACTION: 251x6 x1 ("APOGEE MEANS ACTION"TM) AJ: 38x28 x4 (Pointing man & woman) PUF: 38x28 x4 (dustcloud) SPARK: 10x9 x4 (9x40) HANDLE: 20x23 x8 GIGGLES: 38x44 x28 ICONS: 26x21 x6 (bombicons) AND 42x19 x1 (speedboard) AND 10x15 x10 (7-segment digits 0-9) LAP: 22x29 x18 (digits) AND 80x17 x2 (wrong way) AND 38x41 x1 (empty frame) AND 126x19 x1 (retrys&hog frames) AND 154x9 x1 (0-9Order Me) DOPE: 80x72 x2 (Dopefish) AND 25x15 x1 (bubbles) OFONT: 8x8 x61 (ascii) AND 92x41 x1 (Apogee) AND 8x8 x137 (ascii) EFFECTS: 165x18 AND 12x24 x2 (watereffect) AND 38x28 x4 (waterflosch) AND 32x24 x8 (periscope) AND 135x24 AND 38x28 x4 (lavaflosch) AND 32x24 x8 (periscope) AND ?x12 etc GENEF: 28x24 x6 (medals) AND 417bytes AND 38x28 x8 (startlion etc) AND 12961-14692=1731 *.inf: I dunno, first 4 bytes in file decode to same numbers as filename. Dimensions match the *.SP dimensions: 14x28 OB# 15x13 WFONT1 18x13 HOGMIS 251x6 ACTION 28x28 OB# 32x24 H# 38x28 * #.gam: which graphics to use for level #, plain text, dunno about the numbers #.m: 64x64 indexes to the graphics pcx file subimages describing the level index 0-53 from first pcx in #.gam, 54-107 from second #.par: background description (clouds, buildings, mountains, sun, pyramid), 640x40, same palette as texture pcx #.spw: where objects and shots are placed byte 0-1: how many 12 byte object locations that follow: struct { 16bit objectid; // 0-12 is OB1-OB13, 13-27 is H1-H25 16bit ??; // most significant bits of objectid? (all bits are zero in checked files) 16bit xcoord; // 0-2048 (64tex of 32x32pixels) 16bit ycoord; // 0-2048 (64tex of 32x32pixels) 32bit ??; // animation something? (all bits are zero in checked files, but game circles through many pics before crashing) } #.rd: Where computer players will drive byte 0-1: how many 14 byte objects that follow struct { 16bit i_am_x; 16bit i_am_y; 16bit aim_at_x; 16bit aim_at_y; 4byte ??; 16bit distance; // sqrt((aim_at_x-i_am_x)^2+(aim_at_y-i_am_y)^2) decimals truncated, not rounded } #.sin: where walls, jumps and speeds are placed, dust from wheels, water? describe properties of each texture image, such as drivable, underwater, jump, speed, goal? 12 byte per texture struct { 16bit prop0_active; // boolean telling if prop0 should be considered 16bit prop1_active; // boolean telling if prop1 should be considered 32bit prop0; // properties for index 0 in f_ma#.pcx 32bit prop1; // properties for index 1 in f_ma#.pcx } //prop values, very unsure (error = probably wrong colortable (palette), since I only tested different values on the first track, and the game seems to use the palette from the A_F*.PCX file belonging to the current track, and they are not all the same) 00 = grey dust1, max 80mph 01 = brown dust, max 44mph 02 = speed boost 03 = wall 04 = grey dust1, max 80mph 05 = high dust, deep ground (water) 06 = diver mode, max 26mph 07 = green dust, max 58mph 08 = grey dust1, max 68mph 09 = error dust, max 80mph 0A = jump 0B = error dust, slightly easier spinout, max 80mph 0C = error dust, slightly easier spinout, max 52mph 0D = grey dust2, easy spinout, max 34mph 0E = error dust, max 80mph 0F = error driver, max 52mph 10 = error dust, medium easier spinout, max 80mph 11 = spin out (rotation) 12 = error dust, slightly easier spinout, max 80mph 13 = green dust, max 44mph 14 = error dust, max 74mph 15 = error dust, max 66mph 16 = error dust, max 40mph 17 = grey1 dust, max 26mph 18 = grey1 dust, spinout when to high speed //Never used 19 = grey1 dust, spinout when to high speed 1A = black dust, spinout when to high speed 1B = error dust, slippery #.pos: how human should drive, notify "wrong way" The drivable part of the level described by a 2-byte (what a waste, number ranges from 0 to ~30) number for each texture, increasing in value when driving in correct direction, restarting at '1' at goal-line. Extra two last bytest gives highest number, ie number where it wrap around to '1' at goal-line *.bmc: first 16bit is number of remaining 3-byte blocks, every third is zero, unknown function Files not in wacky.dat ---------------------- wacky.dtt: The four highscores of wacky shoot out, each of this format struct { char name[20]; long score; } wacky1.hi & wacky2.hi: Fameous drivers, hall of fame, scores; for 12hp resp. 6hp The game seems to zero the last 6 or so bytes of the strings if the score is beaten. struct { short ??; short driver; // Uno = 0, Sultan = 1, Morris = 2, Peggles = 3, Razer = 4, Ringo = 5, Blombo = 6, Tigi = 7 short score; char date[20]; char driver[20]; }