Fw: ares and n64 support
David James <[email protected]> Sat, 10 Jan 2026 11:01:07 +0000
| Newsgroups | gmane.linux.debian.devel.games |
|---|---|
| Message-ID | <ljpxjwKZr7G_T8adlkRUxUgKyRrSjLr74S1Y6LL0jDsclid5KMITGDKNXyZgF4vRUOYAyVS20vkMrXUuHjA45V2lcPyjsy2ylVTxy-nGALg=@proton.me> |
Sorry if you got this twice. I sent it to the subscribe email by mistake. ------- Forwarded Message ------- From: David James <[email protected]> Date: On Saturday, 10 January 2026 at 10:56 Subject: ares and n64 support To: SmartList <[email protected]> CC: Christopher Obbard <[email protected]>, [email protected] <tchet@debian= .org> >=20 >=20 > Dear Debian Games Team, > Since the ares package is now receiving some love this seems like > the ideal time to bring up the possibility of restoring the n64 > core to the package. Especially since a new bug has just been raised > against it (#1124986) [1]. >=20 > It is my understanding that the core was originally disabled because > the source checks for SSE4.1 instructions at compile time and gives > optimised instructions if it is detected. >=20 > With the new version, -march=3Dx86-64-v1 can be enforced in d/rules. > The upstream source will choose "slow" instructions if SSE4.1 is not > detected, so since we're targeting x86-64-v1 anyway, is it still > necessary to disable this core? >=20 > When building the package with the core enabled, I don't run into > any errors, apart from the performance hit of targeting v1 over v2. > I need to test it extensively in qemu to ensure that it would run on > a v1 CPU. >=20 > I personally can't see any reason to keep the core disabled but > that's why I wanted to start this conversation. I wanted to reach > out to the more experienced developers here, especially those who > have worked with ares before, so if I'm making a gross > misunderstanding I can understand the reason behind it. >=20 > Regards, >=20 > David James >=20 > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1124986