On 9/18/2010 5:24 PM, Robert Green wrote:
Bah, 2D in OpenGL really isn't that hard and there's not that much
extra code. If someone were to just write a simple spriterenderer
class that takes a set of bitmaps and lets you draw them wherever you
want by index then improve it to handle an atlas of images for faster
drawing and you've got 90% of most 2D game rendering code done right
there, all in under a couple hundred or so lines.
No one was saying rendering 2D in OGL was hard and I think you're vastly
over simplifying things. Actually I just Googled this from your own journal:
"Android is none too easy to develop OpenGL apps for."
http://www.rbgrn.net/content/215-light-racer-3d-development-journal
As soon as you have OGL in the picture you have to deal with alot of
stuff like pow2 textures, texture formats, state changes, viewport,
different drivers etc. My current game Tank Recon 3D is suffering a
crash on the HTC Hero that is in the OGL driver. There is also a thread
going on talking about a really hard to find OGL crash. Why would you
want to subject yourself to this if you're game is all about pushing 2D
sprites? I'm not trying to be negitive but the reality is if I don't
have to use a 3D api for 2D stuff I won't. Freddy Falling, Freddy Jump
and Wrath all use the 2D API and were MUCH MUCH easier to write and
handle the Activity lifecycle.
The lifecycle isn't that bad - all you ever have to do is reload vram-
stored stuff like textures and VBOs, which I just have a method called
vInit() that does that for any given renderer in the game, and when
the gl context has changed, my main renderer just calls vInit() on all
the subrenderers and all is back into the context and ready. I think
that took me all of a few hours to get working correctly.
I don't agree with you there at all. For one thing an OGL context gets
kicked out far more often than a full Activity does. Now your game also
has to manage reloading all the resources which it might not have been
written to track.
I think the original point was that it would be nice if you could do a
simple bitblt that was hardware accelerated using the 2D API.
On Sep 18, 1:55 pm, Leigh McRae<leigh.mc...@lonedwarfgames.com>
wrote:
On 9/18/2010 2:23 PM, Dianne Hackborn wrote:> On Fri, Sep 17, 2010 at 7:54
PM, Leigh McRae
<leigh.mc...@lonedwarfgames.com
<mailto:leigh.mc...@lonedwarfgames.com>> wrote:
Making a few fast paths for drawing bitmaps (BitBlt) would be
huge for game developers. I know that 3 of my games I have made
aren't OGL simply because I don't want the extra code
maintenance/burden. If a game is doing some of the things you
mention, well then it's not likely concerned with frame-rate.
Use OpenGL ES.
As I stated, using OpenGL ES requires extra code. You to manage
re-loading the assets such as textures and VBO. With the Android
Activity life cycle this is even more of an issue than other platforms.
This isn't trivial. It also exposes you to driver bugs/oddities.
Seriously, you generally can't just accelerate one function and
nothing else. What you will end up with is the worst of both worlds,
as you take the hit of switching between hardware and software
rendering all the time.
You can actually. I don't think it's being suggested that you use the
OpenGL driver to implement a basic bitblt. Its being suggested that the
Android OS supports the ability for hardware to accelerate the bitblt.
Maybe it already does, I don't know.
If you just want to draw bitmaps to the screen, this can certainly be
accomplished with Open GL ES, and you don't need to rely on the
platform to provide you with essentially helper APIs to make it easier
to do that particular special case. You can ask anyone here to write
such a thing for you. Waiting for the platform to provide it is a
really bad option because you don't know when it will be available (we
don't really, either), and even once it does become available you
can't really take advantage of it until it is available on the
majority of the devices.
There are so many things people can do without relying on the platform
to give it to them in a nice little bundle.
I don't think anyone is waiting. I believe it was just a
request/suggestion.
--
Dianne Hackborn
Android framework engineer
hack...@android.com<mailto:hack...@android.com>
Note: please don't send private questions to me, as I don't have time
to provide private support, and so won't reply to such e-mails. All
such questions should be posted on public forums, where I and others
can see and answer them.
--
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
--
Leigh McRaewww.lonedwarfgames.com
--
Leigh McRae
www.lonedwarfgames.com
--
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
