Greetings bipeds,
I’ve decided to start writing my own cross-platform game. Obviously, I
first need to code a kernel, then a C library, etc. (You can already
see I’m completely nuts.) I’m not completely nuts, I’m not going to
design my own silicon. Yet.
Thing is, I’d like to rebuild the Android SDL glue a bit: it’s still a
bit tricky and I’d like to hide all the hairy bits away. It’s either
that, or consider Android and SDL as low-level and put a layer on a
layer. Yuck.
I’ve toyed around a bit with the NVIDIA TADP (basically a set of
"example" native-code libraries they promote for ease of porting), and
I managed to get something hinky running on it pretty quickly, but I
could not replicate my success with SDL. So here’s my proposal, and
then the caveats at the bottom.
I want to:
- Bring controller support up to an initial level (I’ve got a SHIELD
(Thanks NVIDIA!), and I also have wired and wireless XBOX 360
controllers and a PS3 controller)
- Start using NativeActivity glue in stead of the custom-rolled SDL activity.
- Try to figure out OpenSL ES Native audio.
- Attempt to get some sort of sane way to expose the Android
lifecycle, or write a lifecycle wrapper for desktop SDL.
Caveats:
- I want to retarget the Android glue to API-14 (ICS or later). This
allows native controllers (the API is about to go stable for 'em, I’m
not 100% sure it’s available for GB). It would mean less Java
thunking, which is always good.
- The native app glue C example code is licensed as APACHE-2.0. It’s
got a lot more restrictions than zlib, but the requirement of making
source available is not one. It would save a LOT of time if I could
derive the new glue from it in stead of cleanrooming it.
- You will have to respect the Android lifecycle (abstracted a bit): a
desktop SDL program will have to be broken up a bit and the relevant
functional pieces need to be moved into the correct lifecycle
sections.
Getting a desktop SDL program to run without modifications will always
be extremely tricky: desktop SDL has NO concept of lifecycle and it’s
a brilliant layer in that respect. Android (and iOS too, I believe)
uses a very different paradigm and current SDL is an uneasy fit, at
best.
So, before I embark on an epic coding session that will probably
result in a bit of dead-end code that taught me a lot, but is
basically useless, I have a few questions:
- Is the APACHE-2.0 vs zlib thing an issue? I would rather like to
build on battle-tested code than to cleanroom something like a newbie
(which I am), but if it means that it’s never going to get into SDL,
I’ll have a rethink.
- API-9 (Gingerbread) has almost everything I want to add (OpenSL
ES, NativeActivity), but depending on how Google stabilizes the
controller API (expected in the next NDK release), it might need Java
as a fallback to push the events back: that might look REALLY ugly. It
might not even HAVE game controller support! Then again, if you target
Gingerbread, you might not even need the controller support! Does
anyone have experience in multi-API native code? (If it’s a
compile-time decision, it’s easy. Runtime, I have no clue.)
- Would it make more sense to “break out” the bits in SDL that
emulates/manages the app lifecycle into a separate project
(SDL_framework or something?). The idea being that desktop SDL on
conventional OS’es can implement their own event loops, but that
mobile SDL (iOS, Android) need to respect the lifecycle and use
"canned" (but flexible!) event loops for battery efficiency, etc.
Anyway, thanks for wading through the diseased thoughts of a maniac.
Hopefully I actually get some time to implement the funny visions that
are polluting my mind.
Jan Gutter
Take a look at Bugzilla [1], you’ll find patches waiting for review that
add joystick support for Android and also a “Native Glue” patch as well.
I’ve been meaning to review, test and incorporate the joystick patch since
forever, and the other patch also has its merits (though no immediate
benefit for me), so while perhaps it’s not worth the effort of re inventing
the wheel (but by all means go ahead if that’s your thing!), you may want
to help reviewing and testing those. Any help is appreciated.
[1] https://bugzilla.libsdl.org
2013/10/10 Jan Gutter > Greetings bipeds,
I’ve decided to start writing my own cross-platform game. Obviously, I
first need to code a kernel, then a C library, etc. (You can already
see I’m completely nuts.) I’m not completely nuts, I’m not going to
design my own silicon. Yet.
Thing is, I’d like to rebuild the Android SDL glue a bit: it’s still a
bit tricky and I’d like to hide all the hairy bits away. It’s either
that, or consider Android and SDL as low-level and put a layer on a
layer. Yuck.
I’ve toyed around a bit with the NVIDIA TADP (basically a set of
"example" native-code libraries they promote for ease of porting), and
I managed to get something hinky running on it pretty quickly, but I
could not replicate my success with SDL. So here’s my proposal, and
then the caveats at the bottom.
I want to:
- Bring controller support up to an initial level (I’ve got a SHIELD
(Thanks NVIDIA!), and I also have wired and wireless XBOX 360
controllers and a PS3 controller)
- Start using NativeActivity glue in stead of the custom-rolled SDL
activity.
- Try to figure out OpenSL ES Native audio.
- Attempt to get some sort of sane way to expose the Android
lifecycle, or write a lifecycle wrapper for desktop SDL.
Caveats:
- I want to retarget the Android glue to API-14 (ICS or later). This
allows native controllers (the API is about to go stable for 'em, I’m
not 100% sure it’s available for GB). It would mean less Java
thunking, which is always good.
- The native app glue C example code is licensed as APACHE-2.0. It’s
got a lot more restrictions than zlib, but the requirement of making
source available is not one. It would save a LOT of time if I could
derive the new glue from it in stead of cleanrooming it.
- You will have to respect the Android lifecycle (abstracted a bit): a
desktop SDL program will have to be broken up a bit and the relevant
functional pieces need to be moved into the correct lifecycle
sections.
Getting a desktop SDL program to run without modifications will always
be extremely tricky: desktop SDL has NO concept of lifecycle and it’s
a brilliant layer in that respect. Android (and iOS too, I believe)
uses a very different paradigm and current SDL is an uneasy fit, at
best.
So, before I embark on an epic coding session that will probably
result in a bit of dead-end code that taught me a lot, but is
basically useless, I have a few questions:
- Is the APACHE-2.0 vs zlib thing an issue? I would rather like to
build on battle-tested code than to cleanroom something like a newbie
(which I am), but if it means that it’s never going to get into SDL,
I’ll have a rethink.
- API-9 (Gingerbread) has almost everything I want to add (OpenSL
ES, NativeActivity), but depending on how Google stabilizes the
controller API (expected in the next NDK release), it might need Java
as a fallback to push the events back: that might look REALLY ugly. It
might not even HAVE game controller support! Then again, if you target
Gingerbread, you might not even need the controller support! Does
anyone have experience in multi-API native code? (If it’s a
compile-time decision, it’s easy. Runtime, I have no clue.)
- Would it make more sense to “break out” the bits in SDL that
emulates/manages the app lifecycle into a separate project
(SDL_framework or something?). The idea being that desktop SDL on
conventional OS’es can implement their own event loops, but that
mobile SDL (iOS, Android) need to respect the lifecycle and use
"canned" (but flexible!) event loops for battery efficiency, etc.
Anyway, thanks for wading through the diseased thoughts of a maniac.
Hopefully I actually get some time to implement the funny visions that
are polluting my mind.
Jan Gutter
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Gabriel.
Hi,
Take a look at Bugzilla [1], you’ll find patches waiting for review that add
joystick support for Android and also a “Native Glue” patch as well.
Ah! I just found your bug about joystick support.
(https://bugzilla.libsdl.org/show_bug.cgi?id=1700)
Have you had a look at the NVIDIA guys’s TDK_Samples (nv_input
specifically)? The events get passed down to native code and the
native code queries the axis and button parameters using sneaky
AMotionEvent_getAxisValue method. It should be stabilised in the
near future.
The only bug I could find about NativeActivity is an oldish one.
(https://bugzilla.libsdl.org/show_bug.cgi?id=1383) I’ve had a look,
but it doesn’t support OpenSL ES and obviously not the controller.
I’ll recheck to see if I understand it better than basing it off the
NVIDIA samples.
I’ve been meaning to review, test and incorporate the joystick patch since
forever, and the other patch also has its merits (though no immediate
benefit for me), so while perhaps it’s not worth the effort of re inventing
the wheel (but by all means go ahead if that’s your thing!), you may want to
help reviewing and testing those. Any help is appreciated.
Thanks for the reminder! I tend to forget that other people have had
the exact same problems a lot of the time!
JanOn Thu, Oct 10, 2013 at 5:04 PM, Gabriel Jacobo wrote:
Apache2 is incompatible with gpl2 so that would prevent many GPL games to
use your code.
Also since Android seems the main topic of your post, you should be aware
tha newer android version always link your app with libapache2, effectively
imposing gpl3 over the final binary.
VittorioOn Thursday, October 10, 2013, Jan Gutter wrote:
- Is the APACHE-2.0 vs zlib thing an issue? I would rather like to
build on battle-tested code than to cleanroom something like a newbie
(which I am), but if it means that it’s never going to get into SDL,
I’ll have a rethink.
Apache2 is incompatible with gpl2 so that would prevent many GPL games to
use your code.
Thanks, that’s enough for me to decide on cleanrooming that portion at least.
Also since Android seems the main topic of your post, you should be aware
tha newer android version always link your app with libapache2, effectively
imposing gpl3 over the final binary.
I was really unaware of that: I had thought that bionic (the C
library) was BSD-style? I had a look at the headers and they are
licensed APACHE-2.0, but since they don’t contain code, they shouldn’t
force your license, I think. Then again, I am gleefully admitting my
ignorance here.
Certainly, linking statically with android_native_app_glue.c means the
rest of the code has to be APACHE-2.0 compatible: That’s the portion
that needs to get refactored into libSDL’s event-based system anyway.
Jan GutterOn Thu, Oct 10, 2013 at 10:34 PM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote: