I'm trying to make an android game with opengl
I managed to set up the glOrthof view alongside the regular 3D perspective. However I'm having trouble coming up with a way to draw to the gui. I'm thinking of having one Bitmap that will be the screen, and then draw whatever I want to it with a Canvas.
I can turn the screen bitmap into a texture and map it onto a mesh which I can then render normally with the orthographic perspective.
Only problem is that I would most likely need the screen to be updated every frame, and to do that I would have to create a brand new texture whenever I want to update it. And I would imagine that to be horrendously slow.
So, how could I make a gui for my game? I have the orthographic perspective set up already alongside with my 3d perspective. The method I described above doesn't seem like it would work. Can you give me some suggestions or explain to me how I would go about doing it?
Use glDepthFunc(GL_ALWAYS) before you start to paint the UI. This will make all drawcalls to be issued in front of the other drawcalls.
Related
I'm actually implementing a View, which has to draw a floor-plan of a building. I just want to show one floor at the same time but I already got performance issues.
Every floor has x-polygons, which consist out of y-points/edges. I want to draw every point and every edge on my map. In some cases, there are up to 600 points so the drawing takes a lot of time in Canvas.
Is it better to switch to OpenGL? (I don't need any texture, just polygons).
I would say go for OpenGL ES 2.0 if you can't use 2.0 then go for 1.0.
Canvas
Less Code (and more basic and simple programming)
Though Worse Performance
OpenGL ES
More Code
Usually better performance (The more polygons there are, the easier it will be to see that OpenGL ES gives a better performance)
So if we're talking about a small amount of polygons, then Canvas could be able to handle it while still giving a good FPS.
Though be aware that using OpenGL, will require some more "thinking" if you can say it like that. Basically, you need to think about which vertices you want to pack together into VBOs, then less draw calls you have the even better FPS you will get. You also need to know some Matrix and Vector math, probably don't 100% need to, but a lot of thing will get a lot more easier if you do know it.
In Android. If im drawing objects off screen, it would be a big performance boost to disable these objects assuming they arent already disabled from being drawn when off screen.
I assume your question is how to cool the invisible objects. It depends on whether you're using 2d or 3d scene. In 2d it's very simple: everything outside the screen rectangle is culled. While in 3d it is very complex problem and there are tons of different techniques like bsp trees or portal rendering. The key word to google is "object culling".
In my application I need to draw a large network (basically, little boxes connected with lines) and the user will be able to zoom and pan it around.
My first option was to draw the network directly to the canvas, but I thought that was not very efficient, because each time a pan event occurs, the drawing process begins again.
So I tried to use a large mutable bitmap and draw my entire network only once (or at least whenever zoom occurs), and blit the necessary areas to the canvas.
My problem is, since the network is rather big, I get OOM exception when creating the bitmap…
What should I do? Draw directly to the canvas? Use several smaller bitmaps?
Thanks,
Direz
My first question to you is how many sprites you have going at once? By far, the fastest mechanism for having many sprites on the screen is to use OpenGL due to the hardware accelleration. The besy way, on Android, I have found to do this is to use the Cocos2d android (not to be confused with the ios version) which is available on Google Projects. You will have to use the IOS documentation in order to understand it though and there are a few decent tutorials to get started with online..in particular, the hello world template here... Www.sketchydroide.com/Blog/p?=8. It is out of date compared to the latest IOS cocos2d but thats to be expected. I have found that the programs run MUCH faster when not connected to an active debugger session in my experiments.
If you want to stick with your current approach or the above is still not fast enough, you are going to have to attempt to cull any drawing which does not appear n the screen meaning a general function of the form "if the sprite's x and y values are outside the bounds of the visible area, dont draw it" which is basically how most tile base games handle the issue.
It sounds like you are doing the drawing manually if you are doing little squares. I think it is more adviseable to go ahead and draw on the canvas but to be very careful about managing your sprite counts and to avoid heavy for loop iteratiins that occur on
the frame update loops where possible. It is rather easy to max out your little handset with drawing operations.
Another option might be to draw the entire bitmap once into memory and then use a copy rectangle operation to transfer the image to the screen without drawing the full bitmap you have created. I think that copy rect should be a fast operation normally but if you are using it to draw the whole screen it seems like overkill and probably wont work as well.
You're probably not going to like this, but if all you're doing is drawing boxes and lines, the efficiency of the canvas is going to be pretty dang high. Are you getting UI lag or something?
One thing I have messed around with is drawing collections of subcomponents that won't change much or at all to a bitmap then rendering (scaling/moving aren't all that expensive if done at the right level) to the canvas can help efficiency. I have tried in the past to create a framework for rendering a tile-like subset of an existing larger image, but did not meet much success. I've made things work, but the code just gets ugly.
Oh, also a quick test to see if the component you are rendering is within the rectangle created by the screen can save you a bunch of processor time.
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
I am building aprogram that needs to do drag/drop operations of images. Now on a Canvas it is quite easy, and I might chose this. However, I am also interested in using GLSurface View?? Now what I am seeing in examples is either a drag/drop tutorial on Canvas or drawing on GLSurface view. I am wondering if handling touch events is more complicated with GLSurface view? Is it possible to handle touch events with GLSurfaceView. Also why would one chose GLSurface view for rendering images vs. a Canvas? How does one chose between Canvas vs. GLSurfaceView?
It's really just a choice between two APIs.
Canvas:
knows about common Android framework classes like Bitmap
many convenient functions
can draw into bitmaps for saving to the SDCard
GLSurfaceView:
good for using the tried-and-true OpenGL API
designed for redrawing rapidly at a certain framerate
3D drawing
These are just a few aspects of the debate. I don't think either of them has the upper hand on event processing. I'd say that it makes more sense to use Canvas if you are working primarily with the Android SDK, whereas GLSurfaceView is an especially good option for apps using the OpenGL APIs via the NDK.