Distribution options

#1

I was wondering what the options are regarding distributing a game.

Right now my game compiles to JS and runs in a browser window pretty well. I’m finding that is very useful for getting feedback by sticking it on web server and inviting people to have a mess around.

It also compiles and runs in hashlink really well.

Ultimately though I’d like to distribute it as a binary for various platforms. Do you just include hashlink as part of the distribution? Or is there some other process for producing a distributable binary?

#2

Hello!
HashLink can be compiled to C languge (thanks to Dual Compilation https://hashlink.haxe.org/#dual-compilation), and then generated C code can be compiled into executable file.
Unfortunately i can’t help you with this, since i’ve failed with the task of compiling C code (i don’t have such expirience and can’t figure out what should be done to accomplish it)/
Maybe someone else can help us with this task.
Btw, there https://github.com/Yanrishatum/HLCC to compile C output of HashLink, but i’ve also failed to use it :frowning:

#3

Thanks for the advice.

I tried using the -cpp target but it seems the heaps library doesn’t work with it. I was getting errors about missing haxe.GraphicsDriver or haxe.GLTypes. I tried using options like -D usegl or -D usesys but never quite got it to work. I couldn’t find any reference in the haxe source code to those classes either so are they yet to be implemented?

Looking at the Hashlink dual compilation stuff is interesting. Seems it dumps out pretty much the entire source of hashlink along with your own code as C. Are there any instructions on how to then compile this code on Windows/OSX? The example on the website appears to be for Linux.

#4

Yes, Heaps currently doesn’t work with cpp target. There is attempt to make it work with Lime, but it’s in very early state:


#5

So I tried the hashlink C option quickly on my macbook and get:

gcc -O3 -o myapp -std=c11 -I out out/main.c -Lhl
In file included from out/main.c:120:
out/hxd/fs/ConvertTGA2PNG.c:146:1: error: ‘case’ statement not in switch statement
case 2:
^
In file included from out/main.c:129:
out/hxd/fmt/hmd/Writer.c:26:1: error: ‘case’ statement not in switch statement
case 2:
^
In file included from out/main.c:132:
out/hxd/fmt/fbx/Parser.c:473:1: error: ‘case’ statement not in switch statement
case 8:
^
In file included from out/main.c:156:
out/haxe/xml/Parser.c:694:8: error: duplicate case value ‘9’
case 9:
^
out/haxe/xml/Parser.c:79:8: note: previous case defined here
case 9:
^
out/haxe/xml/Parser.c:703:8: error: duplicate case value ‘10’
case 10:
^
out/haxe/xml/Parser.c:80:8: note: previous case defined here
case 10:
^
out/haxe/xml/Parser.c:810:8: error: duplicate case value ‘13’
case 13:
^
out/haxe/xml/Parser.c:81:8: note: previous case defined here
case 13:
^
In file included from out/main.c:285:
out/format/mp3/Reader.c:151:1: error: ‘case’ statement not in switch statement
case 1:
^
In file included from out/main.c:305:
out/haxe/format/JsonParser.c:62:1: error: ‘case’ statement not in switch statement
case 9:
^
out/haxe/format/JsonParser.c:63:1: error: ‘case’ statement not in switch statement
case 10:
^
out/haxe/format/JsonParser.c:64:1: error: ‘case’ statement not in switch statement
case 13:
^
out/haxe/format/JsonParser.c:65:1: error: ‘case’ statement not in switch statement
case 32:
^
In file included from out/main.c:306:
out/hxd/res/Image.c:390:1: error: ‘case’ statement not in switch statement
case 2:
^
In file included from out/main.c:423:
out/h3d/mat/Texture.c:493:1: error: ‘case’ statement not in switch statement
case 2:
^
13 errors generated.

So I’m assuming the C generated by hashlink isn’t 100% compatible with my version of gcc

gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

If I get chance I’ll try tidying up those errors manually and see if it builds.

#6

After manually fixing up the errors (probably incorrectly as cutting pasting unfamiliar optimised C around is rarely a safe bet) I did get it to compile with:

gcc -O3 -o myapp -std=c11 -I out out/main.c ~/work/haxe/hashlink/fmt.hdll ~/work/haxe/hashlink/ui.hdll ~/work/haxe/hashlink/sdl.hdll ~/work/haxe/hashlink/openal.hdll ~/work/haxe/hashlink/libhl.dylib

Except running that gives me:

./myapp
haxe.xml.XmlParserException: Expected attribute name at line 2 char 5

Which is odd as I wouldn’t have thought the XML parser would need invoking at all in my dummy app. After that it sits at 100% CPU usage till I force quit it.

#7

After some debugging with LLDB I realised it was using the XMLParser to load some fonts for my UI. After stripping that out. Doing:

haxe -m Main --hl out/main.c -lib heaps -lib hlsdl

Manually fixing the switch statement errors again. Then rebuilding the binary it actually works. Which is pretty cool!

I suppose my next question is how do I help patch the problem with the C code that is generated so that I don’t have to manually fix it up every time I rebuild the app?

#8

I’ve now managed to get this to build for windows using the following commands:

haxe --main Main -hl out/main.c -lib heaps -lib hldx -resource res/level.json@level
cl /I C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\include /I out out\main.c C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\directx.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\fmt.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\hl.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\libhl.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\mysql.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\openal.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\sdl.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\sqlite.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\ssl.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\ui.lib C:\Users\User\Documents\hl-1.7.0-win\hl-1.7.0-win\uv.lib

Works pretty well. I tried using SDL instead of DirectX but my graphics card doesn’t have the right OpenGL support.

#9

Cool!
i need to do it too

#10

Ok it seems the weird C errors I was getting on OSX were due to using an old version of Haxe 4. Using latest Haxe 4 release seems to have cured those. Just got some weird performance issues in the hxd_clipper algorithm that don’t seem present in the Windows build.

#11

Would be nice if heaps would support something like minimingw, which is a portable cpp compiler distribution in a haxelib.

In normal Haxe, if you target cpp and use this libary, it produces executables.

#12

@patricknr yes, the C compilation error was due to a regression in HL/C output, we fixed that recently.

Regarding

I’m curious and surely would like to know more :slight_smile:

#13

On my macbook pro I get about 40% cpu usage for a basic scene using the intersection method of IPolygon. (this is compiled output from HL/C). Using the Instruments tool it seems almost all of the CPU time is spent in hxd_clipper.

Bizarrely the same identical code running on a slower windows 7 thinkpad (again, compiled HL/C) runs at about 4%. Not had chance to profile it.

My guess is maybe CLANG is doing something weird to the generated C. Or that the Microsoft compiler is doing some crazy optimisation. Or maybe the binary on windows 7 is 32 bit and the binary on my macbook is 64 bit.

Either way it is “odd”. If you want anymore info on the problem to investigate it let me know.