Thyme, a generals ZH reimplementation project.

Blade · Cyborg Commando **Joined**: 23 Dec 2003

I've just pushed the beginings of a Zero Hour reimplementation project to https://github.com/TheAssemblyArmada/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.

temp · Rocket Cyborg **Joined**: 17 Oct 2015

so ,basically this is ares for Zero hour.
good job!

_________________

Blade · Cyborg Commando **Joined**: 23 Dec 2003

Essentially, yes, in that the two projects work in similar manners.

The difference is with goals though, Ares is focused (at least publicly) on implementing new features ASAP, reimplementing only what is necessary, whereas I want to focus on reimplementation and add new features only when the reimplementation progress makes it possible. The end goal for Thyme is also to totally replace the original binary, whereas that isn't a stated goal for Ares I don't believe.

G-E · Defense Minister **Joined**: 09 Feb 2015

What benefits do you see re-implementing everything?

_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Blade · Cyborg Commando **Joined**: 23 Dec 2003

Portability mainly, Linux and Mac versions that can play Windows player for example should be possible. The possibility to recompile for more modern CPU's to take advantage of SSE for or replace the API used for graphics rendering would also be benefits.

Graion Dilach · Posted: Sat Jan 21, 2017 5:35 pm Post subject:

How do you intend to work around the copyright issues dds and mp3 involve?

_________________
"If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more...

Blade · Cyborg Commando **Joined**: 23 Dec 2003

What copyright issues are you talking about?

I believe you are confused with patents, the last of which expires in April for MP3 and October for S3TC, the texture compression codec used in DirectX textures, after which I will be free to include compatably licensed libraries implementing them or write my own implementations.

Since I don't expect to have finished reimplementing everything in the game by October, it seems my "workaround" will simply be to wait the patents out.

Blade · Cyborg Commando **Joined**: 23 Dec 2003

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.

Blade · Cyborg Commando **Joined**: 23 Dec 2003

A little update for those who don't obsessively click refresh on the github page. Filesystem handling is pretty much done, as is string file handling. Most of the guts of the INI parsing system are done, specific functions for parsing into specific types of file are being implemented as the classes they feed are.

The layouts for classes that get allocated during the game engines initialisation are slowly being worked out, right now I'm looking at the audio engine which is huge. Currently it links against something called Miles Sound System which is a commercial sound library but I'll want to implement an alternative around OpenAL instead since I can't use Miles in an open project.

There are several useful things that i could implement currently. I've already started adding debug logs for errors that occur when reading ini files, but even what I've added so far can be improved by logging file names and line numbers. I could also alter the way that .str files are treated so they could be utf-8 formatted rather than just plain ascii which the currently are. That way if you include extra strings with a map, you could use foreign symbols in it.

Largely I'm still just trying to focus on reimplementing logic rather than adding many improvements just yet though. I've also started to think about the possibility of building the incomplete stand alone binary so that its easier down the line to switch without a big refactor and to test cross platform building of the project to see where alternative functions need using/writing.

Banshee · Posted: Fri Jul 07, 2017 2:29 am Post subject:

Very interesting. However, this conversion of Miles Sound System to OpenAL is something that seems to be a little bit complex to be done. Do you really need to touch the audio part, since Generals (and Renegade) uses Miles, according to its official site and such conversion might take a lot of time to be done. I don't know anything about Miles nor OpenAL, although I believe their design seems to be quite different, since OpenAL is inspired on OpenGL while Miles might have taken a completely different direction. Good luck with that anyway.

Blade · Cyborg Commando **Joined**: 23 Dec 2003

The interface for the AudioManager is a virtual interface thankfully. This has two consequences. First, if we match the virtual table layout (which we've already done for the filesystem for example, so we know its possible), then we can easily call the original miles engine from our code. Second is that the use of miles is abstracted, so the acutal implementation under the hood can be completely different and the original code will still be able to use it so long as the results are the same.

At any rate, if thyme ever wants to run standalone and entirely replace the original binary, it will have to switch to a different audio library for the audio engine as miles doesn't provide any kind of free version that I'm aware of.

I'm more concerned about replacing the DirectX 8 rendering engine to be honest, lots of complicated floating point math to make sense of there.

Blade · Cyborg Commando **Joined**: 23 Dec 2003

I've made the github wiki functionality available at https://github.com/TheAssemblyArmada/Thyme/wiki. Its a bit bare bones for the time being, but if anyone wants to contribute anything to it, I've made the wiki publicly editable. I'll be adding useful information to it as I uncover it in the engine.