That whole example is trivial and is missing alot of boiler plate.
Because it is a trivial task
Good news! Post the code when you're done...
There already exists several android game engines for this task such
as: http://www.andengine.org/
Google already provides GLSurfaceView to handle lifecycle changes.
Even using the native android widgets along your game is trivial using
GLSurfaceView.
GLSurfaceView, the last time I check, handles nothing as far a lifecylce is
concerned. It gives you callbacks when you loose your surface. Big deal,
so does SurfaceHolder.
Didn't you look at andengine?
I am sure it's great but I have my own code. Actually why do you need a
2D OGL engine if it's such a trivial task?
My assertion stands that GLSurfaceView does nothing to handle Activity
Lifecycle. On BlackBerry when you loose focus and have been put into
the background, the OS handles it. GLSurfaceView just lets you know
you're context is dead and it's up to you to rebuild it all. So what is
it handling that a regular SurfaceHolder isn't?
GLSurfaceView is just like a view, you don't ever handle lifecycle
changes from a view point of view so it removes that burden from the
pictures. You handle this from your activity.
Changing your view port is ridiculously easy if you detect the view
size has changed.
Shouldn't take you more than a day or so to make your own engine and
build your game around it without any bloat and learning something in
the process.
I think you're missing the point. I also think you are clearly under
estimating the time invloved. I have done both BTW.
I've done this, I wrote a complete game prototype in a week. It was
really easy. You really have to be an incompetent programmer if you
don't write code that handles things such as different screen sizes
automatically.
No need to throw stones :) I have worked on many games thank you, 8 of
which shipped. Screen size isn't the issue.
People, this is just a request. It would only make the platform better.
On Sat, Sep 18, 2010 at 11:55 AM, 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 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
--
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
--
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
