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.
Hello there, I saw your project on another forum already. It's nice that you are attempting this.
Also welcome to the forum. Please read the rules and have fun.
Thanks, this is definitely one of those long haul things as the game has a lot of functions that need to be reimplemented, but you got to start somewhere Fingers crossed I can see it through to the end.
Blade I cant state how happy I am that your a part of this forum and the work your doing.I saw your project like a few years ago was it?
Its truely inspiring to find people like Hunter still modding the old sage engine but as inspiring to find someone whos coding an engine from scratch.
I just gotta ask, whats the story behind the name?
You might be confusing this project with OpenSAGE which was using a top down development strategy while this is bottom up and should be fairly accurate to the original, or perhaps the still unreleased RA++ project which I work on with CCHyper?
Regarding the name, Sage 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.
So.... am i correct in assuming that this is an attempt to code a zh clone from scratch? If not, what is it?
And what can we expect from this?
And if it is, are you guys gonna port rotr to it?
Whoah! this sounds wonderful. I hope you become successful in the full reconstruction of the engine,if that's what youre doing.
Yeah, this is an attempt to clone the game engine. Once complete, any engine bugs will be theoretically fixable, new features will be easier to add than hacking the binary and it will be possible to port it to other operating systems. Along the way, some bugs may be fixable without needing complete reimplementation.
Regarding rotr, I'm guessing that is a mod? It should just work, no porting needed unless they have their own engine hacks in place already.
This forum is the host for ROTR and other mods. ROTR subforum http://forums.swr-productions.com/index.php?showforum=22, ModDB page http://www.moddb.com/mods/rise-of-the-reds
Long term, the goal is to make improvements, but even reaching the shorter term goal of just reimplementing the majority of the engine is going to take a long time. I have already made some progress, I've now reimplemented the main function which sets the long version number and does some other house keeping before constructing the actual game engine object, so if you were to build Thyme and run the launcher with the "-fullversion 1" command line argument you would see a new build time on the options screen. It also doesn't require safedisc anymore, so running Thyme would probably be less work than running the game normally on Windows 10, except for the fact no binary versions are currently provided.
I suppose i can make requests here eh?
1. Longer/extendable commandsets
2. More damage types
3. 3+ weapons per unit
Really looking forward to this....keep it up
You can make requests, but they might take a long time to get fulfilled. Extending things like weapon counts and damage types will likely be some of the last things that can be changed depending on how they were coded as they will likely require larger data structures in the game. Unfortunately, they can't be resized until everything that uses them is handled by thyme code rather than the original binary because of the piecemeal approach that is being taken to reimplementing the game. The first fixes I'll likely be able to implement are things like logic bugs, where things happen that shouldn't or extend things such as allow changing hard coded values currently not exposed in ini files.
is it posible to be able to make the engine see terrain hights properly with this?
Can someone pin this topic?
More SpecialPower Enums and SpecialPower decal please :3
EDIT: Please, Remove the upgrade limit (You cant have more than 128 upgrades) and the 8 rider cap on bike and bike logic units please.
Please make the freaking chemical suit upgrade removable without crashing the game and/or a way to permanently remove the radioactive symbol without using a transparent texture.
Thank you very much for your efforts into this.
One of the things I am frankly sad about is that there will always be issues within the game's engine. I am not talking about limitations but other aspects like game and netcode optimization to reduce lag, allowing the game to perhaps use more of the CPU's power ect..
Does this in anyways allow us to track log files where we can pinpoint causes of crashes and mismatches?
Is there any possibility that this be released before the end of the decade?
Its released now, though you have to compile it, but being able to see a different long version number being the only visible difference isn't really going to make it a must download
I think you mean when will a useful version come out that does cool stuff? It depends when I find the stuff that controls it, currently I'm looking at boring things like loading files from disk and such, low level stuff. I could probably add extra command line options pretty quick as I have the code for that mapped out.
Im not much of a code guy myself, so if your recreating zero hour....When your done Im guessing putting the mod files for say ROTR wouldnt just magiccly make it work now would it?
Good luck with your project!
If I get this right, you are calling the original game's functions and step by step replace them with your own? Looks promising.
Also, it's great that you're sharing the code. I hope I'm able to contribute some day.
I was thinking of a "point to control unit in 1st/3rd person" mode a la call to arms but maybe that's a bit too much.
Maybe someone should make a call to arms base building mod instead?
Stalker, yeah that is right, currently the thyme code calls the existing code where functions aren't yet reimplemented. Currently that is most of them, but as more and more functions are done, less will be called from the original until none are and thyme can run on its own. Currently I'm working on the file system handling so loading big files and such and the abstraction needed to open from it or the normal file system.
Bruce, unless rotr uses a hacked exe already with some custom functions, it should work as is when thyme is complete. I hope to be able to have it load original generals content as well if provided with generals game files instead of zh files, but I'm not sure what differences in the engines exactly I'll need to account for.
It's really inspiring seeing you do this kind of thing despite generals age :v (I thought I'm one of the few guys stuck in the nostalgia zone doing stuff with generals).
I'd gladly help however I'm pretty much java programmer at this point and this actually allows me to appreciate your work even better seeing how java is a piece of cake compared to C and C++. How did you start all of this? (Technically speaking, was it trial and error or did you find some technical documentation about the internal engine shenanigans?)
One of the guys I was working on RA++ with was checking all C&C related files and binaries to try and find left over bits of debug information and came across files that contained more or less complete sets of function symbol information for Generals and Zero Hour. Its only with that that it became feasible enough for me to try and map the windows exe to start one of these "bit at a time" re-implementation projects. Drop in on the dev chat on freenode, channel #thyme if you want to chat about it in more detail.
How about smart units? Would that be possible?
There are a lot of things that can be improved upon in this game but that's the only stuff i can think of so far.
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.
No offence ment but what does this mean? x)
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.
I've just about finished reimplementing the functions for initialising the big files. I understand that the -mod command can't override everything in the big files, possibly because it loads mod files somewhat later in the process after already loading some things from the default. Would a new "-root /path/to/stuff" type command line parameter that sets the games whole working directory to somewhere other than the games install directory be useful? Currently the game loads all bigs from the ZH binary directory, then the Generals install directory, then a little further into the init process, it loads the big files in the directory specified by -mod. I could change that to load from the specified root directory, then the ZH install directory, then the Generals install directory then finally the -mod directory.
If you provide -mod with a directory path and not a single .big file name, the code for it suggests it will load all the big files from that directory, not just one. However my understanding was that this can't override some things.
How about if you give units a slightly higher degree of intelligence/autonomity? Not to the point that it becomes an entirely different game, just enough to make battles look less like those of the 18th century.
Also are cover mechanics possible?
Wow wow slow down jet. From what I understand (basically fuck'all) Blade is still far off from getting thyme to initialize the whole game on its own, let alone adding new functions.
Blade, how's your progress so far?
^Unrelated; Can you please upload an avatar image or something blade...When you can ofc
Avatar image done. So I'm currently working on a class called Xfer which seems to be related to saving and loading data, but it needs functions from other classes so I'm implementing parts of those classes sufficient to provide what I need and provide a skeleton for the rest.
Of features I can probably currently add, I can add pretty much anything to how the file system behaves and new command line options that affect things I've currently got mapped in the exe. For example I'm thinking of porting the windowed mode position command line parameters that are available in at least the Rise of the Witch King. Currently I believe windowed mode just draws itself where ever but in ROTWK and probably the other BFME games, you can specify the X and Y for the initial position. Not an amazingly useful feature, but I'm sure it would have some use for people running windowed mode.
is a windowed borderless option possible with these developments?
I've just had a quick check playing with the window style options and it seems that yes, it would be possible to have no title bar or border. Would be pretty easy to work those in as command line options.
And indeed I have now added -noBorder as a command line option when running thyme in addition to the -win options to get a borderless window. -xPos and -yPos control where it is positioned on screen.
Nice job Blade! Keep up the good work. If this works out till the end, you shall be granted the title of "Jesus of Zerohour"
In terms of new features, the most needed ones would be:
- Removal/Increase of upgrade limit
- Ability to add new Special Power Enums
- Ability to add new Special Power Decals
- Ability to add new Damage Types
- Ability to use multiple Overlord Contain objects per unit
- Enable overlord contain objects to use FireWeaponUpdate
More bike logic drivers as well (currently it's 8).
I wonder how much of a trouble would be to introduce more scripts conditions and actions.
Are the unused scripts unused just in ZH or in both ZH and Generals? One of my stretch goals is to make Generals vanilla data files load unmodified in thyme as well, so if script actions need restoring from it, that is one of the things that will happen. Scripts that are totally unused possibly don't have any code behind them so it would be up to us to implement something appropriate.
A lot of the limits look like they come from a templated bitfield class where the range of possible values is set at compile time. Unfortunately, the code that checks them probably also has the range hard coded. Once the code is reimplemented, it should just be a matter of increasing one number, but reimplementing all the relevant code so that the number can be raised will take time.
before the discussions continues to all the new modding parameters, i would just like to say great work on windowed borderless mate
not being able to alt tab in full screen is hell on windows 10
I think the only issue with using a borderless window in place of full screen is that mouse scroll won't work, though that might be fixable down the line when I look at the event handler.
So I chance upon this thread... and read it to the last page so far. Result: My head hurts. I have no background in coding whatsoever, nor can I understand much. It reminds me of when my family discusses genetics and microbiology at the dinner table
My only hope is that this will come with some sort of readme file I can attempt to use as a guide when it finishes
Anyways, best of luck
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.
All of this sounds pretty amazing. I sadly can't help with any of this, but I can at least cheer for you.
For your efforts so far alone you should be awarded the legend tag on the forums.
Seriously Blade, if this keeps up this is going to be an amazingly rewarding project for all of us.
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.
Any progress ?
It is just GREAT to see the birth of this GREAT project! Thank you! It is just so great to see that a new possibility (even a new era) of this beloved game!
Here're some humble idea about the possible feature of the project.
(a) Fix 128 Upgrade Bug: Currently ZH will go crash if the number of upgrade items in Upgrade.ini exceeds 128, known as the 128-upgrade bug.
( Multi-turret Logic: Currently ZH support only 2 turret on any single object, while CNC3 & RA3 support unlimited number of turret on any object.
© Enhanced Support Fire Logic: Currently ZH support fire logic (like the one on Patriot Missile Battery) only works when the attacker and supporter are the exact same type of unit. Maybe extend this to something like CNC3 beam cannon/Venom/Obelisk logic?
(d) Teleporting Logic: Currently it's impossible to teleport units in ZH. Logic similar to Mastermind (CNC3 Scrin) or Firehawk(CNC3 GDI) would be an potent feature.
(e) Extendable Damage Types.
(f) W3D export/import plugin for 3ds max 9 or later: Currently the W3D import/export plugin works only for 3ds max 7/8, which have obviously become obsolete and 3ds max 7/8 are having problems running on Win10 now.
(g) Worldbuilder Support.
Thank you!
The importer/exporter are not related to the game engine. If you want them to work with Max9 or above, You gotta find someone to recreate the plugins.
Just an update on the upgrade limit, it does indeed use a bit field, the debug symbols show an object called "Bitfield<128>" being passed around between a number of upgrade related functions. It looks like this may be part of larger structures, so it will be changeable quite easily, but probably not very soon because it needs a bunch of other stuff in place first.
Things are looking very promising.
I wonder if you could check out why the game only uses a specific amount of ram/CPU even if the game is running in a very good computer... And if that is possible to change with your project.
one thing i noticed a cupple of weeks ago which im wondering if you could change.
when a unit or structure is constructed for the first time in a match theres an fps drop for a few seconds meaning its the game loading the "data" for said unit/structure into the memory for future instances of it in the match from the ini files.
It will increase the initial load time for the game but could it be done to load all of the data into the memory on start up rather than on the fly during a match to improve performance, though the engines memory could probably do with an increase aswell.
it would help explain why the game slows down so much in the later stages of a match due to the memory clogging up.
skirmish and online,
for eg: building a usa powerplant placeing the very first scaffold on the map for the plant causes a 2fps drop for a second or 2, with a further 2 fps drop for a second once the construction is done and the scaffold goes. following usa powerplants dont. the fps drop happens for every structure and unit for the very first time its placed. weirdly avengers cause 5fps.
the slowdows do come from several areas.
connections (player side)
amount of units on the field
amount of players in the match
map size has a low impact
Weather effects are horrendous on performance, regardless of the players cpu, gpu, ram, graphics settings. (they do need an overhaul on performance but are hard coded to the engine)
Length of the match ( 1 hour is average the longest a match can go b4 the game nopes out)
the game engine only uses 1 cpu core.
Any progress so far , Blade?
I've been mapping out all the classes related to the SidesList class, mostly classes from the scripting engine. I've got skeletons of them all implemented, I just need to test the various functions I've implemented before I push it to the main repo. That should be enough to initialise the SidesList global object in the game engines Init function and brings me one step closer to owning the game initialisation code.
I love how I read that like four five times, each time I read it I understand it but then I think afterwards.
"What did he just say?"
You sir should try politics
Also I had this question forwarded to me by the middle eastern crowd when I mentioned how awsome this project is;
Do you accept donations? Or how can a common man who's as clueless as me contribute? Should we try to hire some other programmers?
Ha ha, so SidesList is an object in the game that appears to handle lists of data pertaining to the sides in play on a map as far as I can tell. When I say I have skeletons implemented, I mean I have in C++ objects that should match the data layout of the same thing in the compiled game (so my code will behave the same as the existing code when it has to work on such an object). However I don't have all the code that does stuff with that data implemented.
Game engine initialisation is all the code the game goes through to get ready to do stuff, its the stuff it does while the initial loading screen with the progress bar at the bottom displays. Loads of one time stuff to do things like process the big files and load the ini data.
Regarding donations, I absolutely cannot accept them as I believe it would put the project on shakier legal ground than it already is and more likely to draw the ire of EA which we definitely don't want. In terms of programmers, they would need to have some familiarity with IDA or a similar tool to map out and understand the original binary and C/C++ knowledge to be able to write re-implementations of the games functions that behave similarly enough that the game doesn't notice we swapped them out.
There are some parts that could be done that don't need any further knowledge of the binary such as implementing an alternative audio engine which should be possible on top of what I've already implemented. They just need a C++ programmer with knowledge of something like OpenAL and maybe some hints from me as to how the original Miles audio class worked.
None programming wise, if I have questions related to how the game behaves when certain things are set or changed then people who are familiar with making mods that use the code I'm trying to understand could be a great help. You could also grab the binaries that come out of the appveyor build service and run them and see if the game behaves as it should and if not report bugs that I've introduced. You would need the game.dat from an English CD release patched to 1.04 though as Thyme is written against that specific version and won't run correctly with any other game.dat.
any new news?
Hopefully its not dead :/
Its certainly not dead, keep an eye on the branches at https://github.com/OmniBlade/Thyme which is where I prestage different areas I'm working on before merging them into the main repo.
The script stuff is everything but the actual script engine that brings it all together, its was mostly to support the implementation of SidesList. I've also added a hack to allow online play on cnc-online, though there appear to be a few bugs that are causing desyncs that I need to locate and resolve before its actually useable.
Some lulls are due to me either trying to map and understand an area of the game before I try and reimplement it or because I'm working on the sister project RA++ t reimplement the original Red Alert.
It would be cool, if you could specify the multiplayer server address in game or trough flag. This way we would not need current workaround for mods like swr.net.
I'd rather not complicate the hack as it currently stands at the moment, but I would like to add the ability to change the servers used for match making in the future. It will require some changes to the gamespy sdk which the game is built against as as it exists currently, the name is hard coded at compile time. For now it would be possible to change the names in the hack (in dllmain.cpp) and build a custom dll that will connect to alternate servers though.
wait with this, could you fix multiplayer lag/mismatch (make better, ik you can't fix it for sure) or force the game to use more than one core?
It will certainly make it possible to start debugging the network issues as we will be able to add more logging as required to try and trace where the desync happened so we can start looking at what we can do about it. Regarding using more cores, that will likely require reworking significant parts of the engine. Using more cores doesn't equal better performing game, we might be able to squeeze more out of a single core by optimising what exists though.
In terms if optimization, have you attempted for that in anyway ( even if its minor).
Not yet, most of the code so far has been related to loading things, it occurs once at load up and is probably more bound by disk io than CPU. Just recompiling with modern compilers could give improvements however, such as being able to compile for SSE/SSE2 instructions instead of the old FPU.
Not sure if this has been asked before (I have a vague feeling that it has), but do you know of this project? https://forums.cncnz.com/topic/21241-first-version-of-opensage-published/
And would it be possible for there to be a collaboration between the two of you?
I've been aware of it for some time, the lead dev has made it clear that he isn't interested in any information gleaned from examining the actual game code, presumably to attempt to keep the project being tainted with possible copyright claims from EA to shut them down, though pratically if EA hit them with a C&D they would not be able to defend it. To me this means he doesn't want any contributors to look at Thyme and thus collaborate at the code level, all I can give is helpful hints.
The approach they are taking is to look at how the game appears to behave and then attempt to write code that mimics that apparent behaviour rather than attempt to write code that is equivalent at the function level. Its like comparing FreeRCT to OpenRCT2 in their approaches.
My personal view is that people work on what they want to work on, but that its a shame that effort ends up being divided and barring legal intervention from EA, that Thyme will end up being playable quicker and be more faithful and compatible with the original games and mods. Then again, Thyme is my project so I'm biased Maybe I need to be more evangelical about Thyme, but until I get to a class or feature that I can really sell it on I feel like I would be selling vapourware.
What do you mean by C&D?
I thought it is legal to reverse engineer a software. Especially if you don't monetize it afterwards.
In case anyone is interested, I've created a dischord server for Thyme at https://discord.gg/YhdMbvD.
"It's about thyme!"
Wow, I just discovered this thread. Things just sort of went silent.
The discord group is a bit more active when it comes to discussions. I've recently merged in a lot of work on the particle system classes that handle a lot of the maths related to them though, development is still very much active.
Sorry for bumping, Discord link is dead.
Also, keep up the good work. If you get far, this could be the ZH equivalent of ARES.
New link is https://discord.gg/UnWK2Tw. If we get far enough this will surpass ARES in that it will allow not only improvements, but porting to other platforms. ZH on a raspberry pi maybe? Ares takes a lot of shortcuts to implement new features, they aren't interested in reimplementing the entire engine or if they are, aren't working directly to that end.
Well I suppose it's okay for a (relatively) light-spec game like RA2, plus it leaves no hassle since virtually no files have to be modified (unless the mod is extensive). I presume that for Thyme's endgame, the package will become its own standalone application? It's either that or a ton of file juggling.
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)