I am animating some frames of a monster jumping and swinging a sword, and the frames are such that the width gets bigger or smaller as he swings the sword (the monster standing is 500 width, but his sword, fully extended to the left, adds another 200 width, thus he varies from 500 to 700 or more in width)
I originally took each frame, which is on a transparent background, and used the Photoshop magic wand tool to select just the monster. I then saved these frames like that, and when I used them to animate, the monster warped and changed sizes (it looked bad).
The original frames had a large 1000 x 1000 transparent background surrounding him, and as a result it always kept him "bound" so that it never warped.
My question is what is a good way to create frames of animation where the sprite inside might change size or width as he's moving so that there is no warping?
If I have to use a large border of transparent pixels, is that the recommended approach? I'm noticing that for my animation, each monster takes up about 3 - 5MB. I plan on potentially having a lot of these people ultimately, so i'm wondering if this is the best approach (using large 900 x 900 images all the time, plus I'll be using more for 2x and 1x). So all of this seems like it could spiral out of control to 4 or 5GB.
What are other people doing when making animations that require different poses and positions? Just fixing the frames with borders that are as small as possible?
Thanks!
You should probably change the approach to animation and use inverse kinematics instead. Take a look at this and Ray's tutorial.
Related
I am making a 2d platformer and I decided to use multiple tilemapnodes as my backgrounds. Even with 1 tile map, I get these vertical or horizontal lines that appear and disappear when I'm moving the player around the screen. See image below:
My tiles are 256x256 and I'm storing them in a tileset sks file. Not exactly sure why I'm getting this or how to get rid of this and it is quite annoying. Wondering if others experience this as well.
Considering to not use the tile maps, but I would prefer to use them if I can.
Thanks for any help with this!!!
I had the same issue and was able to solve it by "extruding" the tiled image a couple pixels. This provides a little cushion of pixels to use when the floating point issue occurs instead of displaying nothing (hence the gap). This video sums it up pretty well.
Unity: extruding tile map images
If you're using TexturePacker to generate your sprite atlas' there is an option to add this automatically without having to do it to your tile images yourself.
Hope that helps!
Sort of like the "extruding" suggested by #cheaze, I simply make the tile size in the drawing code a tiny amount larger than the required tile size. This means the assets themselves do not have to be changed.
Eg. if you assets are sized 256 x 256 and all of your calculations are based on that; draw the textures as 256.02 x 256.02 pixels in size:
[SKSpriteNode spriteNodeWithTexture:texture size:CGSizeMake(256.02, 256.02)];
Only adding .02 pixel per side will overlap your tiles automatically and remove the line glitches, depending on your camera speed and frame rate.
If the problem is really bad, you can even go so far as to add half a pixel (+0.5) or an entire pixel to remove the glitches, yet the user will not be able to see the difference. (Since a one pixel difference on a retina screen is hard to distinguish).
I have an object that is moving very fast (max velocity 900). When it reaches max speed it starts to create trailing objects or motion blur.
But I just want it to be the object moving fast. I am running on 60 fps.
I like the speed of the object but I don't like how its getting rendered (motion blur). How do I handle this?
This object bounces all around the screen with a restitution of 1.02, because I want to make it pick up speed as it keeps bouncing. I want to make it go faster thats why I did the 1.02 restitution.
The motion blur may simply be due to the LCD display having an "afterglow". So the position the object was in the previous frame is still a little brighter in the next frame because it takes some time for the crystals inside the LCD to return to the unlit state.
This causes "motion blur" on any moving object on the screen, and is of course more noticeable the faster the object moves. You may even be able to make out multiple versions of the same objects at different light levels trailing behind the object's position.
This effect may also depend somewhat on the device and model, and is often called 'ghosting'.
Regardless, there's nothing you can do about the "motion blur" caused by the LCD screen's afterglow effect. Here's a good article explaining the effects and their causes.
Hmm... you'll have trouble getting it to render smoothly.
At that speed (900 points per second) it will move 15 points every FRAME if running at 60 fps. That's a significant amount to move in such a short amount of time. In about 1/3 of a second it will travel entirely across the screen.
I'm guessing it will be getting to the limit of the ability of the hardware. Both the processor, the screen and your actual eyes. I imagine you'll also hit physics errors too with it possibly escaping through walls etc...
Can you show a video of how it is currently behaving?
In 2011's WWDC video session 121, to improve performance of the UI, the presenter chose to draw the rounded corners using UIBezierPath in drawRect:, rather than setting corner radius directly on a layer.
Why is drawing using UIBezierPath necessarily faster? drawRect: happens in software which can be slow too.
Short answer: probably just stick with CALayer’s cornerRadius until you see a performance problem.
Long answer:
We first need to distinguish between “drawing” and “compositing”.
Drawing on iOS is the simple act of filling a texture with pixels (a CPU limited task). Compositing is the act of flattening all of those textures into a single frame to print to the screen (a GPU limited task). Generally speaking, when scrolling or animating you’re mostly taxing the GPU, which is good cause things like shifting all pixels down by one is something the GPU eats for breakfast.
-drawRect: is pure drawing, and uses the CPU to fill a texture. CALayer’s cornerRadius is done at the compositing step, and stresses the GPU.
Using -drawRect: has a very high initial cost (it could easily take longer than one frame) and non-trivial memory usage, but scrolls very smoothly after that (it’s just a texture now like any other texture). Using CALayer’s corner radius is ridiculously fast to create a bunch of views with corner radius, but once you get more than a dozen of them you can say goodbye to scrolling speed (because the GPU not only has to do normal scrolling duties but also needs to keep adding corner radius back onto your view).
But don’t take my word for it, have some math. I adapted Florian Kugler’s benchmark and ran on a iPhone 4S running iOS 6.1.3. I measure how many views can be initially created in 1/60th of a second, then measure how many views can be animated before the frame rate drops below 60fps. In other words: upfront cost vs framerate cost.
| -drawRect: | CALayer’s cornerRadus
max number of views rendered in 16.6ms | 5 views | 110 views
max number of views animating at 60fps | ~400 views | 12 views
(note that the app is killed for using too much memory at 500 -drawRect: views)
At the end of the day, in my own projects I tend to stick to CALayer’s cornerRadius as much as possible. I’ve rarely needed more than a couple of views with round corners and -drawRect: just has too much of an initial performance hit. And subclassing a view just to round the corners is just, ugh.
But no matter what method you end up choosing, make sure you measure and pay attention to how smooth and responsive your app is, and respond accordingly.
Can I do this?
My question arises from the need of a button that I'm animating when a user touches it.
This animation has been made with a set of 30 png images (half a second of animation # 60FPS). This totals 60 images for regular and retina screens. It works quite well this way, but I'm not happy about it.
My goals are:
1 - Drastically reduce the size of my app (e.g my background is a 400KB png file, but with quartz I can do it with a dozen lines of code).
2 - Do with it with a perfect, smooth animation, as light on the CPU/GPU as I can.
So, is there anyway I can do this?
I have the images in pure vector, and I can draw them with Quartz. But not animate it without having to redraw everything for every frame. (Well, the animation is a "2 way street", it's the coming back that would be problematic to redraw)
Are there any APIs/Frameworks that would help me do this? How would I go about it?
Thank you!
Take a look at CAShapeLayer. It's path property is animatable. For an animation to look good it's important that the from & to shape in the animation have the same amount of points. So depending on your shapes this might or might not work.
I'm attempting to optimize my app. It's quite visually rich, so has quite a lot of layered UIViews with large images and blending etc.
I've been experimenting with the shouldRasterize property on CALayers. In one case in particular, I have a UIView that consists of lots of sub views including a table. As part of a transition where the entire screen scrolls, this UIView also scales and rotates (using transforms).
The content of the UIView remains static, so I thought it would make sense to set view.layer.shouldRasterize = YES. However, I didn't see an increase in performance. Could it be that it's re-rasterizing every frame at the new scale and rotation? I was hoping that it would rasterize at the beginning when it has an identity transform matrix, and then cache that as it scales and rotates during the transition?
If not, is there a way I could force it to happen? Short of adding a redundant extra super-view/layer that does nothing but scale and rotate its rasterized contents...
You can answer your own question by profiling your application using the CoreAnimation instrument. Note that this one is only available in a device.
You can enable "Color hits in Green and Misses Red". If your layer remains red then it means that it is indeed rasterizing it every frame.