I hope to make one implementation (in Heaps 3D) for upcoming apple glasses and facebook glasses platforms, but also to existing ones - like Hololens and Magic Leap.
To reach multiple current platforms on desktop and mobile - is that to compile the haxe code into a file that can run with OpenGL…?
I have previsouly mainly done mobile app development, But since some of the app I am currently developing are game related, I’d like to potentially put this in a game engine like Heaps Game Engine (And use ‘OpenGLView’ on mobile). And on the new upcoming glasses - to support them as well, as quickly as possible.
How to go from Heaps 3D and run the game content on different platforms. And what are your tips on supporting these glasses platforms?
Side questions, using Heaps. Should I compile the code to a certain programming language - And then on that platform, create a native game project. Then call the game from the native project.
Or should the game in haxe be packaged directly into a game file?
How to distribute the heaps game on different platforms?
And by the way, I think this should have been posted on the Heaps game engine forum: https://community.heaps.io
Armory 3D might be worth looking into because it uses Kha backend which is super portable. Tho I’ve not played with this yet so I can’t give you any tips but you could ask at https://forums.armory3d.org/
If you can get haxe code executing OpenGL draw calls on their own (or Metal for that matter) you’re in a good place – we can setup a native context using whatever build tools apple release and then call into haxe each frame to do the actual drawing (I’ve released a few projects using this approach). This is same approach we took for the WatchOS project just with an added graphics context (Missing hxcpp.h in cpp compilation - #8 by Lelelo1)
For OpenGL and Apple: Apple is of course deprecating OpenGL but I’ve had good success using MetalANGLE to translate OpenGL calls to Metal
Cool!
My understanding so far: A Haxe project using Armory 3D is created containing the actual game/content.
An entry point is created in haxe which uses attributes, like you showed me before:
@:build(HaxeCBridge.expose())
class GameExpose {
public static function startGame() {
// init
// run (from apple glasses for instance)
}
}
Is it that it? Will the game content, for example - if the game content is just a character doing a simple animation - run and show on screen for all platforms that have the needed graphics library/renderer support (OpenGL, Metal etc)?
The critical thing ensuring the native graphics context is used by the haxe code
So for example, OpenGL has this global-state approach, in the swift code for an OpenGL view you have a draw() function where it first binds the graphics context for the view and then any calls to the gl* functions will draw to that context. So I call haxeApp_draw() inside that function and I’m safe to call opengl from there
Metal is better in this regard because it doesn’t use global state for graphics contexts. You could pass in a CAMetalLayer reference inside your startGame (maybe as a void*) and give that to Armory to use and then you’re all good to render whenever you like – but passing this to Armory may take some hacking around in Armory source
I don’t know how Metal requests frames but you may also want to expose a draw() so you can sync with any native render loop
It took some effort and I did not have the time until now, but I installed the Armory3D - which gave me the following options
Only html5, worked - the rest produced error when building on my mac. The html5 gave a black screen.
I expected to see the cube which is present when opening blender
