Iff you could have one thing in the next update it would be. (Archive)
-
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.
-
@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?