1 | SHP file specifications for DUNE2 game (c) by WESTWOOD and VIRIN
|
---|
2 | ==================================================================
|
---|
3 | (c) by Joachim Schiele <js@dune2.de>
|
---|
4 | REVISION 1
|
---|
5 |
|
---|
6 | What are SHP files btw?
|
---|
7 | =======================
|
---|
8 | SHP is a method of saving multible graphics in one file and also be able
|
---|
9 | to have some kind of compression. In this case "DUNE II" it's format80
|
---|
10 | compression mode. The "DUNE II" code is a little bit different from the one
|
---|
11 | of "Command and Conqueror" hacked by Vladan Bato. Major parts of this
|
---|
12 | informations are from him and only needed some little modifications to be
|
---|
13 | compatible with the ones of "DUNE II". But in case you want to work with
|
---|
14 | this format i think it's better if it's function is documented.
|
---|
15 | Explanations and example codes are in "c", see sandtools how to code a
|
---|
16 | extractor/converter for shpfiles.
|
---|
17 |
|
---|
18 | ============
|
---|
19 | HEAD
|
---|
20 | ============
|
---|
21 |
|
---|
22 | *** File: ../data/pak/dune/arrow.shp (hextype output)
|
---|
23 | 00000000 : 09 00 28 00 00 00 34 00-00 00 B3 00 00 00 36 01 : ................
|
---|
24 | 00000001 : 00 00 A7 01 00 00 17 02-00 00 A0 02 00 00 21 03 : ................
|
---|
25 | 00000002 : 00 00 B3 03 00 00 0A 04-00 00 02 00 01 01 00 01 : ................
|
---|
26 | 00000003 : 0C 00 02 00 00 01 00 00-10 10 00 10 7F 00 B8 00 : ................
|
---|
27 | exampe 1
|
---|
28 |
|
---|
29 | (symbolized diagram)
|
---|
30 | 00000000 : XX XX YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................
|
---|
31 | 00000001 : YY YY YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................
|
---|
32 | 00000002 : YY YY YY YY YY YY EE EE-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
---|
33 | 00000003 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
---|
34 |
|
---|
35 | The XXXX(short) field has the "number of images" in it, afterwards an array
|
---|
36 | of "image offsets" is following. The "number of images" field has 2byte. The
|
---|
37 | offsels after the "number of images" field take 4byte each. There are
|
---|
38 | "number of images" + one EOF (2byte) field. In example 1. the XXXX contains
|
---|
39 | 0x0900(hex). So you have (9x 4byte + 2byte EOF) of offsetfields.
|
---|
40 | (Symboliced with 36x YY fields, and 2x EE EOF fileds)
|
---|
41 |
|
---|
42 | EXCEPTION:
|
---|
43 | ----------
|
---|
44 | There are shpfiles which don't follow this stricktly rule. If the "number of
|
---|
45 | images" field has exactly 1 image in it, it may be that there is no 4byte long
|
---|
46 | offsetfield aftwerwards, it's only 2byte (not 4byte!). If this is the case
|
---|
47 | there is only a 2byte Offsetfield and a 2byte EOF field afterwards.
|
---|
48 | But it depends, sometimes files with 1 image inside don't have this exception.
|
---|
49 | You have to check this or you get in trouble. (see example 2.)
|
---|
50 |
|
---|
51 | *** File: ../data/pak/finale/credit43.shp
|
---|
52 | 00000000 : 01 00 08 00 00 00 E8 1B-00 00 00 00 6E B6 00 6E : ................
|
---|
53 | 00000001 : E0 1B 80 4D 83 9A 9A 99-C9 01 00 81 99 20 04 EA : ................
|
---|
54 | exampe 2
|
---|
55 |
|
---|
56 | 00000000 : XX XX YY YY EE EE QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
---|
57 | 00000001 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
---|
58 |
|
---|
59 | In this example there is only 1 image inside (2byte "XX XX") for the
|
---|
60 | "number of images" field and followed by a (2byte "YY YY") offsetfield.
|
---|
61 | And the (2byte "EE EE") EndOfFile field.
|
---|
62 | Afterwards the QQ fields (imagedata) follows.
|
---|
63 |
|
---|
64 | ============
|
---|
65 | BODY
|
---|
66 | ============
|
---|
67 |
|
---|
68 | How to find the real start of a internal image in a shpfile?
|
---|
69 |
|
---|
70 | The body of a shpfile starts at the first "image offset" symbolized with
|
---|
71 | "YY YY YY YY" (see ex. 1) in this case it would be at byte "28" and ends
|
---|
72 | at byte "34-1". The END- and START-offsets of a image stored in a shpfile is
|
---|
73 | calculated with the [StartOffset of the following image] - 1(byte).
|
---|
74 | The "EE EE" (EndOfFile) field has the END-offset of the last image in the
|
---|
75 | shpfile.
|
---|
76 | But becareful with this start- and endoffsets because a image inside the
|
---|
77 | shpfile doesn't start at the startoffset nor does it end at a endoffset.
|
---|
78 | The images starts at [startoffset+2byte] and it ends at [endoffset + 2].
|
---|
79 | As you can see both offsets need to be moved 2byte on.
|
---|
80 |
|
---|
81 | Let's have a deeper look into this BODY:
|
---|
82 |
|
---|
83 | *** File: deathhand.shp
|
---|
84 | 00000000 : 07 00 20 00 00 00 85 00-00 00 DB 00 00 00 1F 01 : ................
|
---|
85 | 00000001 : 00 00 77 01 00 00 B9 01-00 00 0D 02 00 00 57 02 : ................
|
---|
86 | 00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................
|
---|
87 | 00000003 : 0C 0C 00 0E 0C EA 0C 00-0D 0C B8 00 06 83 0C 0C : ................
|
---|
88 | 00000004 : E8 10 07 81 0B 00 07 10-08 81 0A 10 08 10 09 81 : ................
|
---|
89 | 00000005 : 09 20 09 10 0A 81 08 30-0A 10 0B 87 07 0C 0C 0C : ................
|
---|
90 | 00000006 : EC E8 E8 00 06 8F 00 07-00 03 0C E9 E8 EC 00 09 : ................
|
---|
91 | 00000007 : 00 04 EC E8 E9 00 26 82-00 04 00 28 30 08 10 20 : ................
|
---|
92 | 00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................
|
---|
93 | exampe 3
|
---|
94 |
|
---|
95 | As you can see this shpfile stores 7 graphics. And the first image is at 0x20.
|
---|
96 |
|
---|
97 | 00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................
|
---|
98 | 00000002 : RR RR TT NN Y_ X_ NN Y_ SS SS CK CK QQ QQ QQ QQ : ................
|
---|
99 |
|
---|
100 | RR : belongs always to the last image's end. in this case it's the first image
|
---|
101 | in the shpfile so there can't be a EOF of a previous image.
|
---|
102 |
|
---|
103 | NN : simply nothing, or maybe i don't know but dune2 doesn't make use of it.
|
---|
104 | TT : it's a type field, there are 4 different types:
|
---|
105 | 0000: Start with format80 command || Always end with 0x80 command
|
---|
106 | 0001: Always start with "0" || Always end with 0x80 command
|
---|
107 | 0002: ?? || ??
|
---|
108 | 0003: can start with 0,1,2,3,4,6 || Always end with "0"
|
---|
109 | Y_ : it's the y dimension of the image [hight]
|
---|
110 | as you can see this field is there twice but i didn't find a reason why?
|
---|
111 | both fields always match, i tested it with all shpimages from DUNE II
|
---|
112 | X_ : it's the x dimension of the image [width]
|
---|
113 | SS : (read as unsigned short)
|
---|
114 | it's the size of the first image of this shp file + 10 so if you want to
|
---|
115 | have the real size of the image it's "0x0065-a" in hex or
|
---|
116 | "101-10=91" in dec.
|
---|
117 | CK : (read as unsigned short)
|
---|
118 | it's the ckecksum of the image, if you add all counts while decode80
|
---|
119 | together you get this value.
|
---|
120 | QQ : again, it's the imagedata
|
---|
121 |
|
---|
122 | 00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................
|
---|
123 | 00000008 : QQ QQ QQ QQ QQ QQ QQ NN NN NN NN NN NN NN NN NN : ................
|
---|
124 |
|
---|
125 | QQ : imagedata
|
---|
126 | NN : noting -> next image
|
---|
127 |
|
---|
128 | So here we can see that this image usually ends with 0x80, that's because it's
|
---|
129 | format80 and 0x80 means command 1 with count=0 so EOF is reached ;-)
|
---|
130 | But see format80 specification for further informations.
|
---|
131 |
|
---|
132 | ============
|
---|
133 | CREDITS
|
---|
134 | ============
|
---|
135 |
|
---|
136 | I wish to thank especially Valadan Bato because of his work on CNC
|
---|
137 | -Vladan Bato (bat22@geocities.com)
|
---|
138 |
|
---|
139 | And also thanks to the following people :
|
---|
140 |
|
---|
141 | -Andrew Griffin (buggy@adam.com.au)
|
---|
142 | -Aaron Glover (arn@ibm.net)
|
---|
143 | Denis Moeller (d.moeller@rendsburg.netsurf.de) for their work on .SHP files.
|
---|