Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Nov 2012
Offline Last Active Yesterday, 03:08 PM

Posts I've Made

In Topic: Android NDK C++ crash reporting

21 November 2015 - 02:57 AM

I've released an Android game recently without having put much thought into crash reporting systems.


I've found that Java crashes (or unhandled java exceptions) are being caught and reported by Flurry (not something we particularly intended, we'd only plugged in Flurry for analytics).


Crashes in our C++ code are reported very well through the Google Play developer console (crashes appear quickly and symbolicated). It's much better than iOS's built-in crash reporting, which never seems to report anything at all because you have to wait until the same crash happens on the same version of iOS dozens of times before it'll show a report). I guess we're only seeing crash reports from users who have ticked some box to allow crash reports to be sent, but we're getting plenty through and I don't feel the need to use any third-party service.

In Topic: IDE for Android NDK

21 November 2015 - 02:50 AM

I use NSight Tegra (which plugs into Visual Studio): https://developer.nvidia.com/nvidia-nsight-tegra


When it works, it's great. When it's not working or you're struggling to plug in some new library, it can be very frustrating because all the online tips and tutorials are geared around eclipse and Android Studio.

In Topic: Mobile games with big file size

29 October 2015 - 11:58 AM

Loads of successful games are bigger.


If you were close to the 100MB mark *, I'd recommend trying to get under it, so that your game can be downloaded over a cellular connection.


You're nowhere near small enough to get under that (unless you're being very wasteful and there's loads of stuff you can cut), but you're nowhere near large enough that typical users would worry about downloading over WiFi or worry about the storage you're taking up on the device.


Some games cheat the system a bit by making their initial download small, then downloading loads of extra stuff immediately. This is partially justified by the fact that different devices support different types of compressed texture, so the correct texture format can be selected.


* Limit used to be 50MB until very recently. It's now 100MB for apps targeting Android 4 and above.

In Topic: ETC and PVRTC dead to an unified compression ?

28 October 2015 - 12:32 PM

"since Vulkan and Metal support BC compression and is used for mobile too, is it the end of multiple compression for one unified compression ?"

I'm not sure if the OP meant BC or ASTC, but metal support for both is device-dependent: https://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/MetalFeatureSetTables/MetalFeatureSetTables.html#//apple_ref/doc/uid/TP40014221-CH13-SW1


If there is going to be a unified compression (across phones and desktop) it will be ASTC, not BC, but you'll have to wait a good few years before you can assume support.

In Topic: What are my options for loading my game files for an android app?

16 October 2015 - 11:52 PM

im using fopen (C++) to load files directly from sdcard/internal memory <- i would like not to change that but loading things through assets and then saving them to sd card seem pretty lame since game will take 2x more space than it should.


I dont want to change the loading code.


The ideal thing would be that apk (game only could be downloaded with all game files - without any additional download from my app.)


So during apk installation it could extract files to desired path, then delete the zipped content.


I'm pretty sure you can't delete the apk contents, I'm afraid.


One option would be for you to disable compression of your files within the apk. Certain extensions like .mp3 .zip, etc don't get compressed, so if you rename your game files to one of those then you can disable compression, alternatively you can get your hands dirty and figure out whereabouts in the build process the compression decision is made and turn it off completely or just for your particular file extensions.


With an uncompressed asset in your apk, you can use AAsset_openFileDescriptor to get a file descriptor for a package file, then you can use fdopen followed by fread/fclose. So you'd only have to rewrite your file opening code and not your file manipulation code which might be a less daunting prospect.


Obviously if the build process isn't compressing for you, then you probably ought to be compressing your game files yourself, plus it's worth noting that the docs don't really make promises that AAsset_openFileDescriptor will work. I'm pretty certain that AAsset_openFileDescriptor does always work for non-compressed main apk assets and that it's unlikely to ever change on future revisions, but that's very different from it actually being a guarantee in the documentation.


All that said, you're probably best introducing a layer of abstraction in your file loading code and just using AssetManager functions on Android.