Blade

Thanks to the STLPort stuff I've been able to fully reimplement the filesystem code and the string file parser now. I've also mapped out most of the global options class, a few members are still unknown or uncertain, but all the user configurable options are mapped.

Part of the standard C++ is a library of data structures and algorithms such as std::vector or std::map, the behaviour of which is mandated by a standard. However the underlying implementation isn't defined so different compilers implement them differently. The implementation even changes between compiler versions. Provided your program is self contained and doesn't try and pass these data structures between dll's or anything the fact that the implementation can change over time doesn't matter though because the version your program uses is set in stone when you compile it. However when you are trying to hook into an older existing binary where some functions do pass them around and some of the data structures contain them, the differences basically mean things don't line up correctly when you try and re-implement them so functions that theoretically would match the original in behaviour don't match at a binary level, you need to use the same implementation as the original. Part of the reimplementation is working out the layout of the data structures for things like the INI file parser and the big file loader so they can interoperate with the original code and having the correct C++ implementation makes that much easier.

Made an interesting discovery, it seems that the game was written against STLPort rather than the standard c++ library that comes with MSVC and we think we've identified the version they used so with a bit of massaging to get it compiling, we have an ABI compatible C++ library implementation making it much easier to implement and test functions one at a time, even those that rely on STL containers which we didn't think we could touch until later.

For anyone keeping track, I've pushed some work on the filesystem and hooked enough that I can call the original filesystem functions to handle files. Some parts of it I can't reimplement fully until later in the project as they pass around C++ STL objects and the binary interface for those changes between MSVC versions, so I need to reimplement everything that uses them at the same time. I've started looking at the ini file parsing now, and a lot of that should be replaceable though.

Until recently I believe C&CNet did, but they recently divested themselves of it due to lack of man power IIRC in maintaining it. Not sure who took over managing it.

Its one of those "done when its done" things that I work on when I have chance I'm afraid. Its probably going to be quite slow until I get it to the point where its interesting enough to get more contributors, but we are probably talking years as the engine is quite large. Regarding the name, Sage (as in SAGE engine, the name of the engine Generals uses) and Thyme are both herbs and "Thyme" is pronounced the same as "time" which is a recurring focus of many of the C&C games.

The issues with playing them on windows 10 are because the safedisk driver is blacklisted as I understand it. A no-cd crack should fix them, though I think they have issues running in true 32bit mode due to the way they blit the screen. Generals ZH also has an issue with the safedisk driver, but as with TS and probably RA2, the safedisk check is done in a launcher, the main binary is fine, it just looks for the launcher. I already reimplemented the functions that check the launcher. It now does something like bool isLauncherRunning() { return true; }.

Until its further along, its hard to say exactly possible, but when we have an entire reimplementation there shouldn't be anything we can't change about the game. If nothing else, having a source reimplementation will allow tracking down the source of the desyncs more easily through the use of debug builds that log information about the game state.

I've just pushed the beginings of a Zero Hour reimplementation project to https://github.com/T...blyArmada/Thyme if anyone is interested in contributing to such a project. The project is using a similar approach to the one recently used successfully by the OpenRCT2 project. That is, the reimplementation is initially being implemented as a dll that is injected into the game run time that replaces the games functions with new implementations as they are written, allowing it to be reimplemented a bit at a time. I've already reimplemented the custom memory allocator the game uses as well as a couple of string classes. Its very early days for the project, but if anyone has some C++ knowledge and is interested in getting involved, drop by the #thyme channel on freenode.net IRC. When some significant progress has been made it should become possible to fix engine bugs and add additional features to the game.

The crypto functions were a big pain, I'd been working on them on and off for ages, but it's nice to be able to decrypt the mix files without relying on external libraries or the XCC code. We've recently got scenario files loading, hopefully that will lead to us having basic map drawing working soon so we'll have pretty pictures to start showing.