Blade

As side projects to the main RedAlert++ project, I've been developing simple tools to convert to the various C&C file formats. So far I've just been releasing them separate, but as they are pretty tiny command line tools, I've decided I'll just link to a zip with them all in. http://omniblade.cncnet.org/tools.zip This zip has a couple of new tools too. It has d2wsaset which should write the Dune 2 version of the WSA format (its untested so feedback is welcome) and stringset which can convert the string table files to an ini file for easier editing and back. It doesn't currently handle the dipthong encoding used on some Dune 2 string tables however. It also doesn't do any code page conversion so make sure you save the ini in the correct code page before converting it or you could have some interesting effects.

Looks like the stretch table still isn't right to me. BTW, just in case you didn't realise, the palette has to be the same across all the pcx files and it will only include the palette from the first file if -p is specified as a result. Regarding the error, I think we might need Nyerguds to look up what function it happens in to be able to guess what went wrong.

RedHorizon doesn't have the format correct, it doesn't set a field called Delta correctly in the header which is needed by the game to allocate the decompression buffer. This is why its hit or miss if a file encoded by it works in game. Regarding the palette issues, TD uses stretch tables (interpolation palettes) that it reads from disk to stretch the images at 640x400 because the WSA format is pretty much limited to 320x200 (mainly by the size of the Delta field in the header). You have to ensure that you also generate a new version of this file to match your palette if you want the image to be drawn correctly in game (unless you are only playing it in DOS of course). Nyerguds has a tool for generating them.

Glad its proving to be of some use, its probably the only tool currently that can generate consistently working WSA files, but I wasn't sure if anyone actually wanted to replace them.

Well, I'm just saying how the RA95 code works, I haven't seen any for the interpolate function from C&C95, so I can't be certain they are the same. I'd be very surprised if the WSA draw code was significantly different though, the code in RA is virtually identical to that seen in OpenDUNE (and by extension Dune2) as far as I can tell apart from a few adjustments made to the format between the games. Are the loops you refer to something similar to those see in https://github.com/OpenDUNE/OpenDUNE/blob/master/src/wsa.c at line 463 and below?

In RA, the WSA style interpolation palette load and save is decided on by Interpolate_2X_Scale function, which is the front end function for the 3 possible scaling types. It is passed GraphicBuffer classes for source and destination buffers, a char * to use as a filename and an enum that decides which interpolation technique will be used. If the filename char * isn't NULL and the palette to use during interpolation has changed, it will load the filename if it is available on disk. If it isn't available it will generate it and then attempt to write it out. The filename can be anything, it doesn't have to relate to the actual WSA filename being interpolated. If the C&C95 code is the same as the RA95 code, I guess the problem was that Interpolate_2X_Scale was being called with the wrong file name, so during development it never generated the file it was supposed to to bundle in the mix files, it just kept using the wrong one. If you had just fixed the changed the interpolation pal filename for the problem WSA files, the game might have generated them for you. Alternatively, just changing the code to pass NULL as the filename for those WSA files would have made the game generate them everytime which would also probably work.

In RA the remap tables are loaded mostly from a cps file, palette.cps. We have implemented that loading and the shp drawing code to apply them as demonstrated by our lovely model, MCV. Again, don't pay too much attention to the fact the main menu PCX is in the wrong palette, it doesn't share the same palette as the game palette apart from a few indices that are required to draw the mouse cursor.

It seems I was a bit confused in my response to LavenderMoon, my reply related to the WSA loading logic not the VQA stuff, oops The VQA stretch table format is the same between RA95 and C&C95 though and is pre-computed for both. As Nyerguds says there is logic to write out the WSA table to file, it should be called if the function to load (or generate) a table is called with a filename to load, but that file doesn't actually exist in the search path. Since RA never calls the function with a filename, they never get written out, but C&C95 should write them out if they weren't found in the mix files.

I'd be interested in seeing the manual, but I can't speak for the site maintainers as to if they are comfortable with it being linked to in the public forum.

There are no plans to make any kind of preview of the code, I don't really see what it would accomplish (other than prove we are doing something). The final licence will likely be GPL v2 or later or GPL v3 or later.

Its currently a lot of low level stuff that work correctly, Mix loading, ini parsing, a bunch of boring (from the pov of a player) stuff so far. We have the skeleton of the game classes mapped out, but there is still a lot to do before we have path finding and state machine working. How long did it take for OpenDUNE to get to the point where it was playable? Think that kind of time scale if not longer.

It would appear so, yeah.

TransFlag is actually an offset to one of the arrays in the footer of the file, its the footer array that contains the values treated as bools flagging each cell image as using the transparent blitter or not. This is for the software blitter at any rate, there is also a code path that caches the tiles as directdraw surfaces, its behaviour regarding the flags might be different.

It looks like the TransFlags array in the footer is an array of boolean values that flags if the blitter should draw index 0 pixels or just skip them and leave the pixel value that was there already for the cells they refer to.

The main problem as I understand it with creating a new sole survivor server is that you need a deterministic game server that makes the same calculations as the game itself would in any given situation so that it stays in sync with all players clients. This means you have to reverse engineer all the games core logic and no one has gotten around to that. The other option would be if you could make the game act as a server itself, but it seems even the code for that is incomplete or at least not understood well enough that anyone has made it work yet.

I guess if Allocated is only used at run time, then it reading Count as int32 or int16 would give the same result for the range of values its likely to have, so I can see how it was mis-interpreted.

The function that acts as the interface for the different interpolators also takes an optional filename. If the file exists it is loaded as the table, otherwise one is generated and the file written out to disk to load next time. Of course you can just pass it NULL and it will just generate one. The generation is also controlled by a bool that gets set when a new palette is loaded and cleared once the table is generated for that palette to prevent unnecessary loading/generating. In RA most of the time a filename isn't provided so it just generates it, I am guessing that in C&C95 a filename is always provided so it attempts a load, but if it was missing, would generate the requested file (might be interesting to test that theory by removing the interpolation files in C&C95 and seeing what it does).

Which is exactly what it looks like the game does. OpenDUNE went out of their way to use bitfields for some stuff to ensure the serialised format was the same from what I can tell, but that just makes the code harder to read and maintain IMO. Lets forget this focus on the save game formats as we are a bit off implementing the serialisation routines for objects yet. We may come up with a slightly nicer on disk binary format than just dump everything, but at the end of the day it still won't support the old saves out of the box.

The WSA and most of the VQA animation in game are only 320x200 and require scaling up for the Win95 version of the game. Although most RA players will only have noticed the scaling on the VQAs which uses an interleaved scaling by default (blank scan lines), its actually also used on the mission select screen. The difference being the algorithm used. There are actually 3 algorithms implemented in the game, ranging from the fast interlaced version where it does a bilinear interpolation of even lines, but leaves the odd ones blank to the full interpolation version where it bilinear scales the whole thing. The one in the middle scales the even lines, but just copies them to the odd lines. Anyhow we have reimplemented them, so check out the difference in scaling quality. Ignore the fact it says ORA in the window title, that is because I haven't changed the text for the test app title bar yet to reflect the project rename.

Bit of a necro post, but for anyone who stumbles on this thread looking for format info, the actual struct for the header was found by CCHyper in some debug info left in one of the exes and is as follows: struct IControl_Type { short Width; short Height; short Count; short Allocated; short MapWidth; short MapHeight; long Size; long Icons; long Palettes; long Remaps; long TransFlag; long ColorMap; long Map; };

There were already plenty of examples of the decompression algorithm available in open source tools the community has made. https://github.com/OpenDUNE/OpenDUNE/tree/master/src/codec has good examples in C that are close to the original implementations, though the format80 implementation doesn't handle the extended algo for data over 64K in size. You can find an implementation that does at https://github.com/madmoose/replicant/blob/master/src/decompress.cpp, though the differences are minimal.

Its lifted from a code base that is compiled as C++ so its written in that style, I'm well aware of this subtle difference between C++ and C treatment of void* and didn't feel like cleaning it up further to compile as straight C, its provided as is that it might prove useful to those writing tools to write the C&C graphics formats. LCW (not LZW) is a proprietary compression format used in many WW games. Most implementations don't compress as well as the WW original, this one does. XORDelta is similarly a binary delta format used in the WW animation formats, the only other working implementation I know of is the Red Horizons Java version. Its required to implement a WSA format writer and can greatly improve the compression of the shp format if implemented as WW did. You might see these formats referred to as format80 and format40 respectively, LCW and XORDelta are the original names used by Westwood.

Can you load the DOS save games in the Win95 version? No you can't, so why would a completely rewritten exe be able to load old ones? From what little I've seen, the save games look like binary state dumps of the game minus the stuff it can reload from disk. Loading them makes assumptions about the word size and of object sizes in the game in general, most of which we won't go out of our way to guarantee between platforms for performance reasons and we won't be going out of our way to make them match the original objects exactly. In general, supporting the old saves is way down on the priority list, it wouldn't be impossible to write a parser that translated the old saves to a newer format, but I don't think either myself or CCHyper is going to invest much time investigating it.

Although I've not actually looked at the code that handles carryover I can say with some certainty that it will be part of the game state held in memory and will be written to the save game. No secret files or reg keys.

Its a bit early in development to be taking feature requests, but things like build queues do change the dynamics of the game, particularly for competition. If such features are ever implemented they will be optional behaviours to enable and certainly not default.