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