Created attachment 252388 [details] new port ares ares is an open-source multi-system emulator with a focus on accuracy and preservation. It is a descendant of the emulators higan and bsnes. It's source code is structured to be maximally readable and self-documenting. ares supports the following systems: Arcade, WonderSwan, WonderSwan Color, Pocket Challenge V2, ColecoVision, PC-Engine / TurboGrafx, SuperGrafx, My Vision, NES / Famicom, Famicom Disk System, SNES / Super Famicom, Satellaview, Sufami Turbo, Nintendo 64, Nintendo 64DD, Game Boy, Game Boy Color, Game Boy Advance, SG-1000, Master System / Mark III, Mega Drive / Genesis, Mega CD, 32X, Game Gear, Neo Geo Pocket, Neo Geo Pocket Color ares has experimental support for the following systems: Atari 2600, MSX, MSX2, PC-Engine CD / TurboGrafx CD, ZX Spectrum, Neo Geo (AES/MVS), PlayStation ares has all the features one would expect from a great emulator system: native multi-platform UI, dynamic rate control, save states, run-ahead, rewind and fast-forward, pixel shaders, color correction, input multi-mapping, debugger ares uses librashader for it's pixel shader engine. This means it is highly compatible with existing slang shaders, e.g. the slang-shaders from libretro. https://ares-emu.net/ The port depends on bug #280470 in order to unbundle librashader from ares.
+ # CPUTYPE from /etc/make.conf overrides official default + ifeq ($(CPUTYPE),) + # For official builds, default to x86-64-v2 (Intel Nehalem, AMD Bulldozer) which supports up to SSE 4.2. + flags += -march=x86-64-v2 + endif Ports targeting on generic (base) amd64 without even SSE3. Remove "flags += -march=x86-64-v2".
Created attachment 252397 [details] new port ares Alright. ares does a SSE 4.2 check at runtime and will abort the program if the host isn't capable. AFAIK SSE 4.2 intructions are generated at core execution, i.e. JIT, intrinsics etc. The ares executable itself doesn't need to be build for SSE 4.2. Therefore I removed the -march=x86-64-v2 setting from the GNUmakefile as requested. The port now always builds according to the specified CFLAGS and CPUTYPE settings. I also removed the section about SSE 4.2 requirement in pkg-message. While there I also updated to version 139.20240731
Created attachment 252681 [details] new port emulators/ares - update to 139.20240809 (will track release versions once 140 is out) - remove unnecessary CPUTYPE form MAKE_ARGS (forgotten after last changes) - remove -DLIBRA_RUNTIME_OPENGL from patch and set it in MAKE_ARGS instead - reworked DEBUG and LTO options, patched out -Og from debug builds and set symbols=false (handled by ports system), set lto=false (handled by ports system, WITH_LTO) - use LTO_UNSAFE for QT5 flavor instead of OPTIONS_EXCLUDE - removed VULKAN option, now implicit set by N64 option (Vulkan support only applies to the N64 core) - add NVIDIA build option and associated patch to re-enable "broken-cache-pipeline" workaround from Granite upstream - set build=release instead of build=optimizied, patch out -O2 instead of -O3 - separate OPT_ variables with empty lines to improve readability - reworded pkg-message - pet portclippy, portfmt, portlint
emulators/ares depends on devel/librashader, but devel/librashader is rust software - I am not competent enough in the ports framework for rust, so I do not touch such ports. Also I see flavor qt5 - can emulators/ares work with qt6 too? Qt5 planned for deprecation in ports, but I don't know exact date.
There is games/libretro-shaders-slang port (https://github.com/libretro/slang-shaders) - can emulators/ares use it?
(In reply to Vladimir Druzenko from comment #4) > emulators/ares depends on devel/librashader, but devel/librashader is rust software - I am not competent enough in the ports framework for rust, so I do not touch such ports. No problem, we just have to wait for another brave committer then :) Well, it's not like ares has a hard dependency on librashader. I could remove my patches which unbunbdle librashader from ares. In this case users would have to build librashader themselfs on their system IF they want to use shaders. There are instructions provided by librashader and on ares github itself. I did the unbundling of librashader because I think it would be a nice experience out of the box for the ares port to have shader support without users needing to do anything in addition. I would actually wait a little longer for a brave committer to commit librashader before we go that way. > Also I see flavor qt5 - can emulators/ares work with qt6 too? Qt5 planned for deprecation in ports, but I don't know exact date. QT6 is currently not supported upstream. I don't know if there are any plans to support QT6 anytime soon. I included the QT5 flavor because of completeness. And because the QT5 flavor is currently broken with LTO, I would actually have no hard feelings removing the QT5 flavor from the port. Maybe just remove QT5 flavor and add QT6 flavor if/when supported by upstream? (In reply to Vladimir Druzenko from comment #5) > There is games/libretro-shaders-slang port (https://github.com/libretro/slang-shaders) - can emulators/ares use it? Of course, that's the sole reason I maintain the games/libretro-shaders-slang port ;) It's behind the SHADER port option: SHADER_RUN_DEPENDS= ${LOCALBASE}/${_SHADERS}/bilinear.slangp:games/libretro-shaders-slang
Created attachment 252757 [details] new port emulators/ares With ares being currently the only known open-source project using librashader, it's probably difficult to find a committer for the devel/librashader port. A committer would want to test it with emulators/ares, but emulator/ares isn't in the ports because it waits for devel/librashader to be committed. Chicken-egg-problem. Therefore I removed the dependency for devel/librashader, the port can now be reviewed and hopefully committed without waiting any longer for devel/librashader. I added a section to pkg-message with instructions to compile librashader manually if a user wants to use shaders until devel/librashader is committed. I removed the QT5 flavor. Upstream is also thinking about deprecating and removing QT5 support.
Warning: you might not need LIB_DEPENDS on libcanberra-gtk3.so Does ares use libcanberra-gtk3.so? Warning: you might not need LIB_DEPENDS on libEGL.so Also I see it link with libGL, but not libEGL. Maybe correct is: GLX_USES= gl -GLX_USE= GL=egl +GLX_USE= GL=gl ?
Created attachment 252759 [details] new port emulators/ares (In reply to Vladimir Druzenko from comment #8) > Warning: you might not need LIB_DEPENDS on libcanberra-gtk3.so > Does ares use libcanberra-gtk3.so? At least it's mentioned as dependency on the github site. But there's no occurence of it in the actual sourcecode. I can't get systemsounds out of ares, so I don't really know if there's some setup missing on the host system. It's definitly no hard dependency. In lieu of a better approach I removed it now. > Warning: you might not need LIB_DEPENDS on libEGL.so > Also I see it link with libGL, but not libEGL. > Maybe correct is: > GLX_USES= gl > -GLX_USE= GL=egl > +GLX_USE= GL=gl >? Thanks, good catch! It links against libGL indeed. I corrected it.
Keep "MAKE_ARGS= lto=false" even without Qt5?
sdl2=false ?
(In reply to Vladimir Druzenko from comment #10) > Keep "MAKE_ARGS= lto=false" even without Qt5? Yes, it's handled by the standard ports framework when compiling with WITH_LTO. When we use lto=true, it emits its own compiler and linker flags. I think we want the ports framework flags to be used, similar to how we patch out hardcoded upstream -Ox optimization flags, don't we? (In reply to Vladimir Druzenko from comment #11) > sdl2=false ? Yes, it's handled by the portoptions SDLINPUT and SDLAUDIO. If a user wants to compile ares without any SDL support, leaving it sdl2=true might leave SDL support in. (But, currently, the sdl2 upstream option doesn't do anything on Windows/Linux/FreeBSD anyway. It's only relevant for MacOS. But I'd leave it in in case upstream changes it behaviour.)
(In reply to Stefan Schlosser from comment #12) Mk/Features/lto.mk - I don't know how it work: add USES=lto to ports Makefile and "WITH_LTO=yes to your /etc/make.conf"?
I haven't seen any port which uses USES=lto. It's enough to have WITH_LTO=yes in /etc/make.conf to compile with LTO enabled.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ceee4b76d252715f6552a57c0612a16a8e2272aa commit ceee4b76d252715f6552a57c0612a16a8e2272aa Author: Stefan Schlosser <bsdcode@disroot.org> AuthorDate: 2024-08-14 19:06:03 +0000 Commit: Vladimir Druzenko <vvd@FreeBSD.org> CommitDate: 2024-08-14 19:06:03 +0000 emulators/ares: New port: open-source multi-system emulator with focus on accuracy and preservation ares is an open-source multi-system emulator with a focus on accuracy and preservation. It is a descendant of the emulators higan and bsnes. It's source code is structured to be maximally readable and self-documenting. ares supports the following systems: Arcade, WonderSwan, WonderSwan Color, Pocket Challenge V2, ColecoVision, PC-Engine / TurboGrafx, SuperGrafx, My Vision, NES / Famicom, Famicom Disk System, SNES / Super Famicom, Satellaview, Sufami Turbo, Nintendo 64, Nintendo 64DD, Game Boy, Game Boy Color, Game Boy Advance, SG-1000, Master System / Mark III, Mega Drive / Genesis, Mega CD, 32X, Game Gear, Neo Geo Pocket, Neo Geo Pocket Color. ares has experimental support for the following systems: Atari 2600, MSX, MSX2, PC-Engine CD / TurboGrafx CD, ZX Spectrum, Neo Geo (AES/MVS), PlayStation. ares has all the features one would expect from a great emulator system: native multi-platform UI, dynamic rate control, save states, run-ahead, rewind and fast-forward, pixel shaders, color correction, input multi-mapping, debugger. ares uses librashader for it's pixel shader engine. This means it is highly compatible with existing slang shaders, e.g. the slang-shaders from libretro. https://ares-emu.net/ PR: 280527 emulators/Makefile | 1 + emulators/ares/Makefile (new) | 198 +++++++++++++++++++++ emulators/ares/distinfo (new) | 3 + ...es_n64_vulkan_parallel-rdp_util_timer.cpp (new) | 13 ++ ...n64_vulkan_parallel-rdp_vulkan_device.cpp (new) | 13 ++ .../extra-patch-desktop-ui_desktop-ui.cpp (new) | 15 ++ .../ares/files/patch-desktop-ui_GNUmakefile (new) | 21 +++ emulators/ares/files/patch-hiro_GNUmakefile (new) | 11 ++ emulators/ares/files/patch-nall_GNUmakefile (new) | 29 +++ emulators/ares/files/pkg-message.in (new) | 44 +++++ emulators/ares/pkg-descr (new) | 20 +++ emulators/ares/pkg-plist (new) | 13 ++ 12 files changed, 381 insertions(+)
Thanks.