I don't know on what do you base your idea about Maddox having optimised anything. Perhaps in all these years they've managed to learn enough so that BfB SOW will be better, but given how the il2 series was developed and what I've seen of BfB SOW so far, I kind of doubt it. Although I'd be very happy to be proved wrong in my prediction, when the game is released.

I don't know on what do you base your idea about Maddox having optimised anything

Come back with me now to flying before Il-2 came out <wibbly-wobbly visuals>

Now scroll forward to SoW arriving and our jaws hitting the floor all over again, the first time we take off from Biggin Hill.

Console version looks likely so a move to having an alternative D3D version perhaps. DX11 and tesselation, DirectCompute and so on along the GPUCPU route

Stop me someone I'm getting seriously over-excited just thinking about the dawning over Hackney Marshes

Can't be long now, travelling hopefully is better than arriving.

Ming

BOB SOW will run into the exact same problem on 32-bit OS atleast. Unless it's a 64-bit application (i highly doubt that) or its textures have worse quality than the ROF textures (textures are the main problem).

Anyway, if NeoQb would add the Large-Address-Aware-Flag, this would be no problem on 64-bit OS anymore. And using the 3 GB switch, this shouldn't even be a problem with 32-bit OS. Takes 10 seconds to fix this, plus the time they need to set the checksum for the DRM. If they would be smart, we could see this fix in the coming update with no problem.

I use to hate RoF bashing, but THIS is an absolute shame.

A WW1 simulator in 2009 should have been designed from scratch to be able to handle thousands of units together, on screen.

Have a look at Empire Total War to see what a battlefield in modern games looks like. Even a fraction of what can be seen in this game would have been great.

The limitation to 4 different type of ground units is pityful. Who cares whether an anti-aircraft gun is modelised with 10000 or 100000 polygons? What counts for the player is the immersion, the feeling that she/he flies over a battlefield. And even with extremely detailed models, 4 sounds like a ridiculously low limit.

The limitation to 40 units overall sounds completely nonsensical. I just can't find any understandable explanation to that, and I know what I am talking about.

--

I have to say I am a huge fan of RoF, I love the graphics and the feel of flight, but I sometimes think that there is really something wrong with neoqb. Just like if there were some talented people there but big flaws in the overall organisation.

ofcourse....O P T I M I S A T I O N....

And the other video game developers? How are they solving the problem?

Who can really believe that you need hundreds of megabytes to store the textures of a ground unit which does never appear bigger than 100 pixel during more than a second?

This is complete nonsense. Even uncompressed, a 512x512 texture does not require more than a MByte.

The only object which requires extremely detailed textures, detailed enough to require tens of megabytes, is your own plane, because you look at the textures from a range that can be counted in cm.

If the textures used for other planes are as detailed as they are for your own plane, this is a completely useless waste of ressources. And it is even worst for ground units...

I wish you could be right be the only visuals we had so far were not very impressive...

Except we want it that way, demanding that everything is detailed. If it isn't, we'll say it look like yesterday's sim.

Why not use sprites like Empire Total War? In some cases, they should have!

I never said anything different. Infact i suggested over in the ROF forum to reduce the skins to 1024x1024, which would barely make a difference, except if you want to take nice screenshots to show around, but reduce the ressources needed for the skins by 75%.

Also i don't believe that NeoQb has really tested this. All ground objects (buidlings, artillery, vehicles, you name it) has a total memory usage of less than 100 MB, so putting all this into the game should not produce this memory problem.

I wouldn't mind reduced graphics to counter this problem, but imagine what would happen if NeoQb would downgrade the graphics in one of the coming updates. People would #%&*$# even more about that.

I've suggested also, to just apply the Large-Address-Aware-Flag to the ROF.exe, but from Leftys response over there, i guess they have no idea about what i mean. It would solve this problem for every 64bit user (and the number of 64bit users will increase over the next years for sure) aswell as every 32bit user who is willing to use the 3 GB switch.

Sure, thousands of units when the game is running a simple flight model, simple gunnery model and graphics reminiscent of EAW. It just doesn't work that thousands of units can be available as computations for everything you see and don't see are far more complex than they have ever been. Yes, computers are faster but as the programming becomes more complicated to make the system run the best simulation of physics it can - it's only plausible that it will hit a hard limit at some point until the systems become significantly more powerful and then the limit will be pushed again.



Interesting, but then you'd know that the more complex everything becomes then the more system resources have to be dedicated to it. Programming and processor/GPU development do not run in a parallel path, as one becomes faster the other becomes far more complex requiring even more of the power that is yielded in more advanced processors and GPUs.