Currectly im have no idea why this happens, but a app can crash out on a backbuffer flip after you have minimized the app.
Etc im tried do this:
void OpenGLRainbows::PrepareBackbuffer() {
#if defined(TINYGL) || defined(TRENKI3D)
if (m_Surface[0].m_Height) {
m_Surface[0].MemCpyToScreen();
} else {
if (m_bHasClearColor) {
Screen.Clear();
}
}
#ifdef TRENKI3D
if (m_bDirtyZBuffer) {
m_bDirtyZBuffer=false;
Screen.ClearZBuffer();
}
#endif
#else
#ifdef PALM_WEBOS
#endif
#ifdef GLB_SURFACE_OLDSCHOOL
if (m_Surface[0].usex>0) {
if (m_bDirtyZBuffer) {
m_bDirtyZBuffer=false; glClear(GL_DEPTH_BUFFER_BIT);
}
PasteSurface(0);
} else if (m_bHasClearColor || m_bDirtyZBuffer) {
GLbitfield bits=0;
if (m_bHasClearColor) { bits |= GL_COLOR_BUFFER_BIT; }
if (m_bDirtyZBuffer) { bits |= GL_DEPTH_BUFFER_BIT; m_bDirtyZBuffer=false; }
glClear(bits);
}
#else
g_debug("PrepareBackbuffer start");
if (m_BackSurfaceSpriteID[0] != -1) {
g_debug("1");
PasteSurface(0);
g_debug("2");
} else if (m_bHasClearColor || m_bDirtyZBuffer) {
g_debug("11");
GLbitfield bits = 0;
g_debug("12");
if (m_bHasClearColor) { bits |= GL_COLOR_BUFFER_BIT; }
g_debug("13");
if (m_bDirtyZBuffer) {
bits |= GL_DEPTH_BUFFER_BIT;
m_bDirtyZBuffer = false;
}
g_debug("14");
glClear(bits);
}
#endif
#endif
g_debug("PrepareBackbuffer end");
}
but got a logcat like this:
I/glbasic: [GLB]->loop start() after SHOWSCREEN
[GLB]->loop start()
I/glbasic: [GLB]->loop start() before SHOWSCREEN
__g_paused: 0 0
FlipScreens before
FlipScreens
1
PrepareBackbuffer start
11
12
13
14
I/glbasic: OnPause()
glbasicOnPause
V/SDL: onPause()
V/SDL: nativePause()
V/SDL: surfaceDestroyed() start
I/SDL: surfaceDestroyed() end
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4 in tid 21728 (SDLThread), pid 21683 (ractal.spotrace)
V/SDL: onWindowFocusChanged(): false
And now, removeing glClear(bits) diddent help a test, then its just crashout in a another place in the function.
there is something very strange here. Hate those threads, which im guess its the main issue as FlipScreens might fails, if its that. no idea.
im will property newer fix that issue, due Android Studio is just so much hell with debugger.....
There was much more info with Android SDK, but there is none with Android Studio and any documents im have found is too techincal to read and does not tell step to step what to do and get it working. Nice. What a hell do you not have a default dugger that can tell info like Android SDK did as by default?
etc im did newer got a debugger to work at all. So im have no no info what to do and want to do.
PS. The worst cause about this issue is the app might restart when resumed.
For me Android dev tools are .. lets say that for example Symbian OS / Windows Phone dev tools were much better, almost out of box everything worked, proper debugger and so on.. At least for indie/single developer.
Let's say that even Phonegap/Cordova tools advaised to use older gradle 2.4 and not update some SDK/Studio stuff when I was doing some Android project :DD
So there was no changes in that core part of GLB backbuffer flipping, drawing and handling pause?
I didn't work with android from some time, that logcat file is from adb? Not sure if that applies to all but some smartphones have many options in hidden 'dev mode' for debugging, like warning levels - warn/info/debug/verbose..
Some day day I will need to download that Android Studio to look into it :D
I found this. It might be useful?
https://github.com/googlearchive/android-PdfRendererBasic/issues/20
currectly the main issue is the sound or in nativePause().
The SDL_Mixer that can crash out and even just hangning when called from GLB_ON_PAUSE can cause a crash. Etc when trying to use a STOPMUSIC. When STOPMUSIC touch itm then a crash is possible.
You often want to stop the music. But for some odd reason SDL does not allways do that happens to pause the music as its self and might skipt it.
There is no problems with RESUMING, but more PAUSING that is the main issue right now.
im ends up to use soundpool (from old Android Extras, but this time integrated directly to the commands and can been enabled/disabled by a option) and adds automatic music pausing and resuming in Java instead. This seens works quite better.
Its a attempt to fix that bug and then do a vast of clean up as well, etc by removing the old pausemode in SHOWSCREEN etc as this was newer called corretly anymore.
Also im have emailed to Gernot about changes in HIBERNATE(), MOUSEAXIS(), PLATFORMINFO(), SHOWSCREEN() as well in android_glb_sdl_main.cpp (and various Java files) as well search for usesoundpool for music commands changed.
We also need to warn to NOT use any sound mute or other commands in PAUSE and RESUME subs as they might crash when miniized and that even when shown a ads! Instead let Java do the job automatic instead. This is much more stable.
PS. MOUSEAXIS(), PLATFORMINFO() is for MOUSEAXIS support for chromebook and has nothing with this issue to do.
hm.. serious problems :/ Not sure if I get all right.
does calling sdl to stop music/sound before calling GLB_ON_PAUSE also causes issues? If not, this could be an option to stop audio like this by automatic, and the in main game loop dev would just need to check ismusicplaying after getting resume flag from GLB_ON_RESUME.
What's currenlty needed to target Android from GLBasic - Android Studio surely, and some specifi JRE, JDK or something? Rather for curiosity, and just to see if my chinese device has some additional debug options ;-) Ah and can I install those tools in any directory or it need to be specific, like "C:\Android_crap\" ?
Below will be deleted after gettint resposne:
Other thing: is there way to get current GLB source (as downloads from GLBasic Dev »Sourcecode) point to old source version without those bat scripts for autoupdate.
GLB_ON_PAUSE and GLB_ON_RESUME calling is fine. its not that that cause issue by it self. Im removed those calls from java for test and the above crash still happens. Its not a sound issue, but a graphics issue.
im not still not really sure what happens, but crash look like this:
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: Build fingerprint: 'google/hana/hana_cheets:9/R81-12871.91.0/6417888:user/release-keys'
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: Revision: '0'
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: ABI: 'arm'
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: pid: 11660, tid: 11707, name: SDLThread >>> com.spacefractal.spotrace <<<
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: Cause: null pointer dereference
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: r0 00000000 r1 00000004 r2 0eefc192 r3 00000000
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: r4 00000000 r5 e1936080 r6 00001001 r7 cd47d014
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: r8 cd47d014 r9 00000001 r10 cd47d118 r11 cd47cfd8
2020-04-28 12:06:53.970 11739-11739/? A/DEBUG: ip ea6b0e10 sp cd47cfc8 lr df16e9c0 pc eac0a7bc
2020-04-28 12:06:53.974 11739-11739/? A/DEBUG: backtrace:
2020-04-28 12:06:53.974 11739-11739/? A/DEBUG: #00 pc 000097bc /system/lib/libutils.so (android::RefBase::incStrong(void const*) const+4)
2020-04-28 12:06:53.974 11739-11739/? A/DEBUG: #01 pc 000159bc /vendor/lib/egl/libEGL_mesa.so
A null pointer error. Currectly stuck throught.
also the app can hang on close as well, causing app newer relaunch again. Here this code seens can do that, rather than waiting the thread to been finsished (which does not allways happens) in SDLActivity.java:
if (SDLGlbasic.Arc == true)
{ this.finish();
System.exit(0);
}
Since stability was actuelly pretty nice after the SoundPool change on the emulator and the phone, then we should focus on fixing this null pointer issue. This happens somewhere in SHOWSCREEN me thinks. But not sure.
just poking around this morning. its seen its same null pointer reference each time when its crash and allways when minimize.
So thread renamed to get focus on extractly this issue as other issue like OnDestroy() seens has been fixed by the above code. The Chromebook dont poke with the annoying "Spot Race keeps crashing" popups when closing down anymore. But does it on minimizes after two crash.
While its has been much more stable after the change for the new steam beta on my phone and the emulator, im do a least see such a crash too on Google Vital. So its can been possible its happens on other than Chromebook, like this one im have. So its depend on device.