OK, so I just got this idea for a game. I already know how to develop for Android, so I though of developing for Android first.
The game (without revealing too much :D) will have a single shape onscreen all the time. It will have to smoothly change shape, color etc. in response to a few knobs/sliders on the screen.
As we do not have multiple shapes/objects I do not need any form of physics engine now. I need to be able to draw polygons and transition colors/gradients effortlessly. I'm targeting a high FPS for this game (think PewPew/2Fuse!)
Do I need OpenGL for this? If so, where can I learn it?
(I'm aware that OpenGL is difficult, and that it's time-consuming to learn.)
I can only offer some of my views. Programming a game is much about transferring artistic assets from the programs, in which they are created (3D modeling programs, Photoshop, Gimp, ...), into your own program. Whether you select OpenGL or Canvas is therefore somewhat dependent upon the nature of your assets (3D models, or bitmaps only, for example). You should be aware however, that on modern Android devices OpenGL ES support is universal and that on those devices the Canvas is implemented with OpenGL ES. Choosing OpenGL ES therefore eliminates one level of indirection. You also have libraries like Cocos2D that offer 2D APIs, but use OpenGL for implementation. To conclude, without top-notch artistic assets your game cannot succeed, if those are good however, even a game using the Canvas may succeed.
EDIT: I think you should proceed like this:
game design -> assets implementing game design -> API offering the shortest path towards the reproduction of the assets in your game
If your assets are polygon based (as you mention in a comment) you should go with OpenGL ES 2.0. OpenGL ES 2.0 is non-trivial to learn, but in learning it, you would gain some marketable skills and experience, and you could make work that is very "showy" for a programmer. Just be patient and try to understand how it works and not just "slop through it."
A great place to start learning is with a tutorial like this one.
Related
I'm trying to create to create an app that will house a 3D sphere, with a surface color skin, that the user will be able to manipulate (rotate, zoom in/zoom out, be able to drop pins on coordinates, & other simple tasks like that). I was first considering using OpenGL ES, but I'm currently scared by the following comment taken from https://developer.android.com/guide/topics/graphics/opengl.html,
"However, if you want more control of what your application draws on screen, or are venturing into three dimensional graphics, you need to use a different tool."
Is 3D modeling a complete waste of time in OpenGL ES? Am I better off with a different tool?
Thanks for the help!
First, page you have linked does not have the quoted text. It´s instead in this text.
Now, about the text itself: you are taking it out of context and/or misunderstanding it. Here's a full citation:
The Android framework provides plenty of
standard tools for creating attractive, functional
graphical user interfaces. However, if you want
more control of what your application draws on
screen, or are venturing into three dimensional
graphics, you need to use a different tool. The
OpenGL ES APIs provided by the Android
framework offers a set of tools for displaying
high-end, animated graphics that are limited only
by your imagination and can also benefit from the
acceleration of graphics processing units (GPUs)
provided on many Android devices.
Which means that Android provides standard tools (Canvas or views), but for more control or 3D graphics you need to use OpenGL ES.
Is 3D modeling a complete waste of time in
OpenGL ES? Am I better off with a different tool?
OpenGL ES and the recent Vulkan API are the only tools available for Android which let you do 3D graphics and use GPU more directly.
So, OpenGL ES is what you should use (or Vulkan, if the devices you are targetting have support for it).
OpenGL ES is just a low-level accelerated rendering API - it will let your application get pretty pixels on to the screen.
All of the higher-level logic (handling rotate, zoom, pins, deciding what to draw, etc) needs to be provided by your application. OpenGL ES provides the tools to help, but it can't provide the logic for you.
I have done some reading on OpenGl ES for Android. I know that I could make a game with the canvas API, but I would like to experiment with OpenGl ES first.
From here I can see two options: Use a game engine or develop my OpenGl ES from the ground up.
The coder/math person that I am is pushing me to the harder option(second option). The way I want to start on this journey is by creating a mesh and manipulating it with various transformations. I will worry about the textures later on. I've learned that I could develop my mesh using outside software such as Blender or LibGdx. However, I would like to learn to develop it with the android API. Do you think this is possible? Will it be very taxing for the android system to process many meshes and transform them? I think It will.
Should I just stick to the game engine way, and forget the "from the ground up mindset".
I also just found out about the replica island source code. Perhaps, I should start reading it and tweaking it on my own.
One more thing, from what I see, I have several options when developing graphics on android using OpenGl ES. Create the 3D model meshes or use sprites(such as replica island). Are there any other ways of doing this?
It all depends on the complexity of the game.
If it's on the simpler side, you could very well 'start from scratch'. I'm pretty sure, you'll end up creating something similar to replica island. For a complex game, you'll be near (as we're from moon) unity on the other extreme. We're talking about hundreds of thousands of man-hours.
As far as creating the meshes is concerned, OpenGL(ES) can only render the meshes.
Unless it's a very primitive mesh or one which can be modelled mathematically with a few equations (less likely for a game), you'll have to create them in blender, maya etc.
For a first timer, I suggest reusing an existing game/engine.
The transition from rendering meshes, then applying textures, then using lighting and shadows etc has a decent learning curve.
Trust me, even with this approach the coder/Math person will have enough on his plate.
I'm developing a client for LBS service and I need to implement some 2D and 3D graphics.
As I read, standard package android.graphics is better for 2D grahics and drawing simple objects, and opengl es is better for 3D and it works faster. Unfortunatelly, I did'n find anything alse about their differences. Does anybody konow more about differences between drawing with OpenGL ES and with android.graphics?
OpenGL will give you full control over the graphics that you are using. You will not have many limitations long term on what you would like to do. You can make a good 3D game on an Android using OpenGL, as you can render large amounts of polys and overlay 2D graphics on top of those. It is a great deal of work, though.
Regular old OpenGL is my favorite, and I'd hate to have to use any of the frameworks mentioned in other answers, but I've been working with 3D graphics for many years. I can see why others would recommend them.
If you haven't done 3D graphics before, you have a steep learning curve in front of you. If you don't take the time to learn the underlying math and rendering concepts, you will struggle with it long term.
I love the reference pages from Khronos
Also, the Android developer site has some nice reference.
The main difference is that OpenGL is much faster compared to Canvas (The Android 2D graphics drawing surface). Although hardware acceleration is enabled for Canvas since honeycomb, it is a bit tricky to use it effectively.
Canvas does make life easier though. It's easy to use and simple to understand even for someone new to Computer Graphics.
In the end it will depend on what you need to do. If you need the fancy stuff like Geometry, Lighting etc then you should definitely go for OpenGL. Besides, If you need 3D then OpenGL is your only option since Canvas only supports 2D graphics.
Bare bones OpenGL is very tedious to use in my opinion so I would suggest a framework such as the ones mentioned here.
Hope this helps.
I am a fairly "newb" Android developer, and I would like one of my first projects to be a live wallpaper, however I am conflicted on whether I should be focusing on Canvas or OpenGL for it. Being new to this I know I should master Canvas first since it is easier to use, but I prefer to learn from real world projects that I have an interest in, even if it's a little backwards at times.
I have used both before in very basic ways, and I understand the general concepts to them, but I am not sure how they transfer over to the realm of live wallpapers. I figure that the full blown speed of OpenGL isn't required on a live wallpaper, since running it at max FPS would just run down the battery more than it necessary, but at the same time I am worried that using Canvas would cause lags and stutters when doing things like changing home screens.
I have been leaning towards using OpenGL ES 2.0, both to keep performance optimal and because my initial ideas for the wallpaper involve a lot of layering that I am not sure Canvas is capable of, but I'd like a more experienced developers opinion on whether or not all of the extra work involved in using OpenGL (especially in relation to live wallpapers, from what I've read) is worth it.
If you can get away with just drawing to a canvas (e.g. cube example in SDK), that's much less work. Because of the simplicity of the animation (no bitmaps), the cube is able to achieve a high frame rate without difficulty.
If you want to use OpenGL, you will need to use a supplemental package, such as GLWallpaperService, AndEngine, or RenderScript.
http://www.rbgrn.net/content/354-glsurfaceview-adapted-3d-live-wallpapers
http://www.andengine.org/forums/tutorials/live-wallpaper-template-t258.html
Browse the Android source code to see how the stock wallpapers (e.g. Grass, Galaxy) are implemented using RenderScript. This link may work, but no guarantees: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.1.1_r1/com/android/wallpaper/ (then scroll down to the wallpapers)
Moonblink has discontinued his project, but if you're really keen, you can try researching his work (Substrate) starting here: http://code.google.com/p/moonblink/source/browse/wiki/Setup.wiki
I ended up using OpenGL as halfway through the project, canvas drawing proved to be too slow for what I was trying to achieve. Using OpenGL caused a massive performance boost. Unfortunately I had to refactor my code, so I would reccomend using OpenGL from the start. Dirty rendering is supported by OpenGL as well as the wallpaperservice's structure doesn't rely on the way you render things so you would still be able to create a wallpaper that doesn't drain the battery. Actually a well programmed wallpaper doesn't render when it's hidden. As the wallpapers shipped with android don't follow that pattern, live wallpapers now have the bad name of being battery suckers. Really a shame..
Is there a way to decide up front based on the expected complexity of a game/app in the planning phase whether to use regular Canvas drawing in a SurfaceView or to go with OpenGL?
I've been playing around with a Canvas and only need 2D movement, and on a fairly new phone I'm getting pretty decent performance with a bunch of primitive objects and a few bitmaps running around the screen on a solid background.
Is it fair to say that if I'm going to be drawing background images and increasing the number of objects being moved and drawn on top of them that I should go straight to OpenGL?
All I can say is that it depends on how many sprites you're gonna use. Chris Pruett from Google has also documented this part very well.
Google I/O 2009 and Google I/O 2010.
Below is a picture from one of his slides that are related to your topic:
With that knowledge, you should go with OpenGL using the draw_texture extension. Remember to query out the string and check if draw_texture is supported on the actual device.
For further information that are related to game development in general, see this.
SurfaceView
A GLSurfaceView is a SurfaceView that you can render into with OpenGL.
Choosing between them is simple:
If you're familiar with OpenGL and need what it provides, use a
GLSurfaceView. Otherwise, use a SurfaceView. OpenGL is low-level. If
you're not already familiar with it, it's an undertaking to learn. If
you only need 2D drawing, SurfaceView uses the high-level, reasonably
high-performance Canvas. It's very easy to work with.
Unless you have a strong reason to use a GLSurfaceView, you should use
a regular SurfaceView. I would suggest that if you don't already know
that you need GL, then you probably don't.
OpenGL
OpenGL would be able to handle the rotations and scaling easily.
Honestly, you would probably need to learn a lot of OpenGL to do this,
specifically related to the topics of:
Geometry Lighting (or just disabling it) Picking (selecting geometry
to draw on it) Pixel Maps Texture Mapping Mipmapping Also, learning
OpenGL for this might be overkill, and you would have to be pretty
good at it to make it efficient.
Instead, I would recommend using the graphic components of a game
library built on top of openGL, such as:
Cocos2d
libgdx
Any of the engines listed here
Source
Difference between SurfaceView and GLSurfaceView in Android
Android: Canvas vs OpenGL