Okay, I successfully ported eduke32 (http://www.eduke32.com) so that the Duke also reigns also on Haiku. So far the game runs without problems, but some issues are still open (at least for me :-)).
First of all I used “setarch x86” before compiling. The game allows compiling against SDL1 or SDL2, but since sdl_mixer is not available on Haiku for SDL2, I used SDL1. Also with arch x86 I can install two different OpenGL/Mesa renderer (swrast and swpipe). And I am testing on my dedicated Haiku installation (Intel i7) and under VMware Fusion (with VMware tools installed) on my Intel i5 MacBook.
Now my questions:
SDL Mixer not available for SDL2. Is this just missing or is there some blocking issue which prevents SDL2_mixer for Haiku?
SDL_mixer for SDL1 is compiled with timidity support, but timidity itself seems unavailable in HaikuDepot. And also during game init SDL_mixer issues an error stating that the following files could not be opened: /etc/timidity/freepats.cfg, /etc/timidity/timidity.cfg and /etc/timidity.cfg. Would this be the correct path for timidity files on Haiku?
Regarding OpenGL, if swpipe is installed, the game init fails with “BLocker error” referencing issue 6400. With Swrast the game runs fine. After digging around issue 6400 I am not sure if that is really an error I can do something about that, but I wonder why the two renderer behave differently here.
Running under VMware two additional issues came up:
4) Using swrast the game is dog slow. Compiling the game without OpenGL support solves this.
5) The games fails to reach main menu when music support is enabled, the game runs with SFX enabled without problems.
So how good is the support of the virtual hardware (for sound I needed to install the open sound package)?
This recipe using libsdl2_mixer too, so you need to compile it first with haikuporter to be able to build eduke32.
It is also possible, that there will be other dependencies too which currently not available for your arch in the depot, so you should compile them too first with haikuporter.
Be careful to build the dependencies for SECONDARY_ARCH on gcc2h (it is like:
The lack of SDL2_mixer is just because no one uploaded a package. It should work just fine if you build it yourself with haikuporter. However, if the game supports SDL1 and OpenGL disabled, I think it makes more sense to use that in the current situation. We don’t have hardware acceleration for OpenGL so it rarely helps to use it if you can do without. And the SDL2 port isn’t very mature yet.
For bug #6400, there is nothing you can do on the application side. This is a hack that was introduced in mesa to get Quake 3 running IIRC, and we should probably remove it from the OpenGL code.
For timidity, I don’t know what these files are. If they are supposed to be settings files editable by the user, they should go in home/config/settings or system/settings.
Hm, I completely missed that. It seems that my search script for haikuporter does not work. Why is the port located in games-fps and not in games-action, like Quake3?
[rant]
I mean why on earth did they invent haiku porter at all? Why not use a working system as base, like homebrew, Mac ports, or whatever, with a mature data base and a working search algorithm?
[/rant]
Looking at your patch file I noticed that you took a “short cut” in kplib.cpp inside the file handling part. I don’t know if your version works correctly in all cases. I have a working copy here and I plan to submit a patch for that later.
I let for others to solve things wha i alone cannot.
Rant: what the difference between hp and homebrew?
HB also cannot Patch automagically the sources, and the dependencies also predefined, so whede is the difference?
Actually hp does using the sys provided stuff, HB provides own Set to accomplish the same, afaik.
We are organizing our ports the same way as gentoo portage, which also gave some inspiration to beports (at the early days when it was called that).
We did consider using some other tools, but it was not that easy. Obviously none of them is able to generate hpkg files. Their patch sets may not be enough to get things going on Haiku, so we would have to rework a lot of things anyway. And it is not necessarily easy to collaborate with people maintaining other tools, when they have no interest in our little OS.
As for the search in HaikuDepot (and many other aspects of package management), we are using libsolv for this. It is the base of OpenSUSE’s package manager, and it works just fine for me, and apparently everyone else here. So I would think the problem is not the search algorithm.
@extrowerk, @PulkoMandy
I didn’t want to critize or blame someone. I am used to BSD ports and Mac Ports, where I know how to update and search the ports tree. That eduke did not show up is entirely my fault, or better my own search script.
And yes, I think you should question the Gentoo way of things. For example using FreeBSD ports, eduke32 is located next to Quake and Doom below a single category of “games”, which makes things easy.
And BTW why is there a search algorithm for haikuporter at all? I mean, why not use the query feature of Haiku for that? Like defining a new mime-type for the recipe files and putting the summary and description information into attributes? Then we could use Tracker for searching specific software.
Alexco, i better care about to get stuff work, not about, where is it, sorry.
Git cannot handle the extra attributes, and hovewer it would be possible to initialise the required indexes when haikuporter scans the tree, but theese indexes wouldn’t be indexed automatically, as on BFS de fefault is to index only the minimal stuff. Then the user can add new, but not everybody would do that.
That script can search in the file content too, some package provides plenty different stuff, so searching or query for filename wouldn’t be useful.
But i got a script what using BeFS query to search for recipes, but just in file-name, to see if a stuff ported already or not:
query name="*$argv*.recipe" -v /Ports/
It is for fish shell, maybe it would work withbash too ,maybe you need to change a bit.
I am trying to compile eduke32 on 64-bit and I am getting this error:
~> haikuporter -j4 eduke32
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
----------------------------------------------------------------------
games-fps::eduke32-20200907
/boot/home/haikuports/games-fps/eduke32/eduke32-20200907.recipe
----------------------------------------------------------------------
Skipping download of source for eduke32_src_20200907-9257-93f62bbad.tar.xz
Skipping checksum validation of eduke32_src_20200907-9257-93f62bbad.tar.xz
Skipping unpack of eduke32_src_20200907-9257-93f62bbad.tar.xz
Skipping patchset for eduke32_src_20200907-9257-93f62bbad.tar.xz
Cleaning up temporary directories ...
requires "haiku == r1~beta4_hrev56578_59-1" of package "haiku_devel-r1~beta4_hrev56578_59-1" could not be resolved
requires "eduke32 == 20200907 base" of package "eduke32_debuginfo-20200907" could not be resolved
Error: unable to resolve required packages for build for eduke32-20200907
Error: dependency-infos:
Error: /boot/home/haikuports/repository/eduke32-20200907.DependencyInfo
Error: /boot/home/haikuports/repository/eduke32_debuginfo-20200907.DependencyInfo
Error: /boot/home/haikuports/repository/eduke32_source-20200907.DependencyInfo
Error: repositories:
Error: ['/boot/home/haikuports/packages', '/boot/system/packages']
Error:
~>
Also how do I load the high resolution packs? Should the autoload folder go in the folder where duke3d.grp is?
I edited /boot/home/config/settings/eduke32/eduke32.cfg and set NoAutoLoad = 0. Is that correct?
Seeing something simular here on 64bit while trying to update the quazip1 package (did a full-sync before, only updated gettext packages).
Works fine on 32bit?
EDIT in my case it seemed there was a left-over package for hrev56578_22 in system/packages, moving that out of the folder solved it here.