ZGameEditor forum

Ats wrote: ↑Sun Apr 20, 2025 9:27 am Let’s start with “1 - Platform_CreateMutex Memory Allocation.”

Gemini is 100% correct here. I'm very impressed it found this bug.

This bug is not present in ZPlatform_Win32 so not sure why the Android version was wrong.

Ats wrote: ↑Mon Apr 14, 2025 11:41 am I need to get back to working on this.

Ok I will try to support you the best I can like before. It could be that each Android update has even worse OpenGL backward compatibility.

Almost a two hour video, I didn't realize this game had so much content . Looks like some interesting level design and cool bosses. I'm impressed you had the perseverance to finish this project.

You can try delaying the InitApp call in ZgeAndroid to NativeDrawFrame. This should help get rid of the messages about no current GL context.

About Zge.Java: I think the logic is that it copies it to the app directory only if it is newer than the destination. To avoid overwriting any app-specific changes. It seems the built in Android OpenGL logging have no effect because I can see no such lines in the log. I guess they have removed this ...

These messages are interesting: "call to OpenGL ES API with no current context (logged once per thread)" I see that GLSurfaceView has options to log OpenGL calls. Try adding this line: setDebugFlags(DEBUG_CHECK_GL_ERROR | DEBUG_LOG_GL_CALLS); At line 91 in Zge.java, just before the line &q...

Today, I discovered that Android Studio handles the logcat very efficiently when a real phone is connected to the computer. I noticed some warnings appearing quite frequently: 2024-12-03 14:00:26.318 680-593 gralloc4 and...graphics.allocator-V1-service W Unable to set buffer name VRI[ZgeActivity]#0...

Cool . This is to my knowledge the first ZGE game on Steam.

Can you please DM me the latest version of your Omeganaut zgeproj file so I can look at it and see if I notice anything out of the ordinary? Especially around the sound generation since you mentioned that.

You can also check the ifdef android code in other places. Try insert a "exit;" as first line in ZBitmap GLESPixelsFromTexture. And also insert "exit;" as first line in ZOpenGL functions: fakePushAttrib and fakePopAttrib. That will make the visuals look terrible but would be good...

Those logs doesn't look helpful to me.

Do you have threads enabled again now? Or does setting Tasks.Enabled=False help?

There really shouldn't be any memory leaks in ZGE. I always enable memory leak reporting when debugging and when I notice leaks I fix them right away. If some leak exist then it would be in some "ifdef android" block because I haven't tested that as much. Although it still wouldn't make se...

So I’m wondering if the issue could be with ZFile.pas. How could I stress-test the File/FileAction on Android 64 to investigate this? If you have the file in assets subfolder then the ReadAssetFile routine in ZPlatform_Android will be used. This routine also needs the same changes as the audio code...

Ats wrote: ↑Wed Oct 30, 2024 10:35 am Is it possible that setting Pixel.R (G or B) can crash if it's under 0 or over 1?

No, the ConvertToByte procecure in ZBitmap.pas forces the values to be in between 0 and 1 range.

What if you instead comment out the SetExceptionMask calls. That should flush forward any remaining division by zero errors. If there are any in ZGE then they should be fixed. I think the only reason the BitmapExpression problem existed was because in the beginning ZGE did not support 1 width textur...