Creating an Initial Window from Standalone Haxe

Haxe
#1

A few days ago I thought, “Wouldn’t it be interesting to make a program using OpenFL where I don’t have to invoke the compiler with openfl test?”.

Since then I’ve been trying some different things, but without much success. The most promising-looking thing I’ve ended up with is:

./Source/Main.hx

package;

import lime.ui.WindowAttributes;

import openfl.display.Sprite;


class Main extends openfl.display.Sprite
{
	public static function main()
	{
		var init = new Main();
		
		var winAtt:WindowAttributes =
		{
		    allowHighDPI : true,
		    alwaysOnTop : false,
		    borderless : false,
		    context :
		    {
		        antialiasing : 2,
		        background : 0xFFFFFF,
		        hardware = true;
		    }
		    frameRate : 60,
		    fullscreen : false,
		    height : 300,
		    maximized : false,
		    resizable : true,
		    title : "Window Title",
		    width : 400,
		}
		
		init.stage.application.createWindow(winAtt);
	}
	
	public function new()
	{
    	super();
	}
}

./build.hxml

-cp Source
-main Main

-cpp Build

-lib lime
-lib openfl

Except I only seem to get segmentation faults from it.

What I’m trying to make for is a system where I can compile with haxe build.hxml and run with ./Build/Main, which will create a window as if I’d made the program with OpenFL normally. I’m doing this because I want to get more flexibility with the file system around my binary, and because I’m hoping I’ll be able to apply this to making additional windows from a running project.

The main sources I’ve looked through are this and this, I’m wondering if anyone might be able to direct me to more information?

Thank you.

#2

Please look at the “MinimalApplication” sample:

You should be able to lime create MinimalApplication somewhere if your libraries are up-to-date.

This does NOT use lime test, though is wired to use hxp test as an alternative to using a directory full of cross-platform shell/batch scripts.

You can haxelib install hxp and I’d be happy to help support this workflow more. If you extend openfl.display.Application instead of lime.app.Application then creating a window will automatically have an OpenFL stage attached at window.stage

#3

Alright, I think I’ve made some progress. There is something that I’d like to ask about though.

I didn’t want to fill up this post with a bunch of code fences, please see this repo for project files.

When src.window.Window extends lime.app.application, the render() function will use the colour value specified in it’s script. But, if src.window.Window extends openfl.display.Application, then the render function will use to colour value specified by Window.windowAttributes.context.background. The entire switch statement in render() can be commented out and the program seems to run without issues.

Would you be able to explain why this happens?

#4

Actually, nevermind. I should be alright with this.

Thank you very much! That’s exactly what I wanted.

1 Like