C&C95 Map expanding research

[cn2mc]

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.

[XTF]

What about only increasing the vertical size? I'd avoid a lot of issues.

[AchromicWhite]

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

[cn2mc]

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.

[Jacko]

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?

[cn2mc]

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.

[Jacko]

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.

[AchromicWhite]

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

[cn2mc]

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.

[AchromicWhite]

Huh, never noticed that... Maybe when I have 2 strips I'm just pumping out units and don't care anyway, lol

  -Liam

[cn2mc]

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.

[Nyerguds]

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.

[djjammin1337]

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?

[peterthepigeon]

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.

[Eisengeist]

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?

[Nyerguds]

A technical internal map size of 64x128 could be possible, yes... but then we still need map editors that support it.

[MrParrot]

 

(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?

[Myg]

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.

[MrParrot]

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?

[Myg]

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.

[MrParrot]

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

[Iran]

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.

[Iran]

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.

[Blade]

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.