Google's Mobile Android OS - SDL?

JonnyD · March 30, 2010, 11:38pm

Isn’t there a Java binding for SDL?

Jonny DOn Tue, Mar 30, 2010 at 3:00 PM, Simon Roby <simon.roby at gmail.com> wrote:

Would SDL really make sense on Android? Last time I checked you’re not
supposed to write native C/C++ apps on Android.

On Tue, Mar 30, 2010 at 12:41, Tiresias wrote:

Hello
so whats the status on SDL on Android OS/NDK ?
(has it been ported and does it support using opengl with SDL ?)
Thanks

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

–

SR

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

Paulo_Pinto · March 31, 2010, 6:58am

You know there is always this urge to stay in C land even though the world
moves forward… :)On Wed, Mar 31, 2010 at 12:00 AM, Simon Roby <simon.roby at gmail.com> wrote:

Would SDL really make sense on Android? Last time I checked you’re not
supposed to write native C/C++ apps on Android.

On Tue, Mar 30, 2010 at 12:41, Tiresias wrote:

Hello
so whats the status on SDL on Android OS/NDK ?
(has it been ported and does it support using opengl with SDL ?)
Thanks

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

–

SR

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

Bill_Kendrick · March 31, 2010, 7:00am

Yes. Forward. On top of C.

-bill!On Wed, Mar 31, 2010 at 08:58:22AM +0200, Paulo Pinto wrote:

You know there is always this urge to stay in C land even though the world
moves forward…

Tiresias · March 31, 2010, 8:29am

well when you have 250K lines of C++ and C you dont want to move forward

so anyones know about any existing port?

Paulo_Pinto · March 31, 2010, 9:02am

I think someone did an early port, but I could not find any reference to it.On Wed, Mar 31, 2010 at 10:29 AM, Tiresias wrote:

well when you have 250K lines of C++ and C you dont want to move forward [image:
Smile]

so anyones know about any existing port?

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

Marcel_Wysocki · March 31, 2010, 9:07am

http://lmgtfy.com/?q=sdl+androidOn 03/31/2010 11:02 AM, Paulo Pinto wrote:

I think someone did an early port, but I could not find any reference
to it.

On Wed, Mar 31, 2010 at 10:29 AM, Tiresias <tantididier at yahoo.fr <mailto:tantididier at yahoo.fr>> wrote:
well when you have 250K lines of C++ and C you dont want to move
forward Smile

so anyones know about any existing port?

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

David_Olofson · March 31, 2010, 1:56pm

That (because you don’t want to rewrite massive applications for what should
be a simple port), and the fact that we’re talking about a VM (without JIT,
so far), running on relatively slow hardware.

Anything that isn’t basically tiles + sprites and very simple logic is going
to mean trouble, unless you compile it to native code. My rough ballpark
estimate would be that native code on these devices runs about as fast as
Java, Lua or similar (non-JIT VM, that is) on your average PC.

You can implement a modern 3D shooter pretty much all in Lua on a PC, so…
You just need nice engines/APIs for rendering, audio etc, so you can keep the
VM away from the “pixels and samples” level.On Wednesday 31 March 2010, at 08.58.22, Paulo Pinto wrote:

You know there is always this urge to stay in C land even though the world
moves forward…

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

Paulo_Pinto · March 31, 2010, 2:25pm

I am aware of it.

Actually I think that C and C++ will still be around for a very long time,
many more years than any of us.

It doesn’t change the fact that the future is full with higher level
languages.

Even though I don’t work on the games industry I already had the oportunity
to see several known studios,
that are at least porting their tools to such languages. With some, having
only the game engine itself written in C/C++,
with the rest with some other language, like Lua for example.

There is an alpha version of Dalvik with JIT support, but I don’t understand
why Google hasn’t provided since the beginning.

And existing code bases always play a big role, even Google has done a
presentation at GDC 2010 about game development
with the NDK.

Now if I only could put my hands on a C++11 compiler. :)On Wed, Mar 31, 2010 at 3:56 PM, David Olofson wrote:

On Wednesday 31 March 2010, at 08.58.22, Paulo Pinto <@Paulo_Pinto> wrote:

You know there is always this urge to stay in C land even though the
world
moves forward…

That (because you don’t want to rewrite massive applications for what
should
be a simple port), and the fact that we’re talking about a VM (without
JIT,
so far), running on relatively slow hardware.

Anything that isn’t basically tiles + sprites and very simple logic is
going
to mean trouble, unless you compile it to native code. My rough ballpark
estimate would be that native code on these devices runs about as fast as
Java, Lua or similar (non-JIT VM, that is) on your average PC.

You can implement a modern 3D shooter pretty much all in Lua on a PC, so…
You just need nice engines/APIs for rendering, audio etc, so you can keep
the
VM away from the “pixels and samples” level.

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

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

Loic_LAMBERT · March 31, 2010, 2:31pm

SDL is listed among the android external projects :
http://source.android.com/projects

SDL may be used for the OS itself or maybe just for the simulator
browse here :
https://android.git.kernel.org/?p=platform/prebuilt.git;a=tree
and here :
https://android.git.kernel.org/?p=platform/external/qemu.git;a=tree

for some SDL stuff.

I don’t know if you can run native code under android

Good luck,
Lo?c

Le 31/03/2010 00:00, Simon Roby a ?crit :> Would SDL really make sense on Android? Last time I checked you’re not

supposed to write native C/C++ apps on Android.

On Tue, Mar 30, 2010 at 12:41, Tiresias wrote:

Hello
so whats the status on SDL on Android OS/NDK ?
(has it been ported and does it support using opengl with SDL ?)
Thanks

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

David_Olofson · March 31, 2010, 3:25pm

I am aware of it.

Actually I think that C and C++ will still be around for a very long time,
many more years than any of us.

Indeed. In fact, C is pretty much lowest common denominator, as it’s about as
close to machine code you get without going CPU specific.

(In terms of what machine code can theoretically be generated, C++ doesn’t add
all that much, but as long as we’re pure, portable C - ie no C99, GNU
extensions etc - C++ does offer some tools that can be handy in VMs and
compilers…)

It doesn’t change the fact that the future is full with higher level
languages.

…which could, be implemented using VMs written in C, or compiled to native
code via C using translators.

I’m doing the former with EEL (roughly as fast as Lua), and I’m going for the
latter as a first quick and portable way of turning it into native code when
run-time compilation isn’t required. JIT is a big job, and either way, it
doesn’t mix very well with realtime constraints, so I’m not sure it’s an
option for EEL at all… (“Just In Time before the application starts” would
work, though - but that’s just a traditional native compiler that happens to
be built into the run-time library of the language.)

[…]

There is an alpha version of Dalvik with JIT support, but I don’t
understand why Google hasn’t provided since the beginning.

Like I said, a JIT is a big job, and it’s pretty hairy stuff to get right -
and you really want a VM in a production system to work correctly…
Meanwhile, time is money, and all that stuff. :-)On Wednesday 31 March 2010, at 16.25.37, Paulo Pinto wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

Simon_Roby · April 2, 2010, 4:30pm

That doesn’t mean much when the whole underlying APIs are all Java.On Tue, Mar 30, 2010 at 19:38, Jonathan Dearborn wrote:

Isn’t there a Java binding for SDL?
Jonny D

On Tue, Mar 30, 2010 at 3:00 PM, Simon Roby <@Simon_Roby> wrote:

Would SDL really make sense on Android? Last time I checked you’re not
supposed to write native C/C++ apps on Android.

On Tue, Mar 30, 2010 at 12:41, Tiresias wrote:

Hello
so whats the status on SDL on Android OS/NDK ?
(has it been ported and does it support using opengl with SDL ?)
Thanks

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

–

SR

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

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

–

SR

David_Olofson · April 2, 2010, 4:47pm

Android is not all Java. At least, the Linux kernel is native code, and so is
it’s drivers, the VM (obviously!), various “system” services - and I’m quite
sure the OpenGL ES implementations (whether hardware or software) are native
code too. It would just be ridiculously slow - even on desktop hardware - if
it wasn’t implemented like this!

Either way, rewriting an application in Java, or even just porting to
different APIs, is quite som work. A potential showstopper unless you can
realistically expect to make a good profit from the conversion. Guess why so
many applications are available for one platform only…On Friday 02 April 2010, at 18.30.34, Simon Roby <simon.roby at gmail.com> wrote:

That doesn’t mean much when the whole underlying APIs are all Java.

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

JonnyD · April 2, 2010, 5:31pm

Monopolistic practices?

Jonny DOn Fri, Apr 2, 2010 at 9:47 AM, David Olofson wrote:

On Friday 02 April 2010, at 18.30.34, Simon Roby <simon.roby at gmail.com> wrote:

That doesn’t mean much when the whole underlying APIs are all Java.

Android is not all Java. At least, the Linux kernel is native code, and so
is
it’s drivers, the VM (obviously!), various “system” services - and I’m
quite
sure the OpenGL ES implementations (whether hardware or software) are
native
code too. It would just be ridiculously slow - even on desktop hardware -
if
it wasn’t implemented like this!

Either way, rewriting an application in Java, or even just porting to
different APIs, is quite som work. A potential showstopper unless you can
realistically expect to make a good profit from the conversion. Guess why
so
many applications are available for one platform only…

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

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

David_Olofson · April 2, 2010, 7:35pm

Monopolistic practices?

Well, yes - but if you can be one of few players on a smaller market as an
extra bonus, why not?

To great extent, we (developers) have ourselves to blame for buying into this
BS too easily. Just don’t use a single platform API if there are viable
alternatives - and if there aren’t, it’s still a bad idea to “surrender” and
allow the API and it’s datatypes infect the whole application.

[…]On Friday 02 April 2010, at 19.31.03, Jonathan Dearborn wrote:

On Fri, Apr 2, 2010 at 9:47 AM, David Olofson <@David_Olofson> wrote:

Guess why so many applications are available for one platform only…

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

Paulo_Pinto · April 2, 2010, 8:07pm

Actually rewriting applications seldom make sense, on the other hand it used
to be quite
common on the gaming industry and I bet it is still done.

Many studios focus in just one platform and outsource the work for other
platforms. How
the game is then developed is the contractor’s problem.–
Paulo

On Fri, Apr 2, 2010 at 6:47 PM, David Olofson wrote:

On Friday 02 April 2010, at 18.30.34, Simon Roby <simon.roby at gmail.com> wrote:

That doesn’t mean much when the whole underlying APIs are all Java.

Android is not all Java. At least, the Linux kernel is native code, and so
is
it’s drivers, the VM (obviously!), various “system” services - and I’m
quite
sure the OpenGL ES implementations (whether hardware or software) are
native
code too. It would just be ridiculously slow - even on desktop hardware -
if
it wasn’t implemented like this!

Either way, rewriting an application in Java, or even just porting to
different APIs, is quite som work. A potential showstopper unless you can
realistically expect to make a good profit from the conversion. Guess why
so
many applications are available for one platform only…

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’

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

Rainer_Deyke · April 2, 2010, 8:39pm

When your game is 95% content (i.e. art assets, level design, text,
speech, music, etc.) and 5% code, rewriting that 5% for another platform
can still make sense.On 4/2/2010 14:07, Paulo Pinto wrote:

Actually rewriting applications seldom make sense, on the other hand it used
to be quite
common on the gaming industry and I bet it is still done.

–
Rainer Deyke - rainerd at eldwood.com

Paulo_Pinto · April 2, 2010, 8:51pm

The problem is that most times you also have to handle those 95%.

You cannot just take all content for target platform A and use it as is, for
target
platform B.

Different resolutions
Different compression methods
Different access speeds
Different memory limits
Different cache hits
and so onOn Fri, Apr 2, 2010 at 10:39 PM, Rainer Deyke wrote:

On 4/2/2010 14:07, Paulo Pinto wrote:

Actually rewriting applications seldom make sense, on the other hand it
used
to be quite
common on the gaming industry and I bet it is still done.

When your game is 95% content (i.e. art assets, level design, text,
speech, music, etc.) and 5% code, rewriting that 5% for another platform
can still make sense.

–
Rainer Deyke - rainerd at eldwood.com

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

Rainer_Deyke · April 2, 2010, 9:04pm

That’s an orthogonal issue to code rewrite. If platform B cannot handle
the content, then you need to adjust the content regardless of whether
you reuse or rewrite the game code.On 4/2/2010 14:51, Paulo Pinto wrote:

The problem is that most times you also have to handle those 95%.

You cannot just take all content for target platform A and use it as is, for
target
platform B.

–
Rainer Deyke - rainerd at eldwood.com

Bill_Kendrick · April 2, 2010, 11:40pm

Actually rewriting applications seldom make sense, on the other hand it
used to be quite
common on the gaming industry and I bet it is still done.

Definitely done in the mobile space. Even when your target is the same
platform (e.g., all BREW or all J2ME phones), you end up tweaking your
code and building various versions to work around the bugs and limitations
of all the handsets.

If you’re lucky and have someone uber-smart on your team, you can end
up with a cross-platform system where you target a thin API layer
(kinda like what we around here do with SDL!), and have the app
mostly-automatically-ported between two different platforms (i.e., the
same codebase running on J2ME and BREW!)

Many studios focus in just one platform and outsource the work for other
platforms. How
the game is then developed is the contractor’s problem.

Happened a lot in the early days, too. “Game XYZ - By Original Programmer
(Atari 800 version by Some Other Guy)”

In some cases, the ports inherited limitations in the original platform
(like Apple II games ported to Atari and Commodore and had almost no color),
which always made me sad.

-bill!On Fri, Apr 02, 2010 at 10:07:52PM +0200, Paulo Pinto wrote:

David_Olofson · April 2, 2010, 11:45pm

Actually rewriting applications seldom make sense, on the other hand it
used to be quite common on the gaming industry and I bet it is still done.

Well, that was back in the days when you even had to implement the game logic
in assembly language not to slow the game down too much.

Then again, something close to that level of optimization is still valid for
high volume products (what you pay extra in development costs, you save on the
hardware in each device), and products that absolutely need to keep power
consumption minimal. Embedded electronics, handheld devices etc…

Many studios focus in just one platform and outsource the work for other
platforms. How the game is then developed is the contractor’s problem.

Indeed - but if you look at Linux ports of Windows games, for example, you’ll
find that OpenGL games are (or at least were) ported a lot sooner than
Direct3D games. Apparently, the Linux market is now big enough that converting
Direct3D games can be worthwhile too, despite the extra work.On Friday 02 April 2010, at 22.07.52, Paulo Pinto wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’