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..
Related
I was using OpengGL (Gles2WatchFaceService.engine) for my Wear-OS watch-face projects and it was working great for years. Recently however, this engine got deprecated and therefore, before I recode all my graphics, I am reevaluating if OpenGL is needed at all.
My question to any experienced (watch face) developers here is: When should I use OpenGL for the graphics of a watch face? Only for 3D animation? What about an analog watch face with hands that should move smoothly (with the animation frame rate switching between 5 and 40 fps)? (I am also using some color blending with alpha channel, not sure if I can do that without OpenGL.)
It comes basically down to these considerations:
OpenGL for pure 2D animation could result in smoother animation at a lower CPU load. But, is this always true? Or can I get easily 40 fps for animating up to 9 graphical elements without OpenGL?
Am I getting the advantages of OpenGL (if there are any) at a cost of a more complicated code and more compatibility problems in the future (due to SW and HW updates)?
If OpenGL is the way to go, perhaps someone can point me to a good and recent code example (preferably java), because I can't find any.
Any help/comments appreciated!
I created Android live wallpaper using canvas but it seems to be quite slow in performance. I was thinking of shifting towards OpenGLES 2.0 but it is very difficult to code from scratch because there are a lot of animations. I want a sincere opinion which one is the best for making live wallpapers Unity or OpenGLES 2.0, also give a basic idea whether unity slows down the wallpaper or not.
Thanks in advance.
I'd suggest using Unity.
Unity engine is pretty good for highly-visual stuff, with its visual editor, good asset import pipeline and tons of stuff on Asset Store that would help to boost your development. It'd be very hard to beat it performance-wise. There are other game engines that you could use for live wallpapers, but it'd be a much more tedious task.
The negative side of using Unity is that it might be somewhat heavy - it's expected to have an minimal APK of around 9 MB in size This doesn't really matters if you have a resource-heavy live wallpaper, though.
What makes it possible, is that recently I've released uLiveWallpaper - a Unity asset that makes it possible to create live wallpapers for Android using Unity 5. It is well-tested and reliable, creates projects for Android Studio, complete with placeholder code to get you started.
Check it out:
http://forum.unity3d.com/threads/ulivewallpaper-develop-android-live-wallpapers-with-unity-5.375255/
I don't think you can create a live wallpaper using Unity. At least not easily, Unity is not intended for this. Usually a live wallpaper consists of a service, a Settings activity, and some sort of resource which defines your live wallpaper. Everything you create in Unity will be compiled packaged magically transformed into an activity with a launcher. This means your Unity "game" will not be in the wallpapers list, but in the apps list. Also, by default it will run in the front, not in the back of a home screen like a live wallpaper would do.
To make it work as a wallpaper would require a lot of altering to what Unity outputs when building, because Unity does not offer any live wallpaper settings. That seems like a lot of work. Also, it seems a bit overkill to use a game engine or OpenGL for a live wallpaper.
Keep in mind that you should not try to create a >30 fps live wallpaper, because that would drain an Android device's battery pretty fast. If I were you I would try to make the wallpaper look good with <30 fps. Try not to have fast animations, pre-render 3D stuff and optimize what you already have.
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.
I am planning to make an android game. The game doesn't include a lot of movement. It will be like custom maps that user can switch between, maybe zoom in and out, select parts of the land, draw some objects on the map. User should also have a dashboard to manage his game . It will NOT include objects moving like cars/people.
I am new to both Canvas and OpenGL-ES developing but i feel that OpenGL-ES includes a lot more that what i need.. but just little skeptic if Canvas would be good enough to fulfill my requirements.
So, what would you advise me to do?
Thanks in advance.
Adel
I would say it's a difficult one to answer as it's virtually impossible for anyone but yourself (as the game designer) to know which one your particular game would require.
However, I would say, personally, I would go with openGL ES 2.0. I spent months designing a game (and even longer writing it) only to find that canvas wasn't powerful enough. Granted it did have 'moving objects' but not a huge amount of them - and it ended up with a lot of jerky movement that I just couldn't eliminate, so I am in the process of re-coding it with openGL ES 2.0.
I would say, look at some examples of games written with Canvas / Surfaceview and judge to the best of your ability which one you think you should go with.
Bear in mind while making this decision, that if you think Canvas / Surfaceview would be good enough, then go for it, however even if it is, are you going to be creating more demanding games later down the line? If so, then like I said above, I would just jump straight into openGL ES 2.0.
Canvas = simpler coding, worse performance
Open GL ES 2.0 = more demanding coding, but potential for much better performance.
Just my opinion!
I want to create a simulation game and a main component of this simulation will be a 2D map (topographical/navigation map), which shall have different layers (objects are moving on the map, using of labels, you get it)
The question for me is now, shall I use OpenGL to accomplish this or is that not necessary? I have no special requirements apart of that the scrolling and zooming shall be smooth. The target platform are only Android tablets (so Android OS 3.0+).
Edit: To precise my question:
platform independence is not important for me
I'd like to go with the easiest way concerning implementation efforts
If and only if you're really targeting Honeycomb specifically, then don't bother with OpenGL... and I say that as a reasonably experienced OpenGL programmer who's done some cool things with it on Android.
My reasoning is that, starting with Honeycomb, the normal Canvas-based APIs are hardware-accelerated too. Typically the only real reason for using OpenGL was greatly increaased performance, but that is no longer the case.
Or so the theory goes... I've yet to see actual Honeycomb hardware and run comparative tests. What I do know is that the Honeycomb emulator shows triangular tearing everywhere, strongly suggesting the whole desktop is now going through the GL pipeline.
If you have solid experience with OpenGL go with it. If not try some performance tests before you really decide if you invest time to learn it or if you use the good old simple 2D canvas drawing...
I'm not an expert on OpenGL + android (or any other mobile devices), but I think you will get better results (more FPSs, better drawing and animation options, etc) using OpenGL.
If you're used to non-OpenGL android development and are new to OpenGL it would be easier develop the game without using OpenGL. But before you choose this option, be aware that it should be a better option to use OpenGL if you aim to achieve beautiful/good performance graphics!
In short, if you master "regular" android development and prefer to build something good enough in a short time, stay "regular". Otherwise, I advice you to go for OpenGL.