Error running HaxeFlixel on windows with dev branch of lime + openfl

Any clues?

OpenFL 4 removed the graphics.drawTiles API (in favor of the more stable Tilemap API)

We wrote a new GL renderer for the introduction of OpenFL 4, which means that the old drawTiles code is not even something we could put behind a define. HaxeFlixel relies on drawTiles, and has not updated to another API.

I’m open to working with anyone interested in creating a Tilemap-based version of HaxeFlixel, we can improve Tilemap to support whatever HaxeFlixel needs. There are other approaches (such as custom GL and software renderers for HaxeFlixel) but Tilemap might be the lowest maintenance approach long-term

I’m running on my own branch which updates HaxeFlixel to be compatible with latest version of OpenFL: https://github.com/gamedevsam/flixel/tree/RenderUpdate2

My game compiles to Flash and HTML5. Neko and C++ crash instantly. Neko doesn’t even give a hint as to what may be happening, but the C++ target spits out the call stack attached in the image above.

I’ll be testing HaxeFlixel demos later when I get home to see if the issue is related to my code or recent changes to HF / OpenFL.

Hey, awesome! I just got Mode running on Neko, here :smile:

I’ll try C++

Here’s a small pull request with compile fixes I needed to make with the latest OpenFL/Lime development versions.

I have a feeling the static initialization order fix I made today (for CFFI methods) may have resolved the problem you had, but let me give it a try

Working in C++ :success:

I think it’s something with my project because I’m still getting the crash with your latest changes. I’ll reach out to you via Slack so we can troubleshoot later.

I don’t understand why this is happening. Mode demo runs on my machine, but my app keeps crashing.

The error stems from this generated C++ code:

void NativeHTTPRequest_obj::threadPool_onComplete( ::Dynamic state){
            	HX_STACKFRAME(&_hx_pos_0ebc94bde832cf0c_389_threadPool_onComplete)
            	HX_STACK_ARG(state,"state")
HXLINE( 389)		 ::Dynamic(state->__Field(HX_("promise",9b,cd,e9,f7),hx::paccDynamic))->__Field(HX_("complete",b9,00,c8,7f),hx::paccDynamic)( ::Dynamic(state->__Field(HX_("result",dd,68,84,08),hx::paccDynamic)));
            	}

The call stack when the error occurs:

Called from hxcpp::__hxcpp_main
Called from ApplicationMain::main ApplicationMain.hx line 78
Called from ApplicationMain::create ApplicationMain.hx line 110
Called from lime.app.Application::exec lime/app/Application.hx line 225
Called from lime._backend.native.NativeApplication::exec lime/_backend/native/NativeApplication.hx line 154
Called from lime._backend.native.NativeApplication::handleApplicationEvent lime/_backend/native/NativeApplication.hx line 195
Called from lime.app._Event_Int_Void::dispatch lime/_macros/EventMacro.hx line 101
Called from lime.system.ThreadPool::__update lime/system/ThreadPool.hx line 181
Called from lime.app._Event_Dynamic_Void::dispatch lime/_macros/EventMacro.hx line 101
Called from lime._backend.native.NativeHTTPRequest::threadPool_onComplete lime/_backend/native/NativeHTTPRequest.hx line 389
Critical Error: Uncatchable Throw: Null Object Reference

Patched in the Lime dev builds :slight_smile:

Might be DCE?