Well, precisely my point. While an SDL app on a Linux desktop
might not have any concern about âshould I keep running in the backgroundâ
(it always will), an app on a mobile platform might need to worry about it.
Not sure if this really needs to be part of the SDL API, but Iâm guessing
SDL-level access to stuff like this would be handy. shrugOn Thu, May 27, 2010 at 06:58:19PM -0400, Donny Viszneki wrote:
On Thu, May 27, 2010 at 5:01 PM, Bill Kendrick <@Bill_Kendrick> wrote:
Itâd be nice to be able to hint what your app should do.
(e.g., a game should be happy enough to just save its state and quit,
but a music-playing app might want to continue running in the background)
i agree; also the new multitasking capability of iphoneos 4 could make
use of a âbackgroundingâ api
could someone add it to sdl roadmap http://wiki.libsdl.org/moin.cgi/Roadmap ?
VittorioOn Fri, May 28, 2010 at 1:29 AM, Bill Kendrick wrote:
On Thu, May 27, 2010 at 06:58:19PM -0400, Donny Viszneki wrote:
On Thu, May 27, 2010 at 5:01 PM, Bill Kendrick wrote:
Itâd be nice to be able to hint what your app should do.
(e.g., a game should be happy enough to just save its state and quit,
but a music-playing app might want to continue running in the background)
Also probably depends on the app
Well, precisely my point. ?While an SDL app on a Linux desktop
might not have any concern about âshould I keep running in the backgroundâ
(it always will), an app on a mobile platform might need to worry about it.
Not sure if this really needs to be part of the SDL API, but Iâm guessing
SDL-level access to stuff like this would be handy. ?shrug
Hasnât an SDL_mobile lib been suggested? Do such things need SDLâs
internals?
Jonny DOn Fri, May 28, 2010 at 1:05 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:
i agree; also the new multitasking capability of iphoneos 4 could make
use of a âbackgroundingâ api
could someone add it to sdl roadmap http://wiki.libsdl.org/moin.cgi/Roadmap ?
Vittorio
On Fri, May 28, 2010 at 1:29 AM, Bill Kendrick wrote:
On Thu, May 27, 2010 at 06:58:19PM -0400, Donny Viszneki wrote:
On Thu, May 27, 2010 at 5:01 PM, Bill Kendrick wrote:
Itâd be nice to be able to hint what your app should do.
(e.g., a game should be happy enough to just save its state and quit,
but a music-playing app might want to continue running in the
background)
Also probably depends on the app
Well, precisely my point. While an SDL app on a Linux desktop
might not have any concern about âshould I keep running in the
backgroundâ
(it always will), an app on a mobile platform might need to worry about
it.
Not sure if this really needs to be part of the SDL API, but Iâm
guessing
SDL-level access to stuff like this would be handy. shrug
Would be nice if such lib existed - mobile devices require some rather
special things like on-screen keyboard, automatic screen resizing to support
variety of uncommon display resolutions, option to rebind keys of rather
limited keyboard to some common keys from application point of view etc.On Fri, May 28, 2010 at 3:04 PM, Jonathan Dearborn wrote:
Hasnât an SDL_mobile lib been suggested? Do such things need SDLâs
internals?
Jonny D
On Fri, May 28, 2010 at 1:05 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:
i agree; also the new multitasking capability of iphoneos 4 could make
use of a âbackgroundingâ api
could someone add it to sdl roadmap http://wiki.libsdl.org/moin.cgi/Roadmap ?
Vittorio
On Fri, May 28, 2010 at 1:29 AM, Bill Kendrick wrote:
On Thu, May 27, 2010 at 06:58:19PM -0400, Donny Viszneki wrote:
On Thu, May 27, 2010 at 5:01 PM, Bill Kendrick wrote:
Itâd be nice to be able to hint what your app should do.
(e.g., a game should be happy enough to just save its state and quit,
but a music-playing app might want to continue running in the
background)
Also probably depends on the app
Well, precisely my point. While an SDL app on a Linux desktop
might not have any concern about âshould I keep running in the
backgroundâ
(it always will), an app on a mobile platform might need to worry about
it.
Not sure if this really needs to be part of the SDL API, but Iâm
guessing
SDL-level access to stuff like this would be handy. shrug
It would not be hard to create an SDL_mobile lib with these basic features.
Like usual, I say to bask in the glory of open-source if this is actually of any concern to you. That, of course, meaning: do it yourself and contribute it to the community.
SDL devs still gotta worry about stabilizing on the major platforms of Windows, X11 (Linux/BSD/etc), and OS X. Mobile devices are a point of interest, but not so much concern. This is really something that should be done by the community.
That, or make a suggestion for the next GSoC; since honestly it would be a great project for that once the Android portâs complete.------------------------
EM3 Nathaniel Fries, U.S. Navy
I have some doubts how such a library could work in a non rooted Android
system.
SDL applications on Android have to be coded as libraries with a bit of Java
code, that serves as
glue between standard Android applications and the C and C++ worlds.
All the notification APIs about the process state are in Java, which means
you will need several
points of communication between the SDL application, now running as a
library, and the standard
way to get these notifications in Android.
Regards,
PauloOn Fri, May 28, 2010 at 5:52 PM, Nathaniel J Fries wrote:
It would not be hard to create an SDL_mobile lib with these basic
features.
Like usual, I say to bask in the glory of open-source if this is actually
of any concern to you. That, of course, meaning: do it yourself and
contribute it to the community. [image: Very Happy]
SDL devs still gotta worry about stabilizing on the major platforms of
Windows, X11 (Linux/BSD/etc), and OS X. Mobile devices are a point of
interest, but not so much concern. This is really something that should be
done by the community.
That, or make a suggestion for the next GSoC; since honestly it would be a
great project for that once the Android portâs complete.
I have some doubts how such a library could work in a non rooted Android system.
SDL applications on Android have to be coded as libraries with a bit of Java code, that serves as
glue between standard Android applications and the C and C++ worlds.
All the notification APIs about the process state are in Java, which means you will need several
points of communication between the SDL application, now running as a library, and the standard
way to get these notifications in Android.
Regards,
Paulo
The âglueâ between Java and C is called âJava Native Interfaceâ.
And, while itâs unsightly and somewhat painful to use, it is effective at its job. Without doing any rooting or excessive hacking, one could access all of Androidâs Java APIs through JNI.------------------------
EM3 Nathaniel Fries, U.S. Navy
i am just getting to this part in coding my game ( the saving state resuming
state ) new to java and i think its a java thing, you have to bundle your
data for it to decide if it wants to be resumed with data, presumably the
bundle is some freaked out java struct type thing, and as it will usually
want to be doing this pretty much seamlessly as you take a call, switch app,
or whatever the amount of data you can throw around at this point has to be
really small or it will clog the phone up, if i want my isometric pacman
clone to behave fully androidy then for each time an app interrupts of the
view is changed i have to store all the data in the current game to a little
bundle then get it back out the bundle, so my pacman clone is currently a
20x20 grid of data holding blobs walls, so the easiest way to store that is
put it all into a string and then rebuild the level from that string when
onResume is called, along with whatever other variable i need to recreate a
level mid game, character position, baddies position score, everything. if
the phone rings or the orientation is changed by flipping out the keyboard (
or turning the phone round to landscape in new models dunno ) the app is
killed and restarted, its the little bundle you give it when it is half
killed that makes it appear to have been still running.
just thought iâd let you lot know of my finding while android probing, its
all fun. in a sick way
with the power these latest handsets have there isnât much to argue against
some sort of override for these functions and just keep the game running,
depends on how the back end works, and why the heck you would want to change
the orientation of your screen mid playing a game and such.
I would have to say that if you want your game to behave on android might as
well hit it in the face and just convert it to java, well, if it is in
straight C anyway, its probably just as much work as getting an SDL app to
behave properly on android, by properly i mean as an average android user
would expect a android app to behave, not us lot working for three days to
get a version on circus linux working if your game has some severe
major league funk math routines going on do that bit in C, but the rest
native ( sorry not wanting to put down the wonderful efforts of an android
port of sdl, i believe sdl should be ported to all platforms devices and
electronics, including casio digital watches from the 1980âs and washing
machines )
perhaps as a small JD fueled thought there should be a mini sdl GUI type
thing, menu system at least, so if you chose a menu the system you are on
gives the most simple menu the host system can offer, dunno.
Like I said, itâd be ugly, but this is something far from impossible with JNI.
Hell, make some C++ classes wrapping the Android API JNI calls and you can obscure the ugliness.
(oh: it will require a native callback, youâll have to see JNI reference for an example but itâs not ugly at all on the Java sideâŚ)------------------------
EM3 Nathaniel Fries, U.S. Navy
Since at least 5 years now, I live in managed languages land (JVM, .Net and
some scripting), but I still keep a
foot in the C/C++ land for some occasional stuff, when it makes more sense
to use one of these languages.
It is just that sometimes when people discuss about developing for Android,
I got the feeling that they forget
the official language is Java, with C and C++ only meant for writting
performance critical methods.
You are even not allowed to call the Linux APIs, besides the following
libraries:
libc
libm
libstd++ (partially)
opengl
JNI
But you are right, with some JNI it can be done, most likely.
Regards,
PauloOn Fri, May 28, 2010 at 11:44 PM, Nathaniel J Fries wrote:
Paulo Pinto wrote:
I have some doubts how such a library could work in a non rooted Android
system.
SDL applications on Android have to be coded as libraries with a bit of
Java code, that serves as
glue between standard Android applications and the C and C++ worlds.
All the notification APIs about the process state are in Java, which means
you will need several
points of communication between the SDL application, now running as a
library, and the standard
way to get these notifications in Android.
Regards,
Paulo
The âglueâ between Java and C is called âJava Native Interfaceâ.
And, while itâs unsightly and somewhat painful to use, it is effective at
its job. Without doing any rooting or excessive hacking, one could access
all of Androidâs Java APIs through JNI.
Itâs perfectly valid for an application on Android to go to background
without aborting or freeing any resources, and it does work that way with
Android 2.X devices (yes Android will kil background apps when itâs out of
memory, but it doesnât apply to cases where you just have to answer the
call). Application just freezes inside SDL_Flip() call, and recovers okay
when you switch back to it, and thatâs all.
The whole discussion arised from the fact that with Android 1.6 the
application will lose OpenGL context when it goes to background (but you
still can output sound). Pure SDL application can just re-create all
textures inside SDL_Flip(), with SDL+OpenGL the application should implement
some kind or reinit callback to re-make OpenGL context.
http://developer.android.com/reference/android/app/Activity.html - âThe
Android system attempts to keep application process around for as long as
possible âŚâ , destroying the activity is just like hiding application
window, itâs perfectly valid to keep some threads runing in background.On Sat, May 29, 2010 at 2:54 AM, Nathaniel J Fries wrote:
Like I said, itâd be ugly, but this is something far from impossible with
JNI.
Hell, make some C++ classes wrapping the Android API JNI calls and you can
obscure the ugliness. [image: Smile]
(oh: it will require a native callback, youâll have to see JNI reference
for an example but itâs not ugly at all on the Java sideâŚ)
Itâs perfectly valid for an application on Android to go to background without aborting or freeing any resources, and it does work that way with Android 2.X devices (yes Android will kil background apps when itâs out of memory, but it doesnât apply to cases where you just have to answer the call). Application just freezes inside SDL_Flip() call, and recovers okay when you switch back to it, and thatâs all.
The whole discussion arised from the fact that with Android 1.6 the application will lose OpenGL context when it goes to background (but you still can output sound). Pure SDL application can just re-create all textures inside SDL_Flip(), with SDL+OpenGL the application should implement some kind or reinit callback to re-make OpenGL context.
Since youâre supposed to use the context made by SDL anyway (or am I mistaken?), wouldnât your implementation inside GL work just fine?
That said, most SDL apps can afford to freeze and re-init as Android desires. Making new events and a couple new structs for just this should not be considered a grave sinâŚ
PS: Does iPhone do the same thing? If it does, this is double the reason to make it so. (event: SDL_STATESTORE and SDL_STATERESTORE, structure: SDL_AppState with functions allowing iPhone app/Android activity state information to be set and read)------------------------
EM3 Nathaniel Fries, U.S. Navy
While an SDL app on a Linux desktop
