I'm trying to draw several particles as we touch and moving. When user tilts the device, particles moves to the tilted side.
I made this steps by using each particles on each Image View. But it's too slow when making like 100 image views.
SoilView= [[UIImageView alloc] initWithFrame:CGRectMake(currentPoint.x + randomDist1, CurrentPoint.y + randomDist2, 30, 30)];
[SoilView setImage:SoilImage];
so I tried to change this to particle animation, but it was not working well. most particle animation sample was just blowing up or scatters everywhere. so I couldn't find a way to make my code.
Is there any ways to make each particles to work like each views?
How can I solve this problem? Could Someone please help me?
I would use OpenGL for particle animations. To get you started take a look at this particle Generator and the OpenGL ES Blog posts of the project's author http://iphonedevelopment.blogspot.com/2009/05/opengl-es-from-ground-up-table-of.html
Related
I've developed an airplane 3D shooter game. In this game, I want to make my plane shot a bomb. When the bomb gets to the enemies it will explode and give damage in the area of explosion.
I have already searched for a tutorial to make this code and the animation of explosion. But I couldn't find it. Please tell me about something that could solve this problem. I'm developing my game using C#.
For the explosion animation, you could use a particle system. There are many pre-made ones in the Asset Store, such as this one: https://www.assetstore.unity3d.com/en/#!/content/42285
For detecting what is affected in the explosion's area of effect, do a SphereCast (https://docs.unity3d.com/ScriptReference/Physics.SphereCast.html) from the point of impact and then do whatever you want with any of the objects touched by the sphere.
I am going to create simple iPad game, in which arrow going to hit balls. Where balls are moving in random direction with random speed. When arrow hits ball there is blast like animation with sound (Collision detection is main thing here). So for this what should i prefer. Should I use simple UIImageView and animation or use COCOS2D. Also I am new to COCOS 2d. Any other options are also appreciated. Thank You.
Use cocos2d Animation .Refer below link
if u have spritesheets try this:
1) http://www.raywenderlich.com/1271/how-to-use-animations-and-sprite-sheets-in-cocos2d
or u have separate images refer this:
2) http://cocos2d-iphone.org/wiki/doku.php/prog_guide:animation
Using cocos2d has a lot od advantages over UIKit. One of the things is box2d which will be very helpful for game like this [at least I got this impression for your question].
Do some research about box2d collision detection.
I have worked with cocos2d before, that was simple game with moving objects (CCSprite), but now I want to make a bubbleshooter game ,
Can anyone briefly give me idea how it will work, the flow of game and what should I use, like as I think there will be on layer, and CCSprite over it, but still not clear idea in mind
I would be thankful if someone will describe the whole flow, and classes, more briefly I will specify some major points
What are bubbles used in game? (Image with CCSprites or something else)
How would I know the direction of shooting.
How would I know the collision is occured, and other balloons of same color connect to hitting balloon will also be vanished.
I would be thankful if someone provide the related task tutorials or source codes, so that I would get better idea about it.
Bubbles are sprite Images.
Read this link http://www.raywenderlich.com/692/rotating-turrets it gives how to find the direction of Touch position.
collision detection as usual.In scheduler method find if the Moving ball is collide with other ball.
-(void)checkCollision
{
for(CCSprite *ball In ballArray)
{
if(CGRectIntersectRect([ball boundingBox],[movingBall boundingBox]))
{
CCLOG(#"collision Occurs");
}
}
}
I'm making an iPhone game in cocos2d.
I was wondering how I would make the camera / the view follow a specific sprite?
would I use the CCCamera class?
Yes, CCCamera would work. However, it has some drawbacks that make it undesirable for some uses. Moving the layers respectively all other objects relative to that sprite may be a better solution. It depends on the game.
First, read up what the different approaches and their drawbacks are, you can get a lot out of this cocos2d forum thread:
http://www.cocos2d-iphone.org/forum/topic/5363
It would be helpful if you could describe what your game is about and why you need the camera attached to that sprite.
For example, if you're thinking of a running game like Canabalt, i would not use the camera to scroll over the world, but instead scroll everything relative to the player (towards him) with the player sticking at about the same x coordinate while running. Perfect examples of games where you would not move the camera at all are the iCopter games, they are basically simplified versions of Canabalt. Notice that the player sprite always stays at the exact same x coordinate, and the game world just scrolls
Scrolling the camera itself in my opinion makes the most sense if you have a large game world that the player can traverse in all directions, and the number of objects are simply too numerous and also moving about in various directions, so updating their positions individually each frame would be both overkill and prone to errors. And since the game world is so huge, you would want to use the camera's position to limit what is drawn on screen.
use CCFollow actions
Like these :-
[self runAction:[CCFollow actionWithTarget:(u r hero) worldBoundary:CGRectMake(0,0,1050,350)]];
it will helps
I have 12 views which I rotate almost similar to the icons in the home screen when going into homescreen-customization-mode by touching an icon for a few seconds.
I use a 3D transformation code to do the rotations. They have each a duration of just 0.02 seconds, and the angle and direction of rotation changes permanently upon acceleration measurements.
5 of those views are fine, but 12 have a very bad performance. Here's the rotation code:
CATransform3D rotatedTransform = CATransform3DRotate(CATransform3DIdentity, degrees * M_PI / 180.0, 0.0f, 0.0f, 1.0f);
self.layer.transform = rotatedTransform;
there's some core animation wrapped around it. But I see a waste of CPU here, since I don't do any 3D stuff. I really only rotate 2D and nothing else. They're simple UIImageViews, but a custom class that does this rotation animations on her own.
I've heared that there are "affine" transforms which are supposed to work for the 2D space. Would you advise to change that to 2D in this case?
Must I prefer to change the transform of the layer, or of the view? which is faster?
Shark it. You must know what exactly is slow to continue.
Try increasing that update interval from 0.02s to something like 0.1s; is that acceptable?
If all of the images are being rotated together, use a sublayerTransform on the super-layer instead of transforming each individually
Try it w/o animations off, just to confirm that your callbacks are working as you expect (setDisableActions: on CATransaction). Do you see the same things as being slow in Shark when you have them off?
If you're doing this inside a scroll view, you might have other problems. You'll need to take care of things going on/off screen, etc.
3d transforms are the same speed as affine ones in core animation AFAIK. basic sin/cos stuff isn't slowing down the app
More information about the actual effect you're trying to achieve would really help to improve performance.
How big on screen are the images?
CALayer rotations are hardware accelerated, 2D and 3D transforms would be pretty similar, no redraws are happening, no need to go to opengl, no need to cache.
Shark would help, but you would need to know what you are looking for, and what you're looking for is not improving the performance of your current code, but removing your code completely.
Sounds like you are going through your own code waaay too often, for the purpose of changing the angle of each layer. You win when you let CA do the work.
So the strategy here is to find a way to have CA do the work, and call you back less than 50 times a second.
How about a CAAnimationGroup containing a few CAPropertyAnimation for each of your layers and setting up, say, one second of animation at a time?
Once you hand that off to CA, CA will playing it back in its own thread.
My advice is to go OpenGL ES.
Although Core Animation is a tad snappier than "UITransformations", the problem you're facing is a classic one: you're trying to create frame to frame based action with lots of "virtual" sprites floating around. That is not what UIKit is meant to be used for. Especially the animations you're trying to do. Rotation requires trigonometry in order to calculate pixel interpolation. That's quite an expensive procedure.
Unless there are clear restrictions to the intensitivity of the animation, the number of objects animation at the same time, and the frequency of recalculating new transformations, my only advice for you at this point is OpenGL ES.
My experience thus far with the iPhone has been quite alike. Every time we juiced up the app, the current platform could not handle it. We ended up using OpenGL ES, and it's worth the learning curve. The performance is incredible.
I'm sorry for the "bad news", but I strongly advise against using UIKit and Core Animation for frame to frame based apps.
It sounds like your redrawing your views constantly. I'm sure there is a way to disable this and only redraw at the end of the animation.