Unfortunately we don’t have the luxury of time and there is some major investment wrapped up in this project. So using the work we did with the iphone as a starting point I am looking at ways we can make the scoc2010 version work . Its not really a bad port its just very incomplete.
Our application is maybe a million lines or so of c code (best guess) and it would be a major endeavor to convert to java.
Sam is actually very helpful and we have the advantage he is familiar with our project. So there is hope.
I am wondering if using the toolchain rather than the ndk makes sense, although using the ndk I’ve managed to build our classes. Of course getting code to compile is only half the battle.
The sample program included helps a little, at least it shows how to set up the open gl from the java side.
both ports have issues so its pick one and go with it and I think I am better off with the more “official” one. But this is all big time groping through dark caves and I could easily change my mind.
it does help to go back through the mercuial archive , gives you a picture of were the developers are coming from. Some of the code is very similar to what was done in the iphone version.
If you like we can bounce ideas off each other, if we come up with a decent patch set I am sure we can get this pushed into the source tree.
(Right SAM )
quote=“Luca Barbato”]On 10/17/2010 08:09 PM, michelleC wrote:
I’d be interested in seeing your ffplay port,
I am a major contributor to ffmpeg4iphone, and we made a lot
of ffplay optimizations that you might be able to port to android.
Nice =), my ffplay port is pretty much replace lesson05.c with ffplay.c
and add the needed libs. (since that’s all you need to do).
As for these sdl ports, I have to agree with you, and I am a little shocked
that Sam would even consider the scoc2010 port to be anywhere near complete.
Its barely usable, the only code that seems to work is the lesson05.c sample
included, and that is not very portable.
The key issue is that you need somehow to wrap your app with the dalvik
bridge and that makes your like not that easy (ant+ndk-build).
Additionally Android.mk isn’t exactly easy to bend to your will.
As for the other port, well, if you build game that essentially clone the
same logic as alienbaster with variation than the author is correct it works,
but the code is so unique that it is not potable.
And from my current experience the overhead kills performances and the
audio subsystem isn’t exactly nice, but the main fault here is partially
on the android side.
to be useful as a reusable port, the port should prove the ability
to build all the sdl testcases, the graywin.c sample, and the simple sound samples, .
SDL mailing list
SDL at lists.libsdl.org