ZGameEditor forum

Pointers, 64bits... Could that be it? I doubt it, but you can test this change: procedure TExecutionEnvironment.StackPushPointer(X: pointer); begin {$ifdef debug} if StackGetDepth>=High(ZcStack) then ScriptError('Zc Stack Overflow (infinite recursion?)'); {$endif} ZcStackPtr^ := TStackElement( X );...

Oh, that is fun. With UpdateTime and UpdateScreen disabled, it is drawing the @RefreshContent(Component:BitmapClouds); on the screen. I didn't know that was done on the screen instead of in memory before rendering the rest over it. This happens only on Android because using GL ES we cannot ask the ...

Looking at the end of the callstack, it seems it triggers in a OpenGL call from TZApplication.UpdateScreen. #31 pc 00000000001872ec /vendor/lib64/egl/libGLESv2_adreno.so #32 pc 0000000000041d00 libzgeandroid.so (ZAPPLICATION$_$TZAPPLICATION_$__$$_UPDATESCREEN+200) There are not many GL-calls in Upda...

Hmm .. i suspect this might be caused by GLESPixelsFromTexture executing at the wrong time. That function temporarily disables depth testing and face culling when using ES 1.0. I see, yes. This would paint pixels on the screen but since it it uses push/pop attrib it should restore those settings. I...

Perhaps we are looking at two different problems here. If you get crash only when Tasks.Enabled = true then I suggest you make a test project that only has a MeshExpression and a BitmapExpression and that are both refreshed using RefreshContent each frame. That should stress test the problem.

Ats wrote: ↑Mon Oct 21, 2024 10:03 am So I made a simple BitmapExpression frenzy example:

I added this line to your example because otherwise the BitmapExpression is only updated at startup:
Can you reproduce the crash with a debugger attached?

Perhaps try playing the game in Android Studio and see if you can reproduce the crash. If it only happens with threads enabled then it is likely related to meshexpression or bitmapexpression.

Ok it should be 2 I guess for stereo output. The documentation suggested 12 but if 2 works then we should keep that.

Can you get logs from these crashes?

Looks good, please send a pull request and I can make any final edits if needed.

I wish I thought of this sooner. I forgot that ZzDC.dpr is not used for Android builds. Sorry for letting you go through all that trouble.

Something I don't think we have tried yet. In zgeandroid.pas (not zzdc.dpr), try this uses order:

Maybe the makefile from fixes_3_2 can be copied to trunk and build it that way.

What NDK version are you using now?

I think the Fpc devs are developing on Linux and Mac so they rarely test compiler building on Windows. Maybe the "fixes_3_2" branch works better to build? https://github.com/fpc/FPCSource/tree/fixes_3_2 The CheckSynchronize call is only needed if we use the Synchronize method but ZGE does ...

That version is from 2021 but I see that is the latest released version.

It would be good to test with latest trunk version. If you feel up for it, please check how to build Freepascal from source.