Operations? Stalingrad?

[Peterk]

I've been monitoring since people started receiving the game. There's been tons of gloating but not too many people are actually talking about how good it is.

So? Come on! Spill the beans...let's have some AAR action here.

I'm most interested in knowing what the Operations are like in the newer incarnation? Also how much Stalingrad action is in there and are the scenarios any good?

[Bruce70]

Originally posted by Peterk:

I'm most interested in knowing what the Operations are like in the newer incarnation?

I am also very interested in this. Anyone played an operation yet?

[Tha_Field_Marshall]

Im playing Factory Operation right now it is awesome but huge and very system intensive I dont know if an older system could handle it. The map rocks

Tons O Units

[Peterk]

Hey! Thanks for answering - I posted that message a few days ago. I like what I've heard enough to get the game even though my current PC can't handle it yet.

Are the breaks between battles handled a little better than in CMBO. Is the AI better able to play an op this time around?

[Berlichtingen]

Originally posted by Tha_Field_Marshall:

Im playing Factory Operation right now it is awesome but huge and very system intensive I dont know if an older system could handle it. The map rocks

Tons O Units

Just to let you know, that operation brought my machine to its knees just making it

[MrNoobie]

whats the name of the operation cuz i dont have it? is just called "Factory" and is that it? cuz i dont have it...

[Panzer Leader]

To the Volga!

[Scott B]

"To the Volga" looks magnificent - it's just a shame that my computer can't handle it (ran about 1 frame per second when I was looking through it the first time). I'll have to save that one for when I upgrade.

Scott

[Tha_Field_Marshall]

I started To the Volga at 8:00 last night and by midnight I had only played 5 turns but it is worth every second.

[Becket]

Originally posted by Scott B:

"To the Volga" looks magnificent - it's just a shame that my computer can't handle it (ran about 1 frame per second when I was looking through it the first time). I'll have to save that one for when I upgrade.

Scott

Re: Upgrade -- that operation is stuttery and framey on a Pentium 4 2.0 Ghz Computer with 512 Megs of Ram and a GeForce 3Ti. In other words, it's not the system. I cannot understand why it's so framey and stuttery, unless the game engine is just simply too taxed by the size of the map and numbers of units. I can't imagine there are more polygons on screen that in, say, a fully maxed out Battlefield 1942 game, and that runs smooth as silk for me.

Not bitching here, just noting that you should not get your hopes up that an upgrade will let you play that map.

[rune]

You would be wrong. The terrain, the amount of units, and the shellholes all push that battle more then any BF1942 battle.

Rune

[Peterk]

Would some good Samaritan be kind enough to post a pic of a typical Stalingrad street-corner on the front lines. I get warm-fuzzies on Stalingrad realted stuff!

How is the AI coping with defending on a large battle like this?

[Becket]

Originally posted by rune:

You would be wrong. The terrain, the amount of units, and the shellholes all push that battle more then any BF1942 battle.

Rune

I respectfully disagree. These are very low poly units and a 4 year old engine.

Do you know the poly counts on the infantry, AFV, and buildings? I find it impossible to believe that the sum of those polys is greater than BF1942 at full draw distance or Unreal Tournament 2003 w/ all details cranked. For example, Unreal Tournament 2003 uses 15,000-20,000 polys per player model. (http://www.anandtech.com/showdoc.html?i=1476&p=2) Meanwhile, BF1942, in addition to high poly count models, is rendering outdoor environments with huge draw distances. I can't imagine that there are more than 20,000 polys in an entire battlion of infantry. Since my system can run UT2003 at full detail and 60fps with 16+ players on screen, it just doesn't make sense that fewer polys can cause stuttering.

I'm not saying CMBB is bad; quite the contrary, I love it. Just that the engine can't handle an operation of that size and upgrading your hardware will not help.

[WWB]

Originally posted by Becket:

</font><blockquote>quote:</font><hr />Originally posted by rune:

You would be wrong. The terrain, the amount of units, and the shellholes all push that battle more then any BF1942 battle.

Rune

I respectfully disagree. These are very low poly units and a 4 year old engine.

Do you know the poly counts on the infantry, AFV, and buildings? I find it impossible to believe that the sum of those polys is greater than BF1942 at full draw distance or Unreal Tournament 2003 w/ all details cranked. For example, Unreal Tournament 2003 uses 15,000-20,000 polys per player model. (http://www.anandtech.com/showdoc.html?i=1476&p=2) Meanwhile, BF1942, in addition to high poly count models, is rendering outdoor environments with huge draw distances. I can't imagine that there are more than 20,000 polys in an entire battlion of infantry. Since my system can run UT2003 at full detail and 60fps with 16+ players on screen, it just doesn't make sense that fewer polys can cause stuttering.

I'm not saying CMBB is bad; quite the contrary, I love it. Just that the engine can't handle an operation of that size and upgrading your hardware will not help.</font>

[rune]

WWB is correct, even if it pains me to say that. While in other games polys are "forgotten" when not in view, this cannot be the case with CMBO/CMBB. We had this same discussion when CMBO was first released, and it hasn't changed. Dan can give the actual amount of polys per unit, but To the Volga pushes the poly count big time. All the polys have to stay in order for the different views. I went back and found this among other messages:

ALL OF THE ABOVE

Let's forget frame rates for a sec and only look at between turn calculations. The two are quite different.

The worst CPU killer is the number of potential tiles (any type) on a map. If you took our current game engine and made a 10k x 10k map the game would grind to a halt. Same if you took a normal sized 2000m x 1000m map and made the über tiles 10m x 10m. The more tiles you have on the map the more load on the CPU to figure out something like LOS or how to move from A to B. The 20x20m tiles are used to make computational assumptions which save loads of CPU time without sacrificing accuracy. I don't know the specifics, and don't want to , but I do understand the basic concept.

Because of the assumptions we can simulate larger maps with larger über tiles. If we made the über tiles 50m x 50m we could make even larger maps, but we would also have to bump up the subtiles from 2m x 2m to a larger size as well, since they also count against CPU cycles.

The more variety of terrain TYPES increases the load on the CPU to some extent, but not that bad. Mostly terrain types require more coding and VRAM to support rather than actual cycles to simulate. However, an exception is something like the house anywhere in the square does have a huge effect on CPU requirements. This is because it removes the ability to make assumptions.

Now, in terms of frame rate, the more terrain types you have doesn't mean a great hit on the 3D card and CPU. However, the more bumps and curves you have in the terrain mesh, the more polygons are needed, which means the slower the game will run graphically. Some terrain type's graphics also require more polygons, like woods compared to open ground, so they can cause higher hardware demands. And every doodad you add on the map requires polygons, so one telephone pole might take 22 polygons to make look good. Now multiply that by 50 or 60 telephone poles and you can understand why we left them out Sure, we could have put them in, but then something else would have to come out.

The ability for the computer to handle polygons is finite. You can do tricks to reduce the polygons being drawn (and we are doing LOTS of tricks), but you really do anything to make the computer draw more and draw faster without hacking the hardware (or so I understand). Because of this we have to be VERY careful to not put in too many things that require too many polygons.

And then we have to stick units in on top of this don't forget! And they are VERY demanding...

As for VRAM...

Every thing you can possibly see in a single scenario has a texture loaded into VRAM (exception are lines, like the LOS, which just use a SOLID color). So, if you add a boulder terrain type you have to have boulder graphics. These are stored into VRAM. The pixel size of the graphics determines how much VRAM is used up. The more graphics that are in a scenario (not just on the screen at once) the more VRAM is used.

Also the higher the resolution of the graphics, the more VRAM is used. I could make a 16x16 pixel boulder or something like a 128x128 one. The more pixels the better looking it is in the game. Unfortunately, the more VRAM it sucks up. So you have to be careful to balance quality with usage.

So the more terrain we have available, the more terrain will be in each scenario, the more VRAM is used up. Some terrain is really inexpesive (like the wall texture) while others are horrible (roads are the worst). And there has to be different tiles to add variety sometimes, like the open ground and multiple tree types.

On top of this you have units, vehicles, weapons, smoke, fire, UI graphics, etc. All of this ALSO has to go into VRAM.

The only bright side to this is that you only need to have the texture loaded in ONCE. So if you have 16 tree graphics you can have 1000000000000s of trees without hitting up VRAM for anything else. But of course each new tree hits the CPU and 3D card for drawing power. So there are practical limitations.

Having a smaller terrain scale does not necessarily mean a greater usage of VRAM. BUT, the more variety you have does. So in theory we can shrink the current über tiles down to 2m x 2m without taking up any more VRAM, but adding something like telephone poles would, no matter what the scale. But of course the CPU would raise some objections with both

The end point here is that the more stuff you put into the game, the more it causes a burdon on the hardware. Although some elements come cheaply, nothing comes for free. We have way more candidates for inclusion than the hardware has power and/or capacity to support. Therefore, somethings will have to sit and wait until hardware improves

Believe me or not, up to you.

Rune

[ September 26, 2002, 01:35 PM: Message edited by: rune ]

[KNac]

Some screenshots about the operation and other stalingrad battles? An AAR of someone who has already played the operation (or it´s doing it)?

Pleaase...?

[Becket]

Thanks Rune, that's the kind of information I was looking for.

Believe it or not I was on another forum chatting with a programmer friend about the issue and came to the conclusion that the textures seem to be the core of the issue. After all, nVidia can push multi-millions of untextured polys. But the texturing can bollux everything up.

Anyway, I think the end result is that upgrading won't help for Stalingrad. Or, put differently, you'll need to go above a 2Ghz P4, 512 Ram, and GF3 at the very least.

[Becket]

Crap. Sorry for the multiple post.

[ September 26, 2002, 02:12 PM: Message edited by: Becket ]

[Becket]

(third multiple post deleted, gah)

[ September 26, 2002, 02:13 PM: Message edited by: Becket ]

[rune]

Becket,

No problem Sir. As you know, polys are only part of the problem. You can kill a scenario real easy by putting a lot of smoke out there. When I talked with Berli about his scenario, at first it was not going to go on the CD. However, I liked it, and we had talked about it [there is a scenario on a fight in just a couple of the buildings that I had done first], and when I got permission to go beyond the original 50 scenarios, I knew I had to have this one from Berli. Yes, it is a hog, and it pushes the max, but in a year or two, when hardware is even more faster, it will be what I use for a guide. Nvidia already announced new chips, and Intel says 3 gigahertz by the end of the year. Someday I will upgrade and see how it runs.

Enjoy the game...

Rune

[Tha_Field_Marshall]

I have been playing the operation on a 1.7 with 384K of DDR and a G4 ti 4200 grapics card it brought the system to its knees, so I just ordered a stick of 512 Crucial ram do think this will speed up the time between turns. ANYONE!

[PAEZ]

It's there any way to break this operation into sections so that we can play it

As it is, is almost imposible to run it, if at all

Now I know it will take a lot work to do but

with 4 different sections or so it may be more

bearable

Just and idea

Paez

[WWB]

Originally posted by rune:

Becket,

No problem Sir. As you know, polys are only part of the problem. You can kill a scenario real easy by putting a lot of smoke out there. When I talked with Berli about his scenario, at first it was not going to go on the CD. However, I liked it, and we had talked about it [there is a scenario on a fight in just a couple of the buildings that I had done first], and when I got permission to go beyond the original 50 scenarios, I knew I had to have this one from Berli. Yes, it is a hog, and it pushes the max, but in a year or two, when hardware is even more faster, it will be what I use for a guide. Nvidia already announced new chips, and Intel says 3 gigahertz by the end of the year. Someday I will upgrade and see how it runs.

Enjoy the game...

Rune

Wow, Rune said I was right. I am getting verklempt.

For the record, I will tell you how it runs on an Athalon XP 2000+/GeForce 4 combo this weekend.

WWB

[Zarquon]

Rune, thanks for the info.

Now, does the CM engine allow for poly reduction (I forgot the proper term), where objects far away from the camera are rendered with less polygons, e.g. details you couldn't see anyway are not calculated? This should make a huge performance difference.

[Markus Staudt]

Hey rune,

I have a question that I think i already know the answer to (unfortunately). Will reducing the graphics (ie. resolution, numbers of men in squad, horizon distance etc.) help the system handle the between turns calculations. It is taking me about 50 minutes to complete a turn on a mid to upper range system right now! Don't get me wrong, the operation is unreal and exactly what I was hoping for. It would just be more enjoyable if we didn't have to start the turn before going to bed and view it in the morning. Thanks for the help pal.