Created attachment 357134 [details] mupen64plus-2.0.0.ebuild major version bump GUI not more shipped with the emulator
Comment on attachment 357134 [details] mupen64plus-2.0.0.ebuild https://bitbucket.org/ecsv/mupen64plus-rsp-cxd4 This brings me to something else. Please build rsp-z64 and rsp-cxd4 with mle (hlevideo) support. And there are some dependencies missing (like glew, boost, glu). And why does it depend on sdl-ttf, xz-utils, dejavu and gtk+? I cannot find the dependency anywhere? Maybe it would also be better to just split the big chunk into smaller parts connected by a meta package. At least this seems to be the intended way for distributions because the separate tarballs like the ones found at https://bitbucket.org/richard42/mupen64plus-core/downloads are the only ones with proper digital signatures. Also don't forget the current bugfixes: http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-core.git;a=blob;f=debian/patches/multiple_main.patch;h=d348f99a7be8450a72b5f351404513228802efc9;hb=HEAD http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-core.git;a=blob;f=debian/patches/n64_cic_nus_6105_reset.patch;h=71b09341bc7aa12193d5a238d05eb127f1b6d2e7;hb=HEAD http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-glide64mk2.git;a=blob;f=debian/patches/init_quit.patch;h=7d854f78f6d935c0934769135d86286f3dae8c5a;hb=HEAD http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-glide64mk2.git;a=blob;f=debian/patches/load_hires_cache.patch;h=feb9652ab3f9fdfe3a435d3ee93eb3aaf9f59662;hb=HEAD http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-glide64mk2.git;a=blob;f=debian/patches/mesa_fxt1.patch;h=12c42496223fd4322aab49753b0709e5c03612be;hb=HEAD http://anonscm.debian.org/gitweb/?p=collab-maint/mupen64plus-video-glide64mk2.git;a=blob;f=debian/patches/s3tc_removal.patch;h=e4cd0c0ac93c33c7c3d8084492178c6e7fc0a5fa;hb=HEAD
Created attachment 357278 [details] splitted ebuilds In reply to Comment #1 I think extra dependencies where relics from elder ebuilds. I'm not sure the way it should be, because the more ebuilds you have the more errors you can get. I just tried to split the ebuild in different chunks (with near no dependencies checking). If you can take a look it'll be nice. Thanks for the link to the patchset, I'll work on including them in.
Created attachment 357288 [details] splitted ebuilds
Just had a brief look: The enable/disable logic seems to be broken. For example PIC is (by the upstream build system) enabled by default on amd64 and disabled by default on i386. Your ebuild only allows to disable pic but not force to enable it. There are many more but the biggest problem seems to be HLEVIDEO. This is always disabled and your ebuild only disables it on demand but never enables it. And I think it would be nice to have both (hlevideo and lle) installed at the same time... but I am not sure about it. All video plugins depend on opengl (this is sometimes missing). glide64mk2 needs libpng and zlib when hires is enabled, or am I missing something? And please remove this yasm dependency. No one uses it. And don't forget to remove the temporary/swp files. Why has video-z64 a ftgl dependency? And the descriptions should not be the same copy without change. Rice needs libpng. Following ebuilds need depend on pkg-config (the rest doesn't need it, so please remove it): mupen64plus-audio-sdl mupen64plus-core mupen64plus-video-arachnoid mupen64plus-video-glide64 mupen64plus-video-glide64mk2 mupen64plus-video-rice mupen64plus-video-z64 wxmupen64plus doesn't build at all (missing patches for example). And it is missing the opengl, sdl, x11 and python dependency (python only as build dependency for waf) The license information is not set in most ebuilds...
Created attachment 357338 [details] splitted ebuilds 1) In reply to #comment4 Thanks for your lights about dependencies The enable/disable logic was based upon make targets default value, I changed it again with the previous behavior I used. Dependencies were updated, at least partially I hope totally. About ftgl dependency in z64: rgl_debugger includes FTGLTextureFonts.h, but video-z64 isn't linked to ftgl (maybe debug flag ask it) I've seen mupen64plus (I supposed all delivered on the code.google.com repo) is under the GPL license terms. I assumed all the external plugins are also, may be am I wrong ? HLEVIDEO: plugins are built separately using postfix > Or am I missing something? I can't answer, I just guess you know something about this project, not me. I just enjoy to play sometimes some N64 games I had at home before. One of them doesn't work with previous version of mupen64plus (used to work before 1.5). As I don't like to have many binary in my home directory I had to make an ebuild. About wxmupen: I'll drop a new ebuild on the other thread #482616 2) debug flag: I don't know if it's correct to use it the way I did, especially for mupen64plus-core asm flag: maybe should it build separate plugins and library (mupen64plus-core) ? dynarec flag (mupen64plus-core): should be masked on all arch not supporting it.
Committed the initial set of ebuilds, package.masked for testing. I will consider adding the extra plugins later.
@Samuel, @Franz: do you see a need for the z64 plugins or other plugins from wahrhaft? They seem quite unmaintained to me, so I'm wondering if there are some real cases when they work better than the default set.
At least the mupen64plus-rsp-z64-hlevideo is quite important because the high level emulation of mupen64plus-rsp-hle doesn't support all ucodes. But this can also be replaced by the more recent mupen64plus-rsp-cxd4-hlevideo. I never "used" mupen64plus-video-arachnoid because it doesn't work here quite well. mupen64plus-video-glide64 was the best video plugin for a while but there is now mupen64plus-video-glide64mk2 which should be better (but also slower and more demanding on the gpu features like fragment shader and so on). mupen64plus-video-z64 is the only video plugin supporting the actual low level emulation of mupen64plus-rsp-z64 and mupen64plus-rsp-cxd4. I heard that it can be useful but never used it myself.
(In reply to Franz Schrober from comment #8) > At least the mupen64plus-rsp-z64-hlevideo is quite important because the > high level emulation of mupen64plus-rsp-hle doesn't support all ucodes. Any suggestions on which game I could test this? > But this can also be replaced by the more recent mupen64plus-rsp-cxd4-hlevideo. Is this one open source? Does it have a homepage? > mupen64plus-video-z64 is the only video plugin supporting the actual > low level emulation of mupen64plus-rsp-z64 and mupen64plus-rsp-cxd4. I heard > that it can be useful but never used it myself. That's what I noticed so far, so I guess I'll end up adding the two -z64 variants as well. From what I understand, there's not much point in non-hlevideo version of rsp-z64?
(In reply to Michał Górny from comment #9) > (In reply to Franz Schrober from comment #8) > > At least the mupen64plus-rsp-z64-hlevideo is quite important because the > > high level emulation of mupen64plus-rsp-hle doesn't support all ucodes. > > Any suggestions on which game I could test this? For example anything with MusyX audio codec like Rush 2049, Resident Evil 2, Snow Cross Polaris, Rogue Squadron, The World Is Not Enough, Rugrats In Paris, NBA Show Time, Hydro Thunder, Tarzan, Gauntlet Legend > > But this can also be replaced by the more recent mupen64plus-rsp-cxd4-hlevideo. > > Is this one open source? Does it have a homepage? It seems to be public domain according to https://github.com/cxd4/rsp and the port for mupen64plus can be found at https://bitbucket.org/ecsv/mupen64plus-rsp-cxd4 > > mupen64plus-video-z64 is the only video plugin supporting the actual > > low level emulation of mupen64plus-rsp-z64 and mupen64plus-rsp-cxd4. I heard > > that it can be useful but never used it myself. > > That's what I noticed so far, so I guess I'll end up adding the two -z64 > variants as well. From what I understand, there's not much point in > non-hlevideo version of rsp-z64? At least I didn't find one myself. But you don't need to add mupen64plus-rsp-z64 when you don't add mupen64plus-video-z64. Because the non-hlevideo versions of -rsp-z64 and -rsp-cxd4 don't support any other video plugin. BTW. the -hlevideo versions of -rsp-z64/-cxd4 plugins are generated by setting HLEVIDEO=1 when compiling+installing it.
Thanks for all the intel. I will look at cxd4 tomorrow, and then think about -z64 if it doesn't work well enough.
Thanks for the commit. I used to change the 3rd party plugins ebuild, following mgorny syntax enhancements. But not rsp-cxd4 yet (I did it really to quick and have to spend a bit more time to convert this one). Can upload them if any interest. I tested ebuild as-is but without applying furnished patchset for video-glide64mk2 plugin, any gui fails to close games (when using this video plugin). For now patches can be applied through epatch_user call, but they may have to be directly inserted into the portage tree, I think the init_quit.patch is the one mostly required. See #comment 1 for the patchset links. Hope this comment may be helpful for the unmasking process of these ebuild.
Bumped to 2.5 and unmasked today. If you need more plugins, please open separate bug reports to avoid cluttering this one.
