Modern games and operating systems tend to be 64-bit only these days. How about we do that switch as well? My hope is that it will address issues like https://github.com/OpenRA/OpenRA/issues/12494 as we gain more access to memory and maybe it will improve overall performance. Is that too naive? My technical knowledge in that regard is limited.
Porting should be easy. For the managed code just flip some switches and for the system calls we only need to update the bundled native Windows/Mac dependencies to their 64 bit counterparts and for Linux just update package architecture metadata.
I haven't checked how many players are still running 32-bit operating systems. Is that possible from our player survey? Hopefully no one will be excluded. My assumption or rather wishful thinking would be that most of them could upgrade to a 64-bit OS for their own benefit and 32-bit only era hardware will also make playing OpenRA especially the upcoming TS/RA2 mods not much fun anyway.
Mailaender
All 40 comments
Modern games and operating systems tend to be 64-bit only these days.
There you have the first problem. Especially true with lots of indie game titles these days that I have to skip due to the fact that although I would def. be able to handle them, they tend to be more and more 64-bit only. Which makes me sad, considering that the 32-bit machine I am sitting in front of would easily be able to handle these games in the years to come.
I haven't checked how many players are still running 32-bit operating systems.
Although I do not know the data and also would like to see it I think you would be heavily surprised as to how many players are not only playing ORA for the retro aspects, but also due to the fact that they cannot handle much more elaborate engines in terms of processing power and graphic hogging. The recent dropping of XP has stirred up a bee hive. I fear switching to 64-bit only would do the same for the wasp nest next door.
32-bit only era hardware will also make playing OpenRA especially the upcoming TS/RA2 mods not much fun anyway.
I beg to differ with the same reason as on the top. The architecture - while of course setting the limits for certain hardware does not necessarily show you the "beefiness" of such systems. That being said when it comes to heavily modified gen2-mods like CD and SP or AS, I have no problem running them on my 32-bit machine in terms of performance. And the limiting factors there - if any lag would take hold - is definitely not the 32-bit barrier.
Hopefully no one will be excluded.
Totally unimportant side note: You will lose me.
_PS: My technical knowledge in that regard is limited. All rights reserved._
jaZzKCS
on 16 Jan 2017
Once upon a time there was this pchote who said my previous PC (AMD Athlon II X3 450, 2 GB RAM, Radeon HD 3000) should handle gen2 mods fine and the three complaints I'd raise against that are terrain texture sizes, voxel renderer perf and maybe, MAYBE pathfinding. Neither are related to pathfinding, the first two is GPU, the third... is acknowledged. Resolving the first two is already enough for a good gameplay experience.
I switched to 64bit in 2016, with the sole reason for my switch was that I got 8 GB RAM now. There are machines shipped with 2 GB RAM even today which doesn't benefit (IMO they even lose) in x64.
I acknowledge that the idea of 64bit mempools is intriguing but indeed it would probably mean losing more on the player side and I really don't think after XP-drop and the logo proposal drama we need yet another conflict of such a level for now.
GraionDilach
on 16 Jan 2017
The sensible first step before even thinking about is to collect data through the system information prompt:
Environment.Is64BitOperatingSystem(but note xamarin#37414)
pchote
on 16 Jan 2017
The recent dropping of XP has stirred up a bee hive.
more like "a handful of flies" ... :grinning:
Micr0Bit
on 16 Jan 2017
You can find some useful information about the hardware and software used by millions of players on Steam and apparently ~91.24 % of them use 64 bit operating systems.
Instead of __switching__ to 64 bit executables you could release 32 bit and 64 bit executables.
ghost
on 16 Jan 2017
You could also try the "AnyCPU" option, which means the binary will run at the same bitness as the OS - which hopefully achieves the same effect without requiring two different executables.
RoosterDragon
on 16 Jan 2017
@chrisforbes told me that was avoided on purpose due to undebuggable desync problems.
Mailaender
on 16 Jan 2017
I think it's too early to drop 32-bit just yet. Do what StexoO and just make both 32-bit and 64-bit builds.
Maybe wait until TS and RA2 are released, then consider dropping 32-bit, so everyone can play all the games on 32-bit still.
Anyways, even if 32-bit was dropped, it's not like 32-bit players wouldn't be able to play the games anymore, as you could just use the last version that had 32-bit support still.
ROCKNROLLKID
on 18 Jan 2017
Providing mixed 32/64 bit builds means that we have to deal with the downsides of both, and can't rely on the benefits of either.
If 64-bit executables end up being required for the gen2 mods (i'm not convinced) then the future planned out in #12554 means that we can ship 64-bit only binaries for those while keeping the current mods 32-bit only.
pchote
on 18 Jan 2017
I'd like to get /LARGEADDRESSAWARE properly in first before considering 64bit entirely.
I don't think plain TS/RA2 will need 64bits either. Mods might end up needing it, but i can't tell it at this point. I know that AS reached the stage of requiring /LARGEADDRESSAWARE to prevent crashes at game start two months ago and I am missing three sides and 90% of the YR civilian assets though. I need more tests about this though, so I am leaning towards a weak maybe.
GraionDilach
on 19 Jan 2017
Is it possible to resolve https://github.com/OpenRA/OpenRA/issues/12125 without switching to x64?
Mailaender
on 19 Jan 2017
Yes, and makefile-compiled builds already enable it. Somebody just needs to reconfigure the msbuild project files to run fixheader.
pchote
on 19 Jan 2017
I raised a question about it somewhere ages ago if that should be by including a project file or triggering csc in make.ps1, but got no answer.
GraionDilach
on 19 Jan 2017
@GraionDilach: if you mean #12208 then you did get an answer!
pchote
on 19 Jan 2017
Wow, I entirely forgot it, including my response. Sorry then. Gotta try looking into it in the weekend then.
GraionDilach
on 19 Jan 2017
My two cents. There is no point in dropping 32 bit! In fact, It's a silly idea. THE ONLY benefit of 64 bit is the ability to address more then 4 gigs of ram. (Which OpenRA does not need!). For any computer that maxs out at 4 gigs of ram (Which there is still A LOT in the wild!) It is still advisable to stick with a 32bit operating system. (If not windows, 32bit Linux is still alive and well) This is because 64 bit operating systems use quite a bit more ram in their usage, and is far less efficient with little benefit for such systems.
In short, DON'T! Why put artificial hardware requirements on your software? You're not apple...
JoshuaPettus
on 21 Jan 2017
@JoshuaPettus: the problem isn't with the amount of ram, but with address space. 32 bit processes are limited to 1.8GB by default on Windows, and that can become fragmented and run out even if the total memory usage stays well below that limit.
I expect that #12125, #12131, and other refactorings to reduce large allocations should be more than enough to avoid the problem without having to resort to dropping 32 bit support, so I wouldn't be too worried about this.
pchote
on 21 Jan 2017
Ah in linux, I think it's more like 3 gigs. I forgot about that.
JoshuaPettus
on 21 Jan 2017
Nowadays that RAM is so cheap I wonder why people don't upgrade their hardware and OS. I was under the impression that I was late to this and gamers are far ahead compared to the rest of the PC world. Adding Environment.Is64BitOperatingSystem to the player survey seems to be a good idea, but if there is no necessity then let's stay 32 bit.
Mailaender
on 21 Jan 2017
Old 32 bit "ebay special" laptops are still quite popular.
JoshuaPettus
on 21 Jan 2017
Also considered should be the fact that gen2 mods like CD, SP and AS are already well known to hog up way more system resources than the vanilla [shipped] mods. Especially in the RAM department.
jaZzKCS
on 22 Jan 2017
@JoshuaPettus I am running an ex-Yuri's Revenge mod which I've started to port into OpenRA mid-2015 (the aforementioned AS). So far I got around half of the mod converted properly and I already need /LARGEADDRESSAWARE to prevent crashes from address space exhaustion. Basically see my post written 3 days ago here, but yeah, I'd keep 32 bit support myself as well.
GraionDilach
on 22 Jan 2017
I added the LAA flag for CD, its very crashfriendly with the soundtrack (OutOfMemory galore).
http://i.imgur.com/u3L0Xqa.png
The OST, is about 800mb big. But even without the soundtrack (or instead using AUD files) there where still some reports of Memory crashes after a few games.
DoGyAUT
on 27 Jan 2017
Looks like the virtual file system and the sound engine https://github.com/OpenRA/OpenRA/issues/8593 are a huge memory hog then. :confused: That should be resolved independent from this proposal.
Mailaender
on 27 Jan 2017
If not windows, 32bit Linux is still alive and well
@JoshuaPettus
i recently got (pretty much) forced by steam to install a 64bit linux ... they turned off the shop for 32bit versions
Micr0Bit
on 28 Jan 2017
Yes, 99,72% of all Linux gamers already did the switch https://www.gamingonlinux.com/users/statistics
Mailaender
on 28 Jan 2017
I wouldn't trust that figure to be representative or accurate:
There are 5584 registered users on GamingOnLinux. These statistics are gathered using their manually entered data on their profiles.
pchote
on 28 Jan 2017
The sensible first step before even thinking about is to collect data through the system information prompt:
Environment.Is64BitOperatingSystem(but note xamarin#37414)
This was done in https://github.com/OpenRA/OpenRA/pull/12610.
Mailaender
on 21 Jul 2017
Windows
Version | Win users total | x64 machines | %
-- | -- | -- | --
release-20170421 | 6598 | 6291 | 95,35聽%
release-20170527 | 10255 | 9853 | 96,08聽%
playtest-20170722 | 112 | 108 | 96,43聽%
playtest-20170408 | 810 | 778 | 96,05聽%
playtest-20170304 | 1038 | 988 | 95,18聽%
Linux
Version | Linux users total | x64 machines | %
-- | -- | -- | --
release-20170421 | 1528 | 1449 | 94,83聽%
release-20170527 | 2067 | 1951 | 94,39聽%
playtest-20170722 | 14 | 14 | 100,00聽%
playtest-20170408 | 125 | 120 | 96,00聽%
playtest-20170304 | 223 | 203 | 91,03聽%
Mac
See https://github.com/OpenRA/OpenRA/issues/13478#issuecomment-317168187
Mailaender
on 22 Jul 2017
Note that according to @jrb0001 selfcompiled OpenRA builds already run natively as 64bit on Linux. He never supplied actual information on this though.
GraionDilach
on 11 Sep 2017
Even the releases run natively as 64bit on Linux because they have no other chance.
jrb0001@lubuntu:~$ LC_ALL=C dpkg -s openra | grep "Version:" && openra > /dev/null 2>&1 & sleep 3 && LD_SHOW_AUXV=1 ldd /proc/$(pidof mono)/exe | grep AT_PLATFORM | tail -1 && kill $(pidof mono)
[2] 11540
Version: 20170527.release
[1] Fertig LC_ALL=C dpkg -s openra | grep --color=auto "Version:" && openra > /dev/null 2>&1
AT_PLATFORM: x86_64
jrb0001
on 11 Sep 2017
I would also like to mention, that even some 64-bit systems do not meet the hardware requirements for OpenRA. Many 32-bit systems would be even older and weaker but OpenRA does not aim to support them. I think it makes sense to make 64-bit the primary option, if not drop 32-bit entirely, and then if so, the minority of people who have 32-bit systems can either upgrade their systems or just run an older release of OpenRA.
aaronfranke
on 30 Dec 2017
IMO we should target this together with when we releasing the first TS alpha. But whats the point with multiplayer (x64 and x86) in the past we had desyncs...
LipkeGu
on 4 Jan 2018
I never had a single desync related to that and I always used a 64bit version (and all those windows players don't have a choice besides 32bit)... Even though I don't know it well enough, I would assume that the integer part of C# is processor independent because anything else would be silly. All floating point operations in synced code should be removed anyway.
jrb0001
on 4 Jan 2018
Any progress on this? Switching to 64-bit only becomes a better idea as time goes on.
aaronfranke
on 19 Oct 2018
Using AnyCPU complation forced us to use AnyCPU compiled binaries like SDL2 & OpenAL, so we can only use AnyCPU when the dependencies are also available. otherwise we can get BadImageFormatExceptions.
LipkeGu
on 27 Apr 2019
I think I got this working a long time ago by putting all architecture dependent libraries into another directory and then telling the runtime to search there as well.
The number of players with a 64bit capable system used to be around 95.5% 1.5 years ago (https://github.com/OpenRA/OpenRA/issues/12587#issuecomment-317168596). I assume that increased even more in the meantime. Maybe its time to simply drop 32bit support?
jrb0001
on 27 Apr 2019
Querying the database for users who have run OpenRA in the last three months and opted into sending their system details shows 21800 64-bit Windows systems vs 560 32-bit Windows.
On the one hand you could argue that 2.5% is nothing, but on the other this is still 560 OpenRA fans who we would be actively excluding.
pchote
on 27 Apr 2019
I'm willing to bet that many of those 2.5% are either willing to use an old version of OpenRA or willing to upgrade to play newer versions of OpenRA.
There is also the fact that 32-bit is pretty much nonexistent on Linux, and Mac is going to completely drop the ability to run 32-bit executables in the near future. For best compatibility, I suggest:
Windows: Release 64-bit and 32-bit versions
Mac and Linux: For both, release 64-bit only
aaronfranke
on 27 Apr 2019
Windows: Release 64-bit and 32-bit versions
This was originally on my next release roadmap but has been bumped off due to lack of time.
Mac and Linux: For both, release 64-bit only
This has already been the case for a couple of releases now.
pchote
on 27 Apr 2019
Related issues
Maurice84
路
4Comments
MlemandPurrs
路
4Comments
Mailaender
路
5Comments
FRenzy-OpenRA
路
4Comments
FRenzy-OpenRA
路
3Comments
Most helpful comment
The sensible first step before even thinking about is to collect data through the system information prompt:
Environment.Is64BitOperatingSystem(but note xamarin#37414)