add Windows 64-bits target to the Editor

[ericoporto]

Describe the problem High resolution games may require more RAM than the current maximum of 2GB for 32-bit Windows builds, in fact current 32-bit Windows builds of the engine have produced OoM errors at 1.4GB of used memory. The Linux, macOS, iOS and Android builds currently support their 64-bit variants (Emscripten currently is 32-bit). It makes sense that along with other platforms, the Windows engine would also be available for 64-bit.

Suggested change The things with 64-bit Windows is I am not sure how it should be added, if it needs a separate checkbox or not for it in the Editor, because we don't have something to configure individual targets. Note in the 32-bit Editor, 32-bit variant of the plugins are still necessary even if we are building for Windows 64-bit, as the plugins have an api that is used by the Editor to retrieve some things, including the plugin header. I am not sure how the Editor would work with Windows 64-bit engine, my guess it would have a directory Windows with a directory x64 and inside of it the 64-bit variant of the Engine and of SDL.dll. Perhaps if there is a 64-bit Editor it would have similar structure but for the x86 build of the Windows engine.

[ericoporto]

To clarify, the main questions are:

• Should Windows 64-bit be a different target than Windows or be assumed to be the same? Should we build for both by default or have an option somewhere? (Where?)
• Which directory structure is expected for the Windows build target pre-built engines? Or should them be in the AGS Editor root, with a suffix (say acwin.exe is kept, but we now add acwin-x64.exe in the same dir)
• Where is SDL2.dll for x64 expected to be?
• Where are the plugins expected to be? (these dlls aren't expected to have a suffix)
• The directory structure of the Editor, in case it's changed, should we change the output of the Engine.vcxproj too?

[ivan-mogilko]

I don't have a full picture right now, but two things I might mention first:

1. IMO the build should be called acwin64.exe, to let distinct the engines.
2. If not for plugins, then I would propose to make 64-bit build default, because likely there are not alot of 32-bit systems in use at this point. Plugins seem to be the only blocking issue here (unless I miss anything else?).

I don't have much knowledge about this, so wonder, how the games will be distributed by authors on popular gaming platforms, such as Steam, GOG, and so forth. Do those have separate downloads for 32 and 64-bit versions of the game?

Maybe we may start by adding an alternate build as a non-default option into "build targets". If we keep 32-bit as default, then there's a "Windows x64" checkbox. After we switch default to 64-bit build, then have a "Windows x86" checkbox (unchecked by default).

In regards to suffixes, we might actually require 64-bit plugins to have "64" suffix added to them for easier distinction.

[ericoporto]

Plugins seem to be the only blocking issue here (unless I miss anything else?).

Yes, the big issue here in general are the plugins. If a plugin is 64-bit, and it's the only source of the plugin name and header and a few other things in the plugin API, then either the Editor has to be 64-bit or we have some command line tool that exists in 32-bit and 64-bit executables that get called by the Editor.

I don't have much knowledge about this, so wonder, how the games will be distributed by authors on popular gaming platforms, such as Steam, GOG, and so forth. Do those have separate downloads for 32 and 64-bit versions of the game?

This is a good question, I have no idea, perhaps this is a good thing to ask in the forums.

[AlanDrake]

You don't really see 32 bit versions anymore. I think it was about 6 years ago that developers stopped shipping both versions and since then 32bit executables have dwindled to near obscurity.

I also read that Steam will be removing support for 32bit Mac os games from this very year. You can't eevn see a 32 bit OS on the Steam hardware survey anymore.

We could drop 32 bit versions in the future,, unless we need to keep 'ol x86 around for compatibility in playing older games.

[ericoporto]

I think this may have different answers from ags3 and ags4 perspectives.

First issue though, is if we want to move to 64-bit engine only we need to also move the Editor to 64-bit - because of plugins. Or create a specific executable to work with plugins and extract necessary info from them, this could be an addition of the existing command line tools.

AGS currently runs faster in 32-bit than 64-bit, I think this is due the 32-bit VM and the casts and pointer conversions, so perhaps there's some change in ags4 that could be done to reduce these that can't be done in ags3 because of the compatibility.

The good things about 64-bit Windows binary is this lets the game access more RAM, as the 32-bit combined with fragmentation tends to lock the maximum RAM in Windows at around 1.4GB.

You can't eevn see a 32 bit OS on the Steam hardware survey anymore

The last OS there which is 0.06% of all Windows is 32-bit Windows 7. I know it's very few but it's there - but yes we could ignore it, this was 0.28% in 2021 so there is a clear downward tendency here and I imagine they will disappear in the next survey.

[ivan-mogilko]

Editor only needs limited number of things from the engine's plugin, and iirc all of that is simply a text string. It may be faster to write an intermediate utility that would interact with plugins of respective bitness, extract necessary data, and pass to the editor using whatever means are convenient (like file, stdout, or pipe).

This will make Editor independent from the engine build it's making game for, and work both ways: reading old 32-bit plugins in 64-bit editor and 64-bit plugins in 32-bit editor (if editor will take more time to fully upgrade to 64-bit).

Besides we would need similar utility to build games without editor (checking plugins and extracting script header). So this will come useful.