Menu
▾
▴
dunelegacy-commit
|
From: <otp...@us...> - 2006-07-31 17:59:30
|
Revision: 65 Author: otpetrik Date: 2006-07-31 10:59:21 -0700 (Mon, 31 Jul 2006) ViewCVS: http://svn.sourceforge.net/dunelegacy/?rev=65&view=rev Log Message: ----------- fixed pakfile/Shpfile palette handling. Modified Paths: -------------- branches/dunks/include/pakfile/Shpfile.h branches/dunks/include/pakfile/Wsafile.h branches/dunks/src/pakfile/Shpfile.cpp Modified: branches/dunks/include/pakfile/Shpfile.h =================================================================== --- branches/dunks/include/pakfile/Shpfile.h 2006-07-31 16:28:25 UTC (rev 64) +++ branches/dunks/include/pakfile/Shpfile.h 2006-07-31 17:59:21 UTC (rev 65) @@ -16,7 +16,7 @@ Shpfile(unsigned char * bufFiledata, int bufsize); ~Shpfile(); - SDL_Surface* getPicture(Uint32 IndexOfFile); + SDL_Surface* getPicture(Uint32 IndexOfFile, SDL_Palette *palette); inline int getNumFiles() {return (int) NumFiles;}; Modified: branches/dunks/include/pakfile/Wsafile.h =================================================================== --- branches/dunks/include/pakfile/Wsafile.h 2006-07-31 16:28:25 UTC (rev 64) +++ branches/dunks/include/pakfile/Wsafile.h 2006-07-31 17:59:21 UTC (rev 65) @@ -12,7 +12,7 @@ Wsafile(unsigned char * bufFiledata, int bufsize); ~Wsafile(); - SDL_Surface * getPicture(Uint32 FrameNumber, SDL_Palette* pal); + SDL_Surface * getPicture(Uint32 FrameNumber, SDL_Palette *palette); inline int getNumFrames() { return (int) NumFrames; }; inline Uint32 getFramesPer1024ms() { return FramesPer1024ms; }; Modified: branches/dunks/src/pakfile/Shpfile.cpp =================================================================== --- branches/dunks/src/pakfile/Shpfile.cpp 2006-07-31 16:28:25 UTC (rev 64) +++ branches/dunks/src/pakfile/Shpfile.cpp 2006-07-31 17:59:21 UTC (rev 65) @@ -21,7 +21,7 @@ } }; -SDL_Surface *Shpfile::getPicture(Uint32 IndexOfFile) +SDL_Surface *Shpfile::getPicture(Uint32 IndexOfFile, SDL_Palette *palette) { SDL_Surface *pic = NULL; unsigned char *DecodeDestination = NULL; @@ -115,7 +115,7 @@ return NULL; } - //SDL_SetColors(pic, palette->colors, 0, palette->ncolors); + SDL_SetColors(pic, palette->colors, 0, palette->ncolors); SDL_LockSurface(pic); //Now we can copy line by line This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
|
From: <otp...@us...> - 2006-08-01 18:31:30
|
Revision: 71 Author: otpetrik Date: 2006-08-01 11:31:20 -0700 (Tue, 01 Aug 2006) ViewCVS: http://svn.sourceforge.net/dunelegacy/?rev=71&view=rev Log Message: ----------- fixed pakfile/Icnfile palette handling. Modified Paths: -------------- branches/dunks/include/pakfile/Icnfile.h branches/dunks/src/pakfile/Icnfile.cpp Modified: branches/dunks/include/pakfile/Icnfile.h =================================================================== --- branches/dunks/include/pakfile/Icnfile.h 2006-08-01 18:18:33 UTC (rev 70) +++ branches/dunks/include/pakfile/Icnfile.h 2006-08-01 18:31:20 UTC (rev 71) @@ -10,7 +10,7 @@ ~Icnfile(); - SDL_Surface * getPicture(Uint32 IndexOfFile); + SDL_Surface * getPicture(Uint32 IndexOfFile, SDL_Palette *palette); int getNumFiles(); Modified: branches/dunks/src/pakfile/Icnfile.cpp =================================================================== --- branches/dunks/src/pakfile/Icnfile.cpp 2006-08-01 18:18:33 UTC (rev 70) +++ branches/dunks/src/pakfile/Icnfile.cpp 2006-08-01 18:31:20 UTC (rev 71) @@ -98,7 +98,7 @@ ; }; -SDL_Surface* Icnfile::getPicture(Uint32 IndexOfFile) { +SDL_Surface* Icnfile::getPicture(Uint32 IndexOfFile, SDL_Palette *palette) { SDL_Surface * pic; if(IndexOfFile >= NumFiles) { @@ -119,7 +119,7 @@ return NULL; } - //SDL_SetColors(pic, palette->colors, 0, palette->ncolors); + SDL_SetColors(pic, palette->colors, 0, palette->ncolors); SDL_LockSurface(pic); //Now we can copy to surface This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
|
From: <dv...@us...> - 2008-04-24 16:47:00
|
Revision: 154
http://dunelegacy.svn.sourceforge.net/dunelegacy/?rev=154&view=rev
Author: dvalin
Date: 2008-04-24 09:46:49 -0700 (Thu, 24 Apr 2008)
Log Message:
-----------
add docs describing some of the data formats..
Added Paths:
-----------
branches/dunks/src/pakfile/cnc_specs.txt
branches/dunks/src/pakfile/duneii_shp_specs.txt
branches/dunks/src/pakfile/duneii_specs.txt
Added: branches/dunks/src/pakfile/cnc_specs.txt
===================================================================
--- branches/dunks/src/pakfile/cnc_specs.txt (rev 0)
+++ branches/dunks/src/pakfile/cnc_specs.txt 2008-04-24 16:46:49 UTC (rev 154)
@@ -0,0 +1,623 @@
+
+ COMMAND & CONQUER FILE FORMATS
+
+Revision 4
+
+by Vladan Bato (ba...@ge...)
+
+This document explains the file formats used by Command & Conquer.
+
+Command & Conquer is a tradmark of Westwood Studios, Inc.
+Command & Conquer is Copyright (C)1995 Westwood Studios, Inc.
+
+The information provided here is meant for programmers that want to make
+editor and utilites for Command & Conquer. My explanation might not be
+the best one, but it should be enough.
+
+I can't guarantee that the information in here is correct. If you find any
+errors, please report them to me.
+
+In this document I'll use Pascal notation, and any code samples will be in
+Pascal....
+I wanted to rewrite them in C, but I don't have the time to test the code.
+So, to avoid any risks, I'll use the code from Mix Manager.
+
+In case you don't know, the information contained here has been used to
+make the program Mix Manager, which contains a lot of conversion utilities
+for the various formats. For more info, check my homepage (see the end of the
+document).
+
+===================
+ 1. THE .MIX FILES
+===================
+
+You probably already know the format of these files, but I will add a
+description here for completeness.
+
+The MIX file consists of two parts :
+-A header including the index of all the files contained within
+-A body containing all the files
+
+It's format is :
+
+ Header : record
+ NumFiles : word; {Number of files in MIX}
+ DataSize : longint; {Size of body}
+ Index : array [1..NumFiles] of
+ record
+ ID : longint; {File ID}
+ Start : longint; {Offset of file from the start of the body}
+ Size : longint; {file size}
+ end;
+ end;
+
+The ID field is computed from the original filename, which is not stored in
+the MIX.
+The records are always sorted by the ID field (the numbers are signed
+longints).
+Note that the offsets are relative to the start of the body so to find the
+actual offset in the MIX you have to add the size of the header which is
+NumFiles*12+6
+
+===================
+ 2. THE .PAL FILES
+===================
+
+The most easiest files....
+These files contain the palette in the same format used by VGA cards.
+
+ Palette : array [0..255] of record
+ red,green,blue:byte;
+ end;
+
+Note that only the first 6 bits of each number are used, giving a total of
+262144 possible colors (as opposed to the 8 bits used by .PCX files for
+example).
+
+=================================
+ 3. THE TEMPLATE AND .BIN FILES
+=================================
+
+The Template files contain the map graphics, and can be found in the
+theater specific MIX files (TEMPERAT.MIX, WINTER.MIX, DESERT.MIX).
+The .BIN files contain the maps for the missions and are used in conjunction
+with the .INI files.
+
+I won't explain them here. They are explained with great detail in the
+document titled "Command & Conquer maps" I wrote some time ago.
+The said document can be found on my homepage.
+
+===================
+ 5. THE .SHP FILES
+===================
+
+The .SHP files contain almost all the graphics : units, structures, trees,...
+The header has the following structure :
+
+ Header : record
+ NumImages : word; {Number of images}
+ A,B : word; {Unknown}
+ Width,
+ Height : word; {Width and Height of the images}
+ C : longint; {Unknown}
+ end;
+
+If you know something about those unknown fields, please e-mail me.
+Following that there's an array of records, one for each image :
+
+ Offsets : array [0..NumImages+1] of
+ record
+ Offset : longint; {Offset and format of image in file}
+ RefOffs : longint; {Offset and format of image on
+ which it is based}
+ end;
+
+The most significant byte (last) of the Offset and RefOffs fields
+contains the format, while the lower three are used for the offset.
+The format byte can have one of the three values : 80h, 40h, 20h.
+I will call the three image formats Format80, Format40 and Format20.
+
+The Format80 images are compressed with a compression method I'll explain
+later.
+
+The Format40 images must be xor-ed with a Format80 image. That's what the
+RefOffs field is used for. It tells which Format80 image they are
+based upon. The Format40 will be explained in detail later.
+
+The Format20 images use the same format as the Format40, the difference is
+that they are xor-ed with the image that precedes them in the file. That can
+be either in Format20 or in Format40.
+The offset part of the RefOffs field contains the number of the first
+Format40 image in the chain, and the format field is always 48h.
+
+Here's an example :
+
+0) Off0(three bytes) 80h 000000h 00h
+1) Off1(three bytes) 80h 000000h 00h
+2) Off2(three bytes) 40h Off1 80h
+3) Off3(three bytes) 80h 000000h 00h
+4) Off4(three bytes) 40h Off1 80h
+5) Off5(three bytes) 20h 000400h 48h
+6) Off6(three bytes) 20h 000400h 48h
+7) Off7(three bytes) 40h Off3 80h
+
+For example to draw image 7, you have to draw the image 3 first (whose offset
+and format are given) and then xor image 7 over it.
+
+To draw image 6, you have to xor it over the previous image, i.e. 5, which
+is format20 again, that means that it has to be xor-ed over image 4, which
+is in format40, i.e. it must be xor-ed over the image in format80 it has a
+reference to. In this case it's image 1. Thus the chain is 1,4,5,6.
+This is one way to see it, the other could be :
+Image 6 is in Format20, the RefOffs field contains the number of the first
+Format40 image in the chain, in this case image 4. To draw Image 4, the
+Image 1 has to be drawn first, next is image 4, and then all the images
+from the 4th to the 6th have to be xor-ed over the previous.
+
+I made some experiments and found out that you don't have to use the
+Format40 and Format20 images. I tried converting all of them into Format80
+and it worked.
+
+Also, when changing graphics, note that all the unit and structure graphics
+should be drawn using the GDI colors, which will be automatically converted
+for the other sides.
+The palette you should use is one of those found in DESERT.MIX, WINTER.MIX
+and TEMPERAT.MIX. The GDI colors are colors 0B0h-0BFh. The other colors
+won't be converted and will remain the same for all the sides (be sure to
+use only the colors that are the same all three palettes).
+
+The above applies only to the graphics that appear in all three theaters
+(the .SHP file found in CONQUER.MIX). The graphics for the structures and
+overlays that appear in a single theater (found inside the theater specific
+MIX) can use the palette entries that are unique for that theater (and will
+be shown with garbled colors in the others).
+
+Also a special color is used for shadows. It's color 04h. In the palettes
+it's bright green, but C&C puts a shadow instead of it. I don't know how
+the shadows are calculated however.
+
+You should've noticed that the array has NumImages+2 elements when only
+NumImages elements are needed. The last one contains zeros, and the one before
+that points to the end of the file. These two can be used to identify the file
+as a .SHP.
+
+Here's the description of the compression formats : Format80 and Format40.
+
+----------
+ Format80
+----------
+
+There are several different commands, with different sizes : form 1 to 5
+bytes.
+The positions mentioned below always refer to the destination buffer (i.e.
+the uncompressed image). The relative positions are relative to the current
+position in the destination buffer, which is one byte beyond the last written
+byte.
+
+I will give some sample code at the end.
+
+QKniGhT: struct foo_t { long offset; /* Offset and format of image in file */ long ref_offs; /* Offset and format of image on which it is based */ } Offsets[NumImages+2];
+
+(1) 1 byte
+ +---+---+---+---+---+---+---+---+
+ | 1 | 0 | | | | | | |
+ +---+---+---+---+---+---+---+---+
+ \_______________________/
+ |
+ Count
+
+ This one means : copy next Count bytes as is from Source to Dest.
+
+(2) 2 bytes
+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
+ | 0 | | | | | | | | | | | | | | | | |
+ +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
+ \___________/\__________________________________________________/
+ | |
+ Count-3 Relative Pos.
+
+ This means copy Count bytes from Dest at Current Pos.-Rel. Pos. to
+ Current position.
+ Note that you have to add 3 to the number you find in the bits 4-6 of the
+ first byte
+o obtain the Count.
+ Note that if the Rel. Pos. is 1, that means repeat Count times the previous
+ byte.
+
+(3) 3 bytes
+ +---+---+---+---+---+---+---+---+ +---------------+---------------+
+ | 1 | 1 | | | | | | | | | |
+ +---+---+---+---+---+---+---+---+ +---------------+---------------+
+ \_______________________/ Pos
+ |
+ Count-3
+
+ Copy Count bytes from Pos, where Pos is absolute from the start of the
+ destination buffer. (Pos is a word, that means that the images can't be
+ larger than 64K)
+
+(4) 4 bytes
+ +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
+ | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | | | | | |
+ +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+
+ Count Color
+
+ Write Color Count times.
+ (Count is a word, color is a byte)
+
+(5) 5 bytes
+ +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
+ | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | | | | | |
+ +---+---+---+---+---+---+---+---+ +-------+-------+ +-------+-------+
+ Count Pos
+
+ Copy Count bytes from Dest. starting at Pos. Pos is absolute from the start
+ of the Destination buffer.
+ Both Count and Pos are words.
+
+These are all the commands I found out. Maybe there are other ones, but I
+haven't seen them yet.
+
+All the images end with a 80h command.
+
+To make things more clearer here's a piece of code that will uncompress the
+image.
+
+ DP = destination pointer
+ SP = source pointer
+ Source and Dest are the two buffers
+
+
+ SP:=0;
+ DP:=0;
+ repeat
+ Com:=Source[SP];
+ inc(SP);
+ b7:=Com shr 7; {b7 is bit 7 of Com}
+#in c b7= com >> 7; /* b7 is bit 7 of Com */
+ case b7 of
+ 0 : begin {copy command (2)}
+ {Count is bits 4-6 + 3}
+ Count:=(Com and $7F) shr 4 + 3;
+#in c count = (com && ???) >> 4 + 3;
+ {Position is bits 0-3, with bits 0-7 of next byte}
+ Posit:=(Com and $0F) shl 8+Source[SP];
+ Inc(SP);
+ {Starting pos=Cur pos. - calculated value}
+ Posit:=DP-Posit;
+ for i:=Posit to Posit+Count-1 do
+ begin
+ Dest[DP]:=Dest[i];
+ Inc(DP);
+ end;
+ end;
+ 1 : begin
+ {Check bit 6 of Com}
+ b6:=(Com and $40) shr 6;
+ case b6 of
+ 0 : begin {Copy as is command (1)}
+ Count:=Com and $3F; {mask 2 topmost bits}
+ if Count=0 then break; {EOF marker}
+ for i:=1 to Count do
+ begin
+ Dest[DP]:=Source[SP];
+ Inc(DP);
+ Inc(SP);
+ end;
+ end;
+ 1 : begin {large copy, very large copy and fill commands}
+ {Count = (bits 0-5 of Com) +3}
+ {if Com=FEh then fill, if Com=FFh then very large copy}
+ Count:=Com and $3F;
+ if Count<$3E then {large copy (3)}
+ begin
+ Inc(Count,3);
+ {Next word = pos. from start of image}
+ Posit:=Word(Source[SP]);
+ Inc(SP,2);
+ for i:=Posit to Posit+Count-1 do
+ begin
+ Dest[DP]:=Dest[i];
+ Inc(DP);
+ end;
+ end
+ else if Count=$3F then {very large copy (5)}
+ begin
+ {next 2 words are Count and Pos}
+ Count:=Word(Source[SP]);
+ Posit:=Word(Source[SP+2]);
+ Inc(SP,4);
+ for i:=Posit to Posit+Count-1 do
+ begin
+ Dest[DP]:=Dest[i];
+ Inc(DP);
+ end;
+ end else
+ begin {Count=$3E, fill (4)}
+ {Next word is count, the byte after is color}
+ Count:=Word(Source[SP]);
+ Inc(SP,2);
+ b:=Source[SP];
+ Inc(SP);
+ for i:=0 to Count-1 do
+ begin
+ Dest[DP]:=b;
+ inc(DP);
+ end;
+ end;
+ end;
+ end;
+ end;
+ end;
+ until false;
+
+Note that you won't be able to compile this code, because the typecasting
+won't work. (But I'm sure you'll be able to fix it).
+
+
+----------
+ Format40
+----------
+
+As I said before the images in Format40 must be xor-ed over a previous image,
+or against a black screen (as in the .WSA format).
+It is used when there are only minor changes between an image and a following
+one.
+
+Here I'll assume that the old image is in Dest, and that the Dest pointer is
+set to the beginning of that buffer.
+
+As for the Format80, there are many commands :
+
+
+(1) 1 byte
+ byte
+ +---+---+---+---+---+---+---+---+
+ | 1 | | | | | | | |
+ +---+---+---+---+---+---+---+---+
+ \___________________________/
+ |
+ Count
+
+ Skip count bytes in Dest (move the pointer forward).
+
+(2) 3 bytes
+ byte word
+ +---+---+---+---+---+---+---+---+ +---+-----+-------+
+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 0 | ... | |
+ +---+---+---+---+---+---+---+---+ +---+-----+-------+
+ \_____________/
+ |
+ Count
+
+ Skip count bytes.
+
+(3) 3 bytes
+ byte word
+ +---+---+---+---+---+---+---+---+ +---+---+-----+-------+
+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | 0 | ... | |
+ +---+---+---+---+---+---+---+---+ +---+---+-----+-------+
+ \_____________/
+ |
+ Count
+
+ Xor next count bytes. That means xor count bytes from Source with bytes
+ in Dest.
+
+(4) 4 bytes
+ byte word byte
+ +---+---+---+---+---+---+---+---+ +---+---+-----+-------+ +-------+
+ | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | 1 | ... | | | |
+ +---+---+---+---+---+---+---+---+ +---+---+-----+-------+ +-------+
+ \_____________/ value
+ |
+ Count
+
+ Xor next count bytes in Dest with value.
+
+5) 1 byte
+ byte
+ +---+---+---+---+---+---+---+---+
+ | 0 | | | | | | | |
+ +---+---+---+---+---+---+---+---+
+ \___________________________/
+ |
+ Count
+
+ Xor next count bytes from source with dest.
+
+6) 3 bytes
+ byte byte byte
+ +---+---+---+---+---+---+---+---+ +-------+ +-------+
+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | |
+ +---+---+---+---+---+---+---+---+ +-------+ +-------+
+ Count Value
+
+ Xor next count bytes with value.
+
+
+All images end with a 80h 00h 00h command.
+
+I think these are all the commands, but there might be some other.
+If you find anything new, please e-mail me.
+
+As before here's some code :
+
+ DP = destination pointer
+ SP = source pointer
+ Source is buffer containing the Format40 data
+ Dest is the buffer containing the image over which the second has
+ to be xor-ed
+
+
+ SP:=0;
+ DP:=0;
+ repeat
+ Com:=Source[SP];
+ Inc(SP);
+
+ if (Com and $80)<>0 then {if bit 7 set}
+ begin
+ if Com<>$80 then {small skip command (1)}
+ begin
+ Count:=Com and $7F;
+ Inc(DP,Count);
+ end
+ else {Big commands}
+ begin
+ Count:=Word(Source[SP]);
+ if Count=0 then break;
+ Inc(SP,2);
+
+ Tc:=(Count and $C000) shr 14; {Tc=two topmost bits of count}
+
+ case Tc of
+ 0,1 : begin {Big skip (2)}
+ Inc(DP,Count);
+ end;
+ 2 : begin {big xor (3)}
+ Count:=Count and $3FFF;
+ for i:=1 to Count do
+ begin
+ Dest[DP]:=Dest[DP] xor Source[SP];
+ Inc(DP);
+ Inc(SP);
+ end;
+ end;
+ 3 : begin {big repeated xor (4)}
+ Count:=Count and $3FFF;
+ b:=Source[SP];
+ Inc(SP);
+ for i:=1 to Count do
+ begin
+ Dest[DP]:=Dest[DP] xor b;
+ Inc(DP);
+ end;
+ end;
+ end;
+ end;
+ end else {xor command}
+ begin
+ Count:=Com;
+ if Count=0 then
+ begin {repeated xor (6)}
+ Count:=Source[SP];
+ Inc(SP);
+ b:=Source[SP];
+ Inc(SP);
+ for i:=1 to Count do
+ begin
+ Dest[DP]:=Dest[DP] xor b;
+ Inc(DP);
+ end;
+ end else {copy xor (5)}
+ for i:=1 to Count do
+ begin
+ Dest[DP]:=Dest[DP] xor Source[SP];
+ Inc(DP);
+ Inc(SP);
+ end;
+ end;
+ until false;
+
+
+
+===================
+ 6. THE .CPS FILES
+===================
+
+The .CPS files contain 320x200x256 images. The images are compressed with the
+Format80 compression method. They may or may not contain a palette.
+
+The header has the following structure :
+
+ Header : record
+ Size : word; {File size - 2}
+ Unknown : word; {Always 0004h}
+ ImSize : word; {Size of uncompressed image (always FA00h)}
+ Palette : longint; {Is there a palette ?}
+ end;
+
+If Palette is 03000000h then there's a palette after the header, otherwise
+the image follows.
+CPS file without palette can be found in the SETUP.MIX file, and they all use
+the Palette that can be found inside the same .MIX.
+
+The image that follows the palette (or the Header) is in Format80 which is
+explained above.
+
+===================
+ 7. THE .WSA FILES
+===================
+
+
+WSA files contain short animations and can be found in the GENERAL.MIX files.
+They are basically a series of Format40 images, that are then compressed with
+Format80.
+
+The header is :
+
+ Header : record
+ NumFrames : word; {Number of frames}
+ X,Y : word; {Position on screen of the upper left corner}
+ W,H : word; {Width and height of the images}
+ Delta : longint; {Frames/Sec = Delta/(2^10)}
+ end;
+
+Following that there's an array of offsets :
+
+ Offsets : array [0..NumFrames+1] of longint;
+
+The obtain the actual offset, you have to add 300h. That is the size of the
+palette that follows the Offsets array.
+As for .SHP files the two last offsets have a special meaning.
+If the last offset is 0 then the one before it points to the end of file
+(after you added 300h of course).
+If the last one is <>0 then it points to the end of the file, and the
+one before it points to a special frame that gives you the difference between
+the last and the first frame. This is used when you have to loop the
+animation.
+
+As I said before, the images are in Format40 but are then compressed with
+Format80. That means that you first have to uncompress the Format80 and then
+decode the Format40 image you obtain.
+The first frame should be xor-ed over a black image (filled with zeros), all
+the other are xor-ed over the previous one.
+
+There is a variant of the file without the palette that can be found in
+SETUP.MIX but I wasn't able to decode it (maybe there are some commands I
+don't know about)...
+
+=====================
+ 8. ADDITIONAL NOTES
+=====================
+
+The VQA files (that contain movies) have been decoded by Aaron Glover
+(ar...@ib...), and are explained in a document he wrote up.
+You can find the document on my homepage (or ask him directly).
+
+What is still missing are the .AUD files.
+It seems that the AUD files use some kind of lossy sound compression,
+which means that it is almost impossible to decode them.
+However if someone manages to work them out, I'd really appreciate some
+info.
+
+I know my explanations are not very good, but you'll have to bear them,
+unless someone else wants to rewrite this.
+
+============
+ 9. CREDITS
+============
+
+I wish to thank the following people :
+
+-Andrew Griffin (bu...@ad...) for starting it all.
+-Aaron Glover (ar...@ib...) and
+ Denis Moeller (d.m...@re...) for their work on .SHP files.
+-Aaron Glover for decoding the VQA files.
+-Carl Kenner (and...@un...) for the info on .CPS files.
+
+
+Vladan Bato (ba...@ge...)
+http://www.geocities.com/SiliconValley/8682
+
Property changes on: branches/dunks/src/pakfile/cnc_specs.txt
___________________________________________________________________
Name: svn:eol-style
+ native
Added: branches/dunks/src/pakfile/duneii_shp_specs.txt
===================================================================
--- branches/dunks/src/pakfile/duneii_shp_specs.txt (rev 0)
+++ branches/dunks/src/pakfile/duneii_shp_specs.txt 2008-04-24 16:46:49 UTC (rev 154)
@@ -0,0 +1,143 @@
+ SHP file specifications for DUNE2 game (c) by WESTWOOD and VIRIN
+ ==================================================================
+ (c) by Joachim Schiele <js...@du...>
+REVISION 1
+
+What are SHP files btw?
+=======================
+SHP is a method of saving multible graphics in one file and also be able
+to have some kind of compression. In this case "DUNE II" it's format80
+compression mode. The "DUNE II" code is a little bit different from the one
+of "Command and Conqueror" hacked by Vladan Bato. Major parts of this
+informations are from him and only needed some little modifications to be
+compatible with the ones of "DUNE II". But in case you want to work with
+this format i think it's better if it's function is documented.
+Explanations and example codes are in "c", see sandtools how to code a
+extractor/converter for shpfiles.
+
+============
+ HEAD
+============
+
+*** File: ../data/pak/dune/arrow.shp (hextype output)
+00000000 : 09 00 28 00 00 00 34 00-00 00 B3 00 00 00 36 01 : ................
+00000001 : 00 00 A7 01 00 00 17 02-00 00 A0 02 00 00 21 03 : ................
+00000002 : 00 00 B3 03 00 00 0A 04-00 00 02 00 01 01 00 01 : ................
+00000003 : 0C 00 02 00 00 01 00 00-10 10 00 10 7F 00 B8 00 : ................
+ exampe 1
+
+(symbolized diagram)
+00000000 : XX XX YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................
+00000001 : YY YY YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................
+00000002 : YY YY YY YY YY YY EE EE-QQ QQ QQ QQ QQ QQ QQ QQ : ................
+00000003 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
+
+The XXXX(short) field has the "number of images" in it, afterwards an array
+of "image offsets" is following. The "number of images" field has 2byte. The
+offsels after the "number of images" field take 4byte each. There are
+"number of images" + one EOF (2byte) field. In example 1. the XXXX contains
+0x0900(hex). So you have (9x 4byte + 2byte EOF) of offsetfields.
+(Symboliced with 36x YY fields, and 2x EE EOF fileds)
+
+EXCEPTION:
+----------
+There are shpfiles which don't follow this stricktly rule. If the "number of
+images" field has exactly 1 image in it, it may be that there is no 4byte long
+offsetfield aftwerwards, it's only 2byte (not 4byte!). If this is the case
+there is only a 2byte Offsetfield and a 2byte EOF field afterwards.
+But it depends, sometimes files with 1 image inside don't have this exception.
+You have to check this or you get in trouble. (see example 2.)
+
+*** File: ../data/pak/finale/credit43.shp
+00000000 : 01 00 08 00 00 00 E8 1B-00 00 00 00 6E B6 00 6E : ................
+00000001 : E0 1B 80 4D 83 9A 9A 99-C9 01 00 81 99 20 04 EA : ................
+ exampe 2
+
+00000000 : XX XX YY YY EE EE QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
+00000001 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
+
+In this example there is only 1 image inside (2byte "XX XX") for the
+"number of images" field and followed by a (2byte "YY YY") offsetfield.
+And the (2byte "EE EE") EndOfFile field.
+Afterwards the QQ fields (imagedata) follows.
+
+============
+ BODY
+============
+
+How to find the real start of a internal image in a shpfile?
+
+The body of a shpfile starts at the first "image offset" symbolized with
+"YY YY YY YY" (see ex. 1) in this case it would be at byte "28" and ends
+at byte "34-1". The END- and START-offsets of a image stored in a shpfile is
+calculated with the [StartOffset of the following image] - 1(byte).
+The "EE EE" (EndOfFile) field has the END-offset of the last image in the
+shpfile.
+But becareful with this start- and endoffsets because a image inside the
+shpfile doesn't start at the startoffset nor does it end at a endoffset.
+The images starts at [startoffset+2byte] and it ends at [endoffset + 2].
+As you can see both offsets need to be moved 2byte on.
+
+Let's have a deeper look into this BODY:
+
+*** File: deathhand.shp
+00000000 : 07 00 20 00 00 00 85 00-00 00 DB 00 00 00 1F 01 : ................
+00000001 : 00 00 77 01 00 00 B9 01-00 00 0D 02 00 00 57 02 : ................
+00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................
+00000003 : 0C 0C 00 0E 0C EA 0C 00-0D 0C B8 00 06 83 0C 0C : ................
+00000004 : E8 10 07 81 0B 00 07 10-08 81 0A 10 08 10 09 81 : ................
+00000005 : 09 20 09 10 0A 81 08 30-0A 10 0B 87 07 0C 0C 0C : ................
+00000006 : EC E8 E8 00 06 8F 00 07-00 03 0C E9 E8 EC 00 09 : ................
+00000007 : 00 04 EC E8 E9 00 26 82-00 04 00 28 30 08 10 20 : ................
+00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................
+ exampe 3
+
+As you can see this shpfile stores 7 graphics. And the first image is at 0x20.
+
+00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................
+00000002 : RR RR TT NN Y_ X_ NN Y_ SS SS CK CK QQ QQ QQ QQ : ................
+
+RR : belongs always to the last image's end. in this case it's the first image
+ in the shpfile so there can't be a EOF of a previous image.
+
+NN : simply nothing, or maybe i don't know but dune2 doesn't make use of it.
+TT : it's a type field, there are 4 different types:
+ 0000: Start with format80 command || Always end with 0x80 command
+ 0001: Always start with "0" || Always end with 0x80 command
+ 0002: ?? || ??
+ 0003: can start with 0,1,2,3,4,6 || Always end with "0"
+Y_ : it's the y dimension of the image [hight]
+ as you can see this field is there twice but i didn't find a reason why?
+ both fields always match, i tested it with all shpimages from DUNE II
+X_ : it's the x dimension of the image [width]
+SS : (read as unsigned short)
+ it's the size of the first image of this shp file + 10 so if you want to
+ have the real size of the image it's "0x0065-a" in hex or
+ "101-10=91" in dec.
+CK : (read as unsigned short)
+ it's the ckecksum of the image, if you add all counts while decode80
+ together you get this value.
+QQ : again, it's the imagedata
+
+00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................
+00000008 : QQ QQ QQ QQ QQ QQ QQ NN NN NN NN NN NN NN NN NN : ................
+
+QQ : imagedata
+NN : noting -> next image
+
+So here we can see that this image usually ends with 0x80, that's because it's
+format80 and 0x80 means command 1 with count=0 so EOF is reached ;-)
+But see format80 specification for further informations.
+
+============
+ CREDITS
+============
+
+I wish to thank especially Valadan Bato because of his work on CNC
+-Vladan Bato (ba...@ge...)
+
+And also thanks to the following people :
+
+-Andrew Griffin (bu...@ad...)
+-Aaron Glover (ar...@ib...)
+ Denis Moeller (d.m...@re...) for their work on .SHP files.
Property changes on: branches/dunks/src/pakfile/duneii_shp_specs.txt
___________________________________________________________________
Name: svn:eol-style
+ native
Added: branches/dunks/src/pakfile/duneii_specs.txt
===================================================================
--- branches/dunks/src/pakfile/duneii_specs.txt (rev 0)
+++ branches/dunks/src/pakfile/duneii_specs.txt 2008-04-24 16:46:49 UTC (rev 154)
@@ -0,0 +1,117 @@
+=================================
+ DUNEII FILE SPECIFICATIONS
+=================================
+
+Started:
+14.01.2001 22:37:32
+
+by Joachim Schiele <js...@du...>
+
+This docu explains the file formats used by "dune2 - the battle for arrakis"
+
+"dune is a trademark of dino de laurentiis corp. & licensed by MCA UNIVERSAL
+MARCHANDISING, INC.
+"dune2 - the battle for arrakis" is Copyright (C)1992 Westwood Studios, Inc.
+All rights reserved.
+
+The information provided here is meant for programmers that want to make
+editor and utilites for "dune2 - the battle for arrakis".
+
+A lot of work had already be done by Vladano Bato (ba...@ge...)
+with his document "COMMAND AND CONQUEROR FILE FORMATS" so i want to thank
+him very much.
+
+I put some example c-code in. And everything mentioned about coding is c.
+
+So here a list of what can be found here:
+------------------------------------------
+
+ 1. pak files
+ 2. cps files
+ 3. shp files
+ 4. pal files
+ 6. emc files
+ 7. fnt files
+ 8. tbl files
+ 9. voc files
+ 10. code 80/40/20
+
+==========================
+ 1. The pak-files
+==========================
+
+The PAK-files are devided up into a HEAD and a BODY.
+The HEAD could be like this:
+
+aa 02 00 00 34 23 34 34 24 34 34 23 34 34 23 12 | ................
+00 aa 02 10 00 34 23 34 34 24 34 34 23 34 34 23 | ................
+52 4d 59 2e 56 4f 43 00 d9 c9 05 00 41 43 41 50 | ................
+54 55 52 45 2e 56 4f 43 00 fb e9 05 00 41 4e 45 | ................
+58 54 2e 56 4f 43 00 dd 03 06 00 41 4e 45 58 54 | ................
+32 2e 56 4f 43 00 00 00 00 00 43 72 65 61 74 69 | ................
+76 65 20 56 6f 69 63 65 20 46 69 6c 65 1a 1a 00 | ................
+0a 01 29 11 01 c3 4b 00 ab 00 83 83 83 83 83 83 | ................
+83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 | ................
+83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 | ................
+83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 | ................
+
+StartOffsets:
+You can see the "aa 02 00 00" -> read it with "unsigned long" then you
+will get "00 00 02 aa" as hexaddress in the file - now set your fd
+to this offset you can read out the contence of the IDEFIXII.VOC. After
+the filename there is always a seperator "00" so you know how
+to seperate the names and the offsets. Then you can read the next offset
+of the file ASTERIX.VOC it is "00 10 02 aa" so you get the startoffset of
+it.
+
+EndOffsets:
+The endoffsets of a file "IDEFIXII.VOC" would be just one byte before the
+startoffset of "ASTERIX.VOC".
+So the offsets of "IDEFIXII.VOC" would be:
+ StartOffset: "00 00 02 aa"
+ EndOffset : "00 10 02 aa" - 1 so "00 10 02 A9"
+But the last file in the pak doesn't have these method to generate it's
+endoffset because there isn't any file afterwards the get the startoffset form.
+So the last file in the HEADER has it's endoffset at the fileend of the
+pakfile.
+
+The head is seperated from the body with 5x00 you can see this in my
+example "00 00 00 00 00 43 72 65 .. .. .." this is like the "00" after
+a filename to seperate it from the next and then there would be the next
+offset of the next filename .... and so on.
+
+see /src/pakextract.c for more informations on this. i have put some
+comments in the code so you are not on you own :)
+
+==========================
+ 2. The cps-files
+==========================
+These files are very much like those from CNC.
+Format80 compression is used
+
+==========================
+ 3. The shp-files
+==========================
+==========================
+ 4. pal files
+==========================
+==========================
+ 6. emc files
+==========================
+==========================
+ 7. fnt files
+==========================
+==========================
+ 8. tbl files
+==========================
+==========================
+ 9. voc files
+==========================
+voc files are compressed audio files for duneii usually in mono format
+and with a very low encoding rate
+linux: there is a tool called sox which is able to convert this format to wav
+
+==========================
+ 10. code 80/40/20
+==========================
+
Property changes on: branches/dunks/src/pakfile/duneii_specs.txt
___________________________________________________________________
Name: svn:eol-style
+ native
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X