New Graphics Engine

[Wolf_Rider]

Originally Posted by tarks

Looking at this thread from Oleg back in 2007/2008 the graphics really don't look any different to now , in some shots better i'd say.

http://forum.1cpublishing.eu/showthread.php?t=2040

We have been advised by the developers: the sim won't look any different but it will run better, in comparison to the release engine.

Wolf Rider said:

>>We have been advised by the developers: the sim won't look any different but it will run better, in comparison to the release engine. <<

Yes, this is correct, and needs drawing attention to. Many might have forgotten this over time, so it's as well to remind the forum from time to time. It cannot be stated often enough, especially to those who wish to do nothing but complain.

The forum needs more of this style of factual post, far too much moaning has taken place recently.

A breath of fresh air, Wolf Rider. Thank you.

[skarden]

would you rather have the development team here explaining stuff that has been explained many many times over ( and yet again, very well too by blackdog ) or have them working on the beta? ya can't really have both, they don't have a big team and I for one would rather they be working on ironing out the bugs in the beta then answering the same whining questions over and over to people who don't bother to read previous posts.

[Ataros]

Originally Posted by RickRuski

The reason for the post was to get some answers from the development team, all we seem to be getting lately are excuses. It certainly doesn't bode well for the expansion. We are the paying customers, lets have some truthful answers from the team. Under some countries laws we could demand a refund or the company taken to court for false advertising from what was promised. I know the flag wavers will crucify this thread but I don't realy care any more.

It is possible to search the forum by user to find answers from B6 (not excuses). He posts updates several times a week recently. Last week the patch was ready but final assembly showed new graphical artefacts which they are fixing this week making their best to push the patch before holidays. They are pressed for time by the publishers with sequel announcement and must issue the patch ASAP.

There are 2 options:
- wait, support and encourage the devs on the forums with positive posts if you want them to succeed and continue the series to 1942 - 1945
- talk to UBI about refund if you want your money back and studio closed.

Cursing the devs on the forums or posting the same question every week is not really an option because no one benefits from it: the devs are not encouraged and work slower, you do not get a refund. No point in doing this, just does not make logical sense.

[Verhängnis]

Yes, I would rather have the development team here explaining what is going on, although I am assuming they will at least answer some questions after the patch is released. And as far as I know Blackdog isn't part of the development team, I too could make speculations and general statements about software development, but that doesn't tell us anything specific.
As he said, he only has an "understanding" - like the rest of us. In reality it means nothing about the actual development of the game.

[Thee_oddball]

Originally Posted by Blackdog_kt

My understanding is that the work on the sequel is primarily about 3d modeling and laying the groundwork at this point in time.

It's entirely possible to make "static" models in the meantime, but eventually each engine will handle these models differently to give them motion. One engine might do effects one way while the other engine does effects with a different algorithm, the same for calculating lights and shadows, etc, (and this is what results in the differences in performance and quality) but in the end they all take a 3d object and make calculations on top of it: the initial object that is being "read" into the engine can be the same, even if the calculations to be performed on it are different.

To give a simplistic example, it's like you have a bunch of oranges in your kitchen. You can just eat them, make them into orange juice, or extract the pulp and some orange skin shavings and put it in a cake, the oranges will work fine in every case.

I've taken up a computing degree course this year and one of the things they try to really press in all the classes i attend is modularity, especially for the so called object oriented languages.

To give you another example, as a form of practice for my computer classes i've taken up a project with a mate and we want to build an interface that will allow us to play pen-and-paper tabletop RPGs over the internet with other friends.

I don't know anything about how to handle databases, save data to disk or push packets through a network yet. However, i can still design and implement the interface of the application, as well as define categories of all the objects the game includes (with their proper attributes and ways to interact with them). So, what i'll do is exactly that, then i'll give the code over to my buddy and he'll do the rest.

There is no need for us to be doing exactly the same thing, nor is there a need to be able to do things at the same pace. It's like installing household appliances more or less. I can design my part of the modules (ie, pick some electrical appliances in the above example), the other guy can do the same for his share of the work and the we just have to plug it into a suitable outlet. Well, the power grid in that case is the programming language you use. And languages nowadays don't tell you "you can't plug in a fridge unless you first connect a hair dryer", they just let you plug each module in at your own convenience and, most importantly, take a module out, redesign it (to improve it) and put it back in.

That's pretty much what is being done with the sim currently. It's just that the module they are working on is being built from scratch and it's one of the biggest in the game. However, that doesn't mean it needs every other module to work correctly before it can function: new graphics engine will be just that, regardless of whether the switchology in the cockpits is corrected and vice-versa.

Now, both the previous IL2 series and the new one are built with languages that follow this method (C++ and Java for the old one, C++ and C# for the new one).

So, long story short, I can't tell you exactly how they do it, but i can understand the process somewhat to tell you it's not wasted time.
Heck, you could probably take the code that governs the systems modelling in the sim and port it to another sim with totally different graphics if you wanted to.

I hope this helps explain a few things

just for clarification BD, IL2 had the core game written in C++ CLOD has the core written in .NET with some small libraries written in C++

[6BL Bird-Dog]

Originally Posted by Blackdog_kt

My understanding is that the work on the sequel is primarily about 3d modeling and laying the groundwork at this point in time.

It's entirely possible to make "static" models in the meantime, but eventually each engine will handle these models differently to give them motion. One engine might do effects one way while the other engine does effects with a different algorithm, the same for calculating lights and shadows, etc, (and this is what results in the differences in performance and quality) but in the end they all take a 3d object and make calculations on top of it: the initial object that is being "read" into the engine can be the same, even if the calculations to be performed on it are different.

To give a simplistic example, it's like you have a bunch of oranges in your kitchen. You can just eat them, make them into orange juice, or extract the pulp and some orange skin shavings and put it in a cake, the oranges will work fine in every case.

I've taken up a computing degree course this year and one of the things they try to really press in all the classes i attend is modularity, especially for the so called object oriented languages.

To give you another example, as a form of practice for my computer classes i've taken up a project with a mate and we want to build an interface that will allow us to play pen-and-paper tabletop RPGs over the internet with other friends.

I don't know anything about how to handle databases, save data to disk or push packets through a network yet. However, i can still design and implement the interface of the application, as well as define categories of all the objects the game includes (with their proper attributes and ways to interact with them). So, what i'll do is exactly that, then i'll give the code over to my buddy and he'll do the rest.

There is no need for us to be doing exactly the same thing, nor is there a need to be able to do things at the same pace. It's like installing household appliances more or less. I can design my part of the modules (ie, pick some electrical appliances in the above example), the other guy can do the same for his share of the work and the we just have to plug it into a suitable outlet. Well, the power grid in that case is the programming language you use. And languages nowadays don't tell you "you can't plug in a fridge unless you first connect a hair dryer", they just let you plug each module in at your own convenience and, most importantly, take a module out, redesign it (to improve it) and put it back in.

That's pretty much what is being done with the sim currently. It's just that the module they are working on is being built from scratch and it's one of the biggest in the game. However, that doesn't mean it needs every other module to work correctly before it can function: new graphics engine will be just that, regardless of whether the switchology in the cockpits is corrected and vice-versa.

Now, both the previous IL2 series and the new one are built with languages that follow this method (C++ and Java for the old one, C++ and C# for the new one).

So, long story short, I can't tell you exactly how they do it, but i can understand the process somewhat to tell you it's not wasted time.
Heck, you could probably take the code that governs the systems modelling in the sim and port it to another sim with totally different graphics if you wanted to.

I hope this helps explain a few things

Thanks for a clear explination.

[Jaws2002]

Looks like throwing away the "old" graphics engine and starting from scratch, wasn't such a smart thing to do. They just replaced the bugs they knew about, with new ones and lost some of the advanced featured in the process. This "new" graphics engine was suposed to be a quick fix. LMAO.

[von Pilsner]

Originally Posted by Jaws2002

Looks like throwing away the "old" graphics engine and starting from scratch, wasn't such a smart thing to do. They just replaced the bugs they knew about, with new ones and lost some of the advanced featured in the process. This "new" graphics engine was suposed to be a quick fix. LMAO.

Where did you read that the new graphics engine was to be a quick fix? I seem to recall they said it would take time to do and get right.

[RickRuski]

Just read Blacksix's April 28th post, dear o dear another excuse how sad. Blackdog, I understand that this sim is in modular form but the moduals still have to be able to talk to each other. A mistake in one module should create problems further on. If the main module can't hear what the other is saying correctly then the resultant answer would be something like this. (this is from a birthday card my wife gave me, she says my hearing is getting worse).

Three old friends are walking on the beach one day, male A says "it' fine day" male B replies "no it's Thursday" male C responds "so am I let's have a beer"

A typical example of statements getting mis-interpreted from one to the other. So once again I still can't see how programmer A can complete his module until the master is finished. He will have no way of testing it as has been shown by recent delays in the patch release.