I'm interested in working on a patch to port changes I've modified in the C that always provide me with integration headaches:

1. Volume control. This is a two part change--one is to be able to access the volume keys, and the other is to change the sound management to use the Media Volume instead of the current source (which I believe is Ringer--I forget). All games I've ever seen use the Media Volume.

2. The ability to pass the appropriate env variable to allow calling back out to Java classes. In my code, I've got a few methods written in Java, and I have hacked your code in appropriate places to allow me to make calls back out to Java.

Both of these are really quite simple, actually. I was wondering how to get those to you, pelya, and if you'd be up for merging them into the main code base. Since I don't have write access to the git repo the best I can do is provide a diff of the files here.

Thank you for your fast answer,

to let you know

when compiling with last r5 ndk from cristax.net (android-ndk-r5-crystax-1)

I got first a problem with the compilation of VMCI (lib missing)

Code: Select all

NDK version r5-crystax-1
Building with NDK r5c or r6 - internal STLPort disabled
Building with CrystaX r5 toolchain - wchar support enabled
Android NDK: ERROR:/bla/project/jni/../jni/vcmi/Android.mk:vcmi: LOCAL_SRC_FILES points to a missing file   
Android NDK: Check that /bla/project/jni/../jni/vcmi/libvcmi.so exists  or that its path is correct


Then I got this linking problem of linking, for curl :

Code: Select all

/bla/project/obj/local/armeabi/objs-debug/curl/lib/file.o: In function `file_upload':
/bla/project/jni/../jni/curl/lib/file.c:327: undefined reference to `_CurrentRuneLocale'
/bla/project/jni/../jni/curl/lib/file.c:327: undefined reference to `__mb_sb_limit'
/bla/project/obj/local/armeabi/objs-debug/curl/lib/http.o: In function `Curl_compareheader':
/bla/project/jni/../jni/curl/lib/http.c:1255: undefined reference to `__mb_sb_limit'
...


to me, it is missing in : project/jni/curl/Android.mk
the :

Code: Select all


ifneq ($(CRYSTAX_R5_TOOLCHAIN),)
LOCAL_LDLIBS += -L$(NDK_PATH)/sources/crystax/libs/armeabi -lcrystax_static
endif


Thanks,

gjtorikian wrote:1. Volume control. This is a two part change--one is to be able to access the volume keys, and the other is to change the sound management to use the Media Volume instead of the current source (which I believe is Ringer--I forget). All games I've ever seen use the Media Volume.

Latest Git version of SDL port uses Media volume, because if you'll specify STREAM_RINGER instead of STREAM_MEDIA to the AudioTrack constructor in Java, as it was before, the sound will play out of the phone speaker instead of the headphones if you'll plug them.
Also if you'll specify
RedefinedKeys="LCTRL LALT NO_REMAP NO_REMAP"
inside AndroidAppSettings.cfg the volume keys will not send SDL keycode to the application - they'll do their default function of changing the volume - it changes Media volume, when the application is running.
So I suppose your patch is kinda late.

gjtorikian wrote:2. The ability to pass the appropriate env variable to allow calling back out to Java classes. In my code, I've got a few methods written in Java, and I have hacked your code in appropriate places to allow me to make calls back out to Java.

Mmm, I don't quite understand what did you change, I suppose you're passing the package name inside the env variable to the C code. It won't hurt to add that change to the SDL code I think.
I've added you to the list of collaborators of the SDL Git - I suppose your name on Github is the same as here. So you can commit it directly into Git, or give me the patch, whatever you'd prefer.

slvn wrote:when compiling with last r5 ndk from cristax.net (android-ndk-r5-crystax-1)
I got first a problem with the compilation of VMCI (lib missing)

VCMI compilation is very much broken, I've added all required steps to the readme inside VCMI dir - you'll
have to create dummy libvcmi.so file inside VCMI dir, so build.sh will compile all other libraries except libapplication.so, then remove the dummy libvcmi.so from VCMI dir and from the obj dir, run "make" inside VCMI dir - it will compile the real libvcmi.so and vcmiserver, then run build.sh again, and hopefully it will link it.

slvn wrote:Then I got this linking problem of linking, for curl :

Thanks, I've added your fix.

pelya wrote:Mmm, I don't quite understand what did you change, I suppose you're passing the package name inside the env variable to the C code. It won't hurt to add that change to the SDL code I think.
I've added you to the list of collaborators of the SDL Git - I suppose your name on Github is the same as here. So you can commit it directly into Git, or give me the patch, whatever you'd prefer.

Thanks. I would prefer to send it to you first to review. Currently I also have to change my main function from

Code: Select all

int main(int argc, char *argv[])

to

Code: Select all

int main(int argc, char *argv[], JNIEnv*  env, jobject thiz)

Which is probably unique to just my program, and not preferable for everyone else.

What this allows me is the ability to call, in my C code, statements like:

Code: Select all

JavaVideoThread = (*static_env)->NewGlobalRef(static_env, static_thiz);
   JavaVideoThreadClass = (*static_env)->GetObjectClass(static_env, JavaVideoThread);
   
   JavaControlAccelerometerId = (*static_env)->GetMethodID(static_env, JavaVideoThreadClass, "controlAccelerometer", "(I)V");


Which, in this case calls controlAccelerometer() from the Java side.

int main(int argc, char *argv[], JNIEnv* env, jobject thiz)

I'm already doing something like that inside SDL, I think it will be better to leave main() as it is, and to export it through SDL - create functions SDL_ADNROID_JniEnv() and SDL_ADNROID_JniVideoRenderer() (maybe with less clumsy names)

Hello,

Just for you information, I've published a game based on your port !
this is called "tactical hockey" on the market !

It's a small and simple strategic game, in between pool and hockey.

Thanks,

I've added GLES 2 support - check out hello-gl2 example, I'm not sure that it works correctly, at least it reports that GLES 2 was initialized. Could someone please create a more complicated test?

That was fast! I haven't got it working yet; getting logcat full of the message:

Code: Select all

INFO/libgl2jni([pid]): after glCreateShader() glError (0x23a700)

Also getting the same messages for the hello-gl2 example though, so I may possibly have set up the project incorrectly. I'll look into it a little more closely to see if there is anything obvious I can find wrong.

Hello,

Just to let you know, a friend of mine has reported this bug : at some point, the port freezes.
I will look at that, but I am not familiar. Do you have any clue? Can it help?

Does the SUSPENDED thread means it has crashed ?

Code: Select all

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x4001f188 self=0xce60
  | sysTid=31061 nice=0 sched=0/0 cgrp=default handle=-1345006528
  at net.sbr.tacticalhockey.DemoGLSurfaceView.nativeMouse(Native Method)
  at net.sbr.tacticalhockey.DifferentTouchInput$MultiTouchInput.process(Video.java:218)
  at net.sbr.tacticalhockey.DemoGLSurfaceView.onTouchEvent(Video.java:456)
  at net.sbr.tacticalhockey.MainActivity.dispatchTouchEvent(MainActivity.java:384)
  at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchTouchEvent(PhoneWindow.java:1675)
  at android.view.ViewRoot.deliverPointerEvent(ViewRoot.java:2194)
  at android.view.ViewRoot.handleMessage(ViewRoot.java:1878)
  at android.os.Handler.dispatchMessage(Handler.java:99)
  at android.os.Looper.loop(Looper.java:130)
  at android.app.ActivityThread.main(ActivityThread.java:3683)
  at java.lang.reflect.Method.invokeNative(Native Method)
  at java.lang.reflect.Method.invoke(Method.java:507)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
  at dalvik.system.NativeStart.main(Native Method)

"Thread-15" prio=10 tid=11 SUSPENDED
  | group="main" sCount=1 dsCount=0 obj=0x4060e960 self=0x2e79a8
  | sysTid=31147 nice=-8 sched=0/0 cgrp=default handle=3049880
  at android.media.AudioTrack.native_write_byte(Native Method)
  at android.media.AudioTrack.write(AudioTrack.java:912)
  at net.sbr.tacticalhockey.AudioThread.fillBuffer(Audio.java:70)
  at dalvik.system.NativeStart.run(Native Method)

"AudioTrackThread" prio=10 tid=10 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x4060e8b0 self=0x2e89d8
  | sysTid=31146 nice=-16 sched=0/0 cgrp=default handle=2751832
  at dalvik.system.NativeStart.run(Native Method)

"GLThread" prio=5 tid=9 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x4060bfc0 self=0x29c408
  | sysTid=31084 nice=0 sched=0/0 cgrp=default handle=2891104
  at net.sbr.tacticalhockey.DemoRenderer.nativeInit(Native Method)
  at net.sbr.tacticalhockey.DemoRenderer.onDrawFrame(Video.java:313)
  at net.sbr.tacticalhockey.GLSurfaceView_SDL$GLThread.run(GLSurfaceView_SDL.java:913)

"java.lang.ProcessManager" daemon prio=5 tid=8 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x40562c20 self=0x29ac88
  | sysTid=31074 nice=0 sched=0/0 cgrp=default handle=2728264
  at java.lang.Object.wait(Native Method)
  - waiting on <0x40562a88> (a java.util.HashMap)
  at java.lang.Object.wait(Object.java:358)
  at java.lang.ProcessManager.onExit(ProcessManager.java:139)
  at java.lang.ProcessManager.watchChildren(Native Method)
  at java.lang.ProcessManager$1.run(ProcessManager.java:85)

"Binder Thread #2" prio=5 tid=7 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x40511510 self=0x23bd90
  | sysTid=31067 nice=0 sched=0/0 cgrp=default handle=1970656
  at dalvik.system.NativeStart.run(Native Method)

"Binder Thread #1" prio=5 tid=6 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x405107b8 self=0x115050
  | sysTid=31066 nice=0 sched=0/0 cgrp=default handle=961144
  at dalvik.system.NativeStart.run(Native Method)

"Compiler" daemon prio=5 tid=5 VMWAIT
  | group="system" sCount=1 dsCount=0 obj=0x4050f830 self=0x1e0fc8
  | sysTid=31065 nice=0 sched=0/0 cgrp=default handle=1131672
  at dalvik.system.NativeStart.run(Native Method)

"Signal Catcher" daemon prio=5 tid=4 RUNNABLE
  | group="system" sCount=0 dsCount=0 obj=0x4050f770 self=0x113c18
  | sysTid=31064 nice=0 sched=0/0 cgrp=default handle=592688
  at dalvik.system.NativeStart.run(Native Method)

"GC" daemon prio=5 tid=3 VMWAIT
  | group="system" sCount=1 dsCount=0 obj=0x4050f6c8 self=0x1df6d0
  | sysTid=31063 nice=0 sched=0/0 cgrp=default handle=1131968
  at dalvik.system.NativeStart.run(Native Method)

"HeapWorker" daemon prio=5 tid=2 VMWAIT
  | group="system" sCount=1 dsCount=0 obj=0x4050f610 self=0xea940
  | sysTid=31062 nice=0 sched=0/0 cgrp=default handle=1132760
  at dalvik.system.NativeStart.run(Native Method)


Hi!

Can anyone give some information about how to build ffplay.c using pelya SDL port ?


Thank you!

hey i just started using this port. But i fail from the start using the command android update project -p project the probleem seems to be that androidmanifest.xml is missing, the readme does not really mention you have to create your own and it's the first command one has to type. Is it normal that androidmanifest.xml is missing in the project directory after doing a git clone ?

/opt/Android_SDK/commandergenius$ android update project -p project
Error: project is not a valid project (AndroidManifest.xml not found).
joyrider@joyrider-I7:/opt/Android_SDK/commandergenius$

Please launch "ChangeAppSettings.sh -a ", it will create that file

ah will try that tonight, i guess i have to call android update project -p project and ChangeAppSettings.sh -a again afterwards then ? or the last ChangeAppSettings.sh -a is not needed again then?

I also called ChangeAppSettings.sh at some point and could build all jni sources but the ant debug call failed with some message regarding that it could not find a certain target in DemoActivity. So i thought it was due to the fact i skipped the android update project call. I'll start over tonight and see how far i can get and i get the problem again i'll post the result here.

Thanks

just like to say that i got everything working.

I could even compile my sources straight out of the box but it ran utterly slow which i found a bit weird since the original sources of my game were made for the nokia N810 which although ran linux nativly has worse specs then my htc desire does.

I didn't had time to delve deeper in what's causing the slowdowns i only did a simpel compile without changing anything. The game uses software surfaces with 16 bit graphics, mod music files (so i guess libmikmod is used) and simple wav files for sound. I did have certain screens transitions on a pixel level so my guess is at the moment is that it's this what's causing all of the slow donws. On the nokia n810 the game ran full speed but on my phone i get to see a bit of the screen after like 20-30 seconds.

Anyway i'll have to investigate further to seek out what's causing the slowdowns, but i was wondering if any of you had some pointers where to look at in general when using this port ? Thing one shouldn't do etc. or things you came accross that had a severe negative impact.

Hello pelya--

As discussed on this page, I just made a commit to support calling back to the Java functionality, providing JNI bindings. All the pieces of this are hidden behind the RELEASE_BUILD preprocessor, so no existing code should be affected.

It's used in C like this:

Code: Select all

static JNIEnv*  static_env;
static jobject static_thiz;

static jobject JavaVideoThread;
static jclass JavaVideoThreadClass;

static jmethodID JavaControlAccelerometerId;

#ifdef RELEASE_BUILD
int main(int argc, char *argv[], JNIEnv*  env, jobject thiz)
#else
int main(int argc, char *argv[])
#endif
{
// do some things
#ifdef RELEASE_BUILD
static_env = env;
   static_thiz = thiz;
 
   JavaVideoThread = (*static_env)->NewGlobalRef(static_env, static_thiz);
   JavaVideoThreadClass = (*static_env)->GetObjectClass(static_env, JavaVideoThread);
   
   JavaControlAccelerometerId = (*static_env)->GetMethodID(static_env, JavaVideoThreadClass, "controlAccelerometer", "(I)V");

(*static_env)->CallVoidMethod(static_env, JavaVideoThread, JavaControlAccelerometerId, 1 );


After you call NewGlobalRef() and GetObjectClass(), you can pretty much refer to any Java method. In this useless example, I'm calling the method controlAccelerometer, which enables & disables the accelerometer in the Java code.

Edit: more code. In the Video.java file, you can then add a piece like this:

Code: Select all

AccelerometerReader accelerometer = = new AccelerometerReader(context); // do this in onDrawFrame

public void controlAccelerometer(int flip)
   {
      class Callback implements Runnable
      {
         public int b;
         public void run()
         {
            accelerometer.setEnableAccelerometer(b);
         }
      }
      Callback cb = new Callback();
      cb.b = flip;
      context.runOnUiThread(cb);
   }


As far as I understand, all Java code that JNI refers to needs to be implemented in Video.java