ZGameEditor forum

Let's roll back a bit. Could there be problems with the size of the variables I changed in this commit ? Those changes look good so I don't think they are the problem. It seems it is possible to debug apps with jni native code from Android Studio: https://stackoverflow.com/questions/32413593/how-to...

Looks like a memory problem again. The vec3 memory is not initalized for some reason.

With audio disable, it is still crashing after a random number of frames (currently 25 to 78). But I like the idea. Are there other functions that I could totally disable like that without breaking anything? (other than Platform_GetCpuCount and ZClasses.Tasks.Enabled :lol:) With audio off and tasks...

It is strange that the log shows that it manages to render over 40 meshes before crashing. I have no idea why it would crash after working so relatively long. You could try disable audio in case the audio thread is complicating things: ZPlatform_Android.inc procedure Platform_InitAudio; insert exit ...

We need to be able to see more of the callstack when it crashes.

Try this:

Inc zzdc_globalopt.inc

At the end add these lines

Hi, FL Studio doesn't know ahead of time the waveform for the whole song. But you can export the project from FL Studio to a wav-file first and then import that into Edison. Then capture the Edison window to ZGameEditor. In the attached zip there is a FL Studio project that demonstrates the concept.

Still only that line with "SYSTEM_$$_WAITFREE_VAR" which I assume is some kind of threaded memory issue. I wish it would show more info. I assume you still have those cthreads and cmem additions in the dpr-file. Maybe you could try your full Omeganaut project again and see where that crash...

It hangs on this line: RunObj := Env^.CallStaticObjectMethodV(Env, RunClass, Mid, nil); Maybe CurVM or Env variables are not correctly initialized for the 64-bit architecture? Try changing to RunObj := Env^.CallStaticObjectMethod(Env, RunClass, Mid) (use CallStaticObjectMethod instead of CallStatic...

Based on this page: https://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial It seems some units may be needed for multithreading to work with Freepascal. Please try to insert the units that they suggest. In ZzDC.dpr uses {$ifdef android} cthreads, cmem, {$endif} ZClasses in 'ZClasses....

What version of the Freepascal compiler are you using? Just wondering if the crash in the threaded code could be a problem with the Freepascal memory manager for Android 64-bit platform.

It is important for performance if your game is calling RefreshContent often on bitmaps or meshes that use Mesh/BitmapExpression. If you only use those expressions once during game init or level init then it won't matter.

Hard to say where the problem is now.

Try disabling threaded processing completely:

In TZApplication.Init insert this line

ZClasses.Tasks.Enabled := False;

Aha but wait: now you are testing with just a MeshExpression. A mesh expression needs a mesh to process. Try adding a MeshBox in front of it.

I suggest adding log lines in TMeshExpression.ProduceOutput until it can be shown where it crashes.

The error seems different now. I wish it was possible to get a callstack of the error.

What happens if you simply let Platform_GetCpuCount return 1? (so just a single line with "exit(1);")