Printable Version of Topic
Click here to view this topic in its original format
SWR Productions Forum _ Generals/Zerohour Modding _ Thyme, a Generals ZH reimplementation project.
Posted by: Blade 11 Jan 2017, 16:14
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.
Posted by: SoraZ 11 Jan 2017, 16:32
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.
Posted by: Blade 11 Jan 2017, 17:00
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.
Posted by: (USA)Bruce 11 Jan 2017, 18:20
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?
Posted by: Blade 12 Jan 2017, 9:22
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.
Posted by: Jet02 15 Jan 2017, 13:00
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?
Posted by: TimeBurner 15 Jan 2017, 13:06
Whoah! this sounds wonderful. I hope you become successful in the full reconstruction of the engine,if that's what youre doing.
Posted by: Blade 15 Jan 2017, 16:49
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.
Posted by: SoraZ 15 Jan 2017, 17:13
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
Posted by: TimeBurner 15 Jan 2017, 17:42
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.
That would be great in so many different aspects! If I understand correctly,your goal is to make a complete overhaul of the engine,basically updating it so it can support better graphics and remove the current limitations,no?
Posted by: ComradeGeneral 15 Jan 2017, 18:17
A new Bomb Truck disguise that works for infantry?
Posted by: Blade 15 Jan 2017, 22:05
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.
Posted by: Jet02 16 Jan 2017, 10:34
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
Posted by: Blade 16 Jan 2017, 16:53
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.
Posted by: Skitt 16 Jan 2017, 18:32
is it posible to be able to make the engine see terrain hights properly with this?
Posted by: Jet02 17 Jan 2017, 8:25
Can someone pin this topic?
Posted by: M.P 17 Jan 2017, 11:53
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.
Posted by: X1Destroy 19 Jan 2017, 17:30
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.
Posted by: Mizo 20 Jan 2017, 1:52
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?
Posted by: Blade 20 Jan 2017, 16:17
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?
Not yet, though I have added some debug logging, it will only apply to thyme versions of functions, any functions called from the original binary (which is most of them currently) won't have any logging beyond what already exists (crash logs only from the look of it). Better logging will come with time as more functions are thyme functions.
Posted by: Jet02 20 Jan 2017, 16:19
Is there any possibility that this be released before the end of the decade?
Posted by: Blade 20 Jan 2017, 20:36
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.
Posted by: (USA)Bruce 21 Jan 2017, 3:46
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? 
Posted by: Stalker 21 Jan 2017, 9:30
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.
Posted by: Jet02 25 Jan 2017, 12:17
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?
Posted by: Blade 28 Jan 2017, 17:34
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.
Posted by: Chappi55 18 Feb 2017, 9:58
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?)
Posted by: Blade 18 Feb 2017, 16:11
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.
Posted by: Jet02 19 Feb 2017, 15:09
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.
Posted by: Blade 2 Mar 2017, 14:53
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.
Posted by: (USA)Bruce 2 Mar 2017, 18:23
No offence ment but what does this mean? x)
Posted by: Chappi55 2 Mar 2017, 20:52
No offence ment but what does this mean? x)
I'm sorry man I just had to.
As for what it means - it means that their life just got easier.
Posted by: Blade 2 Mar 2017, 22:18
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.
Posted by: Blade 13 Mar 2017, 9:08
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.
Posted by: Zeke 13 Mar 2017, 16:21
You can actually write the full directory of the mod big file to load a mod from outside the default directory.
The bigger problem is that the -mod function only works for a single .big file at a time.
Most mods these days use multiple .big files, because it is more stable and easier to update.
Posted by: Blade 13 Mar 2017, 16:27
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.
Posted by: Zeke 13 Mar 2017, 17:38
I remember someone mentioning that as well, though I never really got around to testing it.
Well if you can make it so that whatever is in -mod will always get loaded last, then that would be helpful.
Posted by: Jet02 28 Mar 2017, 13:15
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?
Posted by: Mizo 20 Apr 2017, 0:59
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?
Posted by: (USA)Bruce 20 Apr 2017, 1:56
^Unrelated; Can you please upload an avatar image or something blade...When you can ofc
Posted by: Blade 6 May 2017, 21:56
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.
Posted by: {Lads}RikerZZZ 7 May 2017, 0:16
is a windowed borderless option possible with these developments?
Posted by: Blade 7 May 2017, 15:42
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.
Posted by: Blade 9 May 2017, 14:10
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.
Posted by: Mizo 12 May 2017, 18:25
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"
Posted by: Zeke 13 May 2017, 5:00
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
Posted by: SoraZ 13 May 2017, 13:01
More bike logic drivers as well (currently it's 8).
Posted by: Oliver 13 May 2017, 13:52
I wonder how much of a trouble would be to introduce more scripts conditions and actions.
Posted by: ComradeGeneral 13 May 2017, 17:00
Getting most of the Unused scripts working would be a nice start. There's a lot of ones there that don't do anything sadly, and they would be useful.
Posted by: Blade 13 May 2017, 22:57
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.
Posted by: {Lads}RikerZZZ 13 May 2017, 23:51
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
Posted by: Blade 13 May 2017, 23:56
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.
Posted by: jl319 15 May 2017, 11:58
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 
Posted by: Mizo 27 May 2017, 17:38
I'll look into it.
Posted by: Blade 6 Jul 2017, 10:49
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.
Posted by: Shiro 6 Jul 2017, 11:41
All of this sounds pretty amazing. I sadly can't help with any of this, but I can at least cheer for you. 
Posted by: {Lads}RikerZZZ 6 Jul 2017, 11:44
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. 
Posted by: Blade 19 Jul 2017, 10:15
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.
Posted by: Mizo 27 Aug 2017, 3:46
Any progress 
?
Posted by: Blade 31 Aug 2017, 15:09
?Just mapped more of the audio engine and wrote skeletons of more of the classes involved. Progress has been a bit slower of late due to real life commitments and me trying to port some of the work done on redalert++ to a similar dll injection project to try and make it easier to get that project past a few road blocks it's hit, though no source release for that yet as I'd need to get other people involved in that to sign off on it.
Posted by: ai_beyondcontrol 3 Sep 2017, 13:45
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!
Posted by: M.P 3 Sep 2017, 16:45
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.
Posted by: Blade 4 Sep 2017, 13:04
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 upgrade limit is almost certainly due to a bitfield object being involved. The size of those are set at compile time, and it is trivially easy to change the actual number involved, but that can change the size and layout of data in memory, so depending on how many bits of code refer specifically to the bitfield, it may require a lot of the game to be reimplemented before it can be changed as we can't change the size and layout of things that we still need to share access to with the original code.
The other logic changes should be possible, but until we have a more complete reimplementation its hard to say how much work they will be to implement.
As M.P. says, the plugins are mostly their own thing. They do share some code with the games relating to w3d handling, but thyme will only give bits required to reimplement them, not everything. I'd personally rather throw support behind https://github.com/sage-team/W3D-Tools to get similar import/export tools available for the open source Blender 3d modelling software as that is freely available.
Finally, what do you mean by worldbuilder support?
Posted by: Blade 4 Sep 2017, 15:36
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.
Posted by: Mizo 6 Sep 2017, 9:18
Things are looking very promising.
Posted by: Oliver 7 Sep 2017, 13:32
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.
Posted by: Skitt 7 Sep 2017, 13:39
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.
Posted by: Blade 8 Sep 2017, 10:20
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.
Its possible that the game is lazy loading the assets it needs and caching them, I've not noticed it myself. Does it affect both skirmish and online play? More code will need reimplementing before we can look at identifying the cause of it anyhow as game logic hasn't really been reached yet.
Regarding the game slowing down, again is this online, offline or both? The more units there are, then the longer it will take to iterate over all of them and do whatever their logic is for each tick, I suspect you perceive this as slowdown as I think the frame rate is linked to the logic tick rate, so anything slowing the ticks slows the frame rate. It would probably take large restructures of the engine to fix that. Such an endeavour would have to wait until practically everything is reimplemented I would imagine.
Posted by: Skitt 8 Sep 2017, 14:34
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.
Posted by: Blade 13 Sep 2017, 11:52
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.
Yeah, that does sound like a lazy load, once we get to the asset loading code it may be possible to have more of the assets loaded up front or push the loading into a background thread on the idea that it will finish loading before the player actually needs it. I'm surprised that player count has much of an impact other than there generally being more units when there are more players. Weather effects I'll bet are being done largely on the CPU from the impact you describe, again once we control the code for them we can look at options for improving it such as having the GPU do more of the work if it isn't already the case.
Does anyone know if any/all of these issues affect the macOS port in the same way? I realise testing multiplayer on it is no longer possible, but a general idea of the state would be useful.
Posted by: Mizo 21 Nov 2017, 1:05
Any progress so far , Blade?
Posted by: Blade 21 Nov 2017, 22:30
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.
Posted by: (USA)Bruce 21 Nov 2017, 23:56
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?
Posted by: Blade 22 Nov 2017, 10:59
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.
Posted by: XoGamer 14 Jan 2018, 20:04
any new news?
Posted by: Mizo 22 Jan 2018, 17:53
Hopefully its not dead :/
Posted by: Grim Tuesday 23 Jan 2018, 21:16
Not at all. Looking at https://github.com/TheAssemblyArmada/Thyme/commits/develop, there was a lot of activity recently (afaik something related to in game scripts).
Posted by: Blade 25 Jan 2018, 10:12
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.
Posted by: Grim Tuesday 25 Jan 2018, 10:55
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.
Posted by: Blade 25 Jan 2018, 12:52
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.
Posted by: XoGamer 25 Jan 2018, 19:41
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?
Posted by: Blade 25 Jan 2018, 20:49
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.
Posted by: Mizo 26 Jan 2018, 15:31
In terms if optimization, have you attempted for that in anyway ( even if its minor).
Posted by: Blade 26 Jan 2018, 17:15
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.
Posted by: Zeke 11 Feb 2018, 5:34
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?
Posted by: Blade 13 Feb 2018, 0:11
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.
And would it be possible for there to be a collaboration between the two of you?
Posted by: Grim Tuesday 13 Feb 2018, 14:19
What do you mean by C&D?
Posted by: Zeke 13 Feb 2018, 14:40
Cease and Desist
Posted by: Grim Tuesday 14 Feb 2018, 10:45
I thought it is legal to reverse engineer a software. Especially if you don't monetize it afterwards.
Posted by: Blade 16 Feb 2018, 12:16
It depends on the jurisdiction, how its done and for what purpose. I don't think that would stop a C&D if EA thought your were threatening their revenue streams though.
Posted by: Blade 20 Feb 2018, 16:48
In case anyone is interested, I've created a dischord server for Thyme at https://discord.gg/YhdMbvD.
Posted by: Zeke 21 Feb 2018, 3:31
"It's about thyme!"
Posted by: vectorguy 25 Jun 2018, 16:30
Wow, I just discovered this thread. Things just sort of went silent.
Posted by: Blade 24 Jul 2018, 10:34
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.
Posted by: GuardianTempest 28 Nov 2018, 23:41
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.
Posted by: Blade 7 Dec 2018, 15:26
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.
Posted by: GuardianTempest 8 Dec 2018, 9:55
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)