Blade

Regarding compatibility with the older clients, even if we largely reuse the same protocol we will likely want to force people off the old client to fix bugs such as the grouped unit speed and such which Westwood didn't do because they wanted to continue to support older clients. It also gives us the freedom to alter the protocol for other reasons should the need arise. All this is a bit down the road for now though, lets get scenario loading and game logic and drawing down first.

Well it is true you could use any interpreted language, java, python, whatever, but MS does go out of its way to make nice tools and frameworks to make everything easy so you don't have to reimplement basic data structures, so long as you don't mind being tied to them. On windows its not really an issue, but it does make it a bit less cross platform friendly when you have to install a large 3rd party vm and frameworks collection, especially when a lot of people are on those platforms to avoid anything Microsoft. Still, with MS being so big in the business world there is a lot of love for .NET so lots of devs know it and it is harder to mess up than in C++.

Some things are very difficult to achieve with exe hacking, and others practically impossible. With the source code it would be possible to create native ports to OS X or Linux or even Android and iOS for example. It would also be possible to port the rendering back end to something better supported on windows than ddraw so it wasn't necessary to mess with ddraw.dll files and such. It would also make fixing bugs or adding new features a lot easier and make it easier to understand what parts of the code are doing which in turn might enable other tools and projects to be developed.

Well, their default platform handling appears to be SDL2 and OpenGL, so a lot of the drawing effects are going to be done on the graphics card or handled by native code anyway, so as far as I see, it is the engine logic implemented in C# and C# performance (on the Microsoft VM at any rate) is close to native as I understand so I doubt they will actually be loosing much. Back onto the topic of OpenRedAlert, here is a screen shot of a blitter test showing the various RA blitter logics we've implemented so far. They use fading tables as the original game does to remap the palette indexes, though unlike C&C which loads some of them from disk (.mrf files), RA generates them on theater load so so do we.

Pretty much what I did then. It looks like there was a GitHub page with a description of the format at some point, but it must've got taken down which is a shame. Looks like that is what the OpenRA implementation was based on.

True, but that doesn't help writing custom installers or cross platform tools to deal with InstallShield 3 archives.

That is pretty cool, where did you get documentation on the format of the archives InstallShield 3 used? I wrote an extractor for getting the files for C&C95 and Sole Survivor off their CD's a while back and had to crib a few of the fields from existing tools and figure out a few more fields for myself, but I didn't have a complete format I don't think and would like to have it documented somewhere.

Find attached C++ code for efficiently compressing and encoding data in LCW(format80) and XORDelta(format40) formats. This is cleaned up and rewritten in parts from the code used in ShapeSet and WSA set and so provides the same or better compression as the original code used by WestWood for these formats. Ideally any tools that write data in these formats should be updated to use this code (for C/ C++ programs) or else port the code to the relevant language unless their code already matches the performance of the WW originals. This code is released under the GPL v2 or later. If you want to use it in a program using a different license I'm open to discuss it. If anyone needs assistance with the algorithm that is used in the RA/TD shp files to decide what format a frame should have or any other questions related to these compression formats, please ask away. encoders.zip

I think its worth noting that the versions with lyrics were as far as I know the ONLY versions on the Saturn edition. The original DOS version (and IIRC the localised C&C95 versions) also contain the lyric versions as hidden extras and they could be enabled by specific lines added to conquer.ini. I don't recall exactly where I heard/read it but I believe that the lyric versions were the intended tracks and that a decision was made higher up that they might confuse players with the regular unit feed back speech and thus were changed.

Ha ha, I apologise if I have led anyone to believe this package is low quality.

Could be that the audio engine gets set up slightly differently for those instances for some reason. Other that that I don't know, it would require a deeper understanding of how the games load and process audio.

While this is awesome, I actually believe that the game can use aud files packed with pure pcm audio too, its just that no such files exist. Its something I will look into at some point, so it is possible the sound track could get even higher quality even without someone hacking in support for something like ogg vorbis. Storage space needed would go up about 4x over this current release though

Strange that SS should struggle with the stereo audio, maybe they took out the general decoder and just left the optimised mono decoder in for some reason?

Hmm, I've had success with Audacity myself, upload the still not working wav and I'll take a look. The one you uploaded earlier contained a fact chunk which I'm guessing is meta data and isn't supported.

I'll download it and take a look at it in a hex editor later and see why it isn't liking it. The tool is pretty picky about the format of the header, some tools save in rf64 format which isn't supported for example.

You should run the batch file with the path to your wave filled folder as an argument. dirset.bat c:\path\to\dir Give that a go and see if it works.

http://cnc-comm.com/community/index.php?topic=4386.0 for the tool. I've included a sample batch file that should process a directory of wave files for you though its untested. No need to write all the file names, that would make writing the batch file a waste of time

Recently there has been some discussion regarding if TD and RA support stereo audio, but the discussion was somewhat moot as there were no encoders that could encode stereo aud files. Enter AudioSet, a very simple wave to aud file encoder that will convert stereo wave files to the stereo aud format that TD and RA can handle. It will also convert mono as normal. Waves must be saved in the standard microsoft wave riff format and be 16bit. The tool requires you to pass the filename WITHOUT the .wav extension. It will load the wav file and write out the aud file using the same filename. Included is an untested batch file that should let you process a directory. You will need to edit it to tell it where you have saved audioset.exe and run it with the path you want to scan for wav files to convert as the argument. audioset.7z

It won't do wildcards I'm afraid, the interface is going to be really basic. You'll need to write a batch file to deal with multiple files.

Good news everyone. Seems the earlier games (TD, RA, SS) do support stereo and will play it according to testing conducted by Tomson with a tool I wrote. Just need to do a bit more QA on the tool, but shortly we should have a command line wav2aud program that can encode 48000 16bit stereo wave files into corresponding aud files that the game can use.

You can't just back port the larger RA infantry to C&C, the sequences are different even for the same units as the C&C versions have additional hand to hand combat animations that are almost never used but that do figure into frame calculations. The only one you can is the chem trooper that isn't even used in RA but is resized and in the mix files and still has the fighting animations IIRC.

The game appears to have code that will decode an interleaved stereo aud file, but what the game then does with it and if it will actually output it as stereo is a different matter.

Its an image to shp tool, it expects the models to be rendered out first to pcx IIRC.

http://www.ppmforums.com/viewtopic.php?t=38429 is the thread where you can find the leaked tool for TS/RA2 format shp files. Only the RA2 format has info on where to draw a frame, it saves the overall dimensions that the shp should be drawn to, but can save smaller dimensions and sub frame position for each frame. The Dune2 format is more like a collection of individual images, each with their own header, the TD format has all the dimension information in the file header, frames only have info on what compression format they use. As a result all frames must be the same size. The information in the TD X and Y fields appears to be completely ignored in at least RA (though I suspect the same is true of TD and SS as well), it is overwritten in memory by information related to how the game is buffering the image as far as I can tell. The values set in the file appear to only be leftover from the processing of the original images used to generate the shp.

For those who don't know, the Shp header looks something like: struct ShapeHeaderStruct { word FrameCount; word Unk1; word Unk2; word Width; word Height; word MaxFrameSize; word Flags; } This is pretty much the same as the WSA header where the two unknown entries are the X and Y position in a 320x200 canvas that the top left of the animation should be drawn from, but of course shp files can be drawn anywhere. Why then do they seem to have random values that differ between many shp files? This has bothered me for a while as the game doesn't seem to use the read values from the file at all, so what do they mean? Well, it turns out that all shp files started life drawn on a 320x200 image surrounded with a bounding box (probably the rendered output form whatever 3d program they were created in). The WW shp creating tool would detect the bounding box and crop the image and would record the original X and Y position of the top left pixel in the shp header. "Wait a minute!" I hear you cry, "How can you possibly know that"? Well it is something of an inference, but the two pieces of evidence are that 1. The TS/RA version of the shp tool was leaked and can do the cropping I describe and 2. There is an example of an uncropped shp image available along with its correctly cropped version to compare. The French and German versions of aftermath (and the 3.03 patch) contain a faulty uncropped version of carr.shp, the unused helicarrier unit. Compared against the corrected English version you can see that the unknown header values in the correct version match the location of the top left pixel where it would have been cropped in the uncropped version. All of this is of course somewhat useless. The game doesn't seem to use the information and so custom shp files don't need to set these values to anything particular. The only real use might be figuring out where units and structures were in the original 3d scene when it was rendered for anyone that wanted to recreate the models and scene exactly. Other than that it simply serves to solve another mystery of these old data formats.