ZGameEditor forum

Not sure if it matters but you could specify more debug options when compiling like this "-g -gl -gw"

Thread 20 "GLThread 731" received signal SIGSEGV, Segmentation fault. [Switching to Thread 9950.10745] When you see this, then it could be possible from gdb to get the callstack of the crashing thread (in this case thread 20). I've never used gdb but it seems getting the callstack is &quo...

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.