Normally you would load your resources from the same directory as your binary, but when building for Mac, you will have to do it slightly differently. Instead of loading your res from .
, your should load it from ../Resources/
.
Game.app
|_Contents
|_Info.plist
|_MacOS
|_run.sh
|_hl
|_hlboot.dat
|_Resources
|_res.pak
|_Frameworks
|_*.dylib
|_*.hdll
You should be able to to find the full xml online, (or just copy it from another .app) The following is what I got working.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>run.sh</string>
<key>CFBundleName</key>
<string>Game Name</string>
<key>CFBundleGetInfoString</key>
<string>Made with Haxe/Heaps</string>
<key>CFBundleIconFile</key>
<string>icon.png</string>
<key>CFBundleIdentifier</key>
<string></string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>0.1.0</string>
<key>CFBundleSignature</key>
<string></string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>CFBundleSupportedPlatforms</key>
<array>
<string>MacOSX</string>
</array>
</dict>
</plist>
We will also be using run.sh to run instead of running hl directly.
#!/bin/bash
BASEDIR=$(dirname "$0")
cd $BASEDIR
export DYLD_LIBRARY_PATH=../Frameworks
./hl
This is to help set the running directory + also set the dylib path.
Rename your game.hl to hlboot.dat and copy it to MacOS
. Alternatively you could just specify the name in the run.sh.
There are 2 ways to get hl and the required libraries. The first way is to get it from github releases directly. The second way is to build hashlink ourselves by following the instruction on hashlink github.
First, copy hl
to MacOS
.
For the libraries, we will put them in Frameworks
.
Copy all hdll
and also libhl.dylib
to Frameworks
.
Not all hdll are required. For heaps, the basic required ones are
fmt.hdll
openal.hdll
sdl.hdll
(if you are using sdl)ui.hdll
uv.hdll
For each of them, there will be some dylib that are required.
libpng16.16.dylib
libturbojpeg.0.dylib
libvorbisfile.3.dylib
libvorbis.0.dylib
libogg.0.dylib
libz.1.dylib
libSDL2-2.0.0.dylib
libopenal.dylib
libuv.1.dylib
Note that the dylib names need to be exactly what is required or it will not work. These names work as of now but it may change in the future with new releases of hashlink etc.
You can find out what the names of each of the dylib needs to be by using otool
recursively.
otool -L fmt.hdll
fmt.hdll:
fmt.hdll (compatibility version 0.0.0, current version 0.0.0)
libhl.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/libpng/lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
/usr/local/opt/jpeg-turbo/lib/libturbojpeg.0.dylib (compatibility version 0.0.0, current version 0.2.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/local/opt/libvorbis/lib/libvorbisfile.3.dylib (compatibility version 7.0.0, current version 7.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
Although it looks like we will only need libvorbisfile.3.dylib
, if you run otool -L libvorbisfile.3.dylib
, you will realised that the other dylib
are required by vorbisfile.
Do this and you can figure what you need, and the specific name that the file needs to be.