For now only x86-64 is supported by discord sdk, arm64 we ship without
discord sdk. So players can choose if they want more performance without
discord integration, or less performance with discord integration.
Builds and runs successfully with:
cmake -DCMAKE_BUILD_TYPE=Release -GNinja -DPREFER_BUNDLED_LIBS=ON -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
ninja package_dmg
Tested successfully with native arm64 and rosetta
No discord support for universal binary
Declare that we're fine with policies up to 3.19.1. This should fix
policy errors and "too low cmake_minimal_version() errors" for the
forseeable future.
3131: Get CMake 2.8 working r=def- a=Learath2
It only required fixing one weird CMake 2.8 oddity.
I guess we should merge this if we are keeping to claim 2.8 support.
Co-authored-by: Learath2 <learath2@gmail.com>
For AlwaysLivid's Haiku port:
> CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake files:
> /boot/home/ddnet/SQLite3_INCLUDEDIR
@heinrich5991 thoughts?
Add libnotify support for linux client
Also unify notification management
Make libnotify mandatory for the client. It is installed on 100% of Arch
Linux systems and on 70% of Debian systems. I'd guess the remaining
Debian systems are servers.
Detect dependent libraries of `libnotify` using `pkg-config`. Remove
library-specific code from the game module. Decrement refcount for
libnotify notification object before leaving the function.
It's installed basically everywhere and just increases release size.
They're serious about backward compatibility and haven't had a breaking
change in ages.
SHA256 was chosen because it is reasonably standard, the file names
don't explode in length (this rules out SHA512) and it is supported by
basically all versions of OpenSSL (this rules out SHA512/256 and SHA3).
The protocol is changed in a backward compatible way: The supporting
server sends the SHA256 corresponding to the map in the `MAP_DETAILS`
message prior to sending the `MAP_CHANGE` message. The client saves the
SHA256 obtained from the `MAP_DETAILS` message until the next
`MAP_CHANGE` message.
For servers not supporting this protocol, the client falls back to
simply opening maps like in the previous scheme.
Remove the `map_version` tool, it is not being used and would have been
a little bit effort to update.
Use the OpenSSL implementation of SHA256 if it is supported, otherwise
fall back to a public domain one.
Fix#1127.
Edgar
ChillerDragon
