64-bit binaries

[voed]

It would be great to have 64-bit binaries(atleast HLDS) to run server in WSL, use 64-bit tools like .NET Core or just get rid of 32-bit dependencies on Linux.

[SamVanheer]

Since Ubuntu is going to drop 32 bit support eventually it might be a good idea to look into the feasibility of a 64 bit client build, even if mods can't be loaded without modification first.

[hogsy]

To add to the comments above, this is necessary due to macOS dropping support for 32-bit applications as well.

[boukeversteegh]

MacOS 10.15 Catalina was released yesterday, and I can confirm Half-life no longer starts.

[artkirienko]

BUMP, still waiting for macOS Catalina 64bit game binaries

Also, It would be great to have A64 – ARMv8.3‑A binaries to run the game on macOS Big Sur https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/ https://en.wikipedia.org/wiki/Apple_A12Z

[metita]

@mikela-valve This needs to be addressed

[lbibass]

Bumping this again.

[sabianroberts]

Bumping. Players should be able to play what they purchase no matter what their PC's architecture.

[fysiks1]

While I agree that this should happen, we can't expect that it will. I also can't play my Atari game cartridge on an XBOX.

[DeafMan1983]

Please don't forget to release static executable for Alpine and Void-Linux because they don't love to glibc version. Both have musl-libc. Example root directory of Half-Life

Half-Life/
hl <= static executable 
hw.so <= no available because it is embedded in hl executable by musl-libc
  valve/../*.so should compile by musl-libc without dynamic libraries

And custom so file like RcBot or MetaHook etc should normally but so files should compile by musl-libc cause problem loads of glibc.

Please remember use musl-libc then game runs whatever glibc or musl versions.

I write static libraries with X11, xcb, Wayland and other windowing system and I would like to give you or you write own wrapper. If you use Windows or macOS then you should create wrapper for Windows and macOS but sometimes not good direct DllImport.

Why do we need wrapper?

There are communications and callbacks/invokes better functionally. Example best C# development need expert 1:1 If you add SDL2 in DllImport and write oop coding then SetRGB() shows wrong color like R and B are chosen.

That's why we need create own wrapper for whole c++ or dotnet and I get error from after native code generating of dotnet then I change/replace to musl-g++ -static -s .... -lX11 ....

And we would like to create classlibs for client and server into native aot libraries and copy to bin, cl_dlls and dlls of your custom mod then you would like to be happy if we are lazy for hard-coded C++. Do you think we would like to develop for Half-Life with 64 Bit, Vulkan support and improvements.

[xplshn]

Still nothing?

[DeafMan1983]

Please wake and rework hard on 64 Bit.

Now Half-Life has 25 years anniversary and we need to use 64 Bit now! Whatever we fight you because we want to have 64Bit! Please stop using 32 Bit!!!!! Because macOS users are victims by Valve Software. And please tell us! We are your fans :)

[tschumann]

hlds and Counter-Strike had 64-bit support (for Linux only) from 2004to 2006: https://vghe.net/goldsource-engine.html#64-bit-support Not sure why it was removed but there was some discussion at https://forums.alliedmods.net/archive/index.php/t-46712.html and https://forums.alliedmods.net/archive/index.php/t-2173.html

[DeafMan1983]

Oh @tschumann why do you not tell me now?

[tschumann]

I only noticed the amd64 binaries recently but I didn't realise they were so old.

On Sat, 18 Nov 2023 at 22:42, Jens Eckervogt @.***> wrote:

Oh @tschumann https://github.com/tschumann why do you not tell me before?

— Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/halflife/issues/2231#issuecomment-1817499063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA34IYQJ4KPB4MQHD57TRIDYFCUNHAVCNFSM4HH7BR3KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRG42DSOJQGYZQ . You are receiving this because you were mentioned.Message ID: @.***>

[goober-183]

Bumping, Running on a vm after a while cause the game to lag on MacOS. So just a native version would be better so i dont have to deal with the pain of virtual machines

[APGRoboCop]

I don't know if we should be prepared to have our addons and Metamod recompiled for AMD64. But I've managed to do that for Metamod-P, as my new Linux 64-bit Debian 11 works fine. The newer Debian 12 is not quite ready yet as older Linux servers will not work if I compile Metamod and other addons with the newer GLibc. It sucks that my Clang doesn't appear to properly use the -static-libstdc++ and -static-libgcc compile flags, unless I use AMBuild. But AMBuild appears to have -g3 Debug flag glitch, regardless if I don't use the --enable-debug when using AMBuild.

We should also prepare to adjust the AMBuild scripts and that will work for compiling x86-64. The performance on using 64-bit won't make much of a difference I think, but it is scary that more and more distros are dropping i386 completely. As for 3rd Party Gamemods like The Specialists 3.0 which hasn't been updated for SteamPipe whereas ENSL contains the src code for Natural Selection, it will be sad to not see hlds_run work and run those older i386 compiled mods, even with or without Metamod.

[APGRoboCop]

OK I've reinstated and recompiled some AMD64 support for Metamod-P. Now I know there are very few _amd64.so binaries and outdated cs_amd64.so builds and hlds_amd64.so files etc. However, if Debian and SteamOS will drop i386 support in the next years - maybe it will, I guess we really need to prepare ourselves. I know that Debian still supports i386, but SteamOS that uses Arch Linux only unofficially supports i386...

https://github.com/APGRoboCop/metamod-p/releases/tag/v1.21p42