MrParrot

New ROM available! - Added support for DS phat and lite (requires the expansion pak on GBA slot).

Sorry, but I don't.

Ladies and Gentlemen, I present to you Command & Conquer: Red Alert ported to the Nintendo DSi. It is based on Vanilla-Conquer, the source port of C&C Remastered aimed to run on the classic engine. Supported features: √ Full campaign support. √ Counterstrike and Aftermath. √ All FMV content is available. √ Sound and Music. Every track is available, and every sound effect too. √ Skirmish game. √ Savegames. Unsupported Features: x Multiplayer game. x Dual Screen support. Only the bottom screen is used in game. x Nintendo DS phat and Nintendo DS Lite: Not enough RAM. Download and How to play: HERE! Screenshots in attachment. Please report bugs on the GitHub page. Happy Conquering!

New ROM available for download! Major changes: - Better performance - Fixed tickling sound on music - Fixed VQA audio cutting out - Many bugfixes submit to Vanilla-Conquer sourceport incorporated.

Update: Fixed download link.

Ladies and Gentlemen, I present to you the first beta of C&C1 ported to the Nintendo DSi. It is based on Vanilla-Conquer, the source port of C&C Remastered aimed to run on the classic engine. Supported features: √ Full campaign support: all 15 GDI missions, all 13 Nod missions. √ Covert Operations expansion. √ All FMV content is available. Are you picking this up? √ Sound and Music. Every track is available, and every sound effect too. √ Skirmish game. √ Savegames. Unsupported Features: x Multiplayer game. x Dual Screen support. Only the bottom screen is used in game. Download and How to play: HERE! EXPANSION PAK OR DSi MODEL REQUIRED Screenshots in attachment. Please report bugs on the GitHub page. Happy Conquering!

Interesting. Good work filling the gaps there! My question is: Have someone made that code work into something? (for instance, the remaster itself). If yes, we could prototype a "128x128" map version there, and once (and if) we get it working, try porting it back to the original C&C95. The thing is that if we assume that (1) - Every use of those MAP_CELL_MAX_X_BITS, MAP_CELL_MAX_Y_BITS, ..., MAP_CELL_TOTAL are in the part that EA released (2) - We have a working copy of the compiler, assembler and linker used in the game, with the same flags the developers used in the release. (3) - The compiler did a good job in constant folding these attributes to their uses. (4) - Condition (1) was the only necessary thing to make the maps larger in the binary. Larger map editors, and converting old maps to the new format is a problem for the future Then we could track what functions these macros were folded in, therefore generating a list of every function we may have to look into. Generating such list is not hard, we could do a diff in the object files before and after the changes, track back to the function assembler name, and demangle then back to the source code After comes the laborious part. It would be necessary to map all these functions in the binary, so we get a full list of where to change. Then we could use the original compiler used in the game to compile the code with our changes, and manually replace each function into the binary with our code. Caution is required in the replacement, because we need to find the addresses of the objects externally of the current object file, and replace their addresses manually (for example, the call insn would be E8 00 00 00 00 on the object file, but could be E8 AA BB CC DD once all objects file have been linked together) If we assume that we have a working copy of the original compiler, I would expect that we could generate the same code as is in the binary. And more, since we are modifying a bunch of constants (multipling a power of 2 by 2), I would not expect any generated code growth, and therefore we would have just enough space in the binary. However, things get very complicated if condition (1) is not satisfied, because we may end into a problem in somewhere we don't know exactly what it expects, nor exactly the cause. Condition (2) may be worked around if we have a compiler that is capable of respecting the calling conventions used by the game's compiler, and it always generate smaller code (maybe gcc with -Os). If condition (4) is not satisfied, the list of modified functions may increase, but it still doable. ... Or we could simple wait until the devs manage to compile that code into a single game, implementing things there and be happy

Wait... The remaster and the original game does not share that same code then? So if you say so, I assume that the devs already have the original game up and running from recompiling this code, no? Does you guys have a link to the project?

(bumping a 7 years old topic) Any updates on this? The sourcecode of the game was released, and I can`t see why the remaster is still relying on old 64x64 max map size. I have not tried rebuilding the TIBERIANDAWN.DLL since I do not have VisualStudio, but what is preventing the game from having larger maps besides from those macros at DEFINES.H?

I played this yesterday afternoon, and here is my first impression about this game. Graphics: They did a good job in my opinion. They implemented movement acceleration, everything looks crisp and clear, and seems faithful to the original game. Surely some animations like the Comm. Center rotation could be smoother by having more frames, but that's ok. Sound: Everything sounds great in this game, just like in a modern game. However, when units are not visible, sounds played on the west, outside of visible area, get played on right headphone channel, which always get me confused. Also, that Tiberium Sons soundtrack is awesome! AI: It was indeed improved. Now it looks like I am playing against Dune 2000 or Red Alert 1 AI, which is a great addition to what we got in TD. And yes, they kept that stupid harvester AI. Gameplay: Things are different, which is great for ones, bad of others. Better in a way that we now get a really precise mouse cursor that moves as if I was moving it in my desktop, which is great. Unit queuing and healthbar showing is also very interesting, which makes it easier to micro-manage and focus on damaged units. The Tiberium growth rate was increased too. Now about the singleplayer: It seems that developers didn't test all missions. GDI Mission 8b (Defend Moebius) is a nightmare with this settings. First because they decided to make all civilians stupid and move everywhere, attack your units for no reason, thus leaving you no other choice than using lethal force and sandbagging the entire city. I failed it once because I had to kill so many civilians :P. The increased Tiberium spawn also made it harder to control that Tiberium spread across the city. About Multiplayer: Now it runs on normal speed, just as it did when played on Dial-up modems back then. This drastically changed the gameplay, as it now benefits players that micro-manage units and have a more efficient economy. From all games that I have played so far, none of them evolved to a later game situation where both players had superweapons or multiple CY and creeped the other player with obelisks, which is pretty usual on CnCNet. Also, it looks like it only includes the original maps (Green Acres, Nowhere to Hide, Red Sands and Tiberium Garden). Weren't there community maps included? Surely most of them couldn't be added due to copyright issues. Now, since the original maps have small Tib. Fields, The increased Tiberium spread is welcome here. Also, does this game add support for larger maps? Very well, why aren't them available then? With regard to networking, IIRC, the 4-player limit was present when playing this game on LAN, and I have no idea how CnCNet devs managed to get 6 to work. Also, units movement when playing online looks as laggy as the original, which means they probably didn't reworked on that. Now comes some technical questions: Why the hell that game have so many frame drops, with audio dropping as well? That is still a 2D game with no fancy effects, absurd poligons, dynamic lightning and stuff. Mostly of it are planes and pre-rendered animations, and therefore don't think the reason behind it is due to transparency calculation. I could be wrong, tho, but I can't see why a 8th Gen Core-i7 APU can't run it stable. Note that I am not speaking about 60fps, I am complaining about absurd framedrops. Overall, the game pretty faithful to the original, and the work done was indeed great. That indeed is worth the value I played on it. I just hope that now the developers maintain the game with care, improving the game optimization, fixing bugs, and leting it live, just like what Valve does with their classics. It is not, by far, a bad game from a multiplayer perspective, but it can (and should be) improved. Hope that they does it with time. [edit] Come on. Remastered Hard difficulty just changes multipliers? A light tank can easily destroy a medium tank? wtf!

Have you managed to recompile it, or you are still looking into the code and modifying the assembler?

I think the first step is to recompile the game and make it run as the original, reimplementing the missing parts (renderer, audio what else?) but with a modern operating system and a modern toolchain. After that, we may even replace the C&C original binary with this new one. That certainly will speedup fixes, make an skirmish AI possible, make bigger maps possible, add support to more players, add a better networking algorithm to avoid desync, etc. it would be also possible to port it to other platforms, such as cellphones, and maybe homebrews for consoles. The limit is simple the time and skills of the developer and what a machine can process. To be quite honest, I am more attracted to the source code release than the remaster itself.

Great! Oh, if I had time to explore it myself. Has someone any success compiling it with GCC?

s/remake/remaster/g The argument is the same

Wow, nice work! That is absolutely impressive! nice cities design, nice new units! Stunning quality mod! Just.... Why that barracks has a giant turret on top? And why a dragon? I found a issue with the chinook. If you put one questionstalk, the chinook flies away. Did you replace a civilian with it?

Hi. Today I waked up with this interesting news: https://www.ea.com/games/command-and-conquer/command-and-conquer-remastered/news/remaster-update-modding There we read: Do someone have more information about this? What are the content of these two DLLs? That is at least, interesting. Later on they say that Which does make me believe that the entire game source code will be released under GPL-3 license. That make me believe that the game's code such as the engine, renderer, etc (but maybe not the art) will be open and provided for free for anyone to download and redistribute as they wish.

Does it have an Intel or AMD CPU? If true, then yes. I can't enter in details because I don't have a Mac, but it should be very similar to how you should perform in Linux to install it. Install Wine, then install the Windows version, then in winecfg you should make sure to override ddraw.dll for both C&C95.exe and cnc95.exe.

Come on. There is no excuse in this remake to: Not change the harvesting AI, as it is currently pretty basic. Not changing the AI attack targeting, as it always attacks the northwest unit, ignore unreachable terrains, etc. That is absolutely lame. Not allowing maps at least four times bigger, doubling each dimension size. Not allowing some more advanced map scripting, as it is in RA. Rework the network protocol. Release a CD-quality soundtrack. There is still musics in the original game that are still not available in CD-like formats. We are not asking for a new balance or a rewrite from the ground up. That is what OpenRA is, and we don`t expect another OpenRA. I expect the same game with improvements in the AI and in the maps, not how, for instance, the AGT and Obeliks shoots from one cell up, the ability to base-crawl and other details that make this game unique. To take a stand about what I expect, take for example how the Turok series was remastered for the PC. It is the same game, just patching that glitchy and jittered aiming mechanic, a less intense fog, improved framerate, completely eliminating pretty much all bad points in that game and providing a much more pleasurable gaming experience. It is not a new game, it is just the old on steroids. That is what I expect from this release. I hope they address these issues in the future, and they didn`t create so much hype for it to be another disappointment in C&C Series. By the way, 20 euros can be really expensive if you are not paying in Euros ;D

Hi. It is 2020 and CnCNet gave us so much improvement when comparing to 2006, when XWIS was the only thing we had. Back there I remember we basically had 3 Map Editiors for TD: CCMap: A Map editor for MS-DOS. Very unstable and ran in Fullscreen on a poor resolution to the day standards. Even poorly now, and we require emulators to run it. CCWMap: A port of the previous map editor to Windows 95. Unstable as hell, but missions created by it worked flawlessly. XCC Map Editor: A new map editor which was great for making multiplayer maps, lot more stable, but bugs prevented single player maps from working. Since 15 years have passed from there, how is the state of art of map editors in TD? Do we still have these issues in XCC? I see that CCWMap still unstable, even on Wine. Do we have new map editors on the road? Thank you.

I am currently implementing Bilinear filtering (and I will probably implement bicubic later) to cnc-ddraw's GDI render. First thing I must do is convert the 256 colors scheme used by C&C to 32-bits scheme. Currently, I tried to set the bmiHeader.biBitCount to 32 and use the line to convert a ddraw-surface to opengl texture: ((int*)upscaled)[i*dst_width+j] = ddraw->primary->palette->data_bgr[((unsigned char *)ddraw->primary->surface)[i*ddraw->primary->lPitch + j*ddraw->primary->lXPitch]]; But all that I get is a chunky blued output image. Well, I was not going to post this message before revising things, but I pressed a bunch of keys by mistake on my keyboard and this topic was posted. Perhaps someone can give me some useful info.

I appreciated the attention (seriously, I wasn't expecting an answer to this topic). I agree, if there is a huge amount of work (i.e. modify hundreds of lines of code) just to add Win98 support to one person, then this is unfeasible. Maybe I stick around and help with/when I can. Happy new year!

And such libs are? Good, we are getting forward regarding the problem's source.

Thank you! Well, I get paid for doing research, actually There is also this page with a huge table showing unsupported classes by Windows versions, and also a way to capture exceptions caused by it.

So I've dug into a VS2005 20000 pages document, searching anything that is Win98 related. What I've found was: FileSystemWatcher is incompatible with Win98 Asynchronous Operations are incompatible with Win98: BeginExecuteNonQuery - seems to be database related, might not be the issue BeginExecuteReader BeginExecuteXmlReader Unicode functions are not supported. ANSI function may be used instead. TcpServerChannel cannot be specified as secure under Win98. If at least I could get a stacktrace of the crash :-( Anyway, happy new year!

According to MSDN, EventLog is not compatible with both Windows 98 and Millennium.