http://riseofflight.com/Forum/viewtopic.php?f=48&t=3871

and if noted somewhere else here, sorry.

//

Hello,

thanks Haja.

After reading this i am sure you will need a Cray computer to play a "normal" mission in Multiplayer. I wonder whether RoF will ever develop into something Red Baron has been, with those restrictions - or in maybe 10 years ?


Quote from RoF forum:

" ...

«Out of memory…» error

Recently, some users have encountered with this error ... It is time to talk about it in detail.

The reason for this error – not enough of virtual computer memory, which in any configuration is 2Gb.

I draw your attention to the phrase “a virtual computer memory”. No matter how much physical memory cards are installed on your machine - there may be any number – the application uses only 2 GB of virtual memory cause that is permitted by OS Win32, regardless of the overall RAM amount, which can be up to 6 GB. This is done to ensure that all users who have a Win32-OS computer have an opportunity to play the game.

What should I do to avoid this error?
The golden rule - do not violate the following restrictions. Namely:

For DServer hosters:
1. In a mission there should be not more than 3 different aircraft types for one coalition, i.e. the maximum number of different aircraft types for both sodes - 6.
2. All aircrafts’ skins should be default ones. In this case, application will be using the smallest possible amount of hoster’s computer virtual memory. As an example, every real default skin "eats" about 5Mb of memory, i.e. if a mission has 4 SPADs, each with default skin, it will be equal only to 5Mb of memory, because skins are the same and they are loaded once (in the beginning) and are assigned to all 4 SPADs. Conversely, if these 4 SPADs are ‘dressed’ in different skins, we will need to have more than 20Mb of hoster’s memory to display these four different skins, and the same amount of client’s (player) memory.
3. The maximum total number of aircrafts in a mission at any moment of time shall not exceed 30. This number includes both planes controlled by humans and planes controlled by AI.
4. In addition to aircrafts, there should be not more than 4 different types of ground objects per coalition (cars, trains, antiaircraft guns, cannons, balloons, etc.), i.e. maximum number of different types of ground objects for both sides – 8.
5. The maximum total number of ground objects shall not exceed 40 pieces.
6. At least once a day it is necessary to reboot a host computer.

It is also necessary to remember that the additional amount of virtual memory is consumed on the reproduction of various effects (tracers, fire, smoke, shoot, etc.), as well as on different sounds.

For the players (clients):
Everything that is written below is not required, but desirable.
1. If possible, unload from memory all third-party software (anti-virus, email applications, etc.).
2. For weak computers that meet only the minimum requirements of the game, it is desirable to use low quality audio and low quality textures (can be set in Settings.exe).
3. When continuously playing during a long time, it is desirable to reboot the computer at least once in 3-4 hours.

In case of observance of the abovementioned conditions and restrictions, the problem «out of memory ...» errors should not occur.

Sincerely, Lefty-neoqb

... "


Hmm, if NeoQb ever decides to expand, or better create a single career in offline mode, would those restrictions be gone in SP (?)

Greetings,
Catfish

You dont. I have mediacore system(E8400, 4Gb RAM, ATI 4870) and I can play multiplayer just fine.

It's more about limitations in building missions.



And now we get a little more about why DF mode wasn't automatically included at release.

I suspect they're working this one through for the update.

Interesting how 32 bit OS's cause problems.

what a nice optimised sim it is....what a laugh...Im sure now ROF is a piece of #%&*$# unoptimised crap of the software (letting FM aside)

Hello,

@ Mig77 and Dart:

" ... i have a mediacore system(E8400, 4Gb RAM, ATI 4870


" ... And now we get a little more about why DF mode wasn't automatically included at release...."
Interesting how 32 bit OS's cause problems. ..."

1st Mig77 while this is no Cray i would not call this a mediocre system - E8400 Dual core 3 GHz and 4 Gb Ram ?

2nd What Dart wrote is why i thought of a Cray: Limitation of 30 planes altogether with the limited performance of our current employed PC systems, 32 bit wise. So this may say (reading between the lines) that RoF will be open for better systems, and probably make use of faster and more Ram - this is what i would call potential. RedBaron took 5-6 years to develop new patches and a reasonable multiplayer, together with improved hardware. So this is indeed a chance.

What i meant is that at the current point there are some restrictons if you think about comparing the current possible 30 RoF planes and 40 ground objects in MP, to 100+ planes in RedBaron MP. But let's see, it is just the beginning. Thinking of the original RedBaron developer team and Sierra/Dynamix, there is sure much more dedication in RoF.

I still wonder if those RoF restrictions (32bit-wise, and memory) are also present in single play (player against 29 AI planes max. and 40 ground objects) - anyone ?

Greetings,
Catfish

I don't think it's about processing power or RAM, but how 32 bit OS's work with that RAM. I'll take a SWAG and say that RoF either tries to take priority in memory addresses, which causes a conflict with system stuff running in the background (and other apps like TIR running up front) or it doesn't get enough priority and winds up choking and crashing.

Clearly they found that 30 planes was the "safe" number before random crashes could occur, and that more than that had problems with 32 bit systems.

Interesting in that the problem disappears with a 64 bit OS.

Conceivably we could have 64 bit OS only DF servers in the future.

Catfish, I wouldn't see why the same restrictions are in single player as well, as this is a RAM address issue.

There's some build forward there; my guess is neoqb is betting that in five years the 32 bit OS will be as common as Win 3.11.

I think you could upgrade that 2 GB max to 3 GB max using the 3 GB switch and imagecfg. Don't know if that works with ROF or not. It's a bit strange that ROF wouldn't use more than 2 GB anyway.

But that's what you get, if you put high qualitity textures in a game, it was just a matter of time before the first games come out that would run into the 32-bit barrier.

It's not even to do with RAM especially I don't think - it's to do with virtual memory; the local paging file stored on the PC. 32-bit systems are limited to addressing 2GB of virtual (paging) memory, in addition to whatever quantity of physical (RAM) memory they're using.

Give the game (already a hefty memory drain) too many resources to load into the enviroment - too many different types of vehicle, too many types of aircraft, too many different skins - and it tries to address more than 2GB; and you get the Out of Memory error.

It should be noted that the game - regardless of OS - is set to ONLY use 2Gb, which is why 64-bit systems can have the problem as well. However, since a 64-bit system is more likely to have a large quantity of physical memory and so is less likely to heavily rely on paging, it probably explains why I've only had this specific error once or twice and you see less reports of it from 64-bit users.

For 64-bit systems they can add the LARGADDRESSAWARE flag to the game to enable additional virtual memory useage - it sounds (from other posts) like they're considering this.


If you think about a large mission like some on T&T - where there's maybe 8 types of aircraft, five or six types of additional unit - AAA, balloons etc - and maybe 32 aircraft, *possibly* each with their own different skin - well, at 5Mb per skin, you can be talking maybe 250Mb simply for textures alone.


This issue, as Dart says, has nothing to do with whether you're running an i7 920 or an E8400. It has everything to do with Neoqb trying to get the best out of the engine for their customers - to allow *everyone* to use the game whether they're on 32-bit or 64-bit systems.

They are right to be thinking ahead, but clearly it's a bit of a bummer. As for people saying it's unoptimized - there is an element of that, but those pretty graphics have to be loaded *somewhere*, and Neoqb can hardly afford to eliminate every 32-bit using customer out there.

I love memory management issues, they're very interesting problems to solve.
Wish Lefty gave more details. Good luck to them.

I have a 32bit XP rig and have set the page file memory to the max of 4GB with no issues. I have 4GB of ram with 3.25GB's recognised. Are you saying only 2GB's of pagefile memory is recognised regardless of the setting ?

It's 2 GB per user application.

Errr....I have Win7 64bit with 6Gigs of ram and had that error.

Something is a miss. Let's just say that much.

Win7 64bit
i7 920
6Gigs
GX280

I have been bumping against and even exceeding those limits with no apparent ill effects. I have generated up to six different aircraft types and exceeded 30 aircraft. However, my missions tend to be a bit sparse on ground objects so I might be saving space there. Also, I am currently using only generic skins.

It was not a happy read but the limitations are tolerable. My concern comes in when more two seater types are added ... although that is a concern that I would very much enjoy having.

The fun part of compatibility comes into play there. How do you get a game to run on two separate system environments that will operate together in multi-player? Weakest link gets the max operating capabilities, so the plane and skin limits go to the lowest common denominator.

They could atleast set the Large-Address-Aware-Flag for ROF. That way (if it works), with the 3 GB switch ROF could get up to 3 GB and under 64-bit OS (without 3 GB switch of course), it could get 4 GB and that should be enough for ROF anyway.

I checked wether or not that flag was set in the ROF.exe, it's not. So i set it, but i could've guessed it that the DRM didn't like that. Funny thing, gave me a checksum error.

So, we're looking at DF servers with fifteen to a side.

That rules out humongerous servers with oodles of folks in them, but still leaves room for "Dart's Server" ones.

I think the max we've had is 24 back in the days when I set it for 30, and on a really good night we'll have sixteen - which seems really crowded!

Downside - no RoF World League or Great War with 40 to a side, as in the old RB3D days.
Upside - still enough players to make it worthwhile to jump in the fray.

Now if they could make true dedicated server software (that acts only as a hub for data and doesn't require an activation code or installing the full sim) to go along with it, I'll be happy (and host a multi-player server!).

This explains why the environment is so lifeless, You cannot place any real amount of ground objects on the map.

What a joke.

I build this computer over year ago and even then it was not top of the line, so IMO it is mediocre system

some ppl wont admit...the sim is BADLY optimised....you will se how BOB SOW will perform even with better or equal graphics.....in opengl baby

Neoqb should take some lessons from Maddox....

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.

the only visuals we had so far were not very impressive

Oleg keeps everything very close to his chest haltux but we can see where he may be heading. Remember how Oleg came up with a solution to large forests in Il-2 by stacking textures

No need for massive amounts of texture memory if you're using procedural shaders... cornfield shader one day

http://ati.amd.com/developer/SIGGRAPH07/Chapter5-Andersson-Terrain_Rendering_in_Frostbite.pdf

http://epubl.ltu.se/1404-5494/2007/12/LTU-HIP-EX-0712-SE.pdf

Ming

Thanks, Ming, now I know the depths of my ignorance has no bounds.





Lots of weird choices were made in RoF, some of them really good - like the speedtree(ish) fading in of trees to keep them all having to be rendered yet still be "solid" for collisions, and some kind of weird.

Errr, you clearly didn't read or understand the points Neoqb, Dart and I all made - which is that regardless of whether you're on x64 or 32-bit OS, the game can ONLY handle 2Gb of VIRTUAL memory usage.

It doesn't matter a jot that you've got a 1GB graphics card, 6 gigs of DDR3 in triple-channel mode. The game will still only use 2Gb of virtual (pagefile) memory, and when you overrun that you get the "out of memory" error.

I think ROF management needs to do some serious home work on this issue. Based on my experience the ROF designers have porked up the design if these restrictions are real.

I think what they may have done is given the implementation and the current performance testing then here are the best guess restrictions.

It may have been better to not post the restrictions until the rework was completed and new performance testing done unless they do not plan a good solution.

This reminds me similar discussion when FSX was first released. There were always people explaining that FSX was immensely more complex than any other video game (which could be partially true) and that this unavoidably makes the game immensely slower (which is nonsense).

When someone tells you that something that you don't see (like a plane 20km away) needs a lot of CPU time and that's why everything is necessarily so slow, it is either wrong or means that the game is badly designed. If you don't see it, if it does not interact with you, a realistic model is useless and therefore it should not require a lot of CPU time. This should be the basics of any simulation programming (or more generally any kind of "virtual world" programming).

No one requires that the bullet fired by a guy on another guy two kilometers from you on the battlefield is modelized in a realistic way. What people want is that their plane, their opponent's plane, their bullets and the bullet thrown at them are modelized in a realistic way. For the battle field, for ground units moving on the ground and fighting together, there is no reason to have more complexity than in Empire Total War (which is a recent game btw), so displaying a battlefield with thousands of units in RoF should not be more complex in RoF than in Empire Total War.

You are comparing a game that models very simplistic features for even the player controlled unit in front of him to an air combat simulator that is far more complex.

Just the processing power required for the planes in your vicinity is a huge hit. Have you tried a 20 vs 20 dogfight? It is modeling only what you see around you in your immediate vicinity. The computing power required to render an air battle is far more complex than a simple RTS, even a FPS, game.

But you're not talking about having a thousand units, only some of which are visible at any given point. You're talking about having a thousand units in use and visible - and unless you're using something like sprites that is always going to be a hell of a workload for either memory, CPU or GPU.

displaying a battlefield with thousands of units in RoF should not be more complex in RoF than in Empire Total War.

You'll need to study up a bit haltux (which will be enjoyable trust me) if you're interested in simulations generally, functions like geometry instancing mean that there may actually be only five or six soldiers on the table. The rest of the armies are smoke and mirrors

The computing power required to render an air battle is far more complex than a simple RTS, even a FPS, game

And then some Natty.

The soldiers are simple objects having no physics properties. No mass, no spring forces, no gravity

Faithfully modelling even a simple wing under the physics of gravity and wind, lift and drag, fluid dynamics etc needs far more CPU power than that needed to track hundreds of simple smoke-and-mirrors blocks around a tabletop

Physics is maths, maths is CPU. Simple maths, simple physics, simplistic simulation

Games v simulations it all boils down to.

Ming

Stop patronizing me. I know perfectly what you are talking about and you did not understand my point. I'll try to make it clearer.

It is a plane simulator. You have to make models of plane, physics of plane, AI, so on... This is complex, there is no such thing in games like Empire Total War.

Then you have to render the environment (like in ETW), and the ground units: soldiers, trains, tanks, so one. What you want from these ground units is that they behave in a way that looks good, in RoF or ETW (and honestly, even a fraction of the realism of ETW in terms of battlefield rendering quality would be great).

There is no reason why the physics of soldiers and tanks should be more accurate in RoF than in Empire Total War. The mirroring techniques used in ETW would be therefore perfectly suitable to render a battlefield in RoF. This is not more complex.

This is a plane simulator where a decent battlefield rendering would have been great. This is not a battlefield simulator where every moving object should be modelised and simulated in a realistic way.

I completely understand that:
- RoF has a much smaller budget than ETW
- Displaying massive amount of units was not the first priority for RoF

But arguments like "what you can do in a game cannot be done in RoF because it is a simulation" are nonsensical.

Hmmm, thinking of it ... remember the requirements are for multiplayer. Now, in multiplayer, the additional problem is that 'you' are not only in one place which should be modeled accurately, but also the other guys are in another places that should be modeled accurately, so this is what puts strain on the server. More players, more places, more computations for the objects on those places. Same for AI planes, even if they would fly based on a simple FM while you're not close to them, the chances to be close to them is higher in multiplayer. I'm not saying things cannot be optimized etc. but i think this is perhaps the bottleneck. If they want to present a *no-crash* solution, they would compute the worst-case scenario and base requirements on that. I don't think it really crashes everytime you don't respect the requirements, right?

Oleg commented once he can make a sim more real (complex) with perfect graphics but thers still no computer in this world which will be able to deal with all that in dogfight without serious performance issues...so optimisation is one of the most important thing in simulation development....

It's very much makes sense when the aim is for high fidelity at every level rather than half-assing it with smoke and mirrors, tricks and cheats, to give the appearance of a battlefield that you have little chance of fully interacting with. It'd just be a side show, because each unit would require a global basic damage and movement model. Boring.

It sounds to me as though Neoqb have not yet got the art of lazy load/unload down. What they apparently do is load everything in memory at mission start.

A relatively simplistic way to do it is ...
1. Large objects (aircraft models) that would cause a noticeable stutter should be pre-loaded.
2. Models of lesser importance (ground objects) should be made with much less detail to avoid taking too much space.
3. Smaller objects/skins/etc. should be lazy loaded (loaded only when called for).
4. Load only what is in view or close to view range.
5. Unload when no longer needed.

The full advantage of on demand loading are not realized due to up front load of large objects, but it would help.

You could even get more sophisticated at some risk.
For example:
Lazy load everything.
Make low detail models for viewing at a distance.
Avoid loading in combat unless absolutely necessary (necessary = view distance is close enough to demand load even though player is in combat. Stutter may occur).
Mitigate the risk of stutter by getting sophisticated about the load algorithm: try to lazy load on a different thread at low priority when player is just flying around. Bump the priority of the load thread if the object is getting closer to the player.

The problem with this is less well defined behavior. It is complex and can be a #%&*$# to debug. There will be "perfect storm" cases (i.e. lots of different aircraft of different types with different skins appearing simultaneously) that could cause severe stutters or memory errors.

The advantage is much better memory usage, usually much better performance, and vastly better initial load time.

Publicly you state the same restrictions to keep people from creating "perfect storm" missions. Under the hood, however, your software is much more capable and load time greatly decreases.

Please take an hour of your time downloading and trying Empire Total War demo. It worths it, even if you don't like strategy games.

What is boring to me is a battlefield with max 40 ground units.

So, haltux is saying "keep the air combat aspect detailed but give the player a simplified, yet greatly expanded, ground combat aspect to immerse himself in the the virtual world".
On the other hand you say "everything should be detailed as much as possible and since we can't do that due to processing restrictions and having the main focus on the air combat, let's not do anything at all".

Is that the correct way to read into it, or did i misunderstand something? Because if i didn't misunderstand it, i think haltux has a better point and his idea would result in a much better virtual environment.

First of all, this is about the online portion and not the single player segment if you'll take note.

So, let's say you have this massively active battlefield of generic pieces that have group mentality and make movements as units rather than individual pieces. What fun is it going to be to take a 2 seater up when they are flyable and attack a ground unit that doesn't take any evasive action? You know you HAVE to bomb that ground unit to accomplish the mission, so thousands of other units out there won't be applicable. I'd rather ground units that take evasive action individually rather than the generic herd mentality in MP.

This is not really a problem. Once one unit requires individual behaviour, because for example it is in your shooting range, it can be broken away from its group and starts behaving according to a complex, individual model. Then, it will come back to its simpler, global, herd behaviour model once it leaves your shooting range.

The number of unit which will requires the complex, individual model will always be very small compare to the overall number of units.

That's just the AI behavior side, but in herd mentallity they have to take obstacles as a group and can't move individually.

The problem with the memory requirements is the detail that goes into the ground units as far as textures go. While some may be fine with boxes moving along the ground that look like they belong in EAW, I prefer detailed ground objects. Looks terrible when the entire world is extremely detailed and then you have a 1997 era style model that you crash next to.

That's already in there. Agree on everything else though. I don't get it why plane models and textures are no preloaded, it causes MASSIVE slowdowns when flying by other planes.

The ground units are already very "reduced", the average texture for vehicles is 256x256 (= about 80 KB), many are 128x128 and the models are also very small (average less than 200 KB). Like i said before, i don't think the numbers presented by NeoQb for ground units are correct, i don't see why ROF couldn't handle more than 40 ground units, it could probably even handle 400 ground units of the same type (talking about memory restrictions only).

If I read this right, they say that you need to reboot after 3 to 4 hours of play. Sorry, but that's a memory leak, and I have no idea why they're trying to blame the OS for that.

And the 2GB of virtual memory limitation shouldn't even come into play. 3 GB of RAM + 2 GB of virtual memory = 5 GB of total memory. If they can't run this sim in that much memory, something is really FUBAR'd.

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...

Don't know how long that would take (with beta testing and bug hunting that could take a while), it would be a waste of time anyway, because the only real benefit would be more than 4 GB memory address, which is unnecessary anyway and no 32bit user could even start ROF or connect to 64 bit version servers (maybe fastaer loading times also, but that's still not worth it). 4 GB is enough and this could be accomplished easily by setting the flag, which takes me less than 10 seconds but they would have to change their DRM, because it will change the checksum of the ROF.exe, so maybe one hour tops.

I just hope they figure something out, Its not a lot of fun owning the Cadillac of WWI sims when the best you can do is back it out of the garage and look at it.