There is no release-build for Haiku since I do not officially support it yet. I had no time yet to check out if it still compiles and runs on Haiku but it should. Only the console launcher will work since the GUI launcher and IGDE uses FOX ToolKit and that does not seem to work with Haiku. The idea is anyways to use the native toolkit for Haiku builds but thatās future music.
The repository is at https://github.com/LordOfDragons/dragengine . Iāll add today a branch āfeature-haikuā which will be used to apply the necessary changes to run on Haiku.
Creating a build receipt should be a piece of cake. Call āscons archiveā to build archive files ready to unpack into a live system. Adding a ācustom.pyā allows to configurate some parameters like install directory in case I messed them up. There is also an āscons packageā which should produce Haiku ready packages but that has been me experimenting around with them so they could be incorrect. Donāt call just āsconsā as this will build and install which is most probably not what you want in a receipt.
Iāve done a first compilation check on a newly updated Haiku installation. I had to apply some fixes to get it compiling again. The changes are commited to the āfeature-haikuā branch.
There are some issues. Namely the network code detects the public IP using Linux ioctl(sock, SIOCGIFADDR, &ifr)
which seems to not exist under Haiku. Right now I changed it to throw an exception if used until I figured out how this can be done under Haiku.
Also the āBeOS Input Moduleā does not properly handle yet the non-capture use mode which means the DSTestProject.delga and DSVideoPlayer.delga will not be usable but the other examples should work. Here on my system it does not since I still have the unmodified old Mesa which is bugged.
That helped. The network module now compiles again properly. I commited some more fixes.
The one point Iām stuck at right now is the window resizing behavior. In the window is a BGLView which is resized too but the OpenGL inside is broken. It does not seem to scale but instead offsets the view. Since Linux and Windows does not show this behavior there has to be some peculiarity in how BGLView handles (or not handles) resizing.
Any ideas? How do you correctly handle resizing in BGLView?
Current Mesa 17 package contains some bugs that were fixed in Mesa 20 patchset. Resizing may be related.
You can try to periodically unlock GL, for example call UnlockGL; LockGL after swapping buffers. It may help with resizing problem. Also note that OpenGL calls can be done only from thread that called LockGL, if you want to call OpenGL in another thread, you should wrap it with LockGL/UnlockGL.
Doing UnlockGL()/LockGL() after swapping buffers helped.
Iāve now fixed also a few other problems so the āfeature-haikuā branch contains now a working state for haiku.
There is one thing I could not solve though and this is when I use fullscreen mode with BWindow.SetFullScreen(true) then I see no window decorator (correct) but the resize knob is still visible (incorrect). Any ideas how I can hide that resize box too?
I donāt know what you meman with āwindow border styleā. I can not find anything like this in the API documentation nor the Window.h or DirectWindow.h file.
I tried SetLook(B_NO_BORDER_WINDOW_LOOK) but the resize box is still visible.
B_TITLED_WINDOW_LOOK is what you need for a window with a normal titlebar and borders, but no resize knob (there is a resize cornder that does not cover the inside area of the window in any way).
You can also directly set the window type to B_TITLED_WINDOW when creating it. If you donāt have scrollbars/statusbar in your window, this gets rid of the knob completely, which is probably what you want here anyway?
That did the trick. I commited the fix so the known issues should be done.
So we could go to the next important part: haiku friendly installation directories.
Right now I use the following:
prefix = /boot/system : thatās the basic config parameter serving as base for others.
homeDirectory = /boot/home : figured out at runtime looking at $HOME environment variable.
${prefix}/lib : where the engine/igde libraries and modules are installed to.
${prefix}/develop/include : header files for developing engine/editor module.
${prefix}/data : shared data required at runtime (/usr/share under linux).
${prefix}/settings : system wide read-only configuration (hence manually edited)
${prefix}/bin : application binaries
${homeDirectory}/config/settings/dragengine : per-user configuration. read-write. include in backups
${homeDirectory}/config/cache/dragengine : per-user caches. read-write. can be safely deleted. exclude from backups.
${homeDirectory}/config/capture/dragengine : per-user game captures (screenshots, debug, temporary game created content). read-write. user decision if this is backup worthy.
??? (under linux /opt/delauncher/games) : directory where games (*.delga) files are installed to. read-write. maybe ${prefix}/delauncher/games ?
Can you please check if these path are playing along with how Haiku envisions directory structure? The last one is particular and kind of a speciality of the game engine.
EDIT: And yeah, of course, how to register āmime typesā, hence, how to define file types and the default actions to open them.
if you want system wide user installable games that would be in ($prefix)/settings/$(app)/games
iād put builtin games or packaged in HPKG in $(prefix)/data/$(app)/games
Finally i donāt really get the usage of /usr/share
Thatās interesting. I would have guessed $(prefix)/settings is for configuration options hence not large files. installeable games can be possible multiple GB large depending on what it is.
$(prefix)/data/delauncher/games sounds more reasonable to me.
Concerning the /usr/share this is a linux thing and more of a āheritageā thingy back to unix days. By definition executable application content goes into /usr/lib while non-executable application content goes into /usr/share. Iām doing it the same here. All module libraries and their manifests are under /usr/lib/dragengine/modules/* while extra data they require (like shaders in opengl or script files in dragonscript) is located in /usr/share/dragengine/modules/* . So if haiku does not make such a distinction these two can be the same directory without problems.
Iāve adjusted now the path so it installs games now into $(prefix)/settings/delauncher/games.
Also commit some more fixes and some preparation for adding application icons later on. right now there is no use for this as the console launcher has no icon.