Jump to content

CnCNet Forums

Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
pichorra

C&C95 Map expanding research

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :P

  -Liam

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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? :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...