64-bit?

[Kanaro]

Not sure what you mean. The code should be able to handle up to 4GB without alteration, right? Thats the 32-bit limit. >4GB would require a 64-bit conversion of all the code. 2GB was just an artificial limit imposed by 32bit windows, as far as i know.

A quick primer for virtual addressing in Windows that I found yields a bit more information.

The way I understood it to work, is that the header flag in the executable (that programs like CFF Explorer can help edit), merely tells Windows how much virtual memory the process is allowed to address. By default, 32-bit apps are restricted to 2gb. When the flag is thrown to '1' in the exe, Windows lifts that limitation and the exe is free to address up to 4gb.

Conversely, when the application is compiled as natively 64-bit, the limitation is lifted to a max per the operating system's limits (I think 8tb for x64 in recent copies of Windows).

Having said all that, the only thing that really changes is that the limit has been lifted. Windows won't help the application to address more memory actively, nor will it assist in managing assets more efficiently. If the application tries, and the limit isn't there, it succeeds. But it has to be coded to actively go after as many resources as it wants. If you put artificial limits inside the code knowing it is 32-bit and therefore restricted, removing the OS limitation won't help in any way.

This is why most games can have the switch thrown, the limit lifted, and performance and resource management improve. They were never artificially limited, they just had the 2gb exe header flag limiting them from the OS's standpoint. Flipping that on helps the application by providing more natural addressable memory.

You could do as everyone else does - compile for 32-bit with no internal limits, and allow the header flag to be toggled on. But that belies other improvements that 64-bit compilation provide. 64-bit libraries are inherently more efficient from what I understand, and allow a more seamless expansion of associated code and resources when you need to.

I'm not a programmer, but this is how I understand it all to work, having used it over the past 10 years along with stuff like the /3gb switch. Now that we're moving ahead quickly into a 64-bit operating space for everyone, it doesn't make a lot of sense to release a game in 1-2 years and have it still be limited to 2gb.

Just my feedback, take with a grain of salt.

[Captain Deathbeard]

Well I should be ok then, I have no coded 2gb limitations. When the game goes over about 2gb memory usage it will crash (although its pretty rare). Hopefully the switch will just stop those crashes at least.
I don't want to go into a 64-bit conversion, because its a big job and I don't have time.

[Kanaro]

I don't want to go into a 64-bit conversion, because its a big job and I don't have time.

Two years is a long time, a lot can happen.

[Blxz]

Well I should be ok then, I have no coded 2gb limitations. When the game goes over about 2gb memory usage it will crash (although its pretty rare). Hopefully the switch will just stop those crashes at least.
I don't want to go into a 64-bit conversion, because its a big job and I don't have time.

That's a pretty big negative. Are you able to test if your fix has actually fixed it?

Also, does everyone have to edit the files with CFF explorer or will it propagate naturally with the next update?

[Hellhound1]

What effect will it have on people with 32bit systems or less than 3gbs of ram though? Using LAA isn't reccomended under those circumstances, and in sure people have under 3gbs ram still.
(personally I have 16 lol)

Just curious.

[Marrow]

I can verify that Kenshi does crash when going over 2 GB. However, it does vary between regular crashes, Super Crash!es, and freezes.

[Kanaro]

I can verify that Kenshi does crash when going over 2 GB. However, it does vary between regular crashes, Super Crash!es, and freezes.

Active memory management for 32-bit apps can be a big headache. Caching, purging, and generally moving assets in/out of memory is a big deal.

Think of the Elder Scrolls games, and how much they did on the backend of their engine to work with their world's grid/cell division. I wrote an optimizer for Oblivion called Streamline that attempted to help smooth out resource over-management, which due to the game's choppy nature was downloaded over half a million times.

Basically it boils down to game design, the engine, and how many resources need to be ready for use (paged into memory) at any one time. If the game's design is robust and expansive, the engine not overly great at paging assets, and the use of those assets in-game is really aggressive (i.e. a really large active playing area), then it makes sense to go 64-bit right out of the gate.

Chris is going to have to see how Ogre does with his implementation and adjust accordingly. Right now the game does fine with memory (though I've never really done a plot on it). Later as more environments are added, the world is changed, and more things are implemented.. that may change.

[zibathy]

I don't think it would be any smoother, it might lead to less crashes caused by too much memory use. And video cards are usually only 1GB so 64bit wouldn't allow higher-res textures or anything.

My GPU has 4gb so... ;P

[BloodyNex]

64-bit could have a marked impact on speed, based on how the CPU processes information. When a program is compiled, it is turned into machine-code. This machine-code is basically assembly instructions as numbers. On the assembly level, a 64-bit program can process twice as much information in a single instruction as a 32-bit program because the registers (built-in CPU variables) are twice as large. Any time a program is copying or moving information, it will theoretically do so twice as fast in 64-bit as it would in 32-bit. A lot of factors can change how much of an impact this can make, though (Compiler, optimization options, whether a given function is inline'd or not, data types being copied/moved).
Also, when running a 32-bit program in 64-bit windows, it is not running natively. Instead, it is being run in a 32-bit virtual environment (called Windows on Windows-64) - which means more code going through the CPU per-instruction. I have not yet been able to test the performance hit that this has, but I suspect a few frames could be gained by not relying on this virtual environment.