401Kill

Fair enough. Did they say what those 4 bytes are for? I'll need to update my code...

Ultraq's description of the Dune 2 WSA format seems to match my one. I modified my WSA library slightly to output calculated framerates and got the following: File FPS INTRO1.WSA 4 INTRO10.WSA 30 INTRO11.WSA 13 INTRO2.WSA 16 INTRO3.WSA 16 INTRO4.WSA 22 INTRO5.WSA 26 INTRO6.WSA 19 INTRO7A.WSA 20 INTRO7B.WSA 9 INTRO8A.WSA 21 INTRO8B.WSA 4 INTRO8C.WSA 14 INTRO9.WSA 26 Some of these seem very slow though (4 FPS for one of the Harkonnen troopers scenes?), at the moment I would have to agree with MrFlibble - I don't know whether these are actually used by Dune 2 for playback.

Correct me if I'm wrong, but isn't it possible to calculate framerate from the delta given in the WSA file header: WSA header { Int16 NumFrames; // Number of frames in the sequence Int16 Width; // Width and height of the images Int16 Height; Int32 Delta; // Frames per Sec = Delta /(2^10). Int32[0..NumFrames + 1] Offsets; // Image offsets } The above was adapted from Vladan Bato's documentation and serves me fine for Dune 2 v1.07 files (although I haven't actually used the calculated framerate for anything yet) - I am aware that there are differences between the C&C, Dune 2 v1.0 and Dune 2 v1.07 WSA formats, but I can't find any other use mentioned anywhere for these bytes :/

My mistake, the second frame was also buffer overflow. Several of the frames in Static.wsa overrun, the worst one by 485 bytes. However, the resulting bitmaps using the first 4096 bytes of each buffer seem to be correct. Onto the .SHP files now, I think...

Ahh yes, that would make sense! It's amazing how much better the results in Google are when you use the right search term :P I've only ever seen it referred to as XMID before. Reading C++ is not my forte, but I think I can make reasonable sense of what this is doing. Thanks! :) Not yet, but I really should. Will do so ASAP. Maybe, in which case I can compensate by dynamically resizing the buffer if required. What bothers me is that the second frame badly fails to decode (not a buffer overflow), which would suggest improper input, and therefore presumably a wrong offset?

I would like to have a complete set of libraries for dealing with all the Dune 2 data files. Unfortunately, given that I can't find any useful documentation on XMID, I suspect that I will end up having to follow that route.

Quite probably :P C#, but the Format80 decoder is pretty much a direct translation of Vladan Bato's decoder as seen here, with SHL and SHR implementations which behave as in Pascal (ie. do not preserve the sign bit). Since every other CPS and WSA file works fine, it must be a fairly specific bug. Attached the Decode80 routine, since pasting into a [ code ] block is mangling indentation ??? EDIT: Seems saving as a text file has done no better - MonoDevelop is mangling indentation then :P Decode80.cs.txt

Thanks for pointing that out, double checked and static.wsa uses 32-bit offsets though. Also checked the first offset against the raw file data, it appears to be correct as far as I can tell. The problem seems to be that the Format80 decoding routine is using a 4096 byte (64 x 64 px) output buffer based on the image dimensions, however the EOF marker (command 128) is not encountered until the Destination pointer is at 4099 - ie. the decoded image is 4 bytes too long. If I increase the output buffer size, I can marshal the resulting byte array into a bitmap which looks ok, but then the second frame fails to decode. I've tried tweaking the start offset slightly, but that results in a complete failure to decode the first frame - so I think it's probably correct.

I'm on 1.07 European. Fair enough, in that case it's most likely a bug in my code. Just seems strange that all the other WSA files work ??? According to my routine, 'static.wsa' is 64 x 64 pixels, which I would guess is correct for the radar screen, and contains 23 frames. The offsets of which I find to be: Offsets int[23] [0] 102 [1] 2271 [2] 5686 [3] 7770 [4] 11123 [5] 13458 [6] 16002 [7] 17359 [8] 18167 [9] 18212 [10] 18257 [11] 18302 [12] 18361 [13] 18381 [14] 18389 [15] 18397 [16] 18405 [17] 18429 [18] 18437 [19] 18474 [20] 18482 [21] 18506 [22] 20677 Are these the correct values?

Thanks. I'm trying to find a reasonable cross-platform, automated approach - either CLI or a library would be best, since I don't think my format hacking skills are up to decoding it yet lol. Will look into any possible CLI interface to Winamp. Also, I now have a C# routine which decodes all the WSA files correctly, except 'static.wsa' - is there any known issue with that file? I read somewhere that the WSA format used in 1.07 differs from 1.0, is 'static.wsa' perhaps a leftover in the earlier format?

From what I've read, much of the debate on green policy seems to assume that the primary effect of going green is to reduce CO2 emissions. While that is certainly important, I would argue that there is another, equally important consideration: Oil is finite. Therefore, going green is the only viable long-term solution, because at some point we will run out of oil regardless of its impact (or lack of) on the environment - and if we have continued business as usual rather than migrating to renewable alternatives, we will be quite unprepared. Considering the number of highly important products (many life saving drugs, fertilizers, etc for example) which are made from various fractions of oil, continuing to burn it in cars, trains, power stations etc when these can be powered by alternative means is not a good plan. By moving away from oil wherever possible and replacing with renewable technologies, not only do we mitigate any impact of emissions on the environment (not only climate change, but also things like acid rain and smog), but we also retain maximum quantities of oil for areas where it is not so easily removed from the equation. In order to research, develop, build and improve renewable technologies on a scale to rival the current oil industry, many jobs would need to be created. Increasing employment and circulation of money would help the economy. We need governments who can consider the long-term implications of high dependency on finite resources and the probable effects on our environment, rather than the short-term interests of the oil industry. That's my take anyway :)

Just came back to this thread, its been a long time since I had any time to think about such things! The VB effort expired a while back, and is probably dead for good, since I am now rewriting as a cross-platform app in Mono C# (as good an excuse to learn C# as any I guess :P). Only done the PAK reader so far (the easy bit!), and a quick VOC -> OGG conversion using PACPL - but thats kinda Linux dependant at the moment, need to implement a more universal solution (probably just a VOC -> WAV algorithm for starters). Looks like you guys have come up with a wealth of info on the graphics side of it, will need to read the thread in detail now! I am particularly interested in dvalin's work on the music, I was hoping to find some info on converting XMID into a (more) usable format.. eg normal MIDI. Any information on that front would be greatly appreciated! I can see he's done a lot of work on the file formats, and I shall try to make what sense I can of the C++ :P Apologies for reviving an old thread and then wandering off topic, and many thanks for all info! :)

Been away for a while, just come back to the project and I've just got format80 decompression working perfectly - at least for all the .cps files. Turned out to be my SHL implementation was dodgy... thanks for mentioning them, it made me actually research what they were supposed to be doing. :P My success at decoding SHP files varies... some images are perfect and some are incomprehensible. My routine currently ignores format40 shp entries (mostly - I think it might be trying a few and giving these weird results). I haven't worked out logic for dealing with the malformed credit##.shp files (the ones which don't indicate end of header properly) yet, does your code deal with these or just ignore the headers? I'm going to overhaul my shp handling routine now, and then on to Format40 decompression next... joy ;D Just got hold of a new web server, so I'll maybe get a project page going soon...

Thats good to know ;D I may have to implement these... I've just been using mid() and a function to convert numbers to binary... We share a mission then... good luck and thanks for the offer!

The image I uploaded was 'setup.cps' from the original C&C, however all CPS images I decompress with my function have much the same effect. I have implemented RGB multiplication as suggested, this has improved the look significantly. Thanks for that info. Attached are a couple of shots from the new function. Many of the SHP images appear to work correctly, which leads me to believe that it is one of the larger CPS "commands" which has a bug.

Thanks guys. Will check those links... I did find the XCC source, but I'm not competent enough in C to make much of it. I think its going to be one of those horribly annoying, trivial bugs...

Hi, I'm trying to understand the Format80 compression method used in Dune II, C&C etc. I have been working on converting Vladan Bato's Format80 code sample (http://www.geocities.com/SiliconValley/8682/ccfiles4.txt) to VB6, as the syntax is very similar. The images produced (see attached for an example) are nearly correct, however something isn't quite working properly. Any ideas? Thanks, Ben ' Custom functions -' GetBit (byte, bit number)' GetBits (byte, start bit number, end bit number)' String index 1 2 3 4 5 6 7 8' Bit 7 6 5 4 3 2 1 0Function Format80toRAW(Format80_Image_Data As String) As String Dim Source() As String, Dest() As String, OutBuffer As String ' Data arrays and working buffer Dim SP As Long, DP As Long ' File pointers (0 based) Dim Com As Byte, Colour As Byte Dim B7 As Integer, B6 As Integer Dim Count As Long, Pos As Long, i As Long Source = Split(ToHexStr(Format80_Image_Data), " ") ReDim Preserve Source(UBound(Source) - 1) ' remove blank entry from end of array ' zero pointers SP = 0 DP = 0 Do Until False Com = CByte("&H" & Source(SP)) ' source data in hex, convert to byte SP = SP + 1 B7 = getBit(Com, 7) Select Case B7 Case 0 ' Copy command (2) ' Bits 4-6 + 3 Count = BinaryToLong(getBits(Com, 4, 6)) Count = Count + 3 ' Bits 0-3 + next byte Pos = BinaryToLong(getBits(Com, 0, 3)) Pos = Pos + CLng("&H" & Source(SP)) Pos = (DP - Pos) ' Start pos = current pos - calculated value SP = SP + 1 For i = Pos To Pos + Count - 1 ReDim Preserve Dest(DP) Dest(DP) = Dest(i) DP = DP + 1 DoEvents Next Case 1 ' check bit 6 of Com B6 = getBit(Com, 6) Select Case B6 Case 0 ' Copy As-Is command (1) Count = Com And &H3F ' mask 2 topmost bits If Count = 0 Then Exit Do ' EOF marker For i = 1 To Count ReDim Preserve Dest(DP) Dest(DP) = Chr(CInt("&H" & Source(SP))) DP = DP + 1 SP = SP + 1 DoEvents Next Case 1 ' Large Copy, Very Large Copy, and Fill commands Count = Com And CLng(&H3F) If Count < &H3E Then ' Large Copy (3) Count = Count + 3 ' Count = bits 0-5 of com +3 ' Next WORD = position from start of image Pos = CLng("&H" & Source(SP + 1) & Source(SP)) SP = SP + 2 For i = Pos To Pos + Count - 1 ReDim Preserve Dest(DP) Dest(DP) = Dest(i) DP = DP + 1 DoEvents Next ElseIf Count = &H3F Then 'Very Large Copy (5) Count = CLng("&H" & Source(SP + 1) & Source(SP)) Pos = CLng("&H" & Source(SP + 3) & Source(SP + 2)) SP = SP + 4 For i = Pos To Pos + Count - 1 ReDim Preserve Dest(DP) Dest(DP) = Dest(i) DP = DP + 1 DoEvents Next ElseIf Count = &H3E Then ' Fill (4) Count = CLng("&H" & Source(SP + 1) & Source(SP)) Colour = CInt("&H" & Source(SP + 2)) SP = SP + 3 For i = 1 To Count ReDim Preserve Dest(DP) Dest(DP) = Chr(Colour) DP = DP + 1 DoEvents Next End If End Select End Select DoEvents Loop OutBuffer = Join(Dest, vbNullString) Format80toRAW = OutBufferEnd Function