Bye-bye... SDL-for-Android

Hi,

You might know that one can write Android apps without 1 line of java code? It works via the ‘native interface’, which is supporting all startup and resume events, all sensors, as well as touch and multitouch. What more would a developer desire?

Thus I am starting a new project, using OpenGL for graphics, OpenSL for audio, and C++ for the rest. No SDL needed. It is not my intention to re-invent the wheel, so:

Starting point: Android project ‘native-activity’ from android-ndk-r8b.

Learning OpenGL: http://www.glprogramming.com/red/

Borrowing source code:
GUI toolkits GLV: http://mat.ucsb.edu/glv/
and GIGI: http://gigi.sourceforge.net/

Fonts and low-latency audio:
My own project And-Sdl: http://members.chello.nl/w.boeke/and-sdl/

Plus: all features from an Android phone or tablet that are not supported by the native interface, like USB and services from other applications, would still be accessable via the java interface.

By the way: Google might regret that they once did choose for java. All their essential building blocks are in C: the kernel, the graphics engine, etc. The interaction between java and C is very complicated, which actually is hidden for the user. At that, C and C++ are much nicer to code in. All other mobile platforms are using (a version of) C. However, maybe things are changing: if you search (with ohloh) for code containing ‘android_native_app_glue.h’ (which is the api for native code), then you will find a lot of hits from the Android project ‘DART language’.

Regards, maybe I’ll be back here sometimes,
Wouter Boeke

What more would a developer desire?

  • video playback
  • facebook integration
  • in-app purchases
  • webview integration
  • http network access - have fun building curl for android
  • etc.

Ironically, android version of our game started with inhouse
native-activity engine and that switched to SDL :)On Sat, Apr 6, 2013 at 6:54 PM, wboe <w.boeke at upcmail.nl> wrote:

Hi,

You might know that one can write Android apps without 1 line of java code?
It works via the ‘native interface’, which is supporting all startup and
resume events, all sensors, as well as touch and multitouch. What more would
a developer desire?

Thus I am starting a new project, using OpenGL for graphics, OpenSL for
audio, and C++ for the rest. No SDL needed. It is not my intention to
re-invent the wheel, so:

Starting point: Android project ‘native-activity’ from android-ndk-r8b.

Learning OpenGL: http://www.glprogramming.com/red/

Borrowing source code:
GUI toolkits GLV: http://mat.ucsb.edu/glv/
and GIGI: http://gigi.sourceforge.net/

Fonts and low-latency audio:
My own project And-Sdl: http://members.chello.nl/w.boeke/and-sdl/

Plus: all features from an Android phone or tablet that are not supported by
the native interface, like USB and services from other applications, would
still be accessable via the java interface.

By the way: Google might regret that they once did choose for java. All
their essential building blocks are in C: the kernel, the graphics engine,
etc. The interaction between java and C is very complicated, which actually
is hidden for the user. At that, C and C++ are much nicer to code in. All
other mobile platforms are using (a version of) C. However, maybe things are
changing: if you search (with ohloh) for code containing
’android_native_app_glue.h’ (which is the api for native code), then you
will find a lot of hits from the Android project ‘DART language’.

Regards, maybe I’ll be back here sometimes,
Wouter Boeke


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

You might know that one can write Android apps without 1 line of java code? It works via the ‘native interface’, which is supporting all startup and resume events, all sensors, as well as touch and multitouch. What more would a developer desire?

Also native interface is present only from a particular version of
android and around 50% of devices do not have that yet!

By the way sdl runs on more than one platform…

Regards, maybe I’ll be back here sometimes,
Wouter Boeke

Cheers! Make sure to close the door, it’s cold outside :wink:

VittorioIl giorno 06/apr/2013, alle ore 08:54, wboe <w.boeke at upcmail.nl> ha scritto:

What more would a developer desire?

  • video playback
  • facebook integration
  • in-app purchases
  • webview integration
  • http network access - have fun building curl for android
  • etc.

My reply was alredy in my first post:

Plus: all features from an Android phone or tablet that are not supported by the native interface, like USB and services from other applications, would still be accessable via the java interface.

Also, don’t forget that SDL itself is written in C. So if you strip the Android part from it, it could be used unmodified as native part for Android.

Also native interface is present only from a particular version of
android and around 50% of devices do not have that yet!

Thus: my native code would run fine on the other 50%.

Cheers! Make sure to close the door, it’s cold outside!

Actually, the weather outside is fine now, spring has started finally! At that, I have some former projects using SDL and I am still using and maintaining them. SDL has always been a pleasure to work with, only the Android part is far from perfect yet. So: See ya! (quoting Sam Lantinga)

To quote myself:

Also, don’t forget that SDL itself is written in C. So if you strip the Android part from it, it could be used unmodified as native part for Android.

That was not stated very correctly. Better: SDL could be used as it is, only the Android part should be re-written such that it does not use the java-C interface, the JNI. Then applications written on top of SDL could be ported as easily as allways. Applications written for the desktop would have to be modified anyhow, because a touch interface is very different from a mouse+keyboard interface.

I don’t think only 50% of devices qualifies as a good benchmark…

And yeah, there are lots of phones with old Android versions (more
specifically Android 2, for some reason Android 3 is barely heard of).
I have this conspiracy theory that carriers are tying the Android
version to the price. Yeah, unlikely, that’s why it’s a conspiracy,
but hey :v

2013/4/7, wboe <w.boeke at upcmail.nl>:>

What more would a developer desire?

  • video playback
  • facebook integration
  • in-app purchases
  • webview integration
  • http network access - have fun building curl for android
  • etc.

My reply was alredy in my first post:

Plus: all features from an Android phone or tablet that are not supported
by the native interface, like USB and services from other applications,
would still be accessable via the java interface.

Also, don’t forget that SDL itself is written in C. So if you strip the
Android part from it, it could be used unmodified as native part for
Android.

Also native interface is present only from a particular version of
android and around 50% of devices do not have that yet!

Thus: my native code would run fine on the other 50%.

Cheers! Make sure to close the door, it’s cold outside!

Actually, the weather outside is fine now, spring has started finally! At
that, I have some former projects using SDL and I am still using and
maintaining them. SDL has always been a pleasure to work with, only the
Android part is far from perfect yet. So: See ya! (quoting Sam Lantinga)

Yeah it’s more like 10% that don’t support native activity (Android 2.3+,
just like SDL’s minimum). Native activities can still use JNI. There is
overhead in using JNI a lot like the current SDL does. What are the
drawbacks to using native activity instead?

btw, it’s not a conspiracy, it’s capitalism. Some mobile phone
manufacturers tend to treat smartphones as cellphones, those things that
you throw away when you want a newer version of anything. The conspiracy
would be that most consumers are complicit.

Jonny DOn Sun, Apr 7, 2013 at 5:19 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

I don’t think only 50% of devices qualifies as a good benchmark…

And yeah, there are lots of phones with old Android versions (more
specifically Android 2, for some reason Android 3 is barely heard of).
I have this conspiracy theory that carriers are tying the Android
version to the price. Yeah, unlikely, that’s why it’s a conspiracy,
but hey :v

2013/4/7, wboe <w.boeke at upcmail.nl>:

What more would a developer desire?

  • video playback
  • facebook integration
  • in-app purchases
  • webview integration
  • http network access - have fun building curl for android
  • etc.

My reply was alredy in my first post:

Plus: all features from an Android phone or tablet that are not
supported

by the native interface, like USB and services from other applications,
would still be accessable via the java interface.

Also, don’t forget that SDL itself is written in C. So if you strip the
Android part from it, it could be used unmodified as native part for
Android.

Also native interface is present only from a particular version of
android and around 50% of devices do not have that yet!

Thus: my native code would run fine on the other 50%.

Cheers! Make sure to close the door, it’s cold outside!

Actually, the weather outside is fine now, spring has started finally! At
that, I have some former projects using SDL and I am still using and
maintaining them. SDL has always been a pleasure to work with, only the
Android part is far from perfect yet. So: See ya! (quoting Sam Lantinga)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/4/7 wboe <w.boeke at upcmail.nl>

**
To quote myself:

Quote:

Also, don’t forget that SDL itself is written in C. So if you strip the
Android part from it, it could be used unmodified as native part for
Android.

That was not stated very correctly. Better: SDL could be used as it is,
only the Android part should be re-written such that it does not use the
java-C interface, the JNI. Then applications written on top of SDL could be
ported as easily as allways. Applications written for the desktop would
have to be modified anyhow, because a touch interface is very different
from a mouse+keyboard interface.

There’s been failed attempts at implementing SDL on top of the native glue
code (http://bugzilla.libsdl.org/show_bug.cgi?id=1383) . I guess that quest
is still looking for the right hero, are you up for it?

Also, SDL has this neat feature of supporting a lot of platforms, if you
are focusing exclusively on Android, then there’s certainly more direct
ways of developing an app.–
Gabriel.

Depends, if I went Linux-only I’d still stick to SDL just because of
how many headaches it saves (there are so many system configurations
and such that getting it right by programming the OS APIs directly is
just painful). Given how fragmented is Android, I wonder if that’s the
case there too?

And I said the conspiracy thing because I have absolutely no proof of
it XD I just find it curious Android 2 is still around in such a large
amount when carriers generally stop supporting phones that are older
than a year. Anyway, that’s off-topic to this thread.

2013/4/7, Gabriel Jacobo :> 2013/4/7 wboe <w.boeke at upcmail.nl>

**
To quote myself:

Quote:

Also, don’t forget that SDL itself is written in C. So if you strip the
Android part from it, it could be used unmodified as native part for
Android.

That was not stated very correctly. Better: SDL could be used as it is,
only the Android part should be re-written such that it does not use the
java-C interface, the JNI. Then applications written on top of SDL could
be
ported as easily as allways. Applications written for the desktop would
have to be modified anyhow, because a touch interface is very different
from a mouse+keyboard interface.

There’s been failed attempts at implementing SDL on top of the native glue
code (http://bugzilla.libsdl.org/show_bug.cgi?id=1383) . I guess that quest
is still looking for the right hero, are you up for it?

Also, SDL has this neat feature of supporting a lot of platforms, if you
are focusing exclusively on Android, then there’s certainly more direct
ways of developing an app.


Gabriel.

I think even native activity calls JNI methods under the hood.Have a look

http://en.wikibooks.org/wiki/OpenGL_Programming/Android_GLUT_Wrapper#Android_Events

I think there is no real reason that sdl should switch to native activity
instead of a java activity as entry point.On Sun, Apr 7, 2013 at 10:09 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

Depends, if I went Linux-only I’d still stick to SDL just because of
how many headaches it saves (there are so many system configurations
and such that getting it right by programming the OS APIs directly is
just painful). Given how fragmented is Android, I wonder if that’s the
case there too?

And I said the conspiracy thing because I have absolutely no proof of
it XD I just find it curious Android 2 is still around in such a large
amount when carriers generally stop supporting phones that are older
than a year. Anyway, that’s off-topic to this thread.

2013/4/7, Gabriel Jacobo :

2013/4/7 wboe <w.boeke at upcmail.nl>

**
To quote myself:

Quote:

Also, don’t forget that SDL itself is written in C. So if you strip the
Android part from it, it could be used unmodified as native part for
Android.

That was not stated very correctly. Better: SDL could be used as it is,
only the Android part should be re-written such that it does not use the
java-C interface, the JNI. Then applications written on top of SDL could
be
ported as easily as allways. Applications written for the desktop would
have to be modified anyhow, because a touch interface is very different
from a mouse+keyboard interface.

There’s been failed attempts at implementing SDL on top of the native
glue
code (http://bugzilla.libsdl.org/show_bug.cgi?id=1383) . I guess that
quest
is still looking for the right hero, are you up for it?

Also, SDL has this neat feature of supporting a lot of platforms, if you
are focusing exclusively on Android, then there’s certainly more direct
ways of developing an app.


Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

When you develop a pure native Android app, you’re not magically bypassing the JNI. The app still initializes Dalvik and calls the Java app interface, which then calls the C glue code via JNI; and when the C glue code needs something from the Android API, it still calls via JNI.

When profiling you might notice a performance benefit from using the app interface properly, rather than trying to obscure it away like SDL currently does, but I’d be terribly surprised if the end-user noticed.

It’s also probable that the glue code is optimized better than SDL’s accesses to the Java interfaces, but that just signifies room for improvement in SDL’s code (fortunately, Android is open-source ;)).------------------------
Nate Fries

If I recall correctly support for native code in general is pretty
poor, both API-wise and toolchain-wise. Google really expects
developers to do everything in Java when it comes to Android. It isn’t
surprising that performance is much better when using the Java
interface directly.

SDL also has the issue of originally being made for a paradigm much
different from the used in phones, so that probably isn’t helping. I’m
not sure to what extent this affects performance, though.

2013/4/7, Nathaniel J Fries :> When you develop a pure native Android app, you’re not magically bypassing

the JNI. The app still initializes Dalvik and calls the Java app interface,
which then calls the C glue code via JNI; and when the C glue code needs
something from the Android API, it still calls via JNI.

When profiling you might notice a performance benefit from using the app
interface properly, rather than trying to obscure it away like SDL currently
does, but I’d be terribly surprised if the end-user noticed.

It’s also probable that the glue code is optimized better than SDL’s
accesses to the Java interfaces, but that just signifies room for
improvement in SDL’s code (fortunately, Android is open-source ;)).


Nate Fries

Coder Bear wrote:

That is a good point. But it is not just Google, it gets even worse as Apple wants to to write and learn and entirely new and uncommon language that costs money just to learn it as the only way to truly code it is on a Mac.

At least on iOS, you can access system APIs using native code.------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com

Probably because Objective-C is based off C so basically C code “just
works” (mostly). With Java it’s a completely different issue.

2013/4/8, RodrigoCard :>

Coder Bear wrote:

That is a good point. But it is not just Google, it gets even worse as
Apple wants to to write and learn and entirely new and uncommon language
that costs money just to learn it as the only way to truly code it is on a
Mac.

At least on iOS, you can access system APIs using native code.


Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com

Coder Bear wrote:

That is a good point. But it is not just Google, it gets even worse as Apple wants to to write and learn and entirely new and uncommon language that costs money just to learn it as the only way to truly code it is on a Mac.

Or, if you have a friend with the mac, you can download developer tools and the iOS SDK, transfer it to your computer (via thumbdrive or whatever), build your own copy of Apple’s GCC for ARM, and use your Windows/Linux IDE of choice… ofc you need to root your device to test, which means violating U.S. federal law (and probably whatever warranty iPhones have), but anyways. :expressionless:

Also, I use GNUStep for initial Mac porting on the rare occasion that it’s necessary. Even if the code doesn’t actually build for Mac as it does on Windows/Linux, it’s usually some small change only that’s needed.------------------------
Nate Fries

That is a good point. But it is not just Google, it gets even worse as Apple wants to to write and learn and entirely new and uncommon language that costs money just to learn it as the only way to truly code it is on a Mac.