Fixed doxygen warnings and markdown formatting.

main
Philipp Wiesemann 2014-08-12 23:28:45 +02:00
parent 05d8780022
commit cfaa99bb56
4 changed files with 52 additions and 33 deletions

View File

@ -81,7 +81,7 @@ sdk.dir=PATH_TO_ANDROID_SDK
Here's an explanation of the files in the Android project, so you can customize them: Here's an explanation of the files in the Android project, so you can customize them:
android-project/ android-project/
AndroidManifest.xml - package manifest. Among others, it contains the class name AndroidManifest.xml - package manifest. Among others, it contains the class name
of the main Activity and the package name of the application. of the main Activity and the package name of the application.
build.properties - empty build.properties - empty
@ -141,6 +141,7 @@ To customize your application name, edit AndroidManifest.xml and replace
Then create a Java class extending SDLActivity and place it in a directory Then create a Java class extending SDLActivity and place it in a directory
under src matching your package, e.g. under src matching your package, e.g.
src/com/gamemaker/game/MyGame.java src/com/gamemaker/game/MyGame.java
Here's an example of a minimal class file: Here's an example of a minimal class file:
@ -291,30 +292,39 @@ You can create and run an emulator from the Eclipse IDE:
* Window -> Android SDK and AVD Manager * Window -> Android SDK and AVD Manager
You can see if adb can see any devices with the following command: You can see if adb can see any devices with the following command:
adb devices adb devices
You can see the output of log messages on the default device with: You can see the output of log messages on the default device with:
adb logcat adb logcat
You can push files to the device with: You can push files to the device with:
adb push local_file remote_path_and_file adb push local_file remote_path_and_file
You can push files to the SD Card at /sdcard, for example: You can push files to the SD Card at /sdcard, for example:
adb push moose.dat /sdcard/moose.dat adb push moose.dat /sdcard/moose.dat
You can see the files on the SD card with a shell command: You can see the files on the SD card with a shell command:
adb shell ls /sdcard/ adb shell ls /sdcard/
You can start a command shell on the default device with: You can start a command shell on the default device with:
adb shell adb shell
You can remove the library files of your project (and not the SDL lib files) with: You can remove the library files of your project (and not the SDL lib files) with:
ndk-build clean ndk-build clean
You can do a build with the following command: You can do a build with the following command:
ndk-build ndk-build
You can see the complete command line that ndk-build is using by passing V=1 on the command line: You can see the complete command line that ndk-build is using by passing V=1 on the command line:
ndk-build V=1 ndk-build V=1
If your application crashes in native code, you can use addr2line to convert the If your application crashes in native code, you can use addr2line to convert the
@ -334,7 +344,9 @@ For example, if your crash looks like this:
You can see that there's a crash in the C library being called from the main code. You can see that there's a crash in the C library being called from the main code.
I run addr2line with the debug version of my code: I run addr2line with the debug version of my code:
arm-eabi-addr2line -C -f -e obj/local/armeabi/libmain.so arm-eabi-addr2line -C -f -e obj/local/armeabi/libmain.so
and then paste in the number after "pc" in the call stack, from the line that I care about: and then paste in the number after "pc" in the call stack, from the line that I care about:
000014bc 000014bc
@ -342,7 +354,7 @@ I get output from addr2line showing that it's in the quit function, in testsprit
You can add logging to your code to help show what's happening: You can add logging to your code to help show what's happening:
#include <android/log.h> #include <android/log.h>
__android_log_print(ANDROID_LOG_INFO, "foo", "Something happened! x = %d", x); __android_log_print(ANDROID_LOG_INFO, "foo", "Something happened! x = %d", x);
@ -357,7 +369,9 @@ APP_OPTIM := debug
The best (and slowest) way to debug memory issues on Android is valgrind. The best (and slowest) way to debug memory issues on Android is valgrind.
Valgrind has support for Android out of the box, just grab code using: Valgrind has support for Android out of the box, just grab code using:
svn co svn://svn.valgrind.org/valgrind/trunk valgrind svn co svn://svn.valgrind.org/valgrind/trunk valgrind
... and follow the instructions in the file README.android to build it. ... and follow the instructions in the file README.android to build it.
One thing I needed to do on Mac OS X was change the path to the toolchain, One thing I needed to do on Mac OS X was change the path to the toolchain,
@ -374,12 +388,15 @@ application with it, changing org.libsdl.app to your package identifier:
------------------------------------------ ------------------------------------------
Then push it to the device: Then push it to the device:
adb push start_valgrind_app /data/local adb push start_valgrind_app /data/local
and make it executable: and make it executable:
adb shell chmod 755 /data/local/start_valgrind_app adb shell chmod 755 /data/local/start_valgrind_app
and tell Android to use the script to launch your application: and tell Android to use the script to launch your application:
adb shell setprop wrap.org.libsdl.app "logwrapper /data/local/start_valgrind_app" adb shell setprop wrap.org.libsdl.app "logwrapper /data/local/start_valgrind_app"
If the setprop command says "could not set property", it's likely that If the setprop command says "could not set property", it's likely that
@ -390,9 +407,11 @@ You can then launch your application normally and waaaaaaaiiittt for it.
You can monitor the startup process with the logcat command above, and You can monitor the startup process with the logcat command above, and
when it's done (or even while it's running) you can grab the valgrind when it's done (or even while it's running) you can grab the valgrind
output file: output file:
adb pull /sdcard/valgrind.log adb pull /sdcard/valgrind.log
When you're done instrumenting with valgrind, you can disable the wrapper: When you're done instrumenting with valgrind, you can disable the wrapper:
adb shell setprop wrap.org.libsdl.app "" adb shell setprop wrap.org.libsdl.app ""
================================================================================ ================================================================================

View File

@ -1510,7 +1510,7 @@ DOTFILE_DIRS =
# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note # DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH. # that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
DOT_GRAPH_MAX_NODES = 50 DOT_GRAPH_MAX_NODES = 60
# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
# graphs generated by dot. A depth value of 3 means that only nodes reachable # graphs generated by dot. A depth value of 3 means that only nodes reachable

View File

@ -20,9 +20,9 @@
*/ */
/** /**
* \file SDL_opengles.h * \file SDL_egl.h
* *
* This is a simple file to encapsulate the OpenGL ES 2.0 API headers. * This is a simple file to encapsulate the EGL API headers.
*/ */
#ifndef _MSC_VER #ifndef _MSC_VER

View File

@ -20,7 +20,7 @@
*/ */
/** /**
* \file SDL_opengles.h * \file SDL_opengles2.h
* *
* This is a simple file to encapsulate the OpenGL ES 2.0 API headers. * This is a simple file to encapsulate the OpenGL ES 2.0 API headers.
*/ */