How to use particle effects in view based application?
I have created a game using view based application and I want to use a particle effects in my game. But, I don't have any idea about using a particle in view based application.
Please give some/any idea.
In generally... you can't. Use fullscreen GL for regular particle effect.
Particle effect requires massive count of sprite drawing and alpha blending. You can do this with GL, however, a GL view cannot be overlay over other UIViews.
Normal UIView is implemented with backing CALayer. This is a kind of GL drawing, but optimized for smooth animation of low density UI, not for massive drawing count. So it's performance is too low and unacceptable for particle effect.
I tested CALayer based particle, and 128 particles were max fps with meaningful fps in 3GS.
Related
How can we make an effect of "end scene" using UI Masks scaling or an Shader in Unity?
Thus:
Also as at the end of cartoon where the center circle decreases until the screen goes completely dark. (Scale)
Thanks a lot guys
You won't be able to do this with UI mask. UI mask only masks UI elements.
You can do a couple of tutorials on shaders to learn how to write this shader. But easier would be to have a second camera rendering on top of the first doing this blackout. The blackout can be a spritesheet animation.
I'm developing a game with large obstacle and sprites(in cocos2d+box2d for iPhone), then after zooming out my sprites and layer (by increasing cameraZ), I make my game to play by user, which causes some problem in touch detection of dynamic objects.
Can it be said a good approach to work with? If No then what will be the solution to work properly(consider that I have traveled so far with this approach)?
NOTE:[self.camera setEyeX:0 eyeY:0 eyeZ:180]; (i'm using this line for zooming out, putting camera far from my sprites by increasing z)
If you use a camera for zooming then cocos2d will no longer correctly convert your touch locations to opengl coordinates, since it doesn't invert the camera transform. I would recommend using scale on the layer that your objects reside on to implement zooming. This gives you precise control over the zoom factor and touches will be correctly transformed when you use methods to convert touches from screen space to node space.
What's the best method for pulling back to show more of a view in a 2D OpenGL iPhone game? For instance, in Tiny Wings, when the bird flies toward the top of the screen the bird and the scenery pull back to simulate the bird going higher in the sky. Would this effect be better achieved by scaling all the sprites proportionally, or by using glOrthof? In any case, I'm assuming that the zoom-out factor is inversely proportional to the player's y position.
You almost certainly want to use glOrthof so all you're changing is how the camera sees the scene. This avoids recomputing all the normals and such in the scene, saving quite a bit of work. It's also easier for you to implement.
I have the scene stored in array as collection of shapes that is represented by sequence of points. I'm drawing this scene with CGContextMoveToPoint, CGContextAddLineToPoint, CGContextSetFillColorWithColor and CGContextFillPath functions. The problem is that i need to redraw scene on timer event with short interval (0.01 sec) and the scene redrawing is very slow. Is there a way to accelerate this stuff? Or only OpenGLES can help me?
Quartz 2D (Core Graphics) graphics are not accelerated on the iPhone. Path fills are likely CPU bound as well. If you want hardware acceleration, you'll have to convert your scene to OpenGL ES (triangle strips and textures). Even using OpenGL ES, you will have to optimize your graphics fairly well to get a 60 Hz frame rate (0.017 sec).
One other possibility is to pre-render your shapes into CALayers, and just animate the layers (scale, rotate, overlay, hide, etc.) CALayer animation is also hardware assisted.
I've seen a lot of bandying about what's better, Quartz or OpenGL ES for 2D gaming. Neverminding libraries like Cocos2D, I'm curious if anyone can point to resources that teach using OpenGL ES as a 2D platform. I mean, are we really stating that learning 3D programming is worth a slight speed increase...or can it be learned from a 2D perspective?
GL is likely to give you better performance, with less CPU usage, battery drain, and so on. 2D drawing with GL is just like 3D drawing with GL, you just don't change the Z coordinate.
That being said, it's easier to write 2D drawing code with Quartz, so you have to decide the trade-off.
Cribbed from a similar answer I provided here:
You probably mean Core Animation when you say Quartz. Quartz handles static 2-D drawing within views or layers. On the iPhone, all Quartz drawing for display is done to a Core Animation layer, either directly or through a layer-backed view. Each time this drawing is performed, the layer is sent to the GPU to be cached. This re-caching is an expensive operation, so attempting to animate something by redrawing it each frame using Quartz results in terrible performance.
However, if you can split your graphics into sprites whose content doesn't change frequently, you can achieve very good performance using Core Animation. Each one of those sprites would be hosted in a Core Animation CALayer or UIKit UIView, and then animated about the screen. Because the layers are cached on the GPU, basically as textures, they can be moved around very smoothly. I've been able to move 50 translucent layers simultaneously at 60 FPS (100 at 30 FPS) on the original iPhone (not 3G S).
You can even do some rudimentary 3-D layout and animation using Core Animation, as I show in this sample application. However, you are limited to working with flat, rectangular structures (the layers).
If you need to do true 3-D work, or want to squeeze the last bit of performance out of the device, you'll want to look at OpenGL ES. However, OpenGL ES is nowhere near as easy to work with as Core Animation, so my recommendation has been to try Core Animation first and switch to OpenGL ES only if you can't do what you want. I've used both in my applications, and I greatly prefer working with Core Animation.