Yeah, you’re right.
No, you also have to archive (build) with bob.jar before reloading via HTTP
How do you make your editor aware of the haxe defold library so it can do code prediction and checking? Not too familiar with Haxe, but intrigued by the idea of having the capabilities of a statically typed language.
2 Likes
Hmm, it should just work with VS Code and the Haxe extension from its marketplace, because it picks up the .hxml file and uses that for completion.
There is a minor(ish) issue with building to Lua through VS Code with current Haxe versions, since it tries to build through the haxe’s compilation server and that is bugged in the current Haxe releases. You can avoid the bug by setting "haxe.enableCompilationServer": false in your VSCode workspace settings. (I really should add that to the README).
But that’s unrelated to the completion and other IDE services, that should just work. Could you give me more info (at least a full screenshot of the editor window 
)?
3 Likes
That would be quite annoying. Is there a plan to add something like
http://localhost:8001/post/@resource/build-and-reload in the Editor?
1 Like
I only had the one file open with vscode, which was the problem. Opened it up from the projects root, and it picked up the build file. Took a minute or two for the code completions to be available, but they’re there now. Thanks!
2 Likes
what to do if i want to use other lua libs in a haxe project?
Thanks a lot for making this library. I’ve been testing it out the past few days and I really like it!
I’m used to static languages and had a bit of trouble adapting to lua when a project gets bigger than a few scripts. This makes it a lot easier for me.
1 Like
hello i want to try hxdefold and i downloaded the side scroller example i get an error saying: /main.luaThe file ‘/bit32.lua’ could not be found.
Yeah this is a known issue. The workaround is to create an empty bit32.lua file in your project root.
Hi. I’m checking out the Haxe and the Hxdefold also. It looks like a perfect solution for type-safe coding. And It looks also perfect for creating reusable code library creation with Defold and other engines. I think, creating a game with the Haxe language on Defold really makes sense. I’m planing to follow this path. But I have some issues that I want to mention.
1- The GitHub installation instructions is not working. It says the luv is missing. People also mention missing files. I think the issue is the build.hxml instructions.
I have done some research and have learned some instructions to target the specific Lua version. In my system I only have Lua 5.1.4 installed. I don’t have any other library. I did not follow the Haxe documentation about the Lua. Because it wants to install additional libraries. But I want vanilla lua for defold right? Especially the 5.1.4 version and LuaJit-2.1.beta. So I have entered the following build parameters on my Hello World haxe project.
--lua bin/haxe_build.lua
--main Main
# Enable JIT
-D luajit=2.1
# Force not to use additional libraries for Haxe itself
-D lua-vanilla
# Select Lua version
-D lua-ver=5.1
# Enable analyzer optimization
-D analyzer-optimize
# Set the source directory
-cp src/
With these parameters, I can run Hello World app on the terminal with just
lua .\haxe_build.lua
As you can see I can define the exact Lua version for the Haxe compiler. Haxe compiles my codes as vanilla. And does not throw any missing library error on my Hello World project. In default it was throwing missing library error. The hxdefold requires additional libraries like luv or bit32, right? This means that it is not vanilla lua after the build. I have seen some parameters on the extraParams.hxml. But I’m not sure if is it working or not. I think my parameters should be in hxdefold. I wish to add and get build. But I have just started using Haxe. Your project is too complex for me right now. Maybe after a while, I may do it. Right now it is impossible for me with the lack of information.
2- The Second issue is about the Haxe for me. I have noticed that Haxe generates lots of code. Can we be sure about the performance of our game? I mean, are there gonna be any performance differences in coding between Lua and Haxe for the game runtime?
2 Likes
This is a known issue, and the workaround still is to create empty files luv.lua, bit32.lua, etc at the project root. I will check if your choice of parameters resolves this, thanks for the info!
Not really, the only issue is that some require statements are generated which causes the Defold builder to look for these files in the project root. The empty files seem to satisfy it.
This is irrelevant, a local lua installation is not needed, neither to compile Haxe to lua, nor to build Defold games 
You don’t need a main. The output lua file is just a collection of modules that are called from the Defold scripts.
Actually the compiled lua file needs to be named main.lua and be at the project root. The scripts import it with this name, and this is currently hard-coded. And whether or not you can run the generated file is also irrelevant, since the script itself does nothing. What matters is that Defold can compile it.
If you started your project using the recommended haxelib run hxdefold init you should have a build.hxml that prepares it properly.
The short answer is no, to my knowledge there aren’t any published games using hxdefold out there so we don’t have any proof. Having said that though, if you examine the generated code I think you’ll find that the added overhead is quite minimal. The “lots of code” you are referring to is mostly the standard library: implementations of lists, strings, and so on. The code that actually gets executed for a game object script will be almost identical whether you write it in Haxe or Lua 
I can imagine how the build process may be confusing at first, especially since the needed build.hxml commands aren’t documented anywhere currently apart from some example projects 
I definitely need to write better documentation, hopefully with the upcoming v2 changes. For now I suggest to start with haxelib run hxdefold init, or to study one of the example projects. And of course drop us an issue if you have any questions!
3 Likes
I will also add that this is what your build.hxml might look like, with some comment explanations:
###########################################################
# project files
###########################################################
--class-path src
# recursively include all Haxe sources in the source diretory
# we need this to prevent DCE from removing our script classes
--macro include('', true, null, ['src'])
###########################################################
# hxdefold
###########################################################
# enable hxdefold Haxe library
--library hxdefold
# override to specify another Defold project root directory
-D hxdefold-projectroot=.
# override to specify another output directory for generated script files (relative to the project root)
-D hxdefold-scriptdir=scripts
###########################################################
# output
###########################################################
# enable full dead code elimination
-dce full
# enable static optimizations
-D analyzer-optimize
# where to generate Lua output
--lua main.lua
# generate some empty files needed by the Defold lua compiler
--cmd touch bit32.lua luv.lua socket.lua
2 Likes
Since the performance question came up, I decided to rewrite the Bunnymark example in Haxe!
Original Bunnymark demo: Bunnymark 1.0
Haxe version of Bunnymark demo: Bunnymark 1.0
4 Likes
There is a noticable difference when testing “Bunnymark with a single update()” version. In the Haxe version I get 20k bunnies at ~50FPS while in the original version I start to see a drop in FPS around 23k bunnies. So there will for sure be an overhead using Haxe but it is likely not significant for most usecases.
3 Likes