cn2mc Posted July 28, 2014 Share Posted July 28, 2014 With bigger maps most certainly you'd need more early scouting and defences as the surprize factor of APC and heli rushes will increase dramatically. Also, depending on map design, people might be more inclined to build MCVs instead of spiderbasing to expand. Again, depending on map design, Nod would get a slight boost with their fast bikes, but on the downside, Nod players spawning in the West will have more delay between deliveries, potentially the biggest problem here, easily solved by a second airstrip, which you would need soon anyway if the map was, say 128x128. Also, radar would become more useful, I myself tend to keep mine, if I don't need the cash right away (or am not planning for ion), it's a great way of tracking bikes, stealths and the dreaded APC. I do play lo-res though. Overall, I don't think the game will play better or worse, just a little bit differently. More macro and more room for encircling tank/bike maneuvers sounds fun. Link to comment Share on other sites More sharing options...
XTF Posted August 23, 2014 Share Posted August 23, 2014 What about only increasing the vertical size? I'd avoid a lot of issues. 1 Link to comment Share on other sites More sharing options...
AchromicWhite Posted September 9, 2014 Share Posted September 9, 2014 Yeah, the airstrip would be an issue... in fact, if it was that big would 2 strips actually solve it? You might find it to still be an issue when the map is that big. -Liam Link to comment Share on other sites More sharing options...
cn2mc Posted September 9, 2014 Share Posted September 9, 2014 I'm pretty sure it solves it. The problem with the airstrip is really the fact that with just one you can't call in a second plane until the first one has made its delivery. This results in the unit you've already built and paid for remaining 'ready' but not delivering, thus requiring another click on the icon (if previous delivery was made, the click sends the plane in, if not, the order is cancelled). Having more than one strip eliminates that, because there will be another one for the second plane to head to even before the first one has touched down. In normal 62x62 maps this is only an issue for 1-strip buggies, so it juuuust might be an issue for two strips on 124x124. Link to comment Share on other sites More sharing options...
Jacko Posted September 9, 2014 Share Posted September 9, 2014 dont forget with 2 strips it builds them faster, so you get the same problem regardless. also on 62x62 maps if you place your 1st airstrip on the far west EDGE I think this problem also arises for artillery and bikes, but not lights. Plus if we are in for tweaking airstrip logic is it possible to fix the primary building problems it has? Link to comment Share on other sites More sharing options...
cn2mc Posted September 9, 2014 Share Posted September 9, 2014 Well, it's not exactly the same problem. Airplane speed remains constant and delivery time will still depend mostly on longitude. You will get the double speed (is it actually double?) for two airfields, but two planes will enter almost simultaneously and, presumably, when the first one lands, and the second one is approaching, you've just about built the third. I can imagine the problem still persisting in the very far West of a 124x124 map, but that would be totally the player's fault. Also, I think that this theoretical problem, which could emerge in case we get bigger maps, can easily be solved - although Nyer will probably dislike my suggestion - by simply making the plane faster. AFAIK, it has a speed of 40, and if C&C can handle unit speeds over that (it can for projectiles), voila, almost no west disadvantage. Link to comment Share on other sites More sharing options...
Jacko Posted September 9, 2014 Share Posted September 9, 2014 the speed increase partially negates the 2nd plane because it builds faster, so theres a good chance you still are waiting for both planes to drop the unit off. admittedly the problem happens less often but it doesn't remove it entirely. Link to comment Share on other sites More sharing options...
AchromicWhite Posted September 10, 2014 Share Posted September 10, 2014 What's the primary building problem? You mean that if 1 plane is still to drop off a vehicle, the next will go to the other strip? Because the WF kinda has the same issue, if you build a cheep vehicle, like a hummer, with 2 WF, then if one WF's door are still closing etc, the hummer will pop out the other. Same issue if you make 3 WF and build tanks, some will still come out of another WF. Unless that's not what you're talking about -Liam Link to comment Share on other sites More sharing options...
cn2mc Posted September 10, 2014 Share Posted September 10, 2014 No, it's not that. The primary building bug is when units will keep coming to just one of your airfields, even though you set another for primary. It doesn't always happen, but often. It just uses the east-most strip as a primary and that can sometimes become an issue. Link to comment Share on other sites More sharing options...
AchromicWhite Posted September 10, 2014 Share Posted September 10, 2014 Huh, never noticed that... Maybe when I have 2 strips I'm just pumping out units and don't care anyway, lol -Liam Link to comment Share on other sites More sharing options...
cn2mc Posted September 10, 2014 Share Posted September 10, 2014 That's why as Nod I will usually build my second strip close to the first one, so spamming doesn't result in unused units somewhere else. But under certain circumstances you'll need different spawn points for your units and it is frustrating to build a new airfield specifically to ship units to one part of the map only to later find out that no planes are landing there. Infact, they'll often enter the map with the correct approach, lined up with the primary strip only to suddenly make a sharp turn towards the one they like better and deliver there. Funny things, cargo planes in C&C. Almost as crazy as Harvs. Link to comment Share on other sites More sharing options...
Nyerguds Posted September 11, 2014 Share Posted September 11, 2014 If I remember correctly, the plane will always go to the airstrip the closest to the right-side edge of the map. So yeah, it ignores the primary building. Link to comment Share on other sites More sharing options...
djjammin1337 Posted January 2, 2015 Share Posted January 2, 2015 I take it this isn't going to happen then? I do find the discussion of how it might work very interesting is anyone still working on this? Link to comment Share on other sites More sharing options...
peterthepigeon Posted October 4, 2015 Share Posted October 4, 2015 Changing macros, expanding memory foot print, that's a lot of work. Then making sure units and structures that are in the expanded regions remain inactive. Lots of work. Link to comment Share on other sites More sharing options...
Eisengeist Posted October 9, 2015 Share Posted October 9, 2015 What about only increasing the vertical size? I'd avoid a lot of issues. No one replied to this post by XTF. Possible easier idea to expand to 62x126 or 126x62? Link to comment Share on other sites More sharing options...
Nyerguds Posted October 10, 2015 Share Posted October 10, 2015 A technical internal map size of 64x128 could be possible, yes... but then we still need map editors that support it. Link to comment Share on other sites More sharing options...
MrParrot Posted October 8, 2020 Share Posted October 8, 2020 (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? Link to comment Share on other sites More sharing options...
Myg Posted October 8, 2020 Share Posted October 8, 2020 The remaster and source code are separate things. With the source code our devs (cncnet and others) can modify the game to accept larger maps or do whatever the devs please. I think the remasters have stopped releasing additions to the game now and are just dealing in bug fixes and small patches. Link to comment Share on other sites More sharing options...
MrParrot Posted October 8, 2020 Share Posted October 8, 2020 1 hour ago, Myg said: The remaster and source code are separate things. With the source code our devs (cncnet and others) can modify the game to accept larger maps or do whatever the devs please. I think the remasters have stopped releasing additions to the game now and are just dealing in bug fixes and small patches. 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? Link to comment Share on other sites More sharing options...
Myg Posted October 8, 2020 Share Posted October 8, 2020 Well it uses some of the code. They have their own engine on top called "GlyphX" which runs the code but its proprietary. The cncnet/etc devs are currently at work trying to make something of the dll/code provided by EA. Link to comment Share on other sites More sharing options...
MrParrot Posted October 8, 2020 Share Posted October 8, 2020 24 minutes ago, Myg said: Well it uses some of the code. They have their own engine on top called "GlyphX" which runs the code but its proprietary. The cncnet/etc devs are currently at work trying to make something of the dll/code provided by EA. 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 Link to comment Share on other sites More sharing options...
Iran Posted December 8, 2020 Share Posted December 8, 2020 Megamaps support (256x256 like in Red Alert Aftermath) has been added to C&C1 in the open-source Vanilla Conquer project (C&C remaster source adapted to stand-alone): https://github.com/TheAssemblyArmada/Vanilla-Conquer Note: I didn't work on this. Link to comment Share on other sites More sharing options...
Iran Posted January 6, 2021 Share Posted January 6, 2021 It's now merged into the main branch! https://github.com/TheAssemblyArmada/Vanilla-Conquer You need to use the built-in map editor to make a TD megamap. Link to comment Share on other sites More sharing options...
Blade Posted January 9, 2021 Share Posted January 9, 2021 I did work on this with CCHyper and it feels like it was a lot harder than it should have been. The format it expects is the same as the one Sole Survivor used and the internal map editor will now write that format. The max size is now 128x128 like RA and if you build a TiberianDawn.dll remaster mod from the vanilla conquer source (which supports building both a classic standalone binary and a remaster mod dll), the remaster will also support 128x128 maps. Caveats are that this changes the save format and the save format isn't even stable at the moment as we are making lots of changes to commonise the code with the RA code. Also multiplayer doesn't work in vanilla yet for either game standalone. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now