I'm drawing in a single CALayer between 100 and up to 1000 dots (colored circles actually) in a grid, when each dot state changes from hidden to shown and viceversa. So this layer is drawn quite a lot. The reason I went with a single layer and not 1000 layers is because I think performance would be hit with so many layers. Now I want to animate the dissappearance of (maybe multiple) dots over 2 seconds, a fade-off. Is that possible to do for each individual draw call?
Related
I have a Metal based rendering pipeline that renders a few overlapping squares. It loops over all the squares and draws them to the screen starting from the one furthest to the back and ending with the one closest to the front (painter's algorithm).
However, I need some squares in the middle to hide the contents of the squares underneath them slightly. I'm rendering all of the squares in the same render pass, so the fragment shader has read/sample access to the color that was put down by the square drawn before it. But a later square does not have write access to the color that was already drawn to the screen. At the same time, an earlier draw call does not have access to the pixels that will be drawn using future draw calls.
Is there a way for a later draw call to override a color that was placed using an earlier draw call (i.e. tile shading, multiple render passes, etc.)?
I'm going to be using sktilemapnodes for my 2d iOS platformer. What is better or more efficient?
Using a single size sktilemapnode that is the entire level or breaking the area up into multiple sktilemap nodes.
Example:
I have 3 layers of backgrounds that I'm going to use for a parallax background effect.
1st Layer (furthest back) is just a gradient sky. I have it broken up into 512x512 px tiles. I only have 8 different tiles that can be used as a 1x8 grid of tiles. I could then continue this pattern left/right or up/down in order to have the sky be as large as I need it to be.
Question: My question is whether I should use 1 tile map node for the entire sky, or if I should break it up into smaller chunks that are repeatable (like the 1x8 grid). If I break it up into smaller chunks I wouldn't need it to be so big, and as the camera moves around in my game I can move these chunks around.
I'm wondering if this would consume less resources this way.
2nd Layer are hills. I have about 8 different tiles that are 128x64 px each. I can arrange them into a repeatable pattern to my liking. So again I can have a tilemapnode that is the size of the pattern that I can repeat, and I can create multiple nodes or I can just create the entire map in 1 node.
3rd layer is a little different because it is basically a pattern image of trees that holds 27 512x512 px tiles. 9x3 grid. But again, I can use 1 node, or multiple.
I'm just concerned with efficiency. What is going to give me the most bang for my buck so that I can have room to process other game objects. This is just the background u know....
With the Tilemapnode, I'm not sure if tiles that are not visible are not processed each cycle or if I need to do some sort of check manually. I want to have the options of having massive maps on certain levels. I'm new to using sktilemapnodes, so I'm trying to figure out how I would use them in the most efficient way possible.
Each SKTileMapNode is a single node. Apple does a good job of making sure that multiple map nodes don't use too many resources. That is why there is a single node for a map instead of a node for every tile in a map. It is common practice to layer multiple SKTileMapNode(s) to create a parallax effect or simply to create layers.
For example, a platform game with mountains in the background and clouds behind that would use a single SKTileMapNode for the mountains and a single one for clouds. This gives the added benefit of being able to use transparency in tiles.
I am new to Iphone. I want to draw a circle with different colors in it. And all the colors should cover equal area. Like if I want to have 10 different colors in it. Then each color should cover 1/10th area of the circle. I am not trying to draw a pie chart here. Also not trying to use 10 different colors. Just want 10 equal parts of circle and each part can be filled with colors.
I am trying to build a fortune wheel. Such that a smaller wheel is above the larger wheel. And then I want to drag them separately.
Also is it possible to do this with help of Core Animation?
Ambiguous question. If you draw a piechart with 10 equal areas then each will cover 1/10th of the area, thus fulfilling your request, no?
There are 360° in a circle, so divide that by 10 and each wedge should have a 36°. Now you just have to draw 10 wedges, and this page should help you:
http://www.raywenderlich.com/2106/core-graphics-101-arcs-and-paths
Since you say you don't want pie slices, do you want concentric rings instead?
And are you sure you want equal AREA? That will make the rings different thicknesses. The innermost ring will be fairly thick, and each ring as you go outward will be thinner. Much thinner, on the outer rings.
Our eyes are used to a bulls-eye formation, where each ring is the same thickness.
In any case, you should look at CAShapeLayer objects. You can create a shape layer for each ring that defines a closed path with 2 circles. There is something called the "winding rule" that lets you determine what happens when paths overlap. I think you'd want even-odd path winding (kCAFillRuleEvenOdd).
To make the rings equal area, you could do this:
First calculate the area of the whole circle. Divide by the number of rings. That's the desired area for each ring Let's call that area "a". Start from the center. The radius of that ring (a circle) will be sqrt(pi/a).
For each following ring you'll need to calculate the thickness of the ring based on the area of the outer circle minus the area of the inner circle that makes up the ring. You'll need to write an equation that solves for the outer radius given the desired area and the radius or the previous circle.
I am building a cocos2d iPhone game.
There will be 6 'enemy spaceship sprites' that vary only by colour. I.e. all the sprites will have the same shape only some parts of the interior will have different colours.
My two options are:
1)
Create a template shape with a transparent interior.
At runtime, draw this shape on top of a small block of colour X.
The interior of the sprite will be colour X.
2)
Pre-render 6 different sprites
At run time, simply draw the sprite of a given colour.
What is the advantages and disadvantages of each method? Is there a best practice?
If I later wanted to animate the sprites, or dynamically change their colours, would this effect my choice of method?
Thanks!
I think first you need to figure out what it is that you're trying to do... Animation or a large number of color combinations make pre-rendering unfeasible. On the other hand, pre-rendering makes sense if you have a large number of ships on-screen at the same time, because you can use this technique to cut the number of drawing operations in half.
Alright, I have a UIView which displays a CGPath which is rather wide. It can be scrolled within a UIScrollView horizontally. Right now, I have the view using a CATiledLayer, because it's more than 1024 pixels wide.
So my question is: is this efficient?
- (void) drawRect:(CGRect)rect {
CGContextRef g = UIGraphicsGetCurrentContext();
CGContextAddPath(g,path);
CGContextSetStrokeColor(g,color);
CGContextDrawPath(g,kCGPathStroke);
}
Essentially, I'm drawing the whole path every time a tile in the layer is drawn. Does anybody know if this is a bad idea, or is CGContext relatively smart about only drawing the parts of the path that are within the clipping rect?
The path is mostly set up in such a way that I could break it up into blocks that are similar in size and shape to the tiles, but it would require more work on my part, would require some redundancy amongst the paths (for shapes that cross tile boundaries), and would also take some calculating to find which path or paths to draw.
Is it worth it to move in this direction, or is CGPath already drawing relatively quickly?
By necessity Quartz must clip everything it draws against the dimensions of the CGContext it's drawing into. But it will still save CPU if you only send it geometry that is visible within that tile. If you do this by preparing multiple paths, one per tile, you're talking about doing that clipping once (when you create your multiple paths) versus Quartz doing it every time you draw a tile. The efficiency gain will come down to how complex your path is: if it's a few simple shapes, no big deal; if it's a vector drawn map of the national road network, it could be huge! Of course you have to trade this speedup off against the increased complexity of your code.
What you could do is use instruments to see how much time is being spent in Quartz before you go crazy optimizing stuff.