Iff you could have one thing in the next update it would be. (Archive)
-
@A.S:
Thus a “Memory-Bus” aswell, which is also a Bus in the core (namely double the width in the cpu architecture) will improve speed NOT the FPS necessarily. Big difference: One can calculate 10000 things with 60 FPS or 20000 things with 60 FPS.
Unless you are positing a scenario where memory amount is a serious bottleneck, no. Well, sure, you can throttle execution, but that’s different.
I think you might be confusing 64-bit processors with newer processors that, through being new, have innovations in other areas as well. Stronger internal buses in the CPU have nothing with the 32-64-bit thing to do. What has happened, however, is that desktop computers has made the transition at a time when innovation in memory buses (and ALU, register design etcetera) all were necessary. Mainframes transitioned to 64-bit in the 70’s, workstations in the early 90’s. And note how they did so with no real link to multicore execution and while being hopelessly outclassed by the hardware we have available on the desktop when they commenced the transition back in 2003-2004ish. (Indeed, the first two 64-bit desktop CPU’s I ran were both single-core, running 32-bit XP and 64-bit Linux in dualboot.)
64-bit memory adressing gives access to bigger datasets, allowing you to do more. Your description of it is just wrong - or explained in such a way that it is indistinguishable from wrong. If you are so certain, you could perhaps offer a direct example of what you mean - at the nitty gritty. I’m quite at home in computer components and CPU architectures, so don’t worry, I’ll understand it as long as the terminology is somewhere around right.
However, what RoF did was multithreading. But want to know a little secret? Rise of Flight is 32-bit.
Like DCS previously, it has two compiled paths in the installer, and if the OS is 64-bit it installs 64-bit, if OS is 32-bit it installs 32-bit. But here’s the important thing: even when running 32-bit path, it still has all the same multithreading things that you mention. These are completely separate things and Rise of Flight is actually an example of that fact! They were able to implement multithreading in a good way since their engine saw it’s design stage when multicore processors (32 or 64-bit… who cares? When it started, it was actually majority 32-bit OSes on pseudo-64-bit hardware.) Which is not the same thing as being 64-bit and is completely irrelevant to it.
What has happened, and which I continue to feel is what is causing you confusion, is that the transition in mainstream consumer equipment has happened to occur roughly simultaneously for both 64-bit and multicore processor architectures. (Though that depends on how you count, considering how for the first 5-7 years of 64-bit desktop processors they were none-the-less sold with 32-bit OSes, since with just 256MB of RAM and similar it’s not like they need the memory space anyhow - but since the same architectures were also used in server silicon, that synergy of design effort meant that they did get theoretical support for 64-bit operation as long as they got a 64-bit OS. I personally ran 64-bit Linux back then, since - as most remember - 64-bit XP had atrociously bad driver support.)
@A.S:
But even if all that would be not important, just the wider memory access is reason enough to go for 64bit, especially for flight-sims.
THERE you are getting it.
Being able to manipulate greater amounts of data is huge for combat sims. Civvie sims like MSFX etcetera - meh, not really, cool for ultra-hot terrain packs I guess. But combat sims that, for example, want detailed ground environments that are at the same time large do need to be able to hold a lot of data. (The bubble solution of Falcon 4 only goes so far, since there might still arrive issues in some MP scenarios.)
-
64-bit memory adressing gives access to bigger datasets, allowing you to do more XXXXX
Add “simultaniously” to it and then YOU GET IT
You can also read here for educational purpose: http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/
The internet is full of “Comparing 64bit and 32bit CPU benchmark results” clearly showing performance advantages with 64bit, but it always depends what you are measuring too of course.Here are some example from the CPU tests. (higher numbers are better) TEST: CPU - Integer Math PT6 64bit, Win2003 64bit, Result = 193.3 PT6 32bit, Win2003 64bit, Result = 92.9 PT6 32bit, WinXP 32bit, Result = 92.9 TEST: CPU - Find Prime Numbers PT6 64bit, Win2003 64bit, Result = 217.7 PT6 32bit, Win2003 64bit, Result = 158.2 PT6 32bit, WinXP 32bit, Result = 157.9 TEST: CPU - Data compression PT6 64bit, Win2003 64bit, Result = 2584.6 PT6 32bit, Win2003 64bit, Result = 2578.6 PT6 32bit, WinXP 32bit, Result = 2582.77
What we need to understand is HOW CAN WE BENEFIT FROM 64BIT IN SIMULATIONS AND WHY (NOT ONLY MEMORY WISE) !
I don´t think i can contribute anything more (even if nitty gritty) to someone who already has its own concreted position to the matter and to be honest i can´t even bother explaining again noticing where this might go (waste of time).
Therefore, all to say i guess is: Cool, take your expertise into the DCS and let the 32bit results speak there. -
AS,
If you don’t post source code to benchmark, compiler, its version, stddev, used compiler/linker flags, it’s worth less than nothing.
My SSE3 float code with GNU CC and sane flags has about the same perf on 32-bit and 64.
-
AS,
If you don’t post source code to benchmark, compiler, its version, stddev, used compiler/linker flags, it’s worth less than nothing.
I am not hunting specific cases or “exceptions” to proof counter-argumentative situations.
How 64bit can be utilized for flight-sims generally i pointed out in post 86. -
Actually, 64-bit pointers are slower than 32-bit to pass around Not to mention real RAM usage with tons of them.
-
Isn’t BMS 4.32u6 using large address aware flag? That means full 4 gigs.
Not sure what is “large address aware flag” exactly, but if the limit is not 4GB, I assume that you are right.
Actually, 64-bit pointers are slower than 32-bit to pass around Not to mention real RAM usage with tons of them.
Maybe, but tests showed that 64 bit EXE isn’t slower than 32.
-
There’s “editbin /LARGEADDRESSAWARE some.exe” that users have been using already for some time, with large sceneries and somesuch.
Please see:
- Set LargeAddressAware flag on 32 bit executables.
-
So I don’t know… I guess that’s the case in development EXE which we are using, but still the EXE is limited to only ~1.7GB of RAM, beyond that it’s simply crashing.
-
well the 64bit exe which I-Hawk said it’s faster the case till now was that it was slower and that was why there was no 64bit exe… hmm maybe something changed in the mean time…
Besides that I believe more needed (and more painfull for the coders) would be to better use of cpu cores… like the known demanding aggregate deaggregate functions that bring CPU’s on their knees and have a huge FPS impact not to mention that it’s limiting unit’s - objectives - features numbers… If those functions could be transferred - calculated by other cores, and balance the CPU load, then the whole experience would be smoother, and would open a whole new chapter for BMS details and realism. Also would keep the HW budget to a good point.
I know that is said that the code it’s multicore but is it optimized on the above? Or would such optimization give better results?
-
Being realistic and accepting that what we have now with terrain ( new Balkans and several other WIP) and graphics is pretty darn good, and not going to get much better, I would really like it if the AI were better and ground troops etc more controllable. It seems bizarre that after 10 years, these basic things are still causing issues. Better and more volumetric ( I mean thicker , fluffier cloud layers) clouds would also be a great addition to the realism. And realistic JDAM function would be great as well…
Finally, better terrain elevation, to remove the spiky mountains and flat hill sides.
Apart from those, BMS is pretty much perfect…
-
After all, BMS runs at around 100FPS on taxi and 250FPS in the air on a moderate i72600K and 570GTX system with 4GB+, if the settings are not “greedy” pushed out to the max (HDR Bloom, Cockpit Shadows etc.).
This is quiete an accomplishment i would say, isn´t it? … considering everything going on in a campaign.
Even IL-2 HSFX7 (graphics extensive) runs on the same system with 250-600FPS (OpenGL), which is even better, but this sim doesn´t have so many things being calculated as BMS does i guess.
Rise of Flight runs excellent on compareable systems (so i am told), FSX, Cliffs over Dover and even Warthunder with cinematic graphics run flawless (so i know), only latest DCS products (so i am told) have a big issues to even get close to those FPS ranges on moderate systems, suffering at the lower ends where it is still “playable”.
-
I would really like it if the AI were better and ground troops etc more controllable. It seems bizarre that after 10 years, these basic things are still causing issues. ……
Well…as i worked a lot on AI WVR recently, i can garantee you that this area is far from beeing basic.
Just to give you an example in WVR :
- first you need to teach AI how to keep Corner speed , for that you need to manage Thrust AND Stick position
- Throttle code for AI was 100% wrong since original F4, rewriting it was necessary, this had collateral damages everywhere in code (climbing profiles/ timing for navigation / fuel consumption / refuel positionning / interception courses etc)
- No code was existing for determining what stick position was necessary to maintain a certain speed assuming throttle was set correclty
- after stick code was re written, discovery was made that the stick position passed to the AI FM code was badly handled …so it had to be fixed as well , this had collateral damages everywhere stick position was sent to AI FM …
and that is JUST ONE example…just to be able to maintain a speed…now imagine everything that needs to be done for having a complete AI operationnal
so yeah , AI is pretty much busted in every domain, has always been …some areas will be improved
Ground troops management -> see you in 3 -4 weeks
-
I think that’s the real issue here. Everyone has his or her wishlist, but very few people actually understand how complex it is to change things in Falcon given the age of the original code, the compromises that had to be made back then, and all the changes that have been made since.
I’m just grateful for what we’ve got to be honest. Anything coming out in 3 to 4 weeks is a bonus :bowd:
-
I know, but this is a “wishlist” after all……not a features request thread. I am keenly aware of all the coding issues…
-
So I don’t know… I guess that’s the case in development EXE which we are using, but still the EXE is limited to only ~1.7GB of RAM, beyond that it’s simply crashing.
tomcatz scenery usix no black sky or crash
sorry on phone -
Well…as i worked a lot on AI WVR recently, i can garantee you that this area is far from beeing basic.
Just to give you an example in WVR :
- first you need to teach AI how to keep Corner speed , for that you need to manage Thrust AND Stick position
- Throttle code for AI was 100% wrong since original F4, rewriting it was necessary, this had collateral damages everywhere in code (climbing profiles/ timing for navigation / fuel consumption / refuel positionning / interception courses etc)
- No code was existing for determining what stick position was necessary to maintain a certain speed assuming throttle was set correclty
- after stick code was re written, discovery was made that the stick position passed to the AI FM code was badly handled …so it had to be fixed as well , this had collateral damages everywhere stick position was sent to AI FM …
and that is JUST ONE example…just to be able to maintain a speed…now imagine everything that needs to be done for having a complete AI operationnal
so yeah , AI is pretty much busted in every domain, has always been …some areas will be improved
Ground troops management -> see you in 3 -4 weeks
wow, thanks. Anybody besides me in the mood for some spaghetti?
Hey, just to test the AI is more than a frigging handful, much less fix them I’m sure.
But think about it though, if the AI sucks so much, why is “longevity” medal still the rarest;)
-
I think most of my wishes come true in 3-4 weeks.
A nice feature would be some randomness for the RWR that it will become less reliable.
-
A real SPI system.
-
-
Time compression for falcon weeks.