How can I do antialiasing on triangles on the entire render? Should I put it on the fragmentShader? Is there any other good solution to improve this sort of thing?
Here is my "view", with very crispy edges (not very nice).
After doing some Deep research, I found that It's in fact pretty simple, and the most comonly done is to render like there was a screen 4 times bigger (or even more than 4 times). After rendering to this much more bigger screen, the GPU will take the avarege of that area and set the pixel color based on that.
It's pretty easy to enable this with this library:
https://code.google.com/p/gdc2011-android-opengl/source/browse/trunk/src/com/example/gdc11/MultisampleConfigChooser.java
However,you should keep in mind, that it will spent 4 or more times time to render everything, meaning more time to process, and perhaps, less FPS...
Also, if you are emulating an android device with OpenGL, find out if your GPU supports this kind of Multisampling. Mine for example, doesen't (Tegra).
Here is the final result, with and without multisampling:
Related
I developed already a few apps with Android Studio and i learned the last 3 years java so i would not like to change the language. Now i want to Programm a game but i am not quit sure. I read about the surfaceview and performance problems, and now i want to ask:
Does the surface view has enough power to render a 2d 16 bit RPG in a canvas?
I tried to make a demo and i had a few perfomance problems but I think the reason for this was that i resized the graphics every time befor i drawed it.
Thank you for your Help,
Julius
I would bet it does.
I made a 2d scroller shooter with light effects and shadows and it works smoothly on an pretty old samsung phone.
I used libgdx as a base library.
Also about the resizing graphics in every frame. This is very bad practice. You should decode and resize all graphics (where possible) in an initialization method before starting the playing mode. Then you can reuse resized bitmaps in each frame which will be much faster.
Little prologue: I'm creating a some kind of drawing application for Android (API 14 and higher). Few months ago I've started working on it and decided to use SurfaceView as a canvas to draw on. I thought that this a good decision cause SurfaceView works directly with Graphics. And everything seemed to work fine until one day I've noticed that the drawing process is a little bit laggy. There're probably a lot of weird code down there.
Anyway, now I'm optimizing that code and stuff, and I thought, do I really need to use SurfaceView for such scenario? The main things I need from my "canvas" is to draw smooth and be able to save all the drawings to Bitmap->File on External storage (this works fine).
So, should I use the simple View or the SurfaceView? Also, it would be great to hear props and cons of your decision/proposition.
Thanks
If you want to use Canvas, you are increasingly better off with a custom View, rather than a SurfaceView. The simple reason is that Canvas rendering on a View can be hardware accelerated, while Canvas rendering on a SurfaceView's surface is always done in software (still true as of Android 5.0).
By drawing "smooth" I assume you want some anti-aliasing effects. Check the chart on the hardware acceleration page to confirm that the effects you want are supported for the Android releases you want to ship on.
As device display pixel counts get steadily higher, software rendering gets increasingly expensive, and on some devices the CPU or bus isn't fast enough to keep frame rates high. Fortunately on these the pixel density is so high that you don't really need anti-aliasing, so even if it's not supported you could ignore it until you generate your software-rendered bitmap.
Before you do anything, though, it would be wise to figure out what your source of sluggishness is. It's possible you're being slowed down by inefficiencies in your drawing code rather than pixel fill rate. Check it with some of the profiling tools.
(See also the graphics architecture doc.)
I am trying to write a libgdx livewallpaper (OpenGL ES 2.0) which will display a unique background image (non splittable into sprites).
I want to target tablets, so I need to somehow be able to display at least 1280x800 background image on top of which a lot more action will also happen, so I need it to render as fast as possible.
Now I have only basic knowledge both about libgdx and about opengl es, so I do not know what is the best way to approach this.
By googling I found some options:
split texture into smaller textures. It seems like GL_MAX_TEXTURE_SIZE on most devices is at least 1024x1024, but I do not want to hit max, so maybe I can use 512x512, but wouldn't that mean drawing a lot of tiles, rebinding many textures on every frame => low performance?
libgdx has GraphicsTileMaps which seems to be the tool to automate drawing tiles. But it also has support for many features (mapping info to tiles) that I do not need, maybe it would be better to use splitting by hand?
Again, the main point here is performance for me - because drawing background is expected to be the most basic thing, more animation will be on top of it!
And with tablet screen growing in size I expect soon I'll need to be able to comfortably render even bigger image sizes :)
Any advice is greatly appreciated! :)
Many tablets (and some celphones) support 2048 textures. Drawing it in one piece will be the fastest option. If you still need to be 100% sure, you can divide your background into 2 pieces whenever GL_MAX_TEXTURE happens to be smaller (640x400).
'Future' tables will surely support bigger textures, so don't worry so much about it.
For the actual drawing just create a libgdx mesh which uses VBOs whenever possible! ;)
Two things you dindn't mention will be very important to the performance. The texture filter (GL_NEAREST is the ugliest if you don't do a pixel perfect mapping, but the fastest), and the texture format (RGBA_8888 would be the best and slowest, you can downgrade it until it suits your needs - At least you can remove alpha, can't you?).
You can also research on compressed formats which will reduce the fillrate considerably!
I suggest you start coding something, and then tune the performance up. This particular problem you have is not that hard to optimize later.
I am looking at making a simple game. Without giving out the entire story, I need to draw two pieces of fruit (with arms and legs), who do different movements. They can do a few different actions (less than 5) and they also react to each others actions.
I'd like it to look simple. Very 2D, kids sort of graphics. Maybe shaded, but nice bright happy colours.
Let's say an action is to 'throw ball'. I'd like to see a semi smooth arm action. Smooth if possible.
So, I found a tutorial, which used sprites, and a PNG with 3 different states of a person walking. So, very basic. And I was able to make it walk across the screen, leading each part of the PNG for each state, and iterating through that over and over again, while moving the image.
I got pretty happy with my progress, and would like to base my game on that sort of model - but ... is using sprites, and loading areas of the PNG to make the image move correct? My PNG would be large if I want maybe 20 images just to throw the ball.
But if that's the right way to go, then great! It seems you can go with OpenGL and all that, but that's for 3D graphics right? Using sprites, and a few PNG with images would be OK for perforamnce and all that?
OpenGL is a valid choice for 2D or 3D, you shouldn't have any performance issues.
It will work fine for your game, and would likely be much smoother than trying to use android animations, which are not hardware accelerated on Android 2.x.
My game already consists of an atlas the size of 1024x1024 as I am aware that is the max size for a texture. The problem is I need about 1-2 more of these 1024x1024 textures. That should give me 3 glBindTexture() calls which I know is huge performance drag. I have not tested it yet because I am having other problems currently but would this slow my application by a considerable amount? Is there another solution?
If you are worried about any performance loss, I'd recommend you to profile your application so you really can see where your application's bottleneck is, and then come back if it turns out to be horrible.
Three big atlas textures are still better than many small textures that you bind over and over again.
Currently my game has around 6 512x512 texture atlases and I still dont require any loading screens on any phone so far. Although if you are going to do a lot of binding you may want to look into making a Batcher class that will submit all of your vertices to the GPU at one, it will speed up your application considerably