1) Yep on the memory leak. Only reasonable answer for the reboot, unless RoF isn't unloading textures at the end of a mission.

2) For multiplayer I can see where virtual memory use could be a problem, as everything has be be drawn "full up" from spawn. Every player has the potential to see everything rendered at once at close range, so I understand that part.

Oddly enough, RoF seems to follow the IL-2 series in object rendering memory taxation. In building DF maps with a lot - and I mean into the hundreds - of ground objects I found that it's not so much the number of objects, but the number of types. Ten vehicles of the same type don't really tax performance, but ten unique vehicle types can bog down a server and make things really slow down. This makes sense, as the texture for a type of vehicle is loaded just once and applied many times.

I'm wondering if the "40 pieces" is a mistranslation or neoqb playing it safe. I'd hazard to guess it's 40 types of ground objects.

3) Similarly, I think they're putting up restrictions based on the min specs advertised for the sim. Again, this follows the 1C: Maddox line of thinking. The reason huge maps were never released with the sim through official updates isn't because the code or current computers couldn't handle it, it was because the specs listed as minimum couldn't handle them.

Even in 2009, here's what IL-2: 1946 was coding down to:



For RoF, it's a lot higher:



Thats' closer to what the average flight sim nut has in the West, but still lower.

Everything they put out, though, will be geared to that minimum system, including 32 bit limitations on total RAM useage.

I'm betting that higher end systems using 64 bit systems will be more than happy to break the limits they put down and run just fine.

Yep - they have to gear the software for the average purchaser - maybe in Russia - who won't have the average SimHQ poster level of hardware.

Cheers,

RD.

That doesn't work in mp... because everything has to be synch'd across all clients. It's why servers have "server frames" - a constant data processing rate - to ensure that everyone see the same thing.

In your scenario, one client could see the "herd" behaviour whilst another sees the "individual" behaviour - when you start going down that route you actually end up increasing the complexity of the netcode to ensure that every client is synch'd correctly when they should be.

That's wrong, mainly because the wrong term is used by most people. It's not about virtual memory, but virtual address space. A standard 32bit application like ROF running on a 32bit OS has a total virtual address space of 2 GB, while 2 GB are used for the Kernel (the OS itself basically). That's total and the OS gives the application this space in the virtual memory (page file) and the physical memory, but not more than 2 GB combined. So maybe 1.8 GB physical memory and 200 MB virtual memory. Once the application needs more than 2 GB, it's gonna crash, because it doesn't get more from the OS.

Using the 3 GB switch, you could take about 1 GB from the reserved Kernel space and shift it to the maximum application space, thus the OS has about 1 GB and can give up to 3 GB combined memory to the application, so that it would not crash when it needs more than 2 GB. However, if you use the 3 GB switch, the Kernels 1 GB might not be enough for the OS, that's why many people set it to about 2800 MB for the application and the rest of the 4 GB (4096MB - 2800 MB = 1296 MB) to the Kernel. That's usually enough for both the Kernel and the application.

But this still wouldn't help if NeoQb doesn't give ROF the Large Address Aware Flag, that allows the application to actually take more than 2 GB. And since they don't want to do this for whatever reason, they can't fix this problem. It's not about memory leak.

Sorry for the excurse.

Okay, the virtual memory part sounds about right. I was under the impression that a Windows 32-bit OS gave whatever was left over from its 4GB addressing to the application, which I figured would be at least 3GB. You're correct that that's the total virtual memory, whether it's physical or virtual.

But the fact that the application can run for 2 or 3 hours fine, and then needs a reboot, implies that there's a memory leak.

Yes, the two issues got confused. I think koala's right about the memory leak. It's the easiest answer to the problem.

Man, I feel smarter from this thread.

Btw, I reckon they don't want to put in the Large Address Aware Flag due to some sort of bug it would make for 32 bit OS users. <--- pure speculation.

They don't want to place the flag, because the following COULD occur theoretically.

The server, using 64bit OS and having a full 4 GB for ROF alone could start some super giant mission with hundreds of units and 60 or so planes, all using their own custom skin.

If a user with 32bit and without 3 GB switch would connect to that server, he would very likely get a crash, while users with 64bit OS could most likely run fine.

So they say they don't want to seperate the users but would rather let both have a crash once in a while, if the server uses more than the mentioned numbers.

What they forget that, no matter what game you look at, it's been always this way. If you have a weak system (and the 32bit OS is now considered to be a "weak" part of the system, because of it's 32bit bottleneck), you can't connect to servers with biggest numbers. Hell i could never join a 2vs2 game in Empire Total War with highest unit count, because of my slow system and i never complained that the devs programmed a game that looks so good that i can't play it with highest settings.

I agree they should bring on the schism.

Servers could have 64 BIT OS ONLY in their titles as warning.

I know my next OS (Win7) will be 64-bit. I have a feeling more games will make this a requirement within the next couple of years.

I wonder, how long the conversion of 32 bit engine to full 64 bit might take...