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
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++
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
Might be DCE?