I was hoping that someone had tried a little test app with a simple
scene.  I think I've pretty much reached the limits in terms of get
sprites on the screen at an acceptable frame rate (at least on G1 type
hardware).
It seems, at least for what I'm doing, the limit is about 100 sprites
but for my next project I'd like a bit more.
Maybe I'll just stop making games for 'old' hardware and concentrate
on the Droid and N1.  I can't say I like the idea of ignoring half the
market :(

On Apr 6, 3:37 pm, Ralf Schneider <[email protected]> wrote:
> You will probably not get a clear anwser from anyone. The questions is far
> more complex than it looks like.
>
> It is no problem to put the same number of polys out in OpenGL be it with
> the NDK or SDK. After all it's just same OpenGL calls. The time to render
> the polys (in a batch) exeeds the time of the function call overhead by
> orders of magnitude. So it is usually completely neglectable.
>
> But as soon as an application gets more complex and performs some serious
> calculations(AI, Scene Graph Management, Culling, Image processing, Number
> crunching, etc.) the native version will usually be much faster.
>
> And there is another thing: Beside the fundamental problem that there
> currently is no JIT Compilation.
> The current dalvikvm with its compiler seems to be very basic, without doing
> any optimizations - even not the most basic ones!
>
> There is this (very good) video: Google I/O 2009 - Writing Real-Time Games
> for Android <http://www.youtube.com/watch?v=U4Bk5rmIpic>
> After I have seen it, it was clear for me I will definitely use C++ with the
> NDK.
>
> For example: He is talking about the overhead of function calls "Don't use
> function calls".
> ... So yeah we are back - before 1970 and start talking about the cost of
> structured programming and the performance advantage of using only global
> vars and gotos.
>
> The garbage collection is a real problem for games. So you will spend a lot
> of your time thinking how you can avoid it. Even formatting a string will
> create new objects. So there are tips like: don't show the FPS!
> Seriously, if you know C++ it is probably easier to manage you memory with
> new and delete than to tweak your architecture to reduce/avoid garbage
> collections.
>
> It seems like if you want to program a non trivial real time game, you are
> loosing all the advantages of Java. Don't use Getters and Setters, Don't use
> function calls. Avoid any Abstraction, etc. SERIOUSLY?
>
> But back to your question: The performance advantage of NDK vs SDK can be
> anything from 0-10000%. It all depends.
>
> 2010/4/6 MrChaz <[email protected]>
>
>
>
> > Does anyone have any numbers showing the difference in performance
> > between the NDK and SDK?
>
> > I'm curious how much difference it makes in terms of fps / number or
> > polys on the screen that kind of thing
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]<android-developers%2Bunsubs 
> > [email protected]>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> > To unsubscribe, reply using "remove me" as the subject.

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to