All Activity

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?