Hi! Please find attached heroes3-1.3.1a-r2.ebuild, so it can be localized to Spanish, German and Polish. You can find how to localize Heroes 3 at https://babelize.org/. This ebuild is based on heroes3-1.3.1a-r1.ebuild, so it also depends on existing ${FILESDIR}/heroes3-wrapper.sh Jos
Hi! Please find attached heroes3-1.3.1a-r2.ebuild, so it can be localized to Spanish, German and Polish. You can find how to localize Heroes 3 at https://babelize.org/. This ebuild is based on heroes3-1.3.1a-r1.ebuild, so it also depends on existing ${FILESDIR}/heroes3-wrapper.sh José María
Created attachment 98047 [details] heroes3-1.3.1a-r2.ebuild
https://babelize.org/download does not seem to be working correctly.
(In reply to comment #3) > https://babelize.org/download does not seem to be working correctly. > seems to work now
Created attachment 173899 [details] Added ppc architecture. I added the possibility to install Heroes3 on PPC. Please consider this ebuild file for future inclusion in Gentoo.
Created attachment 189660 [details] working l10n, amd64 & ppc support And another ebuild for Heroes3: * based off current portage ebuild, * updated, working l10n (tested de/pl/ru), * included PPC stuff from Thomas Juerges ebuild (untested), * updated to work on multilib amd64.
Created attachment 190242 [details] Updated wrapper for heroes3 (static) Updated wrapper for heroes3. This one is for the static version.
Created attachment 190243 [details] New wrapper for heroes3 (dynamic) New wrapper for heroes3 (dynamic version)
Created attachment 190246 [details] heroes3-1.3.1a-r3.ebuild (based on Michał Górny's work) I have taken as base Micha? Górny's work, and one improvement is support for dynamically linked version of heroes3 (which works better in my system). This ebuild also keeps previous hiscore.dat file, so it is not lost between reinstalls.
I have been working on heroes3 dynamic support because I have found a couple of problems which did not happen with my previous laptop 3 years ago. First one is related to video mode. My current laptop has a NVidia graphics card, and I'm using latest stable nvidia-drivers driver. The problem is that the driver publishes several 800x600 modes, and one of them is double scan. Statically linked heroes3 uses an old libsdl library, whose video mode selection algorithm is different from the one used by libsdl in Gentoo (basically it reverts the order). So, depending on hardware, driver and available video modes, people may prefer using the dynamic heroes3 instead of the static one. Second one is the sound. If I run heroes3 (static) in my system as a normal user, I get next message: Couldn't open audio: but there is no problem when I tried it as root! With the dynamic version of heroes3 I have no sound problems. I guess the problems I'm suffering with the static version are related to an ESD misconfiguration in my laptop (esdplay plays for root, but not for my user), and dynamic one is working because I compiled libsdl with alsa support and I force it (using SDL_AUDIODRIVER envvar).
Few comments about the dynamic version: 1) I think it should be USE-dependant, 2) the RDEPEND for dynamic version is incomplete, 3) on AMD64 it even can't be complete, because we have no 32-bit smjpeg, and crosscompiling packages using libtool is painful, 4) and even if I install the 32-bit smjpeg, heroes3.dynamic segfaults.
Created attachment 190266 [details] heroes3-1.3.1a-r3.ebuild (based on Michał Górny's work and recommendations) A revised version of my previous ebuild, based on Micha? Górny's recommendations: a USE flag for dynamic heroes3 executable, and missing RDEPEND dependencies. It remains the amd64 issue related to 32-bit smjpeg.
Firstly, what about PPC dynamic version? Is there one? If it is, we should probably put same RDEPENDs as with x86. If there isn't and the user set 'dynamic', we should either die in pkg_setup or warn user there and don't install the wrapper then. Also, I don't we should place both scripts in ${FILESDIR], especially because we already use sed on both of them. I think we should instead place only one version, and modify it appriopriately with sed. And the last thing - I don't like the way we're handling l10n there. It's way too much code - but I don't currently have an idea how to make it better.
If you have access to a Linux Gentoo ppc installation, you are free to check/fix/improve the ebuild. About smjpeg and amd64, I have to do some tests next week. I think the solution should involve an update of sys-libs/lib-compat-loki, so proper smjpeg pre-compiled library is included. And as I explained in a previous post, static and dynamic behave a bit different (due the statically linked stuff), and one of them can work better on some systems than the other one. So, IMHO I would provide both executable versions (they do not collide).
(In reply to comment #13) > Firstly, what about PPC dynamic version? Is there one? If it is, we should > probably put same RDEPENDs as with x86. If there isn't and the user set > 'dynamic', we should either die in pkg_setup or warn user there and don't > install the wrapper then. There is a patch for the dynamic ppc version available (dotsrc link, then heroes3-dynamic-1.3.1-ppc.run) but it obviously needs sys-libs/lib-compat-loki which is not available for ppc. And hence the libs in sys-libs/lib-compat-loki are all binary and for x86 and/or amd64 architectures only, it is impossible to make them work on ppc. Therefore I suggest that the dynamic is limited to x86 || amd64 only.
I have been doing some tests with a dual-head, quad Opteron workstation (with Gentoo amd64). Static binary worked with no problem. About the dynamic version of heroes, I copied the libsmjpeg-0.2.so.0 file from my Gentoo x86 laptop to /opt/heroes3, and it worked! Also, I have found a way to restrict the game to only one of the screens when dynamic version is used, using SDL_VIDEO_FULLSCREEN_HEAD variable. I'm going to upload x86 compiled (with -O2) libsmjpeg library.
Created attachment 190356 [details] New wrapper for heroes3 (dynamic) This wrapper takes into account SDL and Xinerama interactions for dynamic version of heroes3
Created attachment 190357 [details] libsmjpeg-0.2.so.0 (x86, -O2)
(In reply to comment #15) > (In reply to comment #13) > > Firstly, what about PPC dynamic version? Is there one? If it is, we should > > probably put same RDEPENDs as with x86. If there isn't and the user set > > 'dynamic', we should either die in pkg_setup or warn user there and don't > > install the wrapper then. > > There is a patch for the dynamic ppc version available (dotsrc link, then > heroes3-dynamic-1.3.1-ppc.run) but it obviously needs sys-libs/lib-compat-loki > which is not available for ppc. And hence the libs in > sys-libs/lib-compat-loki are all binary and for x86 and/or amd64 architectures > only, it is impossible to make them work on ppc. > > Therefore I suggest that the dynamic is limited to x86 || amd64 only. I think you could get the needed ppc libraries (mainly libsmpeg) using an ancient version of gcc. I have digged on loki-compat libsmpeg, and it is compiled with gcc/g++ 2.95.2 or 2.95.3, and it was generated from C++ code.
From bug 247961 I have learned that media-libs/smjpeg is being removed from Portage tree on September 19th if no package depends on it. So, a dynamic version of heroes3 should either depend on smjpeg or compile its own copy of smjpeg.
(In reply to comment #19) > I think you could get the needed ppc libraries (mainly libsmpeg) using an > ancient version of gcc. I have digged on loki-compat libsmpeg, and it is > compiled with gcc/g++ 2.95.2 or 2.95.3, and it was generated from C++ code. I don't think so. That means that a user has to install an ancient version of GCC just to compile a bunch of ancient libs just to run heroes3 dynamically on PPC. This is really asking for a little bit too much. I suggest not allowing USE=dynamic on PPC. Cheers,
Created attachment 269553 [details] lib-compat-loki-0.3.ebuild (with libsmjpeg-0.2.so.0 included) Well, I hope it's not too bad to resurrect this old bug. I have a suggestion to include pre-compiled libsmjpeg-0.2.so.0 (which is anyway needed to play the game) in, say, lib-compat-loki-0.3. I've done so on my computer locally, using the library from this bug, and that's much more convenient than putting it in place manually.
Created attachment 269555 [details] heroes3-1.3.1a-r4.ebuild (no more static version) Also, I made some (hopefully) improvements to the heroes3 ebuild, removing "dynamic" USE flag (doubt if there're still any gentoo system old enough to run static version; maybe that's just wrong, though), making the localization code more accurate and changing dependency on xdelta from 'versioned' to slotted. I don't know exactly if it was an useful work, but I decided to share it anyway.
Created attachment 269557 [details] New dynamic wrapper for heroes3 (more generic) I've changed the dynamic wrapper just a bit to make it look more generic.
Just tried to install this. The current ebuild fails to find the patch.dat file for loki_patch. Commenting it out lets the emerge succeed, the game runs, but fullscreen doesn't work, which from other comments sounds like one of the issues that the patch.dat resolves. I'm not sure where the file is supposed to come from. This is on amd64 multilib.
I'd be interested in an ebuild that didn't use the app-emulation/emul-linux stuff.
this would need to be updated for eapi6 and stop using games.eclass
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=010852d13e7f1c59bc11ab2e3efe806dfacebaf4 commit 010852d13e7f1c59bc11ab2e3efe806dfacebaf4 Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2019-12-08 21:13:32 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2019-12-08 21:13:32 +0000 games-*/*: drop last-rited pkgs Bug: https://bugs.gentoo.org/515926 Bug: https://bugs.gentoo.org/510960 Signed-off-by: Aaron Bauman <bman@gentoo.org>
