UNIT: Richard Biely, Programmer, Programming Dept.

TO: Arma 3 Dev-Branch Users

OPSUM: Introducing 64-bit Arma 3 - what, why, and how!

In recent years, a growing number of developers have released their games with 64-bit support. Many of our own community have hoped or suspected that, sooner or later, this simply had to happen to our beloved series as well. To bring an end to the eternal discussion about whether it is (im)possible to bring 64-bit support to Arma - and to live up to your hopes - we are proud to announce that 64-bit Arma 3 is knocking right at your door, now released on Dev-Branch. But what exactly are the benefits of having a 64-bit game, what does it mean for you as gamers, and why did you have to wait until now?

A BIT OF A WAIT

Somewhere on the forums one of our loyal community members wrote "there is no simple 'click a button' and it magically becomes 64-bit." That is very true. We currently employ no mages, so we had to improvise and hit those buttons a few (tens of thousands) times. Porting a project which had not been designed with 64-bit in mind is no easy task; with a code base as huge as Arma's, it is doubly true. Other than Arma itself, we had to update our Launcher , too (thanks to that, you will now be able to choose your version of the game splendidly).

One of the main reasons for the delay is that the time simply had to be right for us. 64-bit executables need a 64-bit OS and 64-bit CPU to run. If there are not enough users with such systems, there would be only little reason for us to invest time and experts into working on something this big. Fortunately, the last few generations of processors have been 64-bit. Therefore, it comes down to your OS. According to Steam statistics, over 90% of player machines now have a 64-bit OS installed.

Naturally, it is not all only about programming. In order to make this effort a reality, different departments had to do their part as well. More than anything else, testing has been a huge part of the porting process, taking a lot of time. It is no wonder. There were hundreds of obstacles we had to overcome, some smaller, other greater, and our QA colleagues needed to verify that everything still worked as expected after all these changes. In the end, we feel we succeeded to tame the beast - and we hope you will be just as excited about the results.

A BIT OF BACKGROUND

In order to understand what this magical number means, we need to get technical. We will keep it as concise as possible (of course, at the expense of accuracy, for which we kindly hope anyone technically gifted will excuse us). When processing tasks, your CPU works with data stored somewhere in memory. This memory can be local to the CPU (registers, cache) or external (system memory aka RAM). What interests us the most right now are registers and system memory.

In general, registers are very small and very fast data containers. They come in various forms and sizes ranging from 8 to 64-bits. The amount of bits determines the largest number a CPU can process without any extra work. 32-bit processors can work with numbers as large as 2^32-1=4,294,967,295 (-1 because we start from zero). 64-bit processors take it a few billion steps further and stop at an amazing 2^64-1=18,446,744,073,709,551,615. This comes quite handy when performing complex calculations and addressing memory.

Speaking of memory, let us translate these huge numbers to something more understandable. In the vocabulary of computer memory, 2^32 can be translated to 4 gigabytes while 2^64 equals to 65 petabytes. In simplistic terms, a 32-bit system can physically address at most 4 GB of memory. On top of that, the address space of a 32-bit application running on such a system is usually split in two parts. On Windows, each of them is 2 GB. One is reserved for your applications, the other one for Windows itself.

A BIT MORE MEMORY

Now imagine you have to squeeze Arma - with all of its large terrains and many things going on during a mission - into this relatively small space. As time passed, and as Arma grew larger, this has proven to be a more and more difficult task. Being able to utilize virtually all of your system's memory, more than anything, Arma should show a lot more consistent performance.

With the ability to cache a huge amount of data in-game, less loading/releasing of memory is necessary. This translates into less work for the game to do and, ultimately, into more fluent gameplay. One case where an update in performance should be more recognizable is when playing the game with very large view distances. Given that the amount of data to cache is rather large in such cases, the game will greatly benefit from an increased amount of available RAM (but, note, it may be bottlenecked by other factors).

An important side effect of having larger address space is that we expect fewer memory-related crashes to happen. With no free memory, sooner or later the game (or any other application for that matter) is bound to reach a state where it simply has no other choice but to cause us all sorrow. Memory limits are set in stone; whether a crash is caused by a GPU driver or Arma itself does not really matter from a player's point of view. Trust us, there is nothing more painful then seeing you sad because the game crashed. In 64-bit Arma, this should be less likely.

A BIT OF CAUTION

Do not expect a 64-bit executable to be a golden bullet, though. Rather than quadrupling your FPS, consider this an important optimization for cases where 32-bit Arma can no longer 'keep up'. If you never experienced sudden performance drops, you are unlikely to notice any difference at all. However, if you did, this new version of Arma should make your experience even more splendid than ever.

For modders, too, there are some things to keep in mind. If your scenario or mod uses a call extension, the extension has be to provided both in 32-bit and 64-bit versions now. Otherwise, your game will most likely not work as expected. Unfortunately, there is no flexible way for us to work this around for you behind the scenes. 64-bit processes can only load 64-bit shared libraries (*.dll on Windows, *.so on Linux) and therefore it is expected that content creators provide them. This process should be rather straightforward, though, and we do not expect any major complication on our talented community's side.

To make the transition as transparent for you as possible, we at least made it so that no changes to scripts will be required. All you need to do is build a 64-bit version of your extension and name it <yourExtension>_x64.dll on Windows (or <yourExtension>_x64.so on Linux). In other words, you add the "_x64" suffix to the name. Similarly, mod creators relying on hacking repurposing DirectX libraries will have to dust off their skills once again and perform their magic on 64-bit version of these libraries in similar a fashion as they did on their 32-bit counterparts back in the day. Of course, it is also worth mentioning that you should not forget to whitelist your new libraries with BattlEye!

A BIT OF FEEDBACK

Before we summon the courage to release the 64-bit exe to the wider public, we first need to gather enough feedback on how well it works outside the company walls. As confident as we are about the new exe's performance and stability, it is a rule of thumb that things impossible to happen in theory are bound to happen 50% of the time in practice. Therefore, to deliver the best possible Arma experience, we would like to kindly ask you for your feedback on the forums.

However, although it is true the support for 64-bit has yet to hit our Main Branch, we decided to give you all at least something as a small appetizer. Starting with Update 1.66, when run on 64-bit Windows, 32-bit Arma 3 will be able to effectively work with more than just 2 GB of memory. The current limit has been increased to 3 GB. Magic, yay!

As always, we thank you all for your wonderful support over the years and are looking forward to all your observations and suggestions on this next big step in Arma's history. Have a great time playing the game and may the 64-bits be with you!

Richard Biely

Programmer, Programming Dept.