Google Play New problem : 64bits

All topics about ZGameEditor goes here.

Moderator: Moderators

User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

The "fixes_3_2" branch compiles just fine. Unfortunately, it gives this error right away when building ZGE:
jni.pas(543) Error: Assembler aarch64-linux-android-as.exe not found, switching to external assembling
So I thought that maybe they updated their compiler to be able to use a more recent NDK than r21e, but I recalled that aarch64-linux-android-as.exe does not exist after that NDK.

So I added this PATH in my building script:
PATH=C:\Android\android-ndk-r21e\toolchains\llvm\prebuilt\windows-x86_64\bin;

And the next error is:
ZPlatform_Android.inc(63,59) Fatal: Can't find unit SyncObjs used by ZPlatform

SyncObjs is located in C:\FPC\trunk_3_2\units\aarch64-android\fcl-base for 64bits so I added it as a -Fu

call %FPC_PATH%\ppcrossa64 -B -MDelphi -Sghi -O3 -Tandroid -Paarch64 -XXis -vw -Filib\arm64-v8a -Fl%NDK_PATH%\arch-arm64\usr\lib -Fu. -Fu..\.. -FuC:\FPC\trunk_3_2\units\aarch64-android\fcl-base -FUobj\arm64-v8a\ -FEjava\libs\arm64-v8a\ -olibzgeandroid.so -dANDROID -dMINIMAL -Xd -CpARMV8 %DEBUG_FLAG% zgeandroid.pas

And it builds just fine. But the result is the same. Threads are killing the app after a few frames... :cry:
No different error message either.
User avatar
VilleK
Site Admin
Posts: 2356
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Re: Google Play New problem : 64bits

Post by VilleK »

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

What NDK version are you using now?
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

Using fixes_3_2 makefile in trunk doesn't solve anything. I'm going to create a topic on freepascal's forum regarding the compilation of crosscompiler for Android from Windows.

As for the Android NDK, I'm using the old r21e. That is the only one that works.
I already spent days trying to run a slightly more recent version, that still has the exe needed by fpc, but in a slightly different form: https://www.emix8.org/forum/viewtopic.p ... 767#p10767

And I also tried to build and to link the libzgeandroid.so manually. The resulted library is totally broken.
https://www.emix8.org/forum/viewtopic.p ... 803#p10803
Last edited by Ats on Mon Oct 14, 2024 2:57 pm, edited 1 time in total.
User avatar
VilleK
Site Admin
Posts: 2356
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Re: Google Play New problem : 64bits

Post by VilleK »

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

Code: Select all

uses 
  cmem,
  cthreads,
  jni, 
  ZOpenGL,
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

hahaha, imagine if the fix was that easy...

...

And it is.

Omeganaut is running perfectly fine with threads and sound on Android 64 :lol: WELL DONE!

Now I need to clean things up. I'm going to build libzgeandroid.so with just that last change in ZgeAndroid.pas and see if everything is working. Or if we really need the changes on the JNI calls in ZPlatform_Android.inc
Last edited by Ats on Tue Oct 15, 2024 8:33 am, edited 2 times in total.
User avatar
VilleK
Site Admin
Posts: 2356
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Re: Google Play New problem : 64bits

Post by VilleK »

:)

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.
User avatar
Kjell
Posts: 1915
Joined: Sat Feb 23, 2008 11:15 pm

Re: Google Play New problem : 64bits

Post by Kjell »

:roll:

Image

Good to see that the culprit was finally found!

K
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

Modifying only ZgeAndroid.pas isn't sufficient.
Here's all the changes we made. I removed the ones on ZzDC.dpr

Those two changes are necessary for threads to work:

In ZgeAndroid.pas :

Code: Select all

uses 
  cmem,
  cthreads,
  jni, 
  ZOpenGL,
  ZClasses,
In ZPlatform_Android.pas / function Platform_GetCpuCount:

replace

Code: Select all

RunObj := Env^.CallStaticObjectMethodV(Env, RunClass, Mid, nil);
by

Code: Select all

RunObj := Env^.CallStaticObjectMethod(Env, RunClass, Mid);

But with only those changes, the audio is still crashing.
So here are the changes we made for the audio:


In jni.pas:

Replace

Code: Select all

CallNonvirtualIntMethodV:function(Env:PJNIEnv;Obj:JObject;AClass:JClass;MethodID:JMethodID;Args:va_list):JInt;{$ifdef mswindows}stdcall;{$else}cdecl;{$endif}
by

Code: Select all

CallNonvirtualIntMethodV:function(Env:PJNIEnv;Obj:JObject;AClass:JClass;MethodID:JMethodID):JInt;{$ifdef mswindows}stdcall;{$else}cdecl;{$endif} varargs;

In ZPlatform_Android.inc / function AudioCallback

Replace

Code: Select all

{$IFDEF CPU64}
function AudioCallback(Data : pointer) : Int64;
{$ELSE}
function AudioCallback(P : pointer): LongInt;
{$ENDIF}
by

Code: Select all

{$IFDEF CPU64}
function AudioCallback(P: Pointer): Int64;
{$ELSE}
function AudioCallback(P : pointer): LongInt;
{$ENDIF}
replace

Code: Select all

Params : array[0..10] of integer;
by

Code: Select all

Params : array[0..10] of JValue;
replace

Code: Select all

function C(const args : array of const) : pointer;
var
  I : integer;
begin
   for I := 0 to High(args) do
     Params[I] := args[I].vinteger;
   Result := @Params;
end;
by

Code: Select all

function C(const args : array of const) : PJValue;
var
  I : integer;
begin
  Fillchar(Params, SizeOf(Params), 0);
   for I := 0 to High(args) do
    begin
      case args[I].VType of
        vtInteger: Params[I].i := args[I].VInteger; // Assign integer value
        vtPointer: Params[I].l := args[I].VPointer; // Assign pointer value
        else
          raise Exception.Create('Unsupported argument type');
      end;
    end;
   Result := @Params;
end;
replace

Code: Select all

bufferSizeInBytes := Env^.CallStaticIntMethodV(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 2]));
by

Code: Select all

bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 12]));
replace

Code: Select all

track := env^.NewObjectV(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
by

Code: Select all

track := env^.NewObjectA(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
replace

Code: Select all

MixAndCopyData(PBuffer,OnePassSize);
by

Code: Select all

MixAndCopyData(PBuffer, Min(OnePassSize, bufferSizeInBytes));
replace

Code: Select all

env^.CallNonvirtualIntMethodV(env, track, cAudioTrack, mWrite, C([buffer, 0, OnePassSize]));
by

Code: Select all

env^.CallNonvirtualIntMethodA(env, track, cAudioTrack, mWrite, C([buffer, 0, Min(OnePassSize, bufferSizeInBytes)]));
With all those changes, I fixed the audio from the fresh git code. But should we keep all those changes?

Edit:
I built the 32 bit version of libzgeandroid.so just to be sure it is still working with all those changes. Everything's fine!
User avatar
VilleK
Site Admin
Posts: 2356
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Re: Google Play New problem : 64bits

Post by VilleK »

Looks good, please send a pull request and I can make any final edits if needed.
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

It's done. Thanks for your help with this :)
Once everything will be verified and merge, can you make a new zip for ZGameEditor, so I can benefit from the android folder renamed to armeabi-v7a? Then I'll go on updating how the android Template works and add the recent libraries to it.
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

Woops... There's another BRAND NEW problem that I didn't spot before...

Audio only works in debug mode, when the usb cable is plugged to the computer and the apk is launched using run.bat
If I launch the audio test in debug mode from the phone, with or without the cable, it instantaneously crashes.
It also crashes instantaneously in release mode.

This only happen when there is audio in the project.

I already built the libraries without the -g
And the AndroidManifest is set to android:debuggable="false"

Since running the app with the usb plugged in is way slower that the usual, can that affect the threads or something?
User avatar
VilleK
Site Admin
Posts: 2356
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Re: Google Play New problem : 64bits

Post by VilleK »

Can you get logs from these crashes?
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

Yep. After reactivating debug:

Code: Select all

********** Crash dump: **********
Build fingerprint: 'google/cheetah/cheetah:14/AP2A.240905.003/12231197:user/release-keys'
Abort message: 'Scudo ERROR: corrupted chunk header at address 0x20000732e8b77f0'
#00 0x000000000005d8e4 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#01 0x0000000000048d18 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::die()+8) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#02 0x00000000000499ec /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportRawError(char const*)+28) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#03 0x000000000004995c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::ScopedErrorReport::~ScopedErrorReport()+12) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#04 0x0000000000049ac0 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportHeaderCorruption(void*)+96) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#05 0x000000000004bab4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidNormalConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+276) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#06 0x000000000042e864 /system/lib64/libhwui.so (GrDirectContext::~GrDirectContext()+388) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#07 0x00000000006cf3e0 /system/lib64/libhwui.so (GrDirectContext::~GrDirectContext()+16) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#08 0x00000000002c1b48 /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::setGrContext(sk_sp<GrDirectContext>)+344) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#09 0x000000000040ffa0 /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::destroyRenderingContext()+64) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#10 0x000000000040f494 /system/lib64/libhwui.so (android::uirenderer::renderthread::CacheManager::trimMemory(android::uirenderer::TrimLevel)+260) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#11 0x000000000040f354 /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::trimMemory(android::uirenderer::TrimLevel)+36) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#12 0x00000000004c315c /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+732) (BuildId: 40bb4b94e9a16adbb1371c4bfe55f94e)
#13 0x00000000000115d4 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+244) (BuildId: c07f08c7e5a964a8f8c6bc5c820fb795)
#14 0x000000000006efbc /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+204) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
#15 0x0000000000060d60 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
Crash dump is completed
That's on the pure 64bit phone. On the old one, sometime it is working, sometime not. Maybe because it is noticeably slower?
User avatar
Ats
Posts: 763
Joined: Fri Sep 28, 2012 10:05 am
Contact:

Re: Google Play New problem : 64bits

Post by Ats »

That crash might have nothing to do with our problem. But I found how to fix that:
replacing
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 12]));
by
bufferSizeInBytes := Env^.CallStaticIntMethodA(env, cAudioTrack, mGetMinBufferSize, C([AudioPlayer.AudioRate, 3, 2]));

Pure luck on that one, only because I asked myself why the next
track := env^.NewObjectA(env, cAudioTrack, mAudioTrack, C([3, AudioPlayer.AudioRate, 3, 2, bufferSizeInBytes, 1]));
was 2 instead of 12.

I tried both 12, it crashes, even in adb debug mode.
And both 2, it works, even in release mode.

Does it make sense? I'm not sure :roll:

Edit:
In Omeganaut, in release mode, the sound can be EXTREMELY low-fi. The sound is low-fi, but this is way worse.
And debug or release mode, it crashes randomly while playing. I'm trying to get a log.

crash log isn't helping...
********** Crash dump: **********
Build fingerprint: 'google/cheetah/cheetah:14/AP2A.240905.003/12231197:user/release-keys'
#00 0x0000000000000004 <anonymous:74de5f6000>
Crash dump is completed


Edit:
Lastly, there are no problems with our changes in the code if I run the game in 32bit only on the old phone. The game is working perfectly. No crappy sounds, no crash.
User avatar
VilleK
Site Admin
Posts: 2356
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Re: Google Play New problem : 64bits

Post by VilleK »

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