Iff you could have one thing in the next update it would be. (Archive)
-
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.
-
@A.S:
Therefore, all to say i guess is: Cool, take your expertise into the DCS and let the 32bit results speak there.
64-bit is part of the minimum system requirements for DCS World.
-
64-bit is part of the minimum system requirements for DCS World.
As of, maybe a month ago.
-