[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-18 Thread Piotr

On 18 Mar, 05:18, Kevin Duffey andjar...@gmail.com wrote:
 [...]The screen touch issue
 that is causing massive lag on input and slowing games down greatly, and the
 buggy multi-touch capabilities...

yes, this event-driven approach is not good for games, and even for
most applications with their own graphics, where smooth animation is
required. I think, game low level framework should allow simple and
quick testing screen touch position or control keys in a game loop.

Eh.. even old j2me phones with a much slower cpus and less resources
are running great games with smooth animation, that I still never seen
on Android.

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Piotr
M$ has show already done great XNA gaming framework with VS Express
NET 4 for Win Phone 7, ready to download:

http://developer.windowsphone.com/windows-phone-7-series/

I bet, most developers will choose WinPhone to create games, if they
can just create their games for Zune, X360, PC and WinPhone at once,
and because C#/XNA programming is much simplier and takes less time
than dealing with Canvas optimization, NDK or OpenGL calls and other
stuff, that most developers just do not know how, or do not want to
do.

I say it again, hoping that some Google Worker is watching :D:

Android NEEDS something like XNA. Not for you, professional game
makers, but for all community of developers, who want to start with
game creation.

Creating games is not only a coding, but mostly an art. Good tools
allow to focus on art. Lack of tools = poor games, because developers
with great ideas will waste their energy on creating tools, not an
art.

On 11 Mar, 22:25, Mario Zechner badlogicga...@gmail.com wrote:
 Extremely well written post Bob, thanks a lot for that. I can totally
 agree to your statements and can confirm that the bottleneck in games
 is not the Dalvik VM and therefor Java for almost all parts of agame.
 What kills performance at the moment is way down in the chain at the
 hardware level. Fill-rate limits are the biggest issue wegame
 developers have to face at the moment. Everything else does not
 contribute much, implementing your wholegamein C does not solve that
 problem. And i speak from personal experience in this case :)

 On a side note: ExDeus was not developed with the NDK. Thegameis
 actually a port of an IPhone version so it was developed with the
 IPhone tools for the most part. Those feature a native debugger. The
 Android version is probably only different in setting up the gl
 surface and processing input.

 On 11 Mrz., 17:01, Bob Kerns r...@acm.org wrote:

  This comment is perhaps a bit off your main topic, and I don't mean it
  to derail your efforts or to criticize.

  But I have a bit of a problem with your statement Java is just too
  slow..., taken as a general statement. Perhaps you have benchmark
  data showing specific performance problems, and found it so; I'm not
  disputing that.

  However, the performance landscape is a lot more complex than this
  would suggest, if taken beyond your context. In particular, there are
  at least 4 performance areas to consider here:

  1) Java performance -- which is actually generally quite good in the
  desktop/server world; I've not done any Android benchmarking.
  2) JNI performance -- there's added cost per switch to native code;
  sometimes it's better to do more work in Java to avoid this overhead,
  or to batch up work and do more per JNI call.
  3) OpenGL library/driver performance. This is both the stuff that's
  done in software in preparing for the GPU pipeline, and how
  effectively it makes use of the hardware, and failures to use
  capabilities that exist in the hardware.
  4) The GPU hardware itself

  Judging from the reports I see here (and not personal experience on
  this platform as yet), a lot of the performance problems we see are
  further down this chain. Better graphics hardware and better drivers
  push the bottlenecks up the chain; faster main processors and Java VM
  improvements push them down. But where you encounter the bottleneck
  will always depend on just what the application is doing. Textures are
  a big part of that, as is managing levels of detail so you don't waste
  time rendering detail that isn't really noticeable. There are a lot of
  ways to use OpenGL poorly. And there are a lot of ways to use it well,
  but push the limits in the search for image quality.

  Pushing things down in to C++ is just going to harm developers, if
  it's not actually where the bottleneck is. As Mario says, you have to
  choose carefully. Do you move your physics engine into C++ -- or just
  the matrix multiplications? Or perhaps just significant components,
  like collision detection and the timestep integrations? If you push
  stuff down to C++, how do you allow for customization, without
  incurring the JNI callback overhead?

  Part of what I'm getting at is that because apps are different, the
  optimal tradeoff will differ. I'm not sure that Google providing a
  framework would be the way to go. Obviously, each developer
  implementing their own isn't a good thing either. I think shared
  community efforts, or commercial libraries make a lot more sense
  (though there could be an official library as one of these options).

  This is especially true of physics engines.

  But there is such wide variation in what demands an application makes
  of 3D rendering that blanket statements like Java is too slow
  conceal the issues.

  So I would council against blindly pushing stuff down to native code
  based on such broad statements, but rather doing so conservatively,
  based on realistic benchmarks.

  On Mar 10, 2:35 am, 

Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Weston Weems
Meh. I think its important to keep your finger on the pulse of trends... but
the fact is no matter how.  Good. Frramework is they may and try apple
shenanigans... which makes the scare null andvoid

On Mar 17, 2010 6:48 AM, Piotr piotr.zag...@gmail.com wrote:

M$ has show already done great XNA gaming framework with VS Express
NET 4 for Win Phone 7, ready to download:

http://developer.windowsphone.com/windows-phone-7-series/

I bet, most developers will choose WinPhone to create games, if they
can just create their games for Zune, X360, PC and WinPhone at once,
and because C#/XNA programming is much simplier and takes less time
than dealing with Canvas optimization, NDK or OpenGL calls and other
stuff, that most developers just do not know how, or do not want to
do.

I say it again, hoping that some Google Worker is watching :D:

Android NEEDS something like XNA. Not for you, professional game
makers, but for all community of developers, who want to start with
game creation.

Creating games is not only a coding, but mostly an art. Good tools
allow to focus on art. Lack of tools = poor games, because developers
with great ideas will waste their energy on creating tools, not an
art.

On 11 Mar, 22:25, Mario Zechner badlogicga...@gmail.com wrote:
 Extremely well written post Bob, thanks a lot for that. I can totally
 agree to your statements and can confirm that the bottleneck in games
 is not the Dalvik VM and therefor Java for almost all parts of agame.
 What kills performance at the moment is way down in the chain at the
 hardware level. Fill-rate limits are the biggest issue wegame
 developers have to face at the moment. Everything else does not
 contribute much, implementing your wholegamein C does not solve that
 problem. And i speak from personal experience in this case :)

 On a side note: ExDeus was not developed with the NDK. Thegameis
 actually a port of an IPhone version so it was developed with the
 IPhone tools for the most part. Those feature a native debugger. The
 Android version is probably only different in setting up the gl
 surface and processing input.

 On 11 Mrz., 17:01, Bob Kerns r...@acm.org wrote:

  This comment is perhaps a bit off your main topic, and I don't mean it
  to derail your efforts or to criticize.

  But I have a bit of a problem with your statement Java is just too
  slow..., taken as a general statement. Perhaps you have benchmark
  data showing specific performance problems, and found it so; I'm not
  disputing that.

  However, the performance landscape is a lot more complex than this
  would suggest, if taken beyond your context. In particular, there are
  at least 4 performance areas to consider here:

  1) Java performance -- which is actually generally quite good in the
  desktop/server world; I've not done any Android benchmarking.
  2) JNI performance -- there's added cost per switch to native code;
  sometimes it's better to do more work in Java to avoid this overhead,
  or to batch up work and do more per JNI call.
  3) OpenGL library/driver performance. This is both the stuff that's
  done in software in preparing for the GPU pipeline, and how
  effectively it makes use of the hardware, and failures to use
  capabilities that exist in the hardware.
  4) The GPU hardware itself

  Judging from the reports I see here (and not personal experience on
  this platform as yet), a lot of the performance problems we see are
  further down this chain. Better graphics hardware and better drivers
  push the bottlenecks up the chain; faster main processors and Java VM
  improvements push them down. But where you encounter the bottleneck
  will always depend on just what the application is doing. Textures are
  a big part of that, as is managing levels of detail so you don't waste
  time rendering detail that isn't really noticeable. There are a lot of
  ways to use OpenGL poorly. And there are a lot of ways to use it well,
  but push the limits in the search for image quality.

  Pushing things down in to C++ is just going to harm developers, if
  it's not actually where the bottleneck is. As Mario says, you have to
  choose carefully. Do you move your physics engine into C++ -- or just
  the matrix multiplications? Or perhaps just significant components,
  like collision detection and the timestep integrations? If you push
  stuff down to C++, how do you allow for customization, without
  incurring the JNI callback overhead?

  Part of what I'm getting at is that because apps are different, the
  optimal tradeoff will differ. I'm not sure that Google providing a
  framework would be the way to go. Obviously, each developer
  implementing their own isn't a good thing either. I think shared
  community efforts, or commercial libraries make a lot more sense
  (though there could be an official library as one of these options).

  This is especially true of physics engines.

  But there is such wide variation in what demands an application makes
  of 3D rendering 

Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Sean Hodges
On Wed, Mar 17, 2010 at 1:48 PM, Piotr piotr.zag...@gmail.com wrote:
 I say it again, hoping that some Google Worker is watching :D:

... and right here is where your effort ends, and the whole concept
becomes little more than hot air.

Google are not a gaming company, they are not even a commercial
software vendor. Google are a SAAS company. They develop and host
Web-based services and products, and engage in technology that
increase the market share and accessibility of those services.

Please take your (potentially) great ideas, concepts and designs to
the next level. Work out a business plan, build a community (or a
company), and GET IT DONE. Don't analyse an area of software market
and tell Google they should do it, they pay their own risk managers
and market analysts to do that. If you can find a way to make your
XNA-like gaming platform valuable to the advertising industry - at
that point you're likely to get some serious interest from Google.

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Streets Of Boston
True and not true.

If google thinks that making an XNA like framework could enhance
Android's adoption and device sales enough to bring more ad-revenues/
SaaS-revenues (because more phones would be around if such a framework
existed), then google could be interested in creating such framework.

However, if the potiential return on such a framework is not large
enough, then they won't do it.

On Mar 17, 10:17 am, Sean Hodges seanhodge...@googlemail.com wrote:
 On Wed, Mar 17, 2010 at 1:48 PM, Piotr piotr.zag...@gmail.com wrote:
  I say it again, hoping that some Google Worker is watching :D:

 ... and right here is where your effort ends, and the whole concept
 becomes little more than hot air.

 Google are not a gaming company, they are not even a commercial
 software vendor. Google are a SAAS company. They develop and host
 Web-based services and products, and engage in technology that
 increase the market share and accessibility of those services.

 Please take your (potentially) great ideas, concepts and designs to
 the next level. Work out a business plan, build a community (or a
 company), and GET IT DONE. Don't analyse an area of software market
 and tell Google they should do it, they pay their own risk managers
 and market analysts to do that. If you can find a way to make your
 XNA-like gaming platform valuable to the advertising industry - at
 that point you're likely to get some serious interest from Google.

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


Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Jiri


Does this framework support simple 2d physics and collision detection 
and/or elastic collision?


Jiri

On 10/03/2010 01:11, Mario Zechner wrote:

While it's not nearly as full featured as XNA i started working on
something similar to XNA. It allows you to develop your games mostly
on the desktop and deploying it to your Android device with just a
couple of lines that instantiate a special Activity subclass. It's
based on OpenGL and allows developing 2D and 3D games. I just finished
writting all the java doc for it and am constantly adding new features
to it. It's called libgdx and can be found at http://code.google.com/p/libgdx/.
I also started blogging about it lately and will continue so adding
sample codes for specific problems. You can find that blog at
http://www.badlogicgames.com. An introduction to it can be found at
http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
series of small tutorials wil follow this week and next week.

  The whole thing is LGPL so that there's no problem including it in
commercial apps. It's far from being perfect of course but i think the
base functionality and ease of use can kill some of the burden a fresh
android game developer has to overcome.

I'm open for suggestions and features you want to see in there!

On 9 Mrz., 22:35, Piotrpiotr.zag...@gmail.com  wrote:

Hello,

At my daily job I work as WinMo C++ developer, so I had enough time to
become hater of that platform ;)

But now, M$ is coming with new Windows Phone. As I suspected, they
will abandon awful Win32/MFC native coding and all applications, will
be now managed - run in CLR sandboxes on top of 15 years old Win32
kernel.

Main coding language will be C#  with .NET framework - Java rival.

WinMo always was terrible phone OS, but now, more interesting is, that
Windows Phone will support XNA framework:

http://www.youtube.com/watch?v=LQv_3fwopo8

This is full gaming framework with C# interfaces and support for 2D/3D
graphics, animation, sprites, net play, game sound, controllers, etc..
XNA greatly improves creating games, because it gives a developer an
ready to use game abstraction layer.

To the point; Android needs game framework, like XNA. Maybe it should
be written as NDK library, ready to link with your own application.
This library could load, manage and draw sprites, backgrounds, make
simple physics, etc..

Why ? To create games faster, easier. At this time, you must be very
skilled to create simple platformer with 2 bkgs and 5 sprites. Our
devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
tired of the same logical bricks/ball/falling diamonds games over and
over.

What do you think ?

Is there any chance, that Google will work on something like that ?




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


Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Sean Hodges
On Wed, Mar 17, 2010 at 2:25 PM, Streets Of Boston
flyingdutc...@gmail.com wrote:
 True and not true.

 If google thinks that making an XNA like framework could enhance
 Android's adoption and device sales enough to bring more ad-revenues/
 SaaS-revenues (because more phones would be around if such a framework
 existed), then google could be interested in creating such framework.

 However, if the potiential return on such a framework is not large
 enough, then they won't do it.


You are of course correct, though I firmly believe spending lots of
time speculating on such things will 100% fail to actually get the
work done.

There is also the question of whether Google are the ideal company to
produce such a framework. Microsoft have invested a lot in DirectX and
their XBox projects, they have the experience and the partners to make
it work. What experience do Google have in the games industry?
Personally I think they are stretching themselves enough with their
shoulder barging into the mobile market, without trying to dive into
the centre of the extremely competitive games market.

Having said that, the Android platform does need to compete in this
field. This seems like the perfect opportunity for a start-up, or an
established games development company, to build a native framework and
contribute it upstream. Mario's library might be a good starting point
for this - as well as a technical evaluation of the other
libraries/engines out there (such as Rokon by StickyCoding).

The way to move forward would be to actively pursue a solution though,
rather than mull around the topic passing notes to Google like we were
in the Peoples' Front of Judea. :)

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread niko20
Personally through  my experience this JNI layer overhead is so
small that its effect is negligible. In my apps using NDK with JNI has
alway increased my speed immensly regardless of any JNI method call
overhead. It's just simply not true that the JNI will slow you down.

-niko

On Mar 17, 9:06 am, Sean Hodges seanhodge...@googlemail.com wrote:
 On Wed, Mar 17, 2010 at 2:25 PM, Streets Of Boston

 flyingdutc...@gmail.com wrote:
  True and not true.

  If google thinks that making an XNA like framework could enhance
  Android's adoption and device sales enough to bring more ad-revenues/
  SaaS-revenues (because more phones would be around if such a framework
  existed), then google could be interested in creating such framework.

  However, if the potiential return on such a framework is not large
  enough, then they won't do it.

 You are of course correct, though I firmly believe spending lots of
 time speculating on such things will 100% fail to actually get the
 work done.

 There is also the question of whether Google are the ideal company to
 produce such a framework. Microsoft have invested a lot in DirectX and
 their XBox projects, they have the experience and the partners to make
 it work. What experience do Google have in the games industry?
 Personally I think they are stretching themselves enough with their
 shoulder barging into the mobile market, without trying to dive into
 the centre of the extremely competitive games market.

 Having said that, the Android platform does need to compete in this
 field. This seems like the perfect opportunity for a start-up, or an
 established games development company, to build a native framework and
 contribute it upstream. Mario's library might be a good starting point
 for this - as well as a technical evaluation of the other
 libraries/engines out there (such as Rokon by StickyCoding).

 The way to move forward would be to actively pursue a solution though,
 rather than mull around the topic passing notes to Google like we were
 in the Peoples' Front of Judea. :)

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Mario Zechner
Not at this point. I plan to write a JNI bridge to Box2D and Bullet in
the future though. Happy to have some volunteers that help me put that
together :)

On 17 Mrz., 15:57, Jiri jiriheitla...@googlemail.com wrote:
 Does this framework support simple 2d physics and collision detection
 and/or elastic collision?

 Jiri

 On 10/03/2010 01:11, Mario Zechner wrote:

  While it's not nearly as full featured as XNA i started working on
  something similar to XNA. It allows you to develop your games mostly
  on the desktop and deploying it to your Android device with just a
  couple of lines that instantiate a special Activity subclass. It's
  based on OpenGL and allows developing 2D and 3D games. I just finished
  writting all the java doc for it and am constantly adding new features
  to it. It's called libgdx and can be found 
  athttp://code.google.com/p/libgdx/.
  I also started blogging about it lately and will continue so adding
  sample codes for specific problems. You can find that blog at
 http://www.badlogicgames.com. An introduction to it can be found at
 http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
  series of small tutorials wil follow this week and next week.

    The whole thing is LGPL so that there's no problem including it in
  commercial apps. It's far from being perfect of course but i think the
  base functionality and ease of use can kill some of the burden a fresh
  android game developer has to overcome.

  I'm open for suggestions and features you want to see in there!

  On 9 Mrz., 22:35, Piotrpiotr.zag...@gmail.com  wrote:
  Hello,

  At my daily job I work as WinMo C++ developer, so I had enough time to
  become hater of that platform ;)

  But now, M$ is coming with new Windows Phone. As I suspected, they
  will abandon awful Win32/MFC native coding and all applications, will
  be now managed - run in CLR sandboxes on top of 15 years old Win32
  kernel.

  Main coding language will be C#  with .NET framework - Java rival.

  WinMo always was terrible phone OS, but now, more interesting is, that
  Windows Phone will support XNA framework:

 http://www.youtube.com/watch?v=LQv_3fwopo8

  This is full gaming framework with C# interfaces and support for 2D/3D
  graphics, animation, sprites, net play, game sound, controllers, etc..
  XNA greatly improves creating games, because it gives a developer an
  ready to use game abstraction layer.

  To the point; Android needs game framework, like XNA. Maybe it should
  be written as NDK library, ready to link with your own application.
  This library could load, manage and draw sprites, backgrounds, make
  simple physics, etc..

  Why ? To create games faster, easier. At this time, you must be very
  skilled to create simple platformer with 2 bkgs and 5 sprites. Our
  devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
  tired of the same logical bricks/ball/falling diamonds games over and
  over.

  What do you think ?

  Is there any chance, that Google will work on something like that ?

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Mario Zechner
I agree to this point based on my own experience and micro benchmarks.
That's why i think only performance critical code should be written in
native code such as physics calculations. I'd really love to get more
people on board of libgdx, it's now in a pretty useable state and the
API is nearly good enough to be frozen. Contact me if you are
interested. I contacted the guy who wrote the Scorpios API but he
didn't seem to be interested in collaborating.

On 17 Mrz., 16:31, niko20 nikolatesl...@yahoo.com wrote:
 Personally through  my experience this JNI layer overhead is so
 small that its effect is negligible. In my apps using NDK with JNI has
 alway increased my speed immensly regardless of any JNI method call
 overhead. It's just simply not true that the JNI will slow you down.

 -niko

 On Mar 17, 9:06 am, Sean Hodges seanhodge...@googlemail.com wrote:

  On Wed, Mar 17, 2010 at 2:25 PM, Streets Of Boston

  flyingdutc...@gmail.com wrote:
   True and not true.

   If google thinks that making an XNA like framework could enhance
   Android's adoption and device sales enough to bring more ad-revenues/
   SaaS-revenues (because more phones would be around if such a framework
   existed), then google could be interested in creating such framework.

   However, if the potiential return on such a framework is not large
   enough, then they won't do it.

  You are of course correct, though I firmly believe spending lots of
  time speculating on such things will 100% fail to actually get the
  work done.

  There is also the question of whether Google are the ideal company to
  produce such a framework. Microsoft have invested a lot in DirectX and
  their XBox projects, they have the experience and the partners to make
  it work. What experience do Google have in the games industry?
  Personally I think they are stretching themselves enough with their
  shoulder barging into the mobile market, without trying to dive into
  the centre of the extremely competitive games market.

  Having said that, the Android platform does need to compete in this
  field. This seems like the perfect opportunity for a start-up, or an
  established games development company, to build a native framework and
  contribute it upstream. Mario's library might be a good starting point
  for this - as well as a technical evaluation of the other
  libraries/engines out there (such as Rokon by StickyCoding).

  The way to move forward would be to actively pursue a solution though,
  rather than mull around the topic passing notes to Google like we were
  in the Peoples' Front of Judea. :)

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Bob Kerns
I'd say instead that it doesn't NEED to slow you down.

But if you store your entire scene graph on the native side, but do
all the manipulation of it on the Java side, with a lot of Java-Java
calls dispatched by the JNI layer in between, and lots of arrays
getting locked or copied -- I guarantee you'll regret it.

But if you start with an intelligent architecture, so you're not just
replacing lots of Java calls to trivial code with JNI calls to trivial
code, you will usually be OK.

Chris Pruett's strategy as he outlined it in this talk:
http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html

I find to be a very solid strategy.

BTW, the argument against moving things *unnecessarily* to JNI is not
just one of performance. It is also negatively affects how quickly you
can modify the code, how well you can test it, and how many bugs
you'll ship with.

But so will doing weird things in Java to try to get it fast enough.
There's a point where it makes sense to move a body of code to JNI.
It's somewhere after you benchmark and think about the problem for a
bit, and before you drive yourself nuts or fail to get your product to
market.

If you've done that, and choose a reasonably cohesive chunk, than in
most cases I wouldn't expect the JNI overhead to be an issue. If it
is, well, you ARE analyzing your trace data, right? You'll figure it
out, and what to do about it.

Just never do performance optimization blindly.

On Mar 17, 8:31 am, niko20 nikolatesl...@yahoo.com wrote:
 Personally through  my experience this JNI layer overhead is so
 small that its effect is negligible. In my apps using NDK with JNI has
 alway increased my speed immensly regardless of any JNI method call
 overhead. It's just simply not true that the JNI will slow you down.

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


Re: [android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-17 Thread Kevin Duffey
Great thread.  I happen to agree with both sides of this argument. While I
like the idea of several of the current native/java game engines maybe
collaborating, coming up with some sort of presentation on why it's prudent
for Android to have a much more solid game capable api/sdk, I also think
that Google/Android has sort of said Yes, apple/iPhone, we'll take you on,
and maybe beat you at your game. There has been tons of articles showing
how android will surpass iPhone in a couple years. Yet, I forget the
percentage now, but I thought it was some 35% of the iPhone market is
games.. and there has to be a decent population for audio apps. That's a
pretty good sized market and to ignore that would to me be a potential death
sentence for Android. Maybe not... just my gut. I think most teens/young
twenties and a lot of us older adults that grew up with games look at
platforms like Nintendo DS, PSP, and then compare to our droid/nexus,
iPhones, etc and realize we have a much more capable bit of hardware in our
single device.. why not make it a game/audio app/utility
app/phone/calendar/internet tool all in one. iPhone is already clearly
taking a chunk of Nintendo DS sales.. they say so themselves. Android
devices like the Droid, Nexus, and many new phones coming out have 600+mhz
cpus, lots of memory, etc.. they easily are more powrful than hand held game
devices and we know that even before iPhone/Android that crappy mobile games
on J2ME were huge all over the world. So while I don't know if it should
fall squarely on google to build some robust gaming kit like XNA, I do think
they should invest heavily right now, for a 3.0 release within the next
year, that gives us a JIT, a lot more native access to things like audio
hardware for low latency, and find a way to curb some of the potential GC
issues many threads have brought up. I think right now, within this year, is
the time that google has to really flesh out a solid much improved Android
3.0 that can compete on most levels with iPhone and keep in mind iPhone 4.0
due out in a few months will add multi-tasking (dying to see how they do
this without breaking existing apps and how they are coded), more features,
etc. I think in many many ways Android is a lot better than iPhone or
anything MS will put out.

At the very least, I think it would be great for Google/Android team to
figure out IF they are planning on doing anything close to the above... and
let us developers know. I know many developers have said, and I too am
waiting to see a much improved audio capability so that apps like iPhone
BeatMaker and such can come out. Likewise this impacts game developers,
along with other variables that many developers are quite clearly saying is
impacting them on being able to build better games. The screen touch issue
that is causing massive lag on input and slowing games down greatly, and the
buggy multi-touch capabilities... all of these things need to be wrapped up
into a 3.0, or a 2.5, 2.6 etc in the coming year so that developers get a
few months or longer to make use of them and put out some really good games,
music apps and such by mid 2011. Not that it will be game over, but I would
think that this is important enough to developers that google/android team
should listen and perhaps keep the developers posted on up coming changes to
the platform. Is there any site that covers what is being worked on right
now? Is there any info that we can read about, maybe provide some input on,
that might be coming up in 2.2, 2.3, 2.5, 3.0, etc? I mean, if 3.0 is just
getting started, perhaps nows the time to solicit the developers that will
write apps for the platform and keep it alive for ideas and what is most
important that they need to want to keep writing for Android.

Just my .02.

On Wed, Mar 17, 2010 at 7:40 PM, Bob Kerns r...@acm.org wrote:

 I'd say instead that it doesn't NEED to slow you down.

 But if you store your entire scene graph on the native side, but do
 all the manipulation of it on the Java side, with a lot of Java-Java
 calls dispatched by the JNI layer in between, and lots of arrays
 getting locked or copied -- I guarantee you'll regret it.

 But if you start with an intelligent architecture, so you're not just
 replacing lots of Java calls to trivial code with JNI calls to trivial
 code, you will usually be OK.

 Chris Pruett's strategy as he outlined it in this talk:

 http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html

 I find to be a very solid strategy.

 BTW, the argument against moving things *unnecessarily* to JNI is not
 just one of performance. It is also negatively affects how quickly you
 can modify the code, how well you can test it, and how many bugs
 you'll ship with.

 But so will doing weird things in Java to try to get it fast enough.
 There's a point where it makes sense to move a body of code to JNI.
 It's somewhere after you benchmark and think about the problem for a
 bit, and before you drive 

[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-11 Thread Piotr
Looks great !

I hope, Google will work on native NDK framework like XNA, because
even for 2d games, java implementation is too slow.

Such framework could help in development beginners and others, who
don't want to create advanced 3d games.

It is still problem, because if you want to create rpg or 2d
platformer, you can't get smooth animation in Java. So, you must use
OpenGL calls.

But when you start using OpenGL in Java, you realize, that you can get
more performance in game engine parts, when you go with lowlevel NDK.
So, you are starting to reinvent circle over and over. You must write
basic engine parts. Resource manager, drawing, animation, colission,
controls, data exchange layer, etc..

Maybe I'm wrong, but why just not to create expandable NDK game
framework library with these parts ready to RESUING for all
developers ? I do not have enough knowledge and experience to work on
that, but it seems right way to improve Android as gaming platform.

I'm just surprised, that such framework from Google still does not
exist.

On 11 Mar, 03:20, Carlo ca...@hyperdevbox.com wrote:
 c# and .net will be like having java, nothing can beat native code, so
 the NDK is the way to go, soon the debugging features will be
 implemented and that will boost original game development, if you look
 at ExZeus arcade built upon NDK, we are already far from the logical
 bricks/ball/falling diamonds games  on the android device.

 On Mar 10, 9:03 pm, Mario Zechner badlogicga...@gmail.com wrote:

  I concur with this statement. I did a lot of benchmarking and the JNI
  bridge crossing of OpenGL methods is not a problem, I can happily
  render hundreds of objects. Also, for performance hungry things like
  MP3 decoding (to get PCM data which is not possible at the moment with
  the mediaframework), physics and so on there's a native library in the
  background of libgdx which does just that. The physics library is
  something i'm currently implementing on top of bullet. These native
  components have a JNI bridge as you suggested. I however carefully
  chose what's going to be included in the native library part of libgdx
  to reduce the pain of coding C++.

  What also speaks against a pure NDK solution is the missing debugging
  features which slows down development immenseley.

  On 10 Mrz., 11:35, Piotr piotr.zag...@gmail.com wrote:

   Both these frameworks are interesting, but as I mentioned before; it
   could be better, to create low-level, native NDK game framework
   library. Java is just too slow to handle thousands opengl calls per
   second for any game more complex than falling bricks or sth.

   Such framework could load game elements (maps, tiles, sprites, bkgs,
   sounds), giving developer control interface set to call high level
   methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics,
   etc..

   On 10 Mar, 11:00, Mario Zechner badlogicga...@gmail.com wrote:

Very cool! didn't know about that. I try to get in contact with the
author.

On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote:

  It allows you to develop your games mostly
  on the desktop and deploying it to your Android device

 Neat project. Have you seen this one for the same 
 purpose?http://code.google.com/p/skorpios/

 Might be neat to cooperate or share techniques or something.

 On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote:

  While it's not nearly as full featured as XNA i started working on
  something similar to XNA. It allows you to develop your games mostly
  on the desktop and deploying it to your Android device with just a
  couple of lines that instantiate a special Activity subclass. It's
  based on OpenGL and allows developing 2D and 3D games. I just 
  finished
  writting all the java doc for it and am constantly adding new 
  features
  to it. It's called libgdx and can be found 
  athttp://code.google.com/p/libgdx/.
  I also started blogging about it lately and will continue so adding
  sample codes for specific problems. You can find that blog 
  athttp://www.badlogicgames.com. An introduction to it can be found 
  athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
  series of small tutorials wil follow this week and next week.

   The whole thing is LGPL so that there's no problem including it in
  commercial apps. It's far from being perfect of course but i think 
  the
  base functionality and ease of use can kill some of the burden a 
  fresh
  android game developer has to overcome.

  I'm open for suggestions and features you want to see in there!

  On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:

   Hello,

   At my daily job I work as WinMo C++ developer, so I had enough 
   time to
   become hater of that platform ;)

   But now, M$ is coming with new Windows Phone. As I suspected, they
   will abandon awful 

[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-11 Thread Bob Kerns
This comment is perhaps a bit off your main topic, and I don't mean it
to derail your efforts or to criticize.

But I have a bit of a problem with your statement Java is just too
slow..., taken as a general statement. Perhaps you have benchmark
data showing specific performance problems, and found it so; I'm not
disputing that.

However, the performance landscape is a lot more complex than this
would suggest, if taken beyond your context. In particular, there are
at least 4 performance areas to consider here:

1) Java performance -- which is actually generally quite good in the
desktop/server world; I've not done any Android benchmarking.
2) JNI performance -- there's added cost per switch to native code;
sometimes it's better to do more work in Java to avoid this overhead,
or to batch up work and do more per JNI call.
3) OpenGL library/driver performance. This is both the stuff that's
done in software in preparing for the GPU pipeline, and how
effectively it makes use of the hardware, and failures to use
capabilities that exist in the hardware.
4) The GPU hardware itself

Judging from the reports I see here (and not personal experience on
this platform as yet), a lot of the performance problems we see are
further down this chain. Better graphics hardware and better drivers
push the bottlenecks up the chain; faster main processors and Java VM
improvements push them down. But where you encounter the bottleneck
will always depend on just what the application is doing. Textures are
a big part of that, as is managing levels of detail so you don't waste
time rendering detail that isn't really noticeable. There are a lot of
ways to use OpenGL poorly. And there are a lot of ways to use it well,
but push the limits in the search for image quality.

Pushing things down in to C++ is just going to harm developers, if
it's not actually where the bottleneck is. As Mario says, you have to
choose carefully. Do you move your physics engine into C++ -- or just
the matrix multiplications? Or perhaps just significant components,
like collision detection and the timestep integrations? If you push
stuff down to C++, how do you allow for customization, without
incurring the JNI callback overhead?

Part of what I'm getting at is that because apps are different, the
optimal tradeoff will differ. I'm not sure that Google providing a
framework would be the way to go. Obviously, each developer
implementing their own isn't a good thing either. I think shared
community efforts, or commercial libraries make a lot more sense
(though there could be an official library as one of these options).

This is especially true of physics engines.

But there is such wide variation in what demands an application makes
of 3D rendering that blanket statements like Java is too slow
conceal the issues.

So I would council against blindly pushing stuff down to native code
based on such broad statements, but rather doing so conservatively,
based on realistic benchmarks.

On Mar 10, 2:35 am, Piotr piotr.zag...@gmail.com wrote:
 Both these frameworks are interesting, but as I mentioned before; it
 could be better, to create low-level, native NDK game framework
 library. Java is just too slow to handle thousands opengl calls per
 second for any game more complex than falling bricks or sth.

 Such framework could load game elements (maps, tiles, sprites, bkgs,
 sounds), giving developer control interface set to call high level
 methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics,
 etc..

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-11 Thread Mario Zechner
Extremely well written post Bob, thanks a lot for that. I can totally
agree to your statements and can confirm that the bottleneck in games
is not the Dalvik VM and therefor Java for almost all parts of a game.
What kills performance at the moment is way down in the chain at the
hardware level. Fill-rate limits are the biggest issue we game
developers have to face at the moment. Everything else does not
contribute much, implementing your whole game in C does not solve that
problem. And i speak from personal experience in this case :)

On a side note: ExDeus was not developed with the NDK. The game is
actually a port of an IPhone version so it was developed with the
IPhone tools for the most part. Those feature a native debugger. The
Android version is probably only different in setting up the gl
surface and processing input.

On 11 Mrz., 17:01, Bob Kerns r...@acm.org wrote:
 This comment is perhaps a bit off your main topic, and I don't mean it
 to derail your efforts or to criticize.

 But I have a bit of a problem with your statement Java is just too
 slow..., taken as a general statement. Perhaps you have benchmark
 data showing specific performance problems, and found it so; I'm not
 disputing that.

 However, the performance landscape is a lot more complex than this
 would suggest, if taken beyond your context. In particular, there are
 at least 4 performance areas to consider here:

 1) Java performance -- which is actually generally quite good in the
 desktop/server world; I've not done any Android benchmarking.
 2) JNI performance -- there's added cost per switch to native code;
 sometimes it's better to do more work in Java to avoid this overhead,
 or to batch up work and do more per JNI call.
 3) OpenGL library/driver performance. This is both the stuff that's
 done in software in preparing for the GPU pipeline, and how
 effectively it makes use of the hardware, and failures to use
 capabilities that exist in the hardware.
 4) The GPU hardware itself

 Judging from the reports I see here (and not personal experience on
 this platform as yet), a lot of the performance problems we see are
 further down this chain. Better graphics hardware and better drivers
 push the bottlenecks up the chain; faster main processors and Java VM
 improvements push them down. But where you encounter the bottleneck
 will always depend on just what the application is doing. Textures are
 a big part of that, as is managing levels of detail so you don't waste
 time rendering detail that isn't really noticeable. There are a lot of
 ways to use OpenGL poorly. And there are a lot of ways to use it well,
 but push the limits in the search for image quality.

 Pushing things down in to C++ is just going to harm developers, if
 it's not actually where the bottleneck is. As Mario says, you have to
 choose carefully. Do you move your physics engine into C++ -- or just
 the matrix multiplications? Or perhaps just significant components,
 like collision detection and the timestep integrations? If you push
 stuff down to C++, how do you allow for customization, without
 incurring the JNI callback overhead?

 Part of what I'm getting at is that because apps are different, the
 optimal tradeoff will differ. I'm not sure that Google providing a
 framework would be the way to go. Obviously, each developer
 implementing their own isn't a good thing either. I think shared
 community efforts, or commercial libraries make a lot more sense
 (though there could be an official library as one of these options).

 This is especially true of physics engines.

 But there is such wide variation in what demands an application makes
 of 3D rendering that blanket statements like Java is too slow
 conceal the issues.

 So I would council against blindly pushing stuff down to native code
 based on such broad statements, but rather doing so conservatively,
 based on realistic benchmarks.

 On Mar 10, 2:35 am, Piotr piotr.zag...@gmail.com wrote:

  Both these frameworks are interesting, but as I mentioned before; it
  could be better, to create low-level, native NDK game framework
  library. Java is just too slow to handle thousands opengl calls per
  second for any game more complex than falling bricks or sth.

  Such framework could load game elements (maps, tiles, sprites, bkgs,
  sounds), giving developer control interface set to call high level
  methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics,
  etc..

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-10 Thread Mario Zechner
Very cool! didn't know about that. I try to get in contact with the
author.

On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote:
  It allows you to develop your games mostly
  on the desktop and deploying it to your Android device

 Neat project. Have you seen this one for the same 
 purpose?http://code.google.com/p/skorpios/

 Might be neat to cooperate or share techniques or something.

 On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote:

  While it's not nearly as full featured as XNA i started working on
  something similar to XNA. It allows you to develop your games mostly
  on the desktop and deploying it to your Android device with just a
  couple of lines that instantiate a special Activity subclass. It's
  based on OpenGL and allows developing 2D and 3D games. I just finished
  writting all the java doc for it and am constantly adding new features
  to it. It's called libgdx and can be found 
  athttp://code.google.com/p/libgdx/.
  I also started blogging about it lately and will continue so adding
  sample codes for specific problems. You can find that blog 
  athttp://www.badlogicgames.com. An introduction to it can be found 
  athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
  series of small tutorials wil follow this week and next week.

   The whole thing is LGPL so that there's no problem including it in
  commercial apps. It's far from being perfect of course but i think the
  base functionality and ease of use can kill some of the burden a fresh
  android game developer has to overcome.

  I'm open for suggestions and features you want to see in there!

  On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:

   Hello,

   At my daily job I work as WinMo C++ developer, so I had enough time to
   become hater of that platform ;)

   But now, M$ is coming with new Windows Phone. As I suspected, they
   will abandon awful Win32/MFC native coding and all applications, will
   be now managed - run in CLR sandboxes on top of 15 years old Win32
   kernel.

   Main coding language will be C#  with .NET framework - Java rival.

   WinMo always was terrible phone OS, but now, more interesting is, that
   Windows Phone will support XNA framework:

  http://www.youtube.com/watch?v=LQv_3fwopo8

   This is full gaming framework with C# interfaces and support for 2D/3D
   graphics, animation, sprites, net play, game sound, controllers, etc..
   XNA greatly improves creating games, because it gives a developer an
   ready to use game abstraction layer.

   To the point; Android needs game framework, like XNA. Maybe it should
   be written as NDK library, ready to link with your own application.
   This library could load, manage and draw sprites, backgrounds, make
   simple physics, etc..

   Why ? To create games faster, easier. At this time, you must be very
   skilled to create simple platformer with 2 bkgs and 5 sprites. Our
   devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
   tired of the same logical bricks/ball/falling diamonds games over and
   over.

   What do you think ?

   Is there any chance, that Google will work on something like that ?

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-10 Thread Piotr
Both these frameworks are interesting, but as I mentioned before; it
could be better, to create low-level, native NDK game framework
library. Java is just too slow to handle thousands opengl calls per
second for any game more complex than falling bricks or sth.

Such framework could load game elements (maps, tiles, sprites, bkgs,
sounds), giving developer control interface set to call high level
methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics,
etc..


On 10 Mar, 11:00, Mario Zechner badlogicga...@gmail.com wrote:
 Very cool! didn't know about that. I try to get in contact with the
 author.

 On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote:

   It allows you to develop your games mostly
   on the desktop and deploying it to your Android device

  Neat project. Have you seen this one for the same 
  purpose?http://code.google.com/p/skorpios/

  Might be neat to cooperate or share techniques or something.

  On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote:

   While it's not nearly as full featured as XNA i started working on
   something similar to XNA. It allows you to develop your games mostly
   on the desktop and deploying it to your Android device with just a
   couple of lines that instantiate a special Activity subclass. It's
   based on OpenGL and allows developing 2D and 3D games. I just finished
   writting all the java doc for it and am constantly adding new features
   to it. It's called libgdx and can be found 
   athttp://code.google.com/p/libgdx/.
   I also started blogging about it lately and will continue so adding
   sample codes for specific problems. You can find that blog 
   athttp://www.badlogicgames.com. An introduction to it can be found 
   athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
   series of small tutorials wil follow this week and next week.

    The whole thing is LGPL so that there's no problem including it in
   commercial apps. It's far from being perfect of course but i think the
   base functionality and ease of use can kill some of the burden a fresh
   android game developer has to overcome.

   I'm open for suggestions and features you want to see in there!

   On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:

Hello,

At my daily job I work as WinMo C++ developer, so I had enough time to
become hater of that platform ;)

But now, M$ is coming with new Windows Phone. As I suspected, they
will abandon awful Win32/MFC native coding and all applications, will
be now managed - run in CLR sandboxes on top of 15 years old Win32
kernel.

Main coding language will be C#  with .NET framework - Java rival.

WinMo always was terrible phone OS, but now, more interesting is, that
Windows Phone will support XNA framework:

   http://www.youtube.com/watch?v=LQv_3fwopo8

This is full gaming framework with C# interfaces and support for 2D/3D
graphics, animation, sprites, net play, game sound, controllers, etc..
XNA greatly improves creating games, because it gives a developer an
ready to use game abstraction layer.

To the point; Android needs game framework, like XNA. Maybe it should
be written as NDK library, ready to link with your own application.
This library could load, manage and draw sprites, backgrounds, make
simple physics, etc..

Why ? To create games faster, easier. At this time, you must be very
skilled to create simple platformer with 2 bkgs and 5 sprites. Our
devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
tired of the same logical bricks/ball/falling diamonds games over and
over.

What do you think ?

Is there any chance, that Google will work on something like that ?

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-10 Thread Mario Zechner
I concur with this statement. I did a lot of benchmarking and the JNI
bridge crossing of OpenGL methods is not a problem, I can happily
render hundreds of objects. Also, for performance hungry things like
MP3 decoding (to get PCM data which is not possible at the moment with
the mediaframework), physics and so on there's a native library in the
background of libgdx which does just that. The physics library is
something i'm currently implementing on top of bullet. These native
components have a JNI bridge as you suggested. I however carefully
chose what's going to be included in the native library part of libgdx
to reduce the pain of coding C++.

What also speaks against a pure NDK solution is the missing debugging
features which slows down development immenseley.

On 10 Mrz., 11:35, Piotr piotr.zag...@gmail.com wrote:
 Both these frameworks are interesting, but as I mentioned before; it
 could be better, to create low-level, native NDK game framework
 library. Java is just too slow to handle thousands opengl calls per
 second for any game more complex than falling bricks or sth.

 Such framework could load game elements (maps, tiles, sprites, bkgs,
 sounds), giving developer control interface set to call high level
 methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics,
 etc..

 On 10 Mar, 11:00, Mario Zechner badlogicga...@gmail.com wrote:

  Very cool! didn't know about that. I try to get in contact with the
  author.

  On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote:

It allows you to develop your games mostly
on the desktop and deploying it to your Android device

   Neat project. Have you seen this one for the same 
   purpose?http://code.google.com/p/skorpios/

   Might be neat to cooperate or share techniques or something.

   On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote:

While it's not nearly as full featured as XNA i started working on
something similar to XNA. It allows you to develop your games mostly
on the desktop and deploying it to your Android device with just a
couple of lines that instantiate a special Activity subclass. It's
based on OpenGL and allows developing 2D and 3D games. I just finished
writting all the java doc for it and am constantly adding new features
to it. It's called libgdx and can be found 
athttp://code.google.com/p/libgdx/.
I also started blogging about it lately and will continue so adding
sample codes for specific problems. You can find that blog 
athttp://www.badlogicgames.com. An introduction to it can be found 
athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
series of small tutorials wil follow this week and next week.

 The whole thing is LGPL so that there's no problem including it in
commercial apps. It's far from being perfect of course but i think the
base functionality and ease of use can kill some of the burden a fresh
android game developer has to overcome.

I'm open for suggestions and features you want to see in there!

On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:

 Hello,

 At my daily job I work as WinMo C++ developer, so I had enough time to
 become hater of that platform ;)

 But now, M$ is coming with new Windows Phone. As I suspected, they
 will abandon awful Win32/MFC native coding and all applications, will
 be now managed - run in CLR sandboxes on top of 15 years old Win32
 kernel.

 Main coding language will be C#  with .NET framework - Java rival.

 WinMo always was terrible phone OS, but now, more interesting is, that
 Windows Phone will support XNA framework:

http://www.youtube.com/watch?v=LQv_3fwopo8

 This is full gaming framework with C# interfaces and support for 2D/3D
 graphics, animation, sprites, net play, game sound, controllers, etc..
 XNA greatly improves creating games, because it gives a developer an
 ready to use game abstraction layer.

 To the point; Android needs game framework, like XNA. Maybe it should
 be written as NDK library, ready to link with your own application.
 This library could load, manage and draw sprites, backgrounds, make
 simple physics, etc..

 Why ? To create games faster, easier. At this time, you must be very
 skilled to create simple platformer with 2 bkgs and 5 sprites. Our
 devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
 tired of the same logical bricks/ball/falling diamonds games over and
 over.

 What do you think ?

 Is there any chance, that Google will work on something like that ?

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at

[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-10 Thread Carlo
c# and .net will be like having java, nothing can beat native code, so
the NDK is the way to go, soon the debugging features will be
implemented and that will boost original game development, if you look
at ExZeus arcade built upon NDK, we are already far from the logical
bricks/ball/falling diamonds games  on the android device.

On Mar 10, 9:03 pm, Mario Zechner badlogicga...@gmail.com wrote:
 I concur with this statement. I did a lot of benchmarking and the JNI
 bridge crossing of OpenGL methods is not a problem, I can happily
 render hundreds of objects. Also, for performance hungry things like
 MP3 decoding (to get PCM data which is not possible at the moment with
 the mediaframework), physics and so on there's a native library in the
 background of libgdx which does just that. The physics library is
 something i'm currently implementing on top of bullet. These native
 components have a JNI bridge as you suggested. I however carefully
 chose what's going to be included in the native library part of libgdx
 to reduce the pain of coding C++.

 What also speaks against a pure NDK solution is the missing debugging
 features which slows down development immenseley.

 On 10 Mrz., 11:35, Piotr piotr.zag...@gmail.com wrote:



  Both these frameworks are interesting, but as I mentioned before; it
  could be better, to create low-level, native NDK game framework
  library. Java is just too slow to handle thousands opengl calls per
  second for any game more complex than falling bricks or sth.

  Such framework could load game elements (maps, tiles, sprites, bkgs,
  sounds), giving developer control interface set to call high level
  methods like setSpriteSpeed, setBackgroundScroll, manageSpritePhysics,
  etc..

  On 10 Mar, 11:00, Mario Zechner badlogicga...@gmail.com wrote:

   Very cool! didn't know about that. I try to get in contact with the
   author.

   On 10 Mrz., 02:31, Lance Nanek lna...@gmail.com wrote:

 It allows you to develop your games mostly
 on the desktop and deploying it to your Android device

Neat project. Have you seen this one for the same 
purpose?http://code.google.com/p/skorpios/

Might be neat to cooperate or share techniques or something.

On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote:

 While it's not nearly as full featured as XNA i started working on
 something similar to XNA. It allows you to develop your games mostly
 on the desktop and deploying it to your Android device with just a
 couple of lines that instantiate a special Activity subclass. It's
 based on OpenGL and allows developing 2D and 3D games. I just finished
 writting all the java doc for it and am constantly adding new features
 to it. It's called libgdx and can be found 
 athttp://code.google.com/p/libgdx/.
 I also started blogging about it lately and will continue so adding
 sample codes for specific problems. You can find that blog 
 athttp://www.badlogicgames.com. An introduction to it can be found 
 athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
 series of small tutorials wil follow this week and next week.

  The whole thing is LGPL so that there's no problem including it in
 commercial apps. It's far from being perfect of course but i think the
 base functionality and ease of use can kill some of the burden a fresh
 android game developer has to overcome.

 I'm open for suggestions and features you want to see in there!

 On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:

  Hello,

  At my daily job I work as WinMo C++ developer, so I had enough time 
  to
  become hater of that platform ;)

  But now, M$ is coming with new Windows Phone. As I suspected, they
  will abandon awful Win32/MFC native coding and all applications, 
  will
  be now managed - run in CLR sandboxes on top of 15 years old Win32
  kernel.

  Main coding language will be C#  with .NET framework - Java rival.

  WinMo always was terrible phone OS, but now, more interesting is, 
  that
  Windows Phone will support XNA framework:

 http://www.youtube.com/watch?v=LQv_3fwopo8

  This is full gaming framework with C# interfaces and support for 
  2D/3D
  graphics, animation, sprites, net play, game sound, controllers, 
  etc..
  XNA greatly improves creating games, because it gives a developer an
  ready to use game abstraction layer.

  To the point; Android needs game framework, like XNA. Maybe it 
  should
  be written as NDK library, ready to link with your own application.
  This library could load, manage and draw sprites, backgrounds, make
  simple physics, etc..

  Why ? To create games faster, easier. At this time, you must be very
  skilled to create simple platformer with 2 bkgs and 5 sprites. Our
  devices have even 1GHz CPU's and animation can be STILL too slow ! 
  I'm
  

[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-09 Thread Mario Zechner
While it's not nearly as full featured as XNA i started working on
something similar to XNA. It allows you to develop your games mostly
on the desktop and deploying it to your Android device with just a
couple of lines that instantiate a special Activity subclass. It's
based on OpenGL and allows developing 2D and 3D games. I just finished
writting all the java doc for it and am constantly adding new features
to it. It's called libgdx and can be found at http://code.google.com/p/libgdx/.
I also started blogging about it lately and will continue so adding
sample codes for specific problems. You can find that blog at
http://www.badlogicgames.com. An introduction to it can be found at
http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
series of small tutorials wil follow this week and next week.

 The whole thing is LGPL so that there's no problem including it in
commercial apps. It's far from being perfect of course but i think the
base functionality and ease of use can kill some of the burden a fresh
android game developer has to overcome.

I'm open for suggestions and features you want to see in there!

On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:
 Hello,

 At my daily job I work as WinMo C++ developer, so I had enough time to
 become hater of that platform ;)

 But now, M$ is coming with new Windows Phone. As I suspected, they
 will abandon awful Win32/MFC native coding and all applications, will
 be now managed - run in CLR sandboxes on top of 15 years old Win32
 kernel.

 Main coding language will be C#  with .NET framework - Java rival.

 WinMo always was terrible phone OS, but now, more interesting is, that
 Windows Phone will support XNA framework:

 http://www.youtube.com/watch?v=LQv_3fwopo8

 This is full gaming framework with C# interfaces and support for 2D/3D
 graphics, animation, sprites, net play, game sound, controllers, etc..
 XNA greatly improves creating games, because it gives a developer an
 ready to use game abstraction layer.

 To the point; Android needs game framework, like XNA. Maybe it should
 be written as NDK library, ready to link with your own application.
 This library could load, manage and draw sprites, backgrounds, make
 simple physics, etc..

 Why ? To create games faster, easier. At this time, you must be very
 skilled to create simple platformer with 2 bkgs and 5 sprites. Our
 devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
 tired of the same logical bricks/ball/falling diamonds games over and
 over.

 What do you think ?

 Is there any chance, that Google will work on something like that ?

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


[android-developers] Re: Windows Phone and XNA. Nightmare is real. What we do with that ?

2010-03-09 Thread Lance Nanek
 It allows you to develop your games mostly
 on the desktop and deploying it to your Android device

Neat project. Have you seen this one for the same purpose?
http://code.google.com/p/skorpios/

Might be neat to cooperate or share techniques or something.

On Mar 9, 7:11 pm, Mario Zechner badlogicga...@gmail.com wrote:
 While it's not nearly as full featured as XNA i started working on
 something similar to XNA. It allows you to develop your games mostly
 on the desktop and deploying it to your Android device with just a
 couple of lines that instantiate a special Activity subclass. It's
 based on OpenGL and allows developing 2D and 3D games. I just finished
 writting all the java doc for it and am constantly adding new features
 to it. It's called libgdx and can be found athttp://code.google.com/p/libgdx/.
 I also started blogging about it lately and will continue so adding
 sample codes for specific problems. You can find that blog 
 athttp://www.badlogicgames.com. An introduction to it can be found 
 athttp://apistudios.com/hosted/marzec/badlogic/wordpress/?p=274. A
 series of small tutorials wil follow this week and next week.

  The whole thing is LGPL so that there's no problem including it in
 commercial apps. It's far from being perfect of course but i think the
 base functionality and ease of use can kill some of the burden a fresh
 android game developer has to overcome.

 I'm open for suggestions and features you want to see in there!

 On 9 Mrz., 22:35, Piotr piotr.zag...@gmail.com wrote:

  Hello,

  At my daily job I work as WinMo C++ developer, so I had enough time to
  become hater of that platform ;)

  But now, M$ is coming with new Windows Phone. As I suspected, they
  will abandon awful Win32/MFC native coding and all applications, will
  be now managed - run in CLR sandboxes on top of 15 years old Win32
  kernel.

  Main coding language will be C#  with .NET framework - Java rival.

  WinMo always was terrible phone OS, but now, more interesting is, that
  Windows Phone will support XNA framework:

 http://www.youtube.com/watch?v=LQv_3fwopo8

  This is full gaming framework with C# interfaces and support for 2D/3D
  graphics, animation, sprites, net play, game sound, controllers, etc..
  XNA greatly improves creating games, because it gives a developer an
  ready to use game abstraction layer.

  To the point; Android needs game framework, like XNA. Maybe it should
  be written as NDK library, ready to link with your own application.
  This library could load, manage and draw sprites, backgrounds, make
  simple physics, etc..

  Why ? To create games faster, easier. At this time, you must be very
  skilled to create simple platformer with 2 bkgs and 5 sprites. Our
  devices have even 1GHz CPU's and animation can be STILL too slow ! I'm
  tired of the same logical bricks/ball/falling diamonds games over and
  over.

  What do you think ?

  Is there any chance, that Google will work on something like that ?



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