Was the entire team swapped out when Oleg left? I thought he was the only one that left?

His initials couldnt be anything but when dealing with the mess these forums are at times....

At least sound designer, graphics engine, FM, AI and water programmers were fired or left IIRC and probably several others too. When people fail to deliver results in 3-5 years they have to be fired at last one day. But it may take even more time for new people to decipher old code.

It is good the idea of MMO saves the project from being shut down completely IMO.

Ok, I never knew the fate of the original team, that makes it even easier for me to swallow the problems faced right now.

As for the MMO I agree, but only something more like Warbirds but with maybe different options to get people into the game.

They already ditched completely the old sound engine code and written a new one, and same with the graphics engine (this took 6 months).

So there no old code to decipher in those areas at least.

I guess that the new AI and FM guys are the ones having hard times.

Ohh ... this is an interesting theory, I did not understand you at first but now is more clear.

But ... I recall that this hick-ups (no fps affected) are not in the old build, they was micro-freezes (fixed in the new build).

But you are right ... it can be a interop problem but I think that can be caused by the issue of left the tree and grass code aside of the new build that is in the Alpha patch, so the ddl dependence is high.

Has is written in the know-issues list in BlackSix patch post, the tree and grass optimizations was not complete but it will be in a few days.

Anyway we´ll see this soon :)



By the way, to clear misunderstandings in the DX9/10/11 debate :

Of course you can made a game with DX9/10/11 support but what I was saying is that by doing it you´ll not fully use the DX11/10 possibilities.

That´s it.

Cheers

S!

Not being a programmer, just an average joe, but IMHO they should drop DirectX 9.0c and focus on DX 10/11 as ANY decent GPU these days can handle both. Backwards compatability is like an anchor slowing you down. Look at Frostbite engine used in BF3 for example, it will go 64-bit ONLY in a year. No more limitations of 32-bit like 3Gb RAM or whatever. That would be future proof, not dragging relics with you. Just some thoughts, propably not very educated but nevertheless :) Thoughts?

Because its obvious, and if you can't see this there is no point in further argument. Any improvement the development makes to the game engine, bug fixing, campaign tools, terrain map tools, Triggers, AI, Commands, FM engine, DM engine, Water, Clouds, Dynamic Weather etc can be applied to COD. Some directly with patches to COD before the release of the Sequel, and later when you combine the Sequel with your installation of COD.

It is possible but highly unlikely that the development has dropped work on the Sequels too work solely on the MMO's. The reasons this is unlikely is the MMO won't be completed for atleast a couple of years and the development needs cash now with the release of a Sequel. Also why would the development drop this source of income from the game engine. Everything depends on getting the game engine working. Then developing games, and MMO's from that working game engine is relatively easy.

Luckily it appears the investors/publishers/developers are showing some confidence they will be able to fix the game engine or there would be no talk of developing an MMO.

For future titles yes, but I think the fact that this game was released with it stated on the box it would support 9 means the are bound to do so. At least that makes sense to me...

It sure can be, but there are tons of other games that use Speedtree out there with very good performance, like Battlefield 3 that hardly can be accused of stuttering ;) But then of course, I hardly think there is another game that use so many trees on the same frame :)

Anyway - as the main logic in the game is written in .NET and the Speedtree dll:s are written in C++ there will be interop problems in this critical part that for sure will not help! Of course they can maybe do optimization so that they load stuff and don't do the marshalling every frame, but I really don't know how the Speedtree libraries work in runtime... As Speedtree does culling, lods etc I don't see how you could get around a lot of marshalling to get the C++ trees "into" your C# landscape manager? Just guessing here...

Another thing is that they seem to be using Speedtree 5.2 which is not the latest release so let's hope they work with Speedtree support to fix this and are not stuck on a license for 5.x only.