Sorry your browser is not supported!

Hi,
after a long testing campaign on my app Call of Zombie (FPS 3D), strong doubts on robustness of 3D AppGameKit apps have arisen in my mind.
In fact, on Windows I have played all levels in "debug mode" and I have removed all bugs and error that led to some "<error message> in line XXX at <file>.agc".
Unfortunately, on Android tablet (Galaxy Tab and Galaxy Note) at a certain point in time, the application randomly crashes.
Last error is "error in line X at fileY". I have checked that line and I have realized that no errors could have happened here: the line was a "loadImage", and, if there were a real error, I should have met this error both in Windows and Android every time, while I get this error from time to time without any rational pattern.
The conclusion is:
1) why must the Android app be continuosly blocked on Android devices, causing serious issues to the player and making the app be rated as unstable and so not deserving the right to be purchased?
2) Why simply doesn't the app continue the execution without stopping? This is not a typical Android error message, but an error generated by AppGameKit interpreter itself.
3) It seems that the Android app run in a sort of Debug mode. Is there the possibility to deactivate debugging, so the app does not stop?
Maybe I have not understood well the fundamentals, but I have been working on this project for one year and a half, and it is very frustrating not to be able to identify this mysterious issue after hours and hours of debugging. As it is, I think that AGKv2 is not mature for developing serious 3D stuff, apart the lack of documentation of shaders and the stop of Bullet physics development.
Is it possible to have a feedback from @Paul?

Paul has already mentioned that Bullet physics may still get updates in the future.


Check your image filenames. Android is case sensitive where Windows is not.


SetErrorMode(0)

You could also try getFileExists() to identify if it is a problem with the file.
Have you completely cleared the app folder and started again with an empty folder?
Is this during broadcasting, or fully installing the app?

thanks to both of you for the kind answers.

@CJB @BatVinck
For the image file on Android, I have already checked the extensions of the files in order they are all lowercase (both in file system and in the code). This is well known issue, but from time to time it comes up again.
In any case, it is correct to have the error reporting, what I do not want is the stop of the application.

@CJB
Thanks, I confess I have not searched for error management commands...I am surprised that the default is not 0. Anyway I think that the default is 1, but, on Android, instead of continuing, it stops executions (as value 2).

I'll let you know about the results.

Sounds like a memory issue, it is likely that it ran out of GPU memory to store the images. Try using lower quality images on Android, or deleting some images before loading new ones.

I am grateful to @Paul, the AppGameKit "Darth Vader" , for the answer.
Anyway I added the line, in order to ignore any error that is caught by the interpreter. Of course, this workaround should not catch the case mentioned by Paul (memory overflow cause by hi res images), but should avoid some cumbersome messages to be seen by game players.
I will run the game as much as possible, if the crash shows up again, I'll let you know.

After some thoughts, maybe I have found the issue, and, as usual, Paul was right and has already given me the correct hint. I have simply forgotten to include code to delete all images used for object textures. This is because in previous releases I have used the deleteAllImages() command, but since I have met some issues, I have removed this call. The objects were removed by deleteAllObjects(). So in each level I reloaded and recreated all texture images, leaving alive the old ones (althought I destroyed the objects), and overwhelming the memory capacity on Android systems. So on Android, after 2-3 levels, the system crashed.
Sorry for having doubted over AGKv2 stability, hoping that the issue is exactly that one, but is 99% sure.