Iff you could have one thing in the next update it would be. (Archive)
-
@AS
all 3 bad ideas:
- 64-bit is only a problem for address space. BMS doesn’t use too much address space.
- We have native impl for DirectX now as a Mesa state tracker on Linux now… OpenGL is crap, crippled by CAD-support origins.
- Meshes are always used anyway, as 3D pipeline is based on triangles.
My idea: better thread pooling and profiling of the hot path.
-
@AS
all 3 bad ideas:
- 64-bit is only a problem for address space. BMS doesn’t use too much address space.
- We have native impl for DirectX now as a Mesa state tracker on Linux now… OpenGL is crap, crippled by CAD-support origins.
- Meshes are always used anyway, as 3D pipeline is based on triangles.
My idea: better thread pooling and profiling of the hot path.
With respect Mr. Coder. I agree to disagree a Marlboro-ish 100% in all 3
Your response appears to be instinctively reactive without deeper thougths maybe? :fart: -
First point is especially nonsensical. BMS uses MSVC and a such, vectorization or register starvation doesn’t get addressed as the compiler is crap anyway.
-
I wouldn’t think so… As a lot of the present theater-development is based on people who aren’t even a part of the dev team
But doesn’t BMS contain work from folks not part of the core dev team anyway?
I guess that it’s more about who owns the intellectual property, which based on what I’ve read is a complex subject regarding F4 & it’s variants.
-
f-16 and f-15 skins representing the california air national guard in fresno. it was just takin off the pentigons cut list. lot’s of history. they are the 144th fighter wing and they are true bad asses. they do a lot for my community and somehow always seem to get overlooked. the f-15’s are just starting to arrive as they have been added to the 144th so get skins might be a chore but the f-16’s have been here and i’m sure those can be found pretty easy
-
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 weapons -
Always wondered what does “scripting avionics” actually mean? I mean, what do you expect such a “scripting” system to be able to do? let you decide where some labels will be positioned on the MFD? or what built-in functionality some buttons on the MFD can do? because if that’s the thing, then this isn’t avionics, it just playing around. For real “upgrades” of avionics, only code will help.
As for other ACs systems, I can tell you that even if we had the time to code some (which we don’t, the F-16 itself still require a lot of work), I can hardly think of maybe the F-18 and probably the A-10 as the only other ACs that worth investing some time on, for other jets, its mostly bits and pieces of knowledge here and there, hardly to even start thinking of the basic systems.
I’m thinking of something similar to Nasal used in FlightGear. It has access (both read and write) to lots of sim internal properities and allows to write systems logic (sensors, navigation/autopilot, maybe flcs), cockpit insrtuments and so on.
You know that perfect is an enemy of good. Even for F16 there are variants not represented in Falcon, russkie airframes, even if modelled up to Lockon/FC leve wouod be still better than those franken-planes we have. Older eurpoean crates (esp Mirages) ,so important for middle east scenarios also shouldn’t be impossible to do.
-
lets fix what we already have!
-
First point (64bit) is especially nonsensical.
Regards your answer refering to 64bit suggestion. Don´t you think it would benefit to address all cores. 32bit is really really old stuff meanwhile. Or better… 32 OR 64 bit optional hah?
About OpenGL, well, let´s just say im a believer* in OpenGL for various reasons.
Fractal vs Mesh. The point is terrain generation, not rendering, well actually even in rendering we gain much FPS compared to older conventional methods.
Time moves on …
-
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…)
-
-
Regards your answer refering to 64bit suggestion. Don´t you think it would benefit to address all cores.
What does threading have to do with hardware architecture? Doesn’t make any sense.
About OpenGL, well, let´s just say im a believer* in OpenGL for various reasons.
Well… Have fun with ADS lighting, as interpolation of vert color doesn’t work on frag except on actual vertices*… But the same is true on old D3D versions such as the one used by BMS.
- Talking here about specular
-
What does threading have to do with hardware architecture? Doesn’t make any sense.
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.
-
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: