"Headless" server-side mode?

Haxe
#1

Is there a way of compiling openfl in a “headless” mode for running as a dedicated server?

So the ability to compile and run an openfl native app minus graphics, sounds and input.

A lot of my general code is still dependent on some openfl niceities like openfl.Assets, openfl.utils.* and openfl.geom.* etc but I have branching code depending on whether it’s running as a dedicated server, or with a visual frontend.

Ideally I’d like that branching to be compile-time with something like…

#unless headless
    render_scene();
#end

(and of course for execution to be possible on a box without a gui)

So in the case of a headless build the missing apis would never be linked against. (I would presume they would either be missing, throw exceptions, or be non-functional in a headless build?)

If the answer is a definite no, then I suppose I could look at simply forking and cutting those bits out of openfl (and lime?), or perhaps separating the bits I need, but that sounds possibly a little bit awkward (and cruel :/)

1 Like
Purely command line native program
#2

That’s what Lime is for, right?

Lime provides its own asset handling, geometry classes, utility classes, etc. The difference is that graphics are optional.

#3

If we run without a window, then I think that OpenGL calls would fail, so it would not be possible to strictly run OpenFL as-is in a headless mode.

On the other hand, I do use OpenFL and Lime functions from things like the command-line tools, there are ways to include it directly. However, if you want, the cleanest route may be to use Lime, or perhaps to use OpenFL “next” but to override the Application class so that you can disable the default create() method which generates a window.

I have not extensively tested Lime without a window, but the idea is that this would be supported. Things like lime.Assets, lime.math.* and other classes should not need the window at all to work. Interested to hear how we can help :slight_smile:

#4

Also, if you wanted to toy with something that’s a little automatic, you might look adding #if !headless to the Lime Application class where it creates a new Window, it’s possible everything would work, as-is, you just wouldn’t get render events or update events, but maybe that’s alright.

The other method is illustrated by the Lime tools, which include Lime (and could include OpenFL as well) but are strictly CLI, and not a windowed application

#5

This thread is now seven years old. Are there any new developments which would allow OpenFL or Lime to run headless? I am exploring the possibility of having Away3D on server to facilitate model conversion.

#6

Wouldn’t this still work?

Though it looks like nowadays you’ll have to override createWindow() instead of create().

1 Like
#7

Thanks Joseph; I should have read more carefully before asking.
My current situation is I and my associates have done some experiments using NodeJS and Hashlink but have had difficulty compiling so far. What server side target would you all recommend to use with OpenFL/Lime?

#8

I’m afraid I don’t know about server-side targets, but I can tell you that OpenFL still requires a window, so you should use Lime on its own.

Oh, and HashLink support has improved with the recent 8.0.0 release, but it might not be all the way there yet. I think C++ might be the best-tested target, though most of that testing is of course client side.

#9

Thanks very much. I’m certainly on an adventure with this one! :slight_smile:

#10

I’m making some progress with this. Interestingly someone on Discord was trying similar things.
For the record, I was able to compile to hashlink with this as a base model:

package;

import lime.app.Application;
import lime.graphics.RenderContext;
import lime.ui.WindowAttributes;
import lime.ui.Window;

class Main extends Application {
	
	
	public function new () {
		
		super ();
	}
	//must have a main function if you get an error from the macro in ApplicationMain.hx when compiling. Omit if you really need no window to be created.
	public static function main() {
		var app:Main = new Main();
	}
	override public function createWindow(attributes:WindowAttributes):Window
    {
        trace("Hello Headless World");
        return null;
    }
}

So I’m now trying to use nodejs. It seems that target has become out of date however, as it expects the “nodejs” library instead of the “hxnodejs” library as suggested on the main Haxe site. I tried swapping it out using a Lix alias but that causes an error “/Users/alland/haxe/versions/4.1.5/std/sys/thread/Deque.hx:26: characters 8-52 : This class is not available on this target”.

Is updating the NodeJS support on the horizon? Any suggestions as to fixing my current situation?

#11

If I had to guess, it’s these imports from a few different files in Lime that are causing this error:

#if sys
#if haxe4
import sys.thread.Deque;
#elseif cpp
import cpp.vm.Deque;
#elseif neko
import neko.vm.Deque;
#end

Maybe it would help to add target.threaded in that haxe4 condition?

#if sys
#if (haxe4 && target.threaded)
import sys.thread.Deque;
#elseif cpp
import cpp.vm.Deque;
#elseif neko
import neko.vm.Deque;
#end

It’s unlikely that I would fix Node.js support myself. I can’t speak for other contributors. However, I would certainly be willing to merge a PR, if you figure out what’s necessary to fix it.

#12

I’d be totally willing to contribute a PR if I figure this out. I’m a total noob at this point. :slight_smile: Thanks for the suggestion—I will report back soon.

#13

OpenFL app that runs in the background Its certainly possible to run OpenFL without a window already. I am also working on a truly headless implementation of OpenFL for more optimal server side usage but that is TBD.

#14

After fixing the Deque thing, there are a host of errors generated. Therefore abandoning nodejs for now. Hashlink seems to work better at this time.