All Activity

Thank you Jon. A great deal of what you have shared is rather useful. I actually wish I could have discussed this all with you ahead of the original post to clean it up a bit... and to set you straight on what this endeavor is about. You have provided some rather great insight into the engines, but I need be clear that this is not about modernizing Renegade nor Generals. This is about modernizing the very engines that power those games: Westwood 3D and SAGE, with the intention to make new games/projects on them. One could technically make a modern version of Renegade or Generals using this process, but they will need to rebuild the binaries in Visual Studio 6.0 before getting the project to a modern VS file type via Visual Studio 2003. This is not meant to guide someone to do so. The Git repositories set up by EA do a good job setting up a step-by-step for how to achieve that. Things that I'm thankful you've corrected me on Thanks for the correction on Generals. It was built on Westwood 3D so it uses the same DirectX 8.1 driver. Though, as you said, all games starting with BFME in 2004 are built on DirectX 9, so SAGE 1.0 is, for all intents and purposes, ultimately a DX9 base. It should be noted that EA's github notes mention that SAGE requires DX9's source code/headers, but not DX8.1, which means it's built with DX9. Though, for Generals to run on XP via DX8 it would need DX8.1b, but it's also likely that Generals only has the DX8.1 drivers for running on Windows older than XP since base 8.1 is not compatible with XP. FFMPEG is a great recommendation for those who still wish to use the Bink video format (and other formats), however without an alternative for a means to compress video into the proprietary Bink/Bink 2 format in the first place outside of the Rad Game Tools, it's only good for those remastering Renegade and Generals. Besides, a Rad Game Tools license allows you to use the necessary tools and source code for free until your game starts making money. Honestly, as I have written, you can just do as Valve did and replace the Bink format with a open source one with better compression. All the same, it's good to have more than one option for this. Thanks for the heads up on the Asset Importer (Asimp3), I should update that section to reflect that (serves me right for getting that link from another fan who just lazily found it using an LLM algorithm). Thanks for letting me know where the NVidia tools (NvDXTLib and NVASM)were being used. Interesting that Westwood and EALA used those libraries for the editor only (though they could have easily used them for the main games' textures and done some limited shading FX). Although I already knew that Lightscape was for the baked in lighting, it's good to know that it is indeed completely obsolete as a library for WW3D (SAGE already removed it). Thanks for that, I wasn't fully confident that it was only just for that when I posted. Thanks for the heads up regarding the WW3D/SAGE engine format usage (though it doesn't answer some outlier questions). Glad I found EASTL then. Rather (unusually) thankful for EA providing that for our use (and the link for the most up-to-date version)! That's a rare EA win... that feels wrong. Thanks for confirming that about the Umbra code. I mean, the only thing the file does is plug the existing Renegade camera into Umbra, thus turning the RenCamera into an Umbra camera by replacing all of the occlusion culling calculations with Umbra's. It's a rather roundabout way to use Umbra without creating a new camera and I agree that it's not needed at all. Even better for it that the community can build on the existing WW3D/SAGE cameras for better occlusion culling. Gamespy definitely has a great amount of options. Despite being spoiled for choice, working with the CNC Online team would be the best for any remakes/remasters of Renegade and Generals, but for any new projects, OpenSpy and UniSpy are the best options for reusing the GS online code. The Steam option was placed there for those who wanted to scrap Gamespy completely and try Steam's option instead. Thanks for the LZH-light information. That makes the choice easier (I'll have to edit that one). It's rather strange that it was in the Generals code, but it might have been a leftover from Westwood's part in Generals' development before being handed over to EALA. I agree with that sentiment about RTPatching, however finding that open source solution is difficult as I have never had to deal with it. That said, maybe the following options could be [PDQ Deploy (Enterprise version has more options, but otherwise free)] or [Ansible (OS agnostic, great for Unix/Linux OS's)]. Perhaps the following chart of open source patching tools can be of use (this is definitely outside of my expertise): Good to know about the Java being removable. I'll have to update that section. I'm glad that I'm not the only one who wants to preserve Westwood's Math and Physics libraries and just improve them using modern implementations. However, it is not impossible to replace them, it just takes work. After all, EALA did just that with SAGE 2 by replacing both with RenderWare's libraries (hence why we are probably not getting the source code for Red Alert 3 thanks to RenderWare still being proprietary). Things I wish you were more careful about posting This modernization subject has always been about the engines, and not the games built on them specifically. As such, stating what API that Renegade and Generals used as some kind of limitation is ignoring the fact that both of those games can be rebuilt using either a modern version of DirectX or even switch over to OpenGl/Vulkan (or even having BOTH at the cost of bloating the code). This the core of my endeavor; to build a modern, 64bit foundation for new projects made with Westwood 3D and SAGE. Not to simply modernize Renegade and Generals (as noble a task that would be). Proof that WW3D/SAGE is API agnostic is the fact that the C&C MacOS ports use OpenGL due to Macs being Unix-based. Generals may use the DirectX 8.1 driver, but the source code is indicating DirectX 9 headers. This is where things are tricky on the programming side of things. You can in fact write a DirectX program that has elements from different versions. Consider the fact that Generals needs a DX8.1 driver, but not DX8.1b, suggests that it's only used for backwards compatibility for older Windows versions. Generals launched being able to run on Windows XP, which requires DirectX 9 (native for XP and launched with it) or at least a code based in DirectX 8.1b or later versions of DX8. XP doesn't support programs written needing drivers older than DX8.1b, so it's simply not possible for Generals to have been written with the exact same API as Renegade and still be installable on Windows XP. Games may target the most common hardware for the minimum requirements, but they are often developed with future proofing in mind. This is why I also doubt that Battle For Middle Earth was the first time that SAGE was in DirectX 9 despite needing a DX9 driver. That game was infamously made in only 9 months on crunch time (which led to a rather noteworthy lawsuit), which was very shortly after Zero Hour was launched and would have left very little room for API experimentation, which means they had to build with what SAGE already had. This goes the same for SAGE 2: just because Red Alert 3, Uprising, and C&C4 use DX9c drivers does not indicate the API base. This gets even trickier for SAGE 2 because DirectX 9c is still used in the industry as a goto backwards compatibility driver due to Microsoft's continued support for it (even engines like Panda3D have a DX9 renderer for this purpose despite being based in OpenGL), however, Vista released with more than one Direct3D library. In particular, Vista's DirectX has Direct3D 9 as part of its library in addition to Direct3D 10, which allows Vista to emulate DX9. Without the source code, it's hard to make a determination of what SAGE 2 uses as the API base, though, given how much better shaders looked in Red Alert 3 compared to Kane's Wrath, there is a high chance that SAGE 2 leverages Direct3D 10's newer shader updates when running on Vista. The NVidia tools, as stated in the main post, are not necessary. DXT is the native texture compression in DirectX and as such nvDXTLib can be supplanted with the existing libraries in modern DirectX, or even OpenGL/Vulkan if one decides to use those APIs instead. So you really are not going to lose the capabilities that they provided. Speaking of which... HLSL stands for High-Level Shading/Shader Language. That has EVERYTHING to do with the shading used in General's World Builder editor because it's how shaders are written. Specifically, it's used for SAGE's texture blending in the editor when painting terrain, blurring it with another texture, and saving that information for the level. Modern APIs have that in their libraries. DirectX uses HLSL, OpenGL uses ARG, and Vulkan has its own. So you can replace this tool rather confidently with native libraries. I'm not confident believing that WW3D and SAGE games only use the W3D format for all 3D models. If they do, that's rather strange. I mean, why use a format that specializes in animated meshes with particle information for something static like, for example, a tree? The Renegade 2 files that were released after Westwood closed had Maya Binary (.mb) models included with the in-progress GMAX files and finalized W3D models. That implied to me that Westwood was using both Maya and GMAX, but also maybe that Maya files were being used for static meshes. You have to understand that other companies, like id Software, use a mixture of 3D file types. The id Tech engines have the native id Tech Model format (currently .MD6 for modern id Tech engines), but the engines can also load ASE and lwo models (and that doesn't include the 3D brush models made in-engine). That's where my assumption that Westwood did the same in regards to being able to load formats directly from the modelling software that they were using. If that's not true, then it should be made so with a modern implementation. It's rather useful to have more than one type of 3D model format, and multiple engines have had this capability for quite some time. So pardon me if I find this to be incredulous when it comes to WW3D and engines based on it. Telemetry might be unnecessary for existing games like Renegade and Generals, but not for newer games made with modern API implementation of WW3D and SAGE in mind! NBench is terribly outdated, but a built-in telemetry tool, preferably one we don't have to pay for like Rad Game Tools'... tool, would be very useful! Anything built with newer hardware in mind needs to be tested so it can be optimized. Once again, this is a MODERNIZATION project. The GNU Regular Expressions (RegEx) library is only needed for its posix libraries. This is useful for making a version of Renegade that runs in Linux (or Mac).... IF THIS WERE THE 1990s. The reason there are no modern versions of RegEx is because it is obsolete thanks to modern C library implementations integrating its functionality. It's honestly not necessary and won't compile in modern compilers anyway. You literally reiterated what I had already said about SafeDisk. Though it is interesting about the MS Cabinet code being used for the installer, it's an outdated, proprietary compression format that no one uses for games anymore. The Zip File library (ZLIB) is a superior, open source, replacement that SAGE uses. Westwood 3D should use it too when modernizing it. Otherwise, we would have to shill out money to use Rad Game Tools' Oodle (which does have superior compression options). Converting a dsw Visual Studio program (VS 6.0) to the modern VS format is both straight forward and difficult. Specifically, only Visual Studio 2003 can convert the older dsw format to the new Visual Studio format (as stated in the Github pages). From there, loading that converted project code in a modern Visual Studio will convert it further to a more modern version. However, no Visual Studio past 2003 can read and convert old dsw files (I tried). Furthermore, you talk of Renegade and Generals, games that cannot be rebuilt without first loading the code in a working copy of Visual Studio 6.0 SP5 so that the binaries match the last patches for those games. That part is EXTREMELY difficult to get working. Thankfully, you accidentally given me a spark of inspiration: by trivializing the Visual Studio part you've reminded me that I am not trying to make Renegade nor Generals. I'm working on modernizing the engines behind them! That means I don't have to worry about the binaries for games that will be undergoing heavy modernization! It really is easier than I thought it would be (VS2003 still runs on Windows 10 miraculously). Still a good deal of work, but now better focused. Thank you. If you would permit it, I would like to update the modernization list with some of the new information.

[blurb]On December 26th at 8 PM GMT[/blurb]

Celebrating the life of Udo KierLast month we were saddened by the unfortunate news that Udo Kier, who played the psychic mastermind Yuri in Red Alert 2 and Yuri's Revenge, sadly passed away at the age of 81. Udo's performance as Yuri in RA2 became one of those rare moments where an actor doesn’t just play a character—they reshape an entire community’s culture. His eerie performance as Yuri transcended his role as a simple RTS villain, becoming a cult figure in the world of strategy games that players would rally around and quote for decades to come. In memory of the great theatrical performance that Udo gave us in his role as Yuri, we have released a new patch which aims to introduce some of the spirit and flavour of Yuri's forces into Apocalypse Rising in order to carry on the legacy of Udo's impact on the Command & Conquer Community. Credit to @ Battle Dreadnought for the image below. R.I.P Udo Kier - 1944 - 2025 Hail to the great Yuri. [blurb]The latest update for Apocalypse Rising is out, celebrating the life and influence of Udo Kier.[/blurb] Update 0.9.0.9 The changelog for update 0.9.0.9 is below: Yuri is Master! Head over to the discord for all of out latest updates. As ever, feel free to leave your feedback and we'll hopefully address the issues in the next update! We'll hopefully be focusing on performance moving forward whilst working on some new maps (as well as balance updates), so stay tuned in the new year for that! Have a very Merry Christmas and a Happy New Year! - @ OWA , @ moonsense715 and the AR Dev Team

A massive thank you to everyone who voted for us in the first round of the IndieDB Awards this year! We're proud to announce that we've made it into the top 100, which is incredible for a relatively small and obscure fan project like ours! There's now two days left to vote for us again to make it into the top 10, so we are calling upon your help again! Please help us put this ol' C&C fan game into the public eye! You can vote for us by clicking the image below! [blurb]Comrades! We need your help to get into IndieDB's top 10! Head to IndieDB and support C&C fan games like ours![/blurb]

As someone who has been working with these engines for decades, I can tell you now that you do not need OpenGL in any way for these engines, nothing in the source release needs it. As for DirectX, both Renegade and Generals used DirectX 8, not DirectX 9. EA Started using DirectX 9 for the games with the first BFME game and then used DirectX 9 all the way through to Tiberian Twilight. But more specifically, going over the listed requirements in https://github.com/electronicarts/CnC_Renegade/blob/main/README.md and https://github.com/electronicarts/CnC_Generals_Zero_Hour/blob/main/README.md: The DirectX SDK that matches what was used back in the day for Renegade is this one https://archive.org/details/dx8sdk. For Generals, its this one https://archive.org/details/dx9sdk (although as mentioned, its still using DirectX 8, just using the slightly newer version of the DirectX 8 bits that come with the linked DirectX 9 SDK) And the windows header files that you need will come with the compiler so you don't need anything extra for those. (the stuff you linked to for DirectX and Windows headers is not what you need for Renegade or Generals). For Bink, the best way to replace it would be to replace the Bink SDK with FFMPEG which is capable of decoding the Bink videos. You could then also add support for other video formats at the same time (webm/VP9 is a good choice for a modern video format and FFMPEG can decode that as well) For Miles, Asimp3 has nothing to do with that assimp thing you linked to. Its a thing for decoding MP3 files that is part of the Miles Sound System and is not required for actually working with Generals/ZH source code (its part of some leftover audio code from older games that isn't actually used by Generals/ZH). And for replacing it, FMOD is a good choice, as is OpenAL. NvDXTLib is used by the Renegade level editor to compress textures. Its not necessary if you are building the game itself. If you are building the level editor and don't want to mess with it, you can just remove the code that uses it and things will still work correctly except for the texture compression feature (which isn't essential). Or you can find something else that can do texture compression in the right formats and replace it that way. NVASM has nothing to do with HLSL and is used to assemble the shader files in Generals/ZH. You don't need it unless you want to modify the shader files. If you don't want to modify the shader files, you can just remove those references from the source code and things will still work just fine. Lightscape is a tool that was used to generate pre-baked lightmaps for the game and has nothing to do with the 3D data itself. There are other better ways to make such textures now. And you don't need the Lightscape bits at all unless you want to compile the lightscape tool. All the games (Earth & Beyond, Renegade, Generals, Zero Hour, BFME1, BFME2, Tiberium Wars, Kane's Wrath, Red Alert 3, Uprising and Tiberian Twilight) only ever used 3DS Max for building 3D models and all the games had a custom 3DS max plugin for that purpose. Gmax was supported by the Renegade mod SDK as a way to allow the community to make models for these games (since gmax was free). The engines themselves never read 3DS Max, Maya, Gmax or any other formats, only .w3d (or for the later games, .w3x). And there is no need to throw away .w3d or switch to any other 3d formats, if you can't or don't want to use 3DS Max or GMAX for making 3D models, there is a plugin out there you can use with Blender (which is 100% free) to make your .w3d files. I can't comment on nbench but I can say that modern telemetry almost certainly isn't necessary, these engines don't place anywhere near enough load on modern hardware (network, disk or otherwise) to make any real difference. As for STLPort, EASTL is probably the best option if you are working with more modern stuff and want to replace STLPort. (in fact based on leftover debug strings in the games I can confirm that Red Alert 3, Uprising and Tiberian Twilight all use EASTL in some form instead of the STLPort that the earlier games were using). EASTL is good because its designed specifically for use in games so its going to have performance and the things games need in mind. For Umbra, Westwood was planning to use it for Renegade at one point (hence the code for it in the codebase) but the game as shipped never used Umbra for anything and you don't need any Umbra bits to actually work with the source code. Its using its own occlusion culling logic that's specific to Renegade and you can't just drop in some other occlusion culling system (although there is definitely room to make the Renegade system better if you wanted to) GameSpy there are obviously options for that, I don't know what makes the most sense though. For GNU Regex, https://directory.fsf.org/wiki/Regex has the needed bits. SafeDisk SDK you can just rip out and be done with it. The .cab stuff is used in the installer specifically. https://web.archive.org/web/20040603061506/http://msdn.microsoft.com/library/en-us/dncabsdk/html/cabdl.asp has the right .cab SDK bits. Zlib was never used in Renegade and only used in Generals/ZH for some compression stuff. I don't think its actually necessary but since its still available and still usable, you can just drop it in. LZH-light is a leftover from an earlier game (NOX) and is not actually necessary (you could rip it all out and be fine) There are definitely solutions out there for replacing RTPatch including solutions that don't cost money. The "server stuff" that is using Java is only for the old Renegade ladder/game results server and you don't need that stuff anymore. As for math and physics, replacing them wholesale just isn't going to work and you are better off improving what's there. If you build these things with modern compilers and turn on the necessary compile options, they will automatically take advantage of SSE instructions without you needing to do anything (at least excluding the few bits that use inline assembler). And 3rd party libraries don't care if the thing using them is compiled with SSE or not. And updating the project to a newer version of Visual Studio isn't hard, Visual Studio has ways to convert them (although I don't know for sure how you do it these days).

Umbra Update I have some good news, and bad news, regarding Renegade's Umbra implementation. Let's start with the bad news Commanders. The bad news is that the Umbra 3D team is too busy (and understaffed) to process individual requests, and thus that means it is very unlikely for us to get a license and source code to use in our implementation of Westwood 3D's Umbra code in the near future. However... The good news is that we don't even need it for WW3D's camera to work! That's right! The Umbra occlusion code in WW3D is just a parser that Westwood fed their camera into to make it more optimal like Umbra, but it's just one code file in the WWPhysics section (weird placement, but OK) and it can be removed with no consequences! Just like what SAGE did. As a matter of fact, that reinforces what I said about cross checking WW3D's camera code with SAGE's camera; since SAGE removed Umbra, it is likely that the EALA team made the adjustments needed to no longer rely on it. That's great news! That means we can build off of the existing camera code to make improvements in occlusion culling without too much worry that we are missing out on what Umbra has to offer. And, if Umbra 3D's situation changes, we will still have the parser code to make use of Umbra if the chance arrives.

Hi folks! We haven't been eligible in a while, but since we released this year, we're in the running for ModDB's Indie of the Year Awards 2025! There's only 2 days left to vote, but your vote could help us break into the top 100! Please consider supporting us by leaving a vote at the link below!: Link: → https://www.moddb.com/games/red-alert-2-apocalypse-rising [blurb]Nominate us for the Indie of the Year awards top 100![/blurb]

On December 7th at 8 PM GMT

[blurb]On December 6th at 8 PM GMT Commemorating the life of actor Udo Kier, who portrayed Comrade Yuri in the FMVs.[/blurb]

[blurb]On November 29th at 8 PM GMT[/blurb]

[blurb]On November 22nd at 8 PM GMT[/blurb]

[blurb]This is just a small update that adds the B-52 Bomber, as well as several fixes and improvements.[/blurb] This is just a small update that adds the B-52 Bomber, as well as several fixes and improvements. New Features B-52 Bomber has been added, enjoy doing bombing runs on unsuspecting targets! Added some new net code to support syncing the B-52’s bombs (yes, they inherit the physics of the plane) Pin System has been reworked a bit to make it more secure: Server now logs players out after 2 minutes if they haven’t successfully entered a pin. Server now logs players out after 5 incorrect pin attempts. Improvements/Bug Fixes Updated taxi paths, taxis will now drop players off at the hospital, closer to the motel, and near the police parking garage instead of dumping them in the middle of the road. Updated the data in the crash dumps file to include a list of players as well as the game running time to assist me in debugging. Civilian cars no longer de-spawn on an empty server (This was originally in place to keep the server from being hammered all day, but the new server is plenty powerful to not suffer from this). Upgraded how serverStatus.txt is updated, during map loading it now is updated to “Loading…” If the server locks up it will now restart within 30 seconds, this originally wasn’t possible as I couldn’t detect when the server was loading, but that feature is now possible with bhs updates. Master of Disguise’s wording no longer implies that the player won’t be detected by home defenses. Code formatting and structure cleanup as usual to help my sanity.

Well I find last ver 4.2.4 https://multiplayerforums.com/files/file/9-coopbeta/ Does anyone know if it's configured or if I need to edit the ini?