Hi
I’ve made preliminary port of libSDL 1.2.14 to Google Android platform:
http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html
There’s no sound yet, and no multitouch (will be in Android 2.0 which is
still not released),
everything other seems to be working.
Sergiy Pylypenko wrote:
Hi
I’ve made preliminary port of libSDL 1.2.14 to Google Android platform:
http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html (http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html)There’s no sound yet, and no multitouch (will be in Android 2.0 which is still not released),
everything other seems to be working.
since you went to the trouble, could you give a crack at porting SDL 1.3 (since that’s the future of SDL) as well?
Hi
I’ve added sound to my Android libSDL port, and added code to download
application data on the first run (it’s not bundled in installer package),
so the port is more-less complete.
http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html
Very cool!
Are you interested in porting SDL 1.3? It might be an easy port since
it already has OpenGL ES support…On Wed, Dec 9, 2009 at 6:15 AM, Sergiy Pylypenko <x.pelya.x at gmail.com> wrote:
Hi
I’ve added sound to my Android libSDL port, and added code to download
application data on the first run (it’s not bundled in installer package),
so the port is more-less complete.
http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
I’ve moved my libSDL Android port to SDL 1.3, and added OpenGL support and
hardware surfaces with the help of GLES renderer. It still lacks some
important features like on-screen keyboard to be complete.
The typical Android device has 480x320 screen (there are 800x480 devices,
but alas, they have no keyboard), and typical SDL game requires 640x480
resolution, and it’s a lot of work to fix the game.
When I’ve used SDL 1.2 and self-made software renderer I’ve just called
glDrawTexiOES() with physical screen resolution, and it resized the picture
nicely. But it seems that SDL 1.3 does not support that out of the box.
Where is better to add such resizing code? I guess I should modify
GLES_RenderCopy(), or make my own renderer which will call GLES_RenderCopy()
with modified coordinates. Then I’ll have to do the same for
GLES_RenderDrawPoints(), GLES_RenderDrawLines() etc.
And the links are
http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html or
http://github.com/pelya/commandergenius
Awesome! I’m really looking forward to trying this out. However, i’m curious, do you know the minimum Android OS version this would support? I know that the previous version didn’t work with anything under 1.6 as 1.5 and under didn’t support OpenGL.
But since Verizon FINALLY pushed out the update for my Eris, it shouldn’t be an issue for me to use it. I’m just wanting to know more for end users.
pelya wrote:> I’ve moved my libSDL Android port to SDL 1.3, and added OpenGL support and hardware surfaces with the help of GLES renderer. It still lacks some important features like on-screen keyboard to be complete.
The typical Android device has 480x320 screen (there are 800x480 devices, but alas, they have no keyboard), and typical SDL game requires 640x480 resolution, and it’s a lot of work to fix the game.
When I’ve used SDL 1.2 and self-made software renderer I’ve just called glDrawTexiOES() with physical screen resolution, and it resized the picture nicely. But it seems that SDL 1.3 does not support that out of the box.Where is better to add such resizing code? I guess I should modify GLES_RenderCopy(), or make my own renderer which will call GLES_RenderCopy() with modified coordinates. Then I’ll have to do the same for GLES_RenderDrawPoints(), GLES_RenderDrawLines() etc.
And the links are http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html (http://www.anddev.org/sdl_port_for_android_sdk-ndk_16-t9218.html) or http://github.com/pelya/commandergenius (http://github.com/pelya/commandergenius)
unless he added conditions for it, it’s probably the same.------------------------
EM3 Nathaniel Fries, U.S. Navy
apologies for my ignorance, yet again, but what does this actually mean?
having SDL on android? i have just started figuring out android and just
about finsishe converting crazeeman to run on it… what does SDL on android
do? i have to use java equivilents of the C command i use when i am
programming on a PC? i dont understand. sorry.
(honest)
Neil White wrote:
apologies for my ignorance, yet again, but what does this actually mean? having SDL on android? i have just started figuring out android and just about finsishe converting crazeeman to run on it… what does SDL on android do? i have to use java equivilents of the C command i use when i am programming on a PC? i dont understand. sorry.
(honest)
it’s a port of the Simple DirectMedia Layer (SDL) library to the Google Android operating system for mobile phones, like the Eris and the Droid.
It allows you to write games for the Android in C using their Native Development Kit (NDK).------------------------
EM3 Nathaniel Fries, U.S. Navy
so how would this work? you’d do a basic android fromt end, menus and stuff
, then just have a dosdlbit() function that ran the c code? what about the
pause resume stuff and interacting with menus?
Neil White wrote:
so how would this work? you’d do a basic android fromt end, menus and stuff , then just have a dosdlbit() function that ran the c code? what about the pause resume stuff and interacting with menus?
Ugh.
It would have nothing to do with the menus. You’re thinking far too android now.
It is SDL. Simply SDL. It will not do anything special on Android that it does not do on Windows, Linux, iPhone, or OS X.
It will, in your C code, let you load graphics and render them to the screen. It will, in your C code, play audio files for you. It will, in your C code, give you events from the system.
It will accomplish exactly what it does on every other system. Nothing more, nothing less.------------------------
EM3 Nathaniel Fries, U.S. Navy
just things like track balls or dpad and touchscreen and screen sizes and
dpis would all need to be detected, also people on osx are doing some funky
stuff to use native menus and stuff to interact with sdl stuff so i figured
a similar thing could be done with this, things like when the phone rings an
app goes to the back or whatever is paused or resumed, presumably with
straight sdl the ting would just die completly if the phone rang out you
navigated to another app, dunnos, i get my hands on an andoid phone sometime
next week so will give it a shot anyways. just andoid users would expect a
game or whatever to behave at least similarly to any other andoid program
they use… dunnos
what about for android market would a straight sdl app be accepted? my
brother tells me noone gives a hoot what your app does for android market,
it could wipe the phone and you can still add it to the market, anyways,
again nathan sorry for my utter ignorance, i will now go back to the corner
of my cave and continue dribbeling.
Neil White wrote:
just things like track balls or dpad and touchscreen and screen sizes and dpis would all need to be detected
SDL 1.3 has had touchscreen events since the iPhone port, and trackball support should not be hard (it might already just be a mouse input).
also people on osx are doing some funky stuff to use native menus and stuff to interact with sdl stuff so i figured a similar thing could be done with this, things like when the phone rings an app goes to the back or whatever is paused or resumed, presumably with straight sdl the ting would just die completly if the phone rang out you navigated to another app, dunnos, i get my hands on an andoid phone sometime next week so will give it a shot anyways. just andoid users would expect a game or whatever to behave at least similarly to any other andoid program they use… dunnos
Oh, I understand. I don’t know the internals of how android apps work in the background – whether they’re frozen, or are exited and must save/restore their own state, or just continue running in the background without rendering. You would know more about that than me.
As for working with system menus, just like with SDL on the iPhone, you will need to implement this yourself using Android’s APIs.
what about for android market would a straight sdl app be accepted? my brother tells me noone gives a hoot what your app does for android market, it could wipe the phone and you can still add it to the market, anyways, again nathan sorry for my utter ignorance, i will now go back to the corner of my cave and continue dribbeling.
SDL wouldn’t offer anything over anything else in the market.
What it does offer:
PS: It’s Nate or Nathaniel, please. In my experience guys named “Nathan” are not particularly good people.------------------------
EM3 Nathaniel Fries, U.S. Navy
PS: It’s Nate or Nathaniel, please. In my experience guys named “Nathan” are not particularly good people.
Speaking of which, it’s a shame they went and canceled Heroes, especially after last season where they were finally getting back on track. ;)>From: Nathaniel J Fries
Subject: Re: [SDL] libSDL port on Android3)
sorry Nate or Nathaniel, i wrote Nathan without checking your name properly
i’m sure there are a few good people called Nathan about. And i am with
you on the java thing, i have never really done it purley because i have
looked a books about it and thought WTF is this crap, so learning java and
the ins and outs of Andorid over the last few weeks has been not very fun
really still not too sure wht the heck is actually going on but now i
have a handle on things a proper thread and view going on its pretty much a
case of just copy and pasting my existing C code into java functions.
aside from that a little ramble if not just to clarify in my head what i am
about to do - i have just about got my crazeeman game (
http://www.cloudsprinter.com/software/ ) to behave on andorid, but am having
a few minor issues on dealing with screen sizes - my game size is
intentionally reduced vision view so i want centering the canvas on screens
larger than my game play size and blah fo diggle like that, controls are
another issue as some phones have buttons some have balls and some no
buttons just touch i think, but i read on a mail list (from google engineer)
that is very unlikley that there will ever be an andorid phone without touch
screen capablilites. Also the case of deciding which API to use, keep it all
at the first one, to keep people with older handsets happy, or use the
latest api which actually gives you the option to have drawables for screen
size and dpi settiings avaliable, small screen, middle sized screen or
screen with high dpi.
bye!
Neil White wrote:
aside from that a little ramble if not just to clarify in my head what i am about to do ;)? - i have just about got my crazeeman game ( http://www.cloudsprinter.com/software/ (http://www.cloudsprinter.com/software/) ) to behave on andorid, but am having a few minor issues on dealing with screen sizes - my game size is intentionally reduced vision view so i want? centering the canvas on screens larger than my game play size and blah fo diggle like that, controls are another issue as some phones have buttons some have balls and some no buttons just touch i think, but i read on a mail list (from google engineer) that is very unlikley that there will ever be an andorid phone without touch screen capablilites. Also the case of deciding which API to use, keep it all at the first one, to keep people with older handsets happy, or use the latest api which actually gives you the option to have drawables for screen size and dpi settiings avaliable, small screen, middle sized screen or
screen with high dpi.
Okay, so what you’re asking is if SDL will be able to tell you what hardware input features your phone has?
Not an SDL thing. SDL will work with whatever it has, but not tell you whether or not it has it.
Your best bet is to use touch input.------------------------
EM3 Nathaniel Fries, U.S. Navy
Okay, so what you’re asking is if SDL will be able to tell you what
hardware input features your phone has?
Not an SDL thing. SDL will work with whatever it has, but not tell you
whether or not it has it.Your best bet is to use touch input.
just talking crap to myself really nate, i am a veteran expert at it, at
some point i might venture into the murky world of google NDK for android,
if not just to port some of my random SDL crap for fun
Hey.
I’ve discovered that you have GSoC student working on official SDL port on
Android.
From the commit log I’m guessing that he’s trying to write the port from
scratch.
Is he aware that I’ve switched my port to SDL 1.3 few days ago? It is almost
complete,
and I would like for someone to take development on it from me.
I’ve sent him email, but he did not reply yet.
Not having done any Android development, but owning an Android-based
phone, I think it depends on the app. Some apps seem to just go away
when you switch to another, or go back to the Home screen. Others
very obviously continue running (in many cases, they put an alert into
the annunciator bar). (IRC client, streaming music app, SSH client, etc.)
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)
-bill!
(not in the mood to think about mobile development much right now 
)On Sat, May 22, 2010 at 04:55:40PM -0700, Nathaniel J Fries wrote:
Oh, I understand. I don’t know the internals of how android apps work in
the background – whether they’re frozen, or are exited and must
save/restore their own state, or just continue running in the background
without rendering. You would know more about that than me.
Also probably depends on the app :)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)