Dissecting the Stunts files, trying to. Anyone know more?

[Krys TOFF]

We could be able to create new cars shapes, but if we have the programs that allow us to do so.
I found some infos about XVS extension (it seems to be an XView file format, as described here)
It seems XView is a program created in 1988, so it suits well the timeline with Stunts creation. The program is open-source since the early 90's (hey, it seems to be the oldest open-source program ) but I couldn't find a link to download it, most pages I found were talking about the image viewer (named X-view too) or some toolkit extensions for XView program but not the program itself...

Anyway, the XView program seems to be at the origin of Ogre 3D. Just for those who never take a look at the Stunts sequels thread, StuntCarRacer and TileRacer are developped with Ogre 3D.

I found nothing about 3SH extension. What is this one ?

[zaqrack]

I guess you are mistaken here Krys, the XView you quoted on Wikipedia is a widget toolkit, which allows programmers to create user interfaces for programs.

[Krys TOFF]

Oh, this program is an interface toolkit ?  I saw Ogre 3D in this page so I didn't read it all and I thought it was a way to create 3D objects/programs.
So I don't know what is XVS file format...

[dstien]

I doubt that DSI licensed a format for storing straight-forward bitmaps. The filename extensions are likely just coincidences, the 8+3 naming scheme have led to many collisions. These formats may however have been re-used in other games made by DSI/Unlimited Software at the time, I'm eager to know if this is the case, especially the compression.

The compression can be variable-length encoding or run-length encoding. A compressed file may contain another compressed sub-file, hence allowing both compression schemes to be combined recursively. The total size of all game files uncompressed is 2.5 MB (BB 1.1), this would need four DD 3.5" floppy disks, as opposed to two as the game was shipped on (1.2 MB).

I have registered a Google Code hosted project for my tools, the first one being stunpack, a simple command line program for unpacking packed resources (PRE/P3S/PVS/PES) and code files (COD/CMN/DIF). BB 1.0 files are not supported. They differ from 1.1 files, but I haven't investigated it further.

Here's a pre-release Win32 EXE file. I've only tested it under Wine, so please check if it works on an actual Microsoft system as well. You can do this by unpacking resource files and move the original packed ones out of reach. The game will thus load unpacked ones instead. If the game works as normal, the decompression was successful. Please note that some bitmaps will appear distorted. This is not caused by the decompression, but because some bitmaps are stored in vertical lines instead of the regular horizontal lines. This is probably done to get optimal byte-runs.

• stunpack-0.1.0-rc-win32bin.zip
  
  

Naming for fully decompressed resource files:

Code Select Expand


Misc variables  PRE -> RES
3d shapes       P3S -> 3SH
Bitmap images   PVS -> VSH
Icons(?)        PES -> ESH


Example:

Code Select Expand


stunpack stuntsdir/GAME1.P3S stuntsdir/GAME1.3SH
ren stuntsdir/GAME1.P3S stuntsdir/_GAME.P3S


Now we can start dissecting the actual data stored in the resource files. I tried making a new car by using the existing shape "TRUK" found in GAME2.P3S.
It works, but the mesh will be corrupted as there's no dynamic wheels to transform.

[Chulk]

Now we can start dissecting the actual data stored in the resource files. I tried making a new car by using the existing shape "TRUK" found in GAME2.P3S.
It works, but the mesh will be corrupted as there's no dynamic wheels to transform.

Does it mean we can race with the truck on the starting line?!   

[zaqrack]

Oh boy,oh boy oh boy, how I longed to see such a picture! You are doing an incredible job!

[zaqrack]

I have decompressed the same GAME2 file under linux, and checked the contents. It looks promising, looks like every single obstacle and track element can be identified. It seems you can also race with a boat, or let's say - a windmill. This already provides a lot of fun, if we can create an editor and at least edit these stored pictures (adding new elements would be great, but probably unaccepted by the game engine I guess), it could be endless fun

Meanwhile I propose we could create a fully uncompressed copy of Stunts to make work easier. 

edit: linux executable of current version is attached, it may be help for some...

[Krys TOFF]

OMG ! Awesome job ! You're doing great Dstien !!!

[Duplode]

Quoting Zak, that is the news-of-the-year, period!!

[Duplode]

Dstien, my dear namesake  , or Zak, please enlighten me: I succeeded to unpack GAME2.P3S under Linux and to open it under Vim in hex-mode... but how one can tell what parts of the file are a "TRUK" shape, or a "BARN" or an "ELRD"?

[dstien]

Dstien, my dear namesake  , or Zak, please enlighten me: I succeeded to unpack GAME2.P3S under Linux and to open it under Vim in hex-mode... but how one can tell what parts of the file are a "TRUK" shape, or a "BARN" or an "ELRD"?

As discussed earlier, all game files have a common structure for storing multiple resources. For each id name there's a 4-byte offset into the data section of the file. At offset 0x04 is the number of resources, next is the list of id names at offset 0x06. Each id is four bytes, so the following list of offsets is located at 0x06 + numRes * 4. The corresponding data offsets are 4-byte integers, ending at 0x06 + numRes * 4 + numRes * 4, which is the base offset for the data section.

To locate a shape first find its index in the list of ids. "truk" is the 40th resource in GAME2.3SH. The shape's data offset is thus the 40th entry in the offset list. Add this value to the base data offset and you'll have the position of the 3d shape.

0000000: 6c85 0000 3b00 6261 726e 626f 6174 6272  l...;.barnboatbr  <- Number of resources
0000010: 6964 6361 6374 636c 6431 636c 6432 636c  idcactcld1cld2cl
0000020: 6433 656c 7264 656c 7370 6578 7030 6578  d3elrdelspexp0ex
0000030: 7031 6578 7032 6578 7033 666c 6167 6761  p1exp2exp3flagga
0000040: 7373 676f 7569 676f 756f 676f 7570 6869  ssgouigouogouphi
0000050: 6731 6869 6732 6869 6733 6869 6768 6c61  g1hig2hig3highla
0000060: 6b63 6c61 6b65 6c63 6f30 6c63 6f31 7061  kclakelco0lco1pa
0000070: 6c6d 7261 6d70 7263 6f30 7263 6f31 7264  lmramprco0rco1rd
0000080: 7570 7265 7374 7365 6c72 7365 7374 7369  uprestselrsestsi
0000090: 676c 7369 6772 7372 616d 7465 6e6e 7472  glsigrsramtenntr
00000a0: 6565 7472 756b 7769 6e64 7a62 616e 7a62  eetrukwindzbanzb  <- "truk" at index 39
00000b0: 6f61 7a62 7269 7a62 726e 7a65 6c72 7a65  oazbrizbrnzelrze
00000c0: 7370 7a67 6173 7a6c 636f 7a70 616c 7a72  spzgaszlcozpalzr
00000d0: 616d 7a72 636f 7a72 6475 7a72 6573 7a73  amzrcozrduzreszs
00000e0: 6572 7a73 6573 7a73 7261 7a74 656e 7a77  erzseszsraztenzw
00000f0: 696e 0000 0000 ec01 0000 9e06 0000 a208  in..............  <- End of id name list, start of offset list
0000100: 0000 480d 0000 840e 0000 4a0f 0000 ee10  ..H.......J.....
0000110: 0000 f012 0000 3e14 0000 7e14 0000 be14  ......>...~.....
0000120: 0000 0215 0000 5a15 0000 0016 0000 4a1b  ......Z.......J.
0000130: 0000 b01b 0000 f41b 0000 3a1c 0000 6a1c  ..........:...j.
0000140: 0000 9a1c 0000 ca1c 0000 fa1c 0000 261d  ..............&.
0000150: 0000 541d 0000 5829 0000 702a 0000 e02c  ..T...X)..p*...,
0000160: 0000 982e 0000 9c3a 0000 b43b 0000 423e  .......:...;..B>
0000170: 0000 1844 0000 ba45 0000 884d 0000 ee4e  ...D...E...M...N
0000180: 0000 5450 0000 0052 0000 1e53 0000 1e54  ..TP...R...S...T  <- truk's data offset at index 39
0000190: 0000 4e59 0000 9a62 0000 ba63 0000 aa66  ..NY...b...c...f
00001a0: 0000 c467 0000 e468 0000 fc69 0000 606a  ...g...h...i..`j
00001b0: 0000 826d 0000 7871 0000 fa72 0000 c873  ...m..xq...r...s
00001c0: 0000 be77 0000 3479 0000 9a7b 0000 e27c  ...w..4y...{...|
00001d0: 0000 a07f 0000 6280 0000 ce80 0000        ......b.......   <- End of offset list, base data offset
[...]                                                                  truk's content is at 0x01DE + 0x541E = 0x55FC

Now we know where truk's data starts, but not where it ends as we don't know how to parse the 3d shape data yet. To find the end just use the start offset of the next resource.

[Duplode]

Oh well, I hadn't really understood the *.RES structure description the first time - now it's crystal clear... thanks!

[Duplode]

After toying a bit with those offsets for track elements in GAME1.3SH, I noticed a few simple facts:

• As perhaps could be expected, physical behaviour of track elements is not controlled by the assigned shape in the offset list;
• It seems that offsets can be exchanged at will;
• For a number of track elements, there are two entries with similar names, one of them starting with a "z" on the id-list - for instance, "tunn" and "ztun". In that case, "tunn" is assigned to the shape the element has at close distance, while "ztun" corresponds to the shape from a larger distance and at the track preview. Doing so, I created an element which from afar looks like a sharp left turn (ztur), upon closer inspection appears to be a highway split (gwro) but in fact is a tunnel...

Summing it all up: Krys, it's time for some hard coded illusion tracks!

[zaqrack]

Doing so, I created an element which from afar looks like a sharp left turn (ztur), upon closer inspection appears to be a highway split (gwro) but in fact is a tunnel...[/li]

get away from me, evil!

[BonzaiJoe]

Oh dear, this is so funny & great