Package Details: simple64-git 2024.03.1.r0.g99e37c5-1

Git Clone URL: https://aur.archlinux.org/simple64-git.git (read-only, click to copy)
Package Base: simple64-git
Description: Nintendo64 emulator based on Mupen64Plus (git version)
Upstream URL: https://simple64.github.io/
Licenses: GPL-3.0-only
Conflicts: m64p-git, mupen64plus, simple64
Provides: m64p-git, simple64
Replaces: m64p-git
Submitter: dbermond
Maintainer: dbermond
Last Packager: dbermond
Votes: 4
Popularity: 0.127904
First Submitted: 2022-09-03 01:36 (UTC)
Last Updated: 2024-03-09 10:59 (UTC)

Latest Comments

1 2 3 Next › Last »

dbermond commented on 2023-06-20 01:16 (UTC)

@dreieck the simple64 binary executable is a gui program, while the mupen64plus binary executable is a command line interface. It would not fit the needs of a frontend application that wants to execute mupen64plus through the command line, like m64py. Besides, if you have simple64, you already have a gui/frontend, and another frontend (like m64py) would not be theoretically needed. Also, simple64 is not mupen64plus, but it's a heavily modified version of mupen64plus-core, with it's own Qt gui, a different set of plugins and other unique features and changes.

dreieck commented on 2023-04-24 15:06 (UTC)

This package contains many mupen64plus files.

Can, by adding a symlink /usr/bin/mupen64plus → /usr/bin/simple64, this package have mupen64plus added to it's provides array?

There is at least one package that depends on mupen64plus (m64py).

Regards!

dreieck commented on 2023-04-24 15:02 (UTC)

Please add m64p to the provides array, if you have m64p-git in there.

Star-X commented on 2023-01-15 22:58 (UTC)

Nvm, found a workaround. There's a vosk-api-bin that works fine. Just installed that instead, and no need to reinstall Java.

dbermond commented on 2023-01-14 14:50 (UTC)

@Star-X vosk-api is needed at build time since we are using it from the AUR package (built from sources) instead of using the bundled vosk-api provided by upstream. All vosk-api files provided by upstream are purged. I have no build failures with vosk-api.

Star-X commented on 2023-01-09 02:30 (UTC)

Is it possible to remove vosk-api from make-depends in the PKGBUILD? I really don't care about VRU emulation, like, at all (it's used by one game, and while I have a tiny bit of nostalgia for that one game, it is objectively a trash game that really could've used another 20 years of development in voice recognition before being released), and vosk-api is an absolute pain in the ass to properly compile as it requires a reinstall of java even if you already have it installed, and it tends to fail to compile a LOT.

Seriously, I'm fine with it being an optional dependency, but as a make-dependency it makes me want to just say screw it and use the garbage Mupen64plus variant in Retroarch instead, even for things that Retroarch's variant has enormous problems with (COUGHCOUGH PILOTWINGS 64 COUGHCOUGH). That or do the unthinkable and use the flatpak on a system that really, REALLY doesn't need flatpaks.

noabody commented on 2022-12-29 15:52 (UTC) (edited on 2022-12-29 16:10 (UTC) by noabody)

Needs patch for processor independence, x86-64 architecture, or message to notify user that CPU must support AVX2. See issue less aggressive -march=x86-64-v2.

Can be accomplished with sed/perl, perl examples follow.

To force x86-64:

  perl -pi -e 's|-v3||gi' simple64/{simple,mupen,parallel}*/CMakeLists.txt

To force x86-64-v2:

  perl -pi -e 's|-v3|-v2|gi' simple64/{simple,mupen,parallel}*/CMakeLists.txt

electronic_punk commented on 2022-05-10 14:50 (UTC)

@drito do you have vosk-api installed earlier as a standalone package?

dbermond commented on 2022-04-25 03:26 (UTC)

@drito I've just checked, and the package is currently building fine for me. Issues related to building vosk-api should be reported on the corresponding AUR web page.

drito commented on 2022-04-24 21:40 (UTC)

makepkg failure during vosk-api compilation. No more info in the output.

1 2 3 Next › Last »