Is ED a 32 bit binary? Memory exhaustion could explain this black screen

Run the game for awhile and then try to quit to find a black screen. Is ED 32 bit only? That could explain some of the problems we are seeing.

1628471126815.png
 
Last edited:
Sometimes I wonder, I mean with some of the stuff they broke/forgot/messed up/just plain forgot with this expansion, you gotta wonder if it is possible for them to get the filename wrong... Kinda Kidding on this one, but also kinda not.
 
An executable can be called 64 bit but still not use more than 4GB of memory for other reasons. Heck, some x86-64 processors are actually only 48bit with some parts being 64Bit. It's terribly confusing actually. Being 64Bit supposedly means a program can address past the first 4GB, not that it can or will ever use more than 4GB. I suppose I may see if I can get it over 4GB of ram usage tomorrow for giggles. I have 64Gb available.
 
An executable can be called 64 bit but still not use more than 4GB of memory for other reasons. Heck, some x86-64 processors are actually only 48bit with some parts being 64Bit. It's terribly confusing actually. Being 64Bit supposedly means a program can address past the first 4GB, not that it can or will ever use more than 4GB. I suppose I may see if I can get it over 4GB of ram usage tomorrow for giggles. I have 64Gb available.

The 64bit addressable space is aimed at the size of the galaxy, requiring that number of possible ID's to properly simulate the galaxy, I've never focussed on exactly how much memory it is using, I will check also.
 
The game has been exclusively 64-bit for a while, and can use quite a bit more than 4GiB of memory.

As for CPU bitness, this generally refers to the size of the general purpose registers. Various special purpose registers for instruction extensions and the widths of various data paths may vary considerably, as will actual physical address space available...not that any of this has any relevance here.
 
64bit support wasn't added for the stellar forge or galaxy map etc. those things existed back when the game was a 32bit binary and the engine itself has always been internally 64bit.

they moved to a 64bit binary for the needs of the planetary generation in horizons which inflated texture memory requirements and made being able to address > 4GB natively impactful to the performance of the game ...and simply because they were forced to support 32bit at first because all you intel guys took a bit longer to get on the 64bit bandwagon back in the decade that the game first was developed and released.
 
and simply because they were forced to support 32bit at first because all you intel guys took a bit longer to get on the 64bit bandwagon back in the decade that the game first was developed and released.

Intel lagged behind in adoption of x86-64 by less than two years and the last non-64-bit Intel x86 desktop processors were early Pentium IV Prescotts back in 2005.

I'm not sure why Frontier didn't switch development to 64-bit sooner, but it wasn't because of the hardware.
 
I'm not sure why Frontier didn't switch development to 64-bit sooner, but it wasn't because of the hardware.
Its also the windows version, and I recall FDev saying at the time they thought the %s of who wouldn't be supported was sufficiently low.
I had a similar issue at work, and had to wait until all of our users PCs to be updated to Win7. Now I'm having it again waiting for some to get newer versions of the .Net framework etc.

Assuming this was built using the Microsoft toolset, i.e. Visual Studio (which is likely given that its C++, and the launcher seems to be pure .Net framework) switching from 32bit to 64bit is just a setting on a dropdown. If they use "managed C++" and the solution is correctly configured, you can do this once, on the exe, and all the dlls will inherit at load time, it might be the same for unmanaged (i.e. non-.Net C++). Either way is a very low amount of dev work and theoretically not much QA to make sure the compiler got it right depending on risk appetite (but let's just say we've all got an idea of that post-Odyssey release).
 
Its also the windows version, and I recall FDev saying at the time they thought the %s of who wouldn't be supported was sufficiently low.
I had a similar issue at work, and had to wait until all of our users PCs to be updated to Win7. Now I'm having it again waiting for some to get newer versions of the .Net framework etc.

Assuming this was built using the Microsoft toolset, i.e. Visual Studio (which is likely given that its C++, and the launcher seems to be pure .Net framework) switching from 32bit to 64bit is just a setting on a dropdown. If they use "managed C++" and the solution is correctly configured, you can do this once, on the exe, and all the dlls will inherit at load time, it might be the same for unmanaged (i.e. non-.Net C++). Either way is a very low amount of dev work and theoretically not much QA to make sure the compiler got it right depending on risk appetite (but let's just say we've all got an idea of that post-Odyssey release).

Switching the binaries to 32-bit wasn't the issue; as you point out, that's easy. Converting identifiers and coordinates and all that to assume 64-bit variables and precision for assets that were built around a 32-bit engine is undoubtedly where the difficulty was...other games and engines ran into the same issues that made conversion more than just recompiling an executable. Though, if what Darth Ender says is true and they had always been using 64-bit assets internally, that makes the lag in adopting and mandating a 64-bit client even more puzzling.

When they finally retired the 32-bit client with 2.4, they said that less than 0.01% would be left out. However, even if they had done this in 2012 when they announced the kickstarter, very few people would have been excluded. Half of people were on x64 in 2010 within a year of Window 7's release and most of the 32-bit holdovers were people performing in-place upgrades from older OSes. By the time ED was announced, 64-bit was the rapidly growing majority. By the time it launched, it was nearly omnipresent.

Assuming they had planned for features that would later make 64-bit mandatory, why didn't they make the conversion earlier, instead of continuing on a dead-end path? Even if development began early enough for 32-bit to be a rational assumption, surely this was no longer the case in the years leading up to release.
 
The 64bit addressable space is aimed at the size of the galaxy, requiring that number of possible ID's to properly simulate the galaxy, I've never focussed on exactly how much memory it is using, I will check also.
5900x 64 gb of ram and a 3090. In Horizons in HazRes with a ton of NPC combat going on , I never got much above 3Gb of ram usage. YMMV of course.
I was hoping to get to 5Gb just to put it to rest. I don't consider the games rather light memory usage in my scenario to be either good or bad. It's using what it needs and I am getting the performance I want so I am fine with it.
 
If they use "managed C++" and the solution is correctly configured, you can do this once, on the exe,
They don't. .NET is required to run launcher only. On linux you can use opensource launcher and avoid .NET installation at all.
 
5900x 64 gb of ram and a 3090. In Horizons in HazRes with a ton of NPC combat going on , I never got much above 3Gb of ram usage. YMMV of course.
I was hoping to get to 5Gb just to put it to rest. I don't consider the games rather light memory usage in my scenario to be either good or bad. It's using what it needs and I am getting the performance I want so I am fine with it.
Odessey uses all VRAM. Bitness you talk about includes RAM + VRAM + BIOS + I/O ports + anything else. So once they use 6Gb VRAM it is compiled to use 64 bit pointers.
 
Couldn't get my ED executable above around 2gb or main ram while monitoring yesterday, but I was mainly in space. 1.4gb seemed around the average, but that really has little to do with whether a game is 32bit or 64bit. The game has always been required to handle 64bit integers because the galaxy map required the use of 64bit integers from the very beginning, so the jump from 32 bit to 64bit probably wasn't huge.
 
Back
Top Bottom