Iff you could have one thing in the next update it would be. (Archive)
-
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.
-
@A.S:
Soo, let me ask stuipid then. Why they invented 64bit systems in the first place then?
Because 32-bit systems can only adress a given amount of RAM. To be precise: 2³² bits. (AKA ~4GB.)
To go back a bit, you said this:
“Regards your answer refering to 64bit suggestion. Don´t you think it would benefit to address all cores.”Here’s where I think you’re getting confused; 32bit vs 64bit isn’t about “adressing” cores. It’s about memory adresses. Like this: whenever the computer needs to access or write to memory, it accesses a given memory location. To find this location, it uses an adress. Pretty much the same way the postman uses your adress to find you, or a phone number is used to find your cell phone, or an IP adress is used to find your computer. The memory space is how many adresses are available. (Compare with the ongoing transition from IPv4 to IPv6 for internet; we’re actually running out of IPv4 adresses nowadays, so IPv6 is being phased in to give us a lot more of them.) In a 32-bit system, you have 2^32 adresses. In a 64-bit system, you have 2^64 adresses. You can see this in effect quite easily; take a 32-bit system (or install a 32-bit OS) and try to use it with 8GB of RAM. You’ll find that you don’t get to use your 8 gigs; it stops at 4.
“Adressing” cores towards using them for computation; that is, the processing of instructions, is done with threading. This is a different thing; you can multithread just as easily (or rather, with the same amount of difficulty) on 32-bit as you can on 64-bit. Indeed, multithreading has been done on 32-bit (and 16-bit) waaay back. There is no difference, from a programming perspective, between multithreading an application on a multi-core CPU and doing it on a multi-CPU computer. Each core in your multi-core CPU is in actual fact acting as a separate CPU as far as your program is concerned.
@A.S:
32vs64bit for dummies:
Note that they explained it correctly; ie, they didn’t say what you said.
When it comes to a wider space for communication, what you are then talking about is buses. These are the lanes that transmit information between components (be it internal to the CPU or between components). These can have differing widths, allowing multiple datastreams to occur simultaneously. 64-bit vs 32-bit has absolutely nothing to do with this. An easy example to give would be PCI-Express; you know how the ports and sockets say “x16” and “x8” etcetera - those are the amount of PCI-e lanes available for simultaneous use. (And the limited bus width of the PCI-E controller is the reason why SLI setups might force cards to go in x8 mode even though they’re sitting in x16 sockets.)
Now, if you have three channels, you’ll ask (simplifying now) for three adresses to be read simultaneously, and get the results simultaneously - faster memory access. But if you are on 32-bit, the total adressable space will be only those 2³²; that is, when that memory access/write request is “sent”, it is a number of potentially 2³² bits of length. And if the file you want to manipulate is bigger than that - say, a big uncompressed video for editing - then you are boned. Your computer won’t be able to do it. (Here, btw, is also the reason why FRAPS will cut it’s raw output files at 4GB; it’s a 32-bit process, it cannot adress more than that, so it has to cut the file and start over on a new file.) Using 64-bit memory architecture solves this nicely, allowing you to use your 8, 16, 32 or 128 GB RAM setups. (And theoretical limits in the multiple exabyte range, or about a million times more than current computers.) Basically, what it does is allow you to efficiently handle large amounts of data. And with many games today reaching double-digit gigagbytes for download, expecting them to sit nicely in 4GB of RAM is an exercise in futility; especially when OS also has to sit there.
-
32 bit is a limit for Falcon because the EXE can only use ~1.7GB of memory. Don’t ask me why exactly and I know that 2^32 is ~4GB, but if anyone ever seen a CTD that came after the sky turned black, then it’s because that ~1.7GB limit was pushed. usually ATM if there are no leaks, then 1.7GB should be enough, but looking to the future, 64-bit EXE is the way to go.
-
My number one wish is a day/night switch. Think about the possibilities: external lights (more visible at night), cockpit lighting, afterburner (brighter at night), JHMCS / NVG…
I totally agree.
My number two is add water environment mapping for Plains set type. This may solve this problem:https://www.benchmarksims.org/forum/showthread.php?14333-Ground-units-movement-over-water-type-tiles&p=200927&viewfull=1#post200927
https://www.benchmarksims.org/forum/showthread.php?15668-Tiles-water-black-floor
And no popcorn on AB tiles (set type water ). Some Airports are on coast.Edit:
I looked at Kunsan tiles and all is water set type, not explode on these tiles…
These three tiles is water type (water shader), and no problem:Can anybody explain why in other theaters it is impossible?
-
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.
Don’t get ATI over 6xxx!!! The performance is truly awful, at least for now.
The drivers are improving, but ironically, it’s CAYMAN that has best perf, even 5xxx has better perf than [78]xxx.
-
32 bit is a limit for Falcon because the EXE can only use ~1.7GB of memory. Don’t ask me why exactly and I know that 2^32 is ~4GB, but if anyone ever seen a CTD that came after the sky turned black, then it’s because that ~1.7GB limit was pushed. usually ATM if there are no leaks, then 1.7GB should be enough, but looking to the future, 64-bit EXE is the way to go.
Isn’t BMS 4.32u6 using large address aware flag? That means full 4 gigs.
-
One thing for the next update? Hmmm…. AI wingmen being able to perform a break and visual pattern for landing…
This is just a wish from an occasional player (usually single player). More advanced players certainly see other priorities.Enjoy your virtual and real flights.
-
Because 32-bit systems can only adress a given amount of RAM. To be precise: 2³² bits. (AKA ~4GB.)
To go back a bit, you said this:
“Regards your answer refering to 64bit suggestion. Don´t you think it would benefit to address all cores.”Here’s where I think you’re getting confused; 32bit vs 64bit isn’t about “adressing” cores. It’s about memory adresses. Like this: whenever the computer needs to access or write to memory, it accesses a given memory location. To find this location, it uses an adress. Pretty much the same way the postman uses your adress to find you, or a phone number is used to find your cell phone, or an IP adress is used to find your computer. The memory space is how many adresses are available. (Compare with the ongoing transition from IPv4 to IPv6 for internet; we’re actually running out of IPv4 adresses nowadays, so IPv6 is being phased in to give us a lot more of them.) In a 32-bit system, you have 2^32 adresses. In a 64-bit system, you have 2^64 adresses. You can see this in effect quite easily; take a 32-bit system (or install a 32-bit OS) and try to use it with 8GB of RAM. You’ll find that you don’t get to use your 8 gigs; it stops at 4.
“Adressing” cores towards using them for computation; that is, the processing of instructions, is done with threading. This is a different thing; you can multithread just as easily (or rather, with the same amount of difficulty) on 32-bit as you can on 64-bit. Indeed, multithreading has been done on 32-bit (and 16-bit) waaay back. There is no difference, from a programming perspective, between multithreading an application on a multi-core CPU and doing it on a multi-CPU computer. Each core in your multi-core CPU is in actual fact acting as a separate CPU as far as your program is concerned.
Note that they explained it correctly; ie, they didn’t say what you said.
When it comes to a wider space for communication, what you are then talking about is buses. These are the lanes that transmit information between components (be it internal to the CPU or between components). These can have differing widths, allowing multiple datastreams to occur simultaneously. 64-bit vs 32-bit has absolutely nothing to do with this. An easy example to give would be PCI-Express; you know how the ports and sockets say “x16” and “x8” etcetera - those are the amount of PCI-e lanes available for simultaneous use. (And the limited bus width of the PCI-E controller is the reason why SLI setups might force cards to go in x8 mode even though they’re sitting in x16 sockets.)
Now, if you have three channels, you’ll ask (simplifying now) for three adresses to be read simultaneously, and get the results simultaneously - faster memory access. But if you are on 32-bit, the total adressable space will be only those 2³²; that is, when that memory access/write request is “sent”, it is a number of potentially 2³² bits of length. And if the file you want to manipulate is bigger than that - say, a big uncompressed video for editing - then you are boned. Your computer won’t be able to do it. (Here, btw, is also the reason why FRAPS will cut it’s raw output files at 4GB; it’s a 32-bit process, it cannot adress more than that, so it has to cut the file and start over on a new file.) Using 64-bit memory architecture solves this nicely, allowing you to use your 8, 16, 32 or 128 GB RAM setups. (And theoretical limits in the multiple exabyte range, or about a million times more than current computers.) Basically, what it does is allow you to efficiently handle large amounts of data. And with many games today reaching double-digit gigagbytes for download, expecting them to sit nicely in 4GB of RAM is an exercise in futility; especially when OS also has to sit there.
There is nothing wrong with what you posted. Technically your post is correct, BUT the difference is that there is the know-how in specifics as “engineer” or coder and the ability to utilize that know-how.
As flightsims were pretty much show-off oppertunities for PCs in the past in order to demonstrate what they can do, sims are still benchmarks today in terms of what can be done and how, from coder- and hardware perspective.
Not only because of the wider memory access under 64bit, but because of the ability to split each module (flight physcis, dnyamic weather, environment engine, Ground and Air taking manager, etc etc) under different threads OR/AND cores. The benefits are obvious and a 64bit environment is consequently a “helper” achieving this, from stability to more data or details processed at the same time …etc etc.
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.The issue is, that this has not been utilized well in ANY sim for the home-pc market to my knowledge, exception is Rise Of Flight who followed the right direction regards programing architecture and seperated modules (at least threads-wise). Programing in seperatly calculated modules is “unavoidable” as one can not queeze everything through the same “tunnel” especially with flight-sims with mutiple and independent calculation-areas and constanlty growing data to be processed. We all know the term “bottleneck avoidance” and 64bit does his job right there.
Fighterops was another approach (Modules diverted to different threads/cores parallel and simultaniously), but they failed as we know.
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.
“… don´t embrace excuses, but solutions …”
cheers
-
@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.