Discussion:
[SDL] Possible To Use SDL2 & Android Studio 2 On Linux?
JeZ-l-Lee
2017-01-21 16:19:37 UTC
Permalink
Hi,

I've taken a second look at SDL2 for Android O.S. smartphones & tablets.
I have some question now:
- Does SDL2_Image, SDL2_Mixer, & SDL2_TTF work on Android O.S. ?
- Can I setup SDL2 and above 3 support libraries to work in current Android Studio 2 on Linux?
(URL link to a good tutorial would be great)
- Does SDL2 on Android O.S. utilize hardware accelerated drawings?

Thanks...

------------------------
JeZxLee
JessePalser <AT> GMail <DOT> com
16BitSoft Inc.
Video Game Design Studio
www.16BitSoft.com
maartenengels
2017-01-23 08:04:28 UTC
Permalink
You can but its a crappy way. You will have no debug support, and the whole thing is smelly.

Check:
- taworn/tankdroid (Good project to see how to build everything for android studio.)
- android-sdl2-gradle-template (And use this one as your template project)

Hope this is somewhere to start.
Eric Wing
2017-01-23 17:44:32 UTC
Permalink
Post by JeZ-l-Lee
Hi,
I've taken a second look at SDL2 for Android O.S. smartphones & tablets.
- Does SDL2_Image, SDL2_Mixer, & SDL2_TTF work on Android O.S. ?
Yes, probably, yes.

I’ve use ALmixer for years on Android. It is used commercially in a
few engines, such the Corona SDK, so it has been hammered and debugged
throughly on a bunch of specific Android problems. I finally have a
native OpenSL ES backend decoder for it because the codec dependency
hell and bloat. (All the dependencies are a PITA and then there are
the potential patent issues on some codecs.) SDL_mixer probably works
too, though I can’t attest to how much of a pain it is to build and
how many of the Android issues have been worked through. (By Android
issues, it can be a wide range from manufacturer specific issues to
Android version specific issues, to general Android issues.)
Post by JeZ-l-Lee
- Can I setup SDL2 and above 3 support libraries to work in current Android
Studio 2 on Linux?
You *can*. But you will have to implement it all yourself (or use my
SDK mentioned below). I think I’m one of the few that has pushed very
hard into this frontier, and am probably further along than most

(See my Blurrr SDK intro video starting at

The Android demo is in part 3.
)

However, as maartenengels, things are crappy. I don’t have NDK
debugger support still. (The NDK clang switch-over would have been
disruptive if not for the fact that gdb never really worked to begin
with.) But the bigger primary goal for Blurrr was to help manage the
wide range (currently 6 platforms) of native build systems while still
allowing access to the native toolchain. (Stuff like the adb bridge,
profile tools, and Java debugging is still accessible.)

The Android NDK is a nightmare and the Android tools keep changing and
breaking. Android Studio for the most part doesn’t care about the NDK
so integration has sucked. They recently started rolling out new CMake
support, but they’ve now caused a new kind of fragmentation because
most of the world has been working off a forked version of OpenCV’s
CMake toolchain for many years now. And CMake itself was starting to
introduce its own built-in support, so now we have 3 incompatible
systems.
Post by JeZ-l-Lee
(URL link to a good tutorial would be great)
- Does SDL2 on Android O.S. utilize hardware accelerated drawings?
Yes. It believe it is using OpenGL ES.


So, everything is possible, but you will probably have to do a bunch
of work yourself.

If you would like to try out Blurrr, feel free to contact me directly.
It is designed to tackle a lot of these annoying platform specific
problems so you can just focus on your game. (Though I currently don’t
include SDL_mixer since I have ALmixer. I might eventually add it, but
it has been lower on my priority list.)

Thanks,
Eric
https://blurrrsdk.com
Daniel Gibson
2017-01-23 18:06:44 UTC
Permalink
Post by Eric Wing
I’ve use ALmixer for years on Android. It is used commercially in a
few engines, such the Corona SDK, so it has been hammered and debugged
throughly on a bunch of specific Android problems. I finally have a
native OpenSL ES backend decoder for it because the codec dependency
hell and bloat. (All the dependencies are a PITA and then there are
the potential patent issues on some codecs.) SDL_mixer probably works
too, though I can’t attest to how much of a pain it is to build and
how many of the Android issues have been worked through. (By Android
issues, it can be a wide range from manufacturer specific issues to
Android version specific issues, to general Android issues.)
With "I've used" you mean "I wrote it"? ;-)
Didn't know about ALmixer before, looks pretty good!

One thing I wondered about is: You mention iOS support, but the license
is LGPL - isn't LGPL incompatible with iOS?
At least I think that this is a reason openal-soft isn't available on iOS.

Cheers,
Daniel
Eric Wing
2017-01-23 18:22:22 UTC
Permalink
Post by Daniel Gibson
Post by Eric Wing
I’ve use ALmixer for years on Android. It is used commercially in a
few engines, such the Corona SDK, so it has been hammered and debugged
throughly on a bunch of specific Android problems. I finally have a
native OpenSL ES backend decoder for it because the codec dependency
hell and bloat. (All the dependencies are a PITA and then there are
the potential patent issues on some codecs.) SDL_mixer probably works
too, though I can’t attest to how much of a pain it is to build and
how many of the Android issues have been worked through. (By Android
issues, it can be a wide range from manufacturer specific issues to
Android version specific issues, to general Android issues.)
With "I've used" you mean "I wrote it"? ;-)
Didn't know about ALmixer before, looks pretty good!
One thing I wondered about is: You mention iOS support, but the license
is LGPL - isn't LGPL incompatible with iOS?
At least I think that this is a reason openal-soft isn't available on iOS.
So Apple ships their own OpenAL version with Mac and iOS, so there are
no license issues with that.

ALmixer was originally written in 2002-ish, back when SDL was LGPL. It
seemed like a good idea at the time. Oops.

I've been going through a relicensing thing for awhile now. I haven't
promoted it mostly because I'm not fully done, but basically I'm
moving towards zlib like SDL is now.

So for iOS, as long as you use the Core Audio decoder (default for Mac
& iOS), you are good (since I wrote that and rewrote the shim
interfaces for it...don't use SDL_sound).

The .wav and .ogg codec I pulled from SDL_sound which is LGPL which is
why the migration isn't complete.

I have native Android OpenSL ES, Windows Media Foundation, and Apple
Core Audio decoders, so I can mostly avoid these codecs except on
Linux, which is already a bag of LGPL and dynamic linking, so it's not
a big problem there.

Anyway, if you want to use ALmixer on iOS with the Core Audio codec, I
won't go after you. :)

(If somebody wants to help me and get a zlib-like implementation for
these 2 codecs, I would appreciate it. This could either be a rewrite,
or Ryan Gordon determining that those codec parts were written by him
and relicensing it under zlib. I've been meaning to follow up with him
about this, but it keeps falling to the bottom of my list.)

Thanks,
Eric
Daniel Gibson
2017-01-23 18:52:07 UTC
Permalink
Post by Eric Wing
Post by Daniel Gibson
One thing I wondered about is: You mention iOS support, but the license
is LGPL - isn't LGPL incompatible with iOS?
At least I think that this is a reason openal-soft isn't available on iOS.
So Apple ships their own OpenAL version with Mac and iOS, so there are
no license issues with that.
ALmixer was originally written in 2002-ish, back when SDL was LGPL. It
seemed like a good idea at the time. Oops.
I've been going through a relicensing thing for awhile now. I haven't
promoted it mostly because I'm not fully done, but basically I'm
moving towards zlib like SDL is now.
Cool!
Post by Eric Wing
So for iOS, as long as you use the Core Audio decoder (default for Mac
& iOS), you are good (since I wrote that and rewrote the shim
interfaces for it...don't use SDL_sound).
The .wav and .ogg codec I pulled from SDL_sound which is LGPL which is
why the migration isn't complete.
I gotta admit I'm surprised SDL_sound is (still) licensed under LGPL,
but maybe relicensing is hard due to external contributions?
Post by Eric Wing
I have native Android OpenSL ES, Windows Media Foundation, and Apple
Core Audio decoders, so I can mostly avoid these codecs except on
Linux, which is already a bag of LGPL and dynamic linking, so it's not
a big problem there.
Anyway, if you want to use ALmixer on iOS with the Core Audio codec, I
won't go after you. :)
Good to know :)
Post by Eric Wing
(If somebody wants to help me and get a zlib-like implementation for
these 2 codecs, I would appreciate it. This could either be a rewrite,
or Ryan Gordon determining that those codec parts were written by him
and relicensing it under zlib. I've been meaning to follow up with him
about this, but it keeps falling to the bottom of my list.)
At least libogg and libvorbis and libvorbisfile are under BSD license;
there is also stb_vorbis which is public domain.
The "glue" to ALmixer would have to be rewritten, but it doesn't seem to
be that much code..
For decoding wav https://github.com/nothings/single_file_libs#audio
lists some single file headers under liberal licenses (no idea how good
those are).

Cheers,
Daniel
Eric Wing
2017-01-24 18:02:05 UTC
Permalink
Post by Daniel Gibson
Post by Eric Wing
Post by Daniel Gibson
One thing I wondered about is: You mention iOS support, but the license
is LGPL - isn't LGPL incompatible with iOS?
At least I think that this is a reason openal-soft isn't available on iOS.
So Apple ships their own OpenAL version with Mac and iOS, so there are
no license issues with that.
ALmixer was originally written in 2002-ish, back when SDL was LGPL. It
seemed like a good idea at the time. Oops.
I've been going through a relicensing thing for awhile now. I haven't
promoted it mostly because I'm not fully done, but basically I'm
moving towards zlib like SDL is now.
Cool!
Post by Eric Wing
So for iOS, as long as you use the Core Audio decoder (default for Mac
& iOS), you are good (since I wrote that and rewrote the shim
interfaces for it...don't use SDL_sound).
The .wav and .ogg codec I pulled from SDL_sound which is LGPL which is
why the migration isn't complete.
I gotta admit I'm surprised SDL_sound is (still) licensed under LGPL,
but maybe relicensing is hard due to external contributions?
Post by Eric Wing
I have native Android OpenSL ES, Windows Media Foundation, and Apple
Core Audio decoders, so I can mostly avoid these codecs except on
Linux, which is already a bag of LGPL and dynamic linking, so it's not
a big problem there.
Anyway, if you want to use ALmixer on iOS with the Core Audio codec, I
won't go after you. :)
Good to know :)
Post by Eric Wing
(If somebody wants to help me and get a zlib-like implementation for
these 2 codecs, I would appreciate it. This could either be a rewrite,
or Ryan Gordon determining that those codec parts were written by him
and relicensing it under zlib. I've been meaning to follow up with him
about this, but it keeps falling to the bottom of my list.)
At least libogg and libvorbis and libvorbisfile are under BSD license;
there is also stb_vorbis which is public domain.
The "glue" to ALmixer would have to be rewritten, but it doesn't seem to
be that much code..
For decoding wav https://github.com/nothings/single_file_libs#audio
lists some single file headers under liberal licenses (no idea how good
those are).
Yeah, I've actually written to the Ogg Vorbis APIs before without
SDL_sound, and they were among the easier to use APIs. (In contrast, I
recall being very grumpy with Windows Media Foundation.) However,
since I've seen and worked with the SDL_sound Vorbis implementation
(in fact, I wrote the Ogg Tremor decoder based on it), I want to be
careful about the appearance of "contamination" since I've seen the
other implementation. So I'm kind of hoping somebody might volunteer
to help me and contribute one. It's been many, many years now since
I've looked at the implementation so maybe what I write will feel
perfectly clean.

As for WAV, stb is a pretty good idea. I was also thinking of just
borrowing directly from SDL now that it is zlib.

But time constraints and all, I'm kind of hoping I just get a
contributor, or Ryan just decides to re-license SDL_sound under zlib
(or at least just the parts I use), and then the problem is solved.

Thanks,
Eric

Continue reading on narkive:
Search results for '[SDL] Possible To Use SDL2 & Android Studio 2 On Linux?' (Questions and Answers)
5
replies
how can I be a game developer?
started 2013-08-02 17:12:40 UTC
programming & design
Loading...