Iff you could have one thing in the next update it would be. (Archive)
-
64 -bit is usefull when program hits ~4Gb of RAM usage (plus some case specific speedups), iirc Falcon is still far from that line. Multicore utilisation is about threading, nice but kinda tricky. Parralel execution comes at price of more complex code and cpu overhead spend on making it all thread-safe. Also performance gain ranges from almost linear to amount of threads to near zero. So in the end you might get code more complex and slower at the same time.
Fractal terrain: yep itd be graeat improvement, esp when used to enchance real world data and simulate various terrain and material types (different types of rocks etc…)
True, we cannot really say Falcon rocks until we get the geology right. I’d say my top #1 wish is an improved terrain, one that makes you feel sorry every time you lawndart.
-
-
@A.S:
How many threads (if software structure allows) can you run simultaniously on ONE core anyways on a conventional modern home cpu ?
Even Hyperthreading is semi-parrallel processing (as it is still serial) and not real parallel computing, which would be possible
if more “hardware architecture” (as you call it) or cores could be used simultaniosly. Makes sense now?A flightsimulation (with all its aspects such as FM, weatherdynamics, GFX, etc. etc. you name it, all the modules and split-able in seperated threads firstly and secondly cores) is an ideal example for why a 64bit and not a 32bit solution.
There is a reason why professional sims are not only run on multi-cores, but even multi-cpu s , which luxury most us don´t have anyways, thus the utilization of all cores as PARALLEL processing method and the 64bit expansion.
Again sthalik i sright there 's no relation between arch (32 vs 64 bits) and code parralelisation. You can make 32 bit code as mutli-threaded as 64bit one.
64bits give you larger register size (and so larger amount of mem cells - ie more addresable ram) and depending on complier settings usage of modern instructions set (ie SSE v x.xx, AXV and such)
The latter cat be acheived on 32bit code too by manual setting compiler flags. In both cases you’re excluding older cpus which not support those instructions. -
Ok… lets go back to 8bit, because "size doesn´t matter :mrgreen:
64bits give you larger register size (and so larger amount of mem cells - ie more addresable ram)
aka more FLOPS, right ?
I might be old-fashioned, but for me 64 “channels” push more “water” than 32 “channels” within “the river” and with the same flow-speed (Hz).
In both cases you’re excluding older cpus which not support those instructions
You running XP SP3 or something?
-
The things I would like to see implemented are buddy lasing, better terrain, ir lights… The one I would really like is the system where the radar cursor is “slaved” to the TGP and other sensors to be implemented correctly.
Edit: Just remembered the correct term. What I wan’t is a better SPI implementation.
-
Again, you’re mixing things up.
Compiling code to 64bit doesn’t make it more multi-threaded than 32bit code. It doesn’t affect flops as your equation is about instructions. It doesn’t matter that much if it’s 32 or 64 bit, instruction is instruction.
There are some corner cases where you could try to push two 32bit datachunks in one instruction, but those are rare cases and overall benefit may not be so significant. Cost is possible headaches with variable types (some of them have different size under different arch)
IIRC BMS team had some internal 64bit builds and it didn’t bring any significant benefit to regular 32bit binary.
BTW Nope, i run linux almost exlusively
-
Soo, let me ask stuipid then. Why they invented 64bit systems in the first place then?
32vs64bit for dummies:
-
BMS members:
How is BMS numerics-heavy? Do you do much autovectorization might benefit?
Xeno,
Do you run 3.9+? Bouncing cow lackage makes some nice improvements, that make the software not require core pinning anymore.
For sure try gallium-nine, it gives me a nice 60% CPU boost under light workload, compared to wined3d vanilla.
A.S., addressable space isn’t a problem in BMS. It might be for other workloads but not here. Unless one uses 16384^2 textures or something… Since they /seem/ to be mirrored in sysmem, not just VRAM.
-
First discussion was about multi-core utilisation which as proed has nothing to do with x bit CPU architecture. What you asked for is modular well mutli-threaded code, that is perfectly achievable on 32bit arch.
We currently go for 64bit oses because 32bit systems are able to address 2^32 of RAM (that is exactly 4GB) whcich seems to be not so enough for current usage patterns.
x.bit architecture means memory cell is x bits large, it equals to how big number can be stored. Becauses memory address is exactly one memory cell, amount of addresable RAM depends on how may bits memory cell is wide.Downside of going 64bits is some variable types takes twice the memory comparing to 32bit systems, which may also lead to sligtly slower code as the same data takes more memory thus, using more memory bandwitch to transfer.
-
The things I would like to see implemented are buddy lasing, better terrain, ir lights… The one I would really like is the system where the radar cursor is “slaved” to the TGP and other sensors to be implemented correctly.
Edit: Just remembered the correct term. What I wan’t is a better SPI implementation.
done, not done, not done, done
-
I’m on Fedora19 so it’s 3.11+ mesa 9.2 (build 9.2-1.20130919). Sadly i’m not flying for last few years as my lappy is not really up to the task ( Core2Duo 2.1 + Radeon 4330m). But I saw your posts. It seems there’s a hope for us I’m really looking for 1stQ of 2014 when I’ll get new rig. Most likely I’ll set for Samsung AtivBook 8 current model (i7 + Radeon 8870) or Haswell refresh if it’ll get AMD gpu. I don’t really wanna mess with closed binaries.
-
1. Working Turn and balance indicator (for rate 1 turns)
2. Automatic different tail number for each plane (Is there a way to bypass the issue in MP by assigning for the same model skins with difference in tail paint? So that before the flight each member pick his own paint scheme? It’s not so efficient but it can work,right?)
3. RL JDAM/LJDAM code
4. glide weaponsI was under the (apparently mistaken) impression we already had some of these…
the glide weapons, I was sure I have seen in BMS, and you can already have different tail numbers in multiplayer. I understand a number of wings custom installs feature this - I recall the 27th were going to have one, but the guy working on it left. … not sure if the first VFW install has it, but I seem to recall demo expressing interest in the idea. maybe a 1st VFW member can provide input?
JDAM avionics would be nice to have, and I believe some minor details on them are on wikileaks. sadly iirc the manual details the JDAM avionics for the hornet, not the viper…
yes, you could make a workaround by having 4 identical skins with different tail numbers, but you can instead create 4 different skins with 4 tail numbers each and have 16 different tail numbers flying… per block of jet.
you could have 32 different tailed jets using block 50/52 aircraft and model a squadron quite well.
-
Automatic different tail number for each plane (Is there a way to bypass the issue in MP by assigning for the same model skins with difference in tail paint? So that before the flight each member pick his own paint scheme? It’s not so efficient but it can work,right?)
Mirage-2000D has uindegou project licence plate project. The numbers are controlled via skins.
-
I don’t know how those tail numbers will work. If the jets are all from the same squadron, they will have the same skin set. If a person changes his skin in the loadout screen, then all aircraft in that squadron will have that exact same skin and only he will be able to see them. The skins will remain unchanged for everyone else in MP.
The only way to have different tail numbers would be to have each person fly from a different squadron, which might screw up IDM.
-
I don’t know how those tail numbers will work. If the jets are all from the same squadron, they will have the same skin set. If a person changes his skin in the loadout screen, then all aircraft in that squadron will have that exact same skin and only he will be able to see them. The skins will remain unchanged for everyone else in MP.
The only way to have different tail numbers would be to have each person fly from a different squadron, which might screw up IDM.
Multi-skins are avail in loadout regardless of squadron. Skins are specific to the aircraft (F-16) Block in BMS.
Assuming, you had 4 aircraft in the same pkg, 1 aircraft in each pkg flight. You would then be able to switch individual skins. If the skins were on both you and each other flight everyone could see the particular skin you selected, I believe.
There are 4 switches allocated to the"license plates" in BMS. This is being researched as we speak.
-
It hasn’t worked like that in my experience. Yes the skins are specific to the aircraft, but each squadron is assigned a skin set by default. The 1027th is set #2 and 1028th is set #3, for example.
If you have a 4-ship in the 1027th and you change your skin in the loadout screen, that skin will be applied to all 4 jets in that flight. In SP TEs, if you fly in the 1027th but change the skin of the 1028th flight in the loadout screen, once you get in game the 1028th will revert to its default of set #3 regardless. There’s also this strange phenomenon in the campaign where, despite the fact skin sets are assigned via the camo.cfg file, if the player changes his skin some of the AI squadrons will have their skis changed as well. For example in Rolling fire, if I fly as the 111th (default skin set is #6) and choose set #4 for a mission, somehow the AI Block 40s of the 80th are changed to set #3 despite the fact that the camo.cfg file tells them they should be set #6. At Osan, if I fly as the 36th and change the skins, the AI A-10 skins are somehow changed from the OS to SP. This has happened to me consistently since Update 1.
-
Make a pkg flight, 1 ship each flight total 4 flights. Change all the skins and go in pit. Last I tested this was the only way so far.
-
I know this has been discussed before but having a FAC, of better yet, a ground Combat team would make “come Help me now!” missions so much better. The AWACS “vector to target” does get you in the right direction but there needs to be some kind of local handoff to the target. Soon A-10s will be gone an F-16s will be doing more “On Call” missions (the Airforce will never use a F-35 to take out a single FO harassing our troops). Even a “Pop Smoke! for your location” feature would be cool. For now using labels for friendly locations can be used but not real.
-
-
Make a pkg flight, 1 ship each flight total 4 flights. Change all the skins and go in pit. Last I tested this was the only way so far.
Different squadrons right? That’s what I was thinking. The only problem is that if I change the skins and then go in pit, all the other flights will go back to their default skins. However if I set the proper skins to the squadron it would work.
Oh and I remembered on other thing I wish we had: less Cowboy 9 flights at the same time.