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!
Related
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 want to implement a news ticker in my application, with vertical and horizontal scrolling, as well as some alpha animations.
I need the animation to be unaffected by the rest of the application (GPU/hardware accelerated). Especially since the application will be run on a Google TV box, and the user is expected to be using D-Pad navigation which can cause animation to become choppy.
These appear to be my options (I need to support Honeycomb and above):
Use the Android Animation classes
Will the performance of this approach ever match using OpenGL?
Is hardware acceleration possible, and reliable?
Easiest to work with.
OpenGL ES 2
There appears to be a limit to the texture size of 2048. If I have a headline longer than that
RenderScript
The documentation is sparse here.
In your opinion, what is the best solution? What other solutions are there?
One pattern that's common is to enable hardware acceleration, animate, then disable it. However, on the Intel based GoogleTV boxes there is a problem with text when you turn on Hardware Acceleration. I haven't tried it on an ARM based Google TV yet.
I am by no means an OpenGL ES expert, but I am a huge fan and have seen some wonderful things done using it for Google TV. That said, I think your understanding of OpenGL ES Textures is incorrect. The size of the texture should have little bearing on the length of a headline. I currently have an intern working on a bunch of OpenGL ES examples that we hope to publish by the end of August.
There is excellent sample code for working with RenderScript, even if the documentation is sparse. However some developers haven't been able to integrate RenderScript w/ d-pad navigation.
My suggestion is to try your worst case senario using OpenGL ES as a very short program and see how it works. It's likely to be the best solution.
I can imagine why your seeing choppiness on some GoogleTV animations, StateLists firing when D-Pading, but it's not an insolvable issue.
I'm porting a 2D action game from Windows Phone 7 (developed in XNA 4.0) over to Android. I'm using a lot of Canvas.drawBitmap() calls - around 200-300 per frame update - with different Paints for each call to handle varying transparency and colourisation at draw-time. This is managing particle systems and various other overlays and in-game effects as well as a tiled background and in-game sprites. I'm not doing any on-demand resizing or rotating, it's simple src->dest rectangles of the same size.
On WP7 this runs at 30+fps but I'm struggling to get 12fps on my test 'droid hardware (Samsung Galaxy S). This is making the game unplayable. Having profiled the code, I've confirmed that all my time is being lost in Canvas.drawBitmap()
I seem to be following all the usual performance advice - using a SurfaceView, mindful of GC so not creating loads of throwaway objects, and avoiding Drawables.
Am I right in understanding that Canvas.drawBitmap() is CPU-bound, and if I want to improve performance I have to switch to OpenGL which will use the GPU? I can't find it stated that baldly anywhere, but reading between the lines of some comments I think that might have to be my next step...?
This is normal. Canvas is amazingly slow when using transparency (like ARGB_8888).
2 options:
Switch to OpenGL ES
Use the least possible transparency on your bitmaps (i.e use RGB_565 the most you can).
Perhaps this will run better on Android 3+ since it uses hardware acceleration for canvas operations.
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..
I'm currently playing around with 2D graphics in android and have been using a plain old SurfaceView to draw Drawables and Bitmaps to the screen. This has been working alright, but there's a little stutter in the sprite movement, and I'm wondering the feasibility to do a real time (but not terrible fast) game with this.
I know GLSurfaceView exists which uses OpenGL, but I'm curious as to the extent to which this makes a difference. Is a plain SurfaceView hardware accelerated, or do I need to use OpenGL? What type of speed difference could I expect from switching to OpenGL, and how much altering of code would it require to switch (the game logic is all in a separate object that provides an ordered array of drawables to the SurfaceView)?
As far as I can tell, you have to use openGL to get HW acceleration. But don't take is for granted and wait for other answers ^^
If it really is the case, the speedup should be quite important. Any 2D application should work at at very least 20 fps (generally less polygons than 3D applications)
it would take a substantial amount of code, but 1) as a first attempt, you could try with only 1 square VBO and change the matrix each time and 2) your rendering seems already quite encapsulated so it should simplify things a lot.
SurfaceView is not hardware accelerated in default.
if you want to get HW acceleration
use GLSurfaceView, which use opengl and is hardware accelerated.
Hardware acceleration is possible for a regular SurfaceView since 3.0.
http://developer.android.com/guide/topics/graphics/hardware-accel.html