let's say I want to display a customizable (2D, cartoon-like) character, where some properties e.g. eye color, hair style, clothing etc can be chosen from a predefined set of options. Now I want to animate the character. What's the best way to deal with the customization?
1) For example, I could make a sprite sheet for each combination of properties. That's not very memory efficient and not very flexible, but probably gives the best performance.
2) I could compose the character from various layers, where each property only affects one layer. Thus, I could make a sprite-sheet for the body, a collection of sprite-sheets for the eyes (one for each eye color) etc.
2a) In that case, I could merge the selected sprite-sheets in order to generate a single sprite-sheet containing the animation of the customized character.
2b) Alternatively, I could keep the sprite-sheets separate and try to animate them simultaneously as layers. I fear, that this might become a problem performance-wise.
3) I could try to modify the layers programmatically, e.g. use a sprite-sheet for the eyes as a mask and map some texture on it before merging it down to a single sprite-sheet. I would think this is a very flexible approach when it comes to simple properties like eye colors, but might become difficult for things like hair-style. I am aware that this depends much on the character and probably a general answer is difficult.
I assume that my problem is not new, so there is probably a standard approach to it.
Concerning the platform, I'm particularly interested in iOS and try to avoid OpenGL (well, I'm open-minded). Maybe there is a nice framework that can help me here?
Thanks!
Depending on what your working on, you might want to animate part/all of the animations outside in another tool, such as flash. It is much easier to work with a visual environment.
Then there are tools that take swf files, and create sprite sheets that you would then animate in cocos2d.
That is a common game creation workflow.
You problably want to take a look on how to create sprites at cocos2d.
Cocos2d comes with a set of tools that help you to animate single parts and offers abstractions to compose parts (like CCBatchNode or CCNode). Also, it comes with tools that helps you to pack sprites into sprite sheets (e.g Texture Packer) and develop levels (e.g Level Helper).
Cocos2d is an open source framework and it is widely used. You also have cocos3d but I never used it :).
Related
I am trying to build a gantt control with Konva (does it make sense to use Konva for this)? I have tried to sketch the control below:
I was thinking of breaking down the Konvas stage as follows:
One stage with 4 layers: activity names, timeline, activity views, and scrollbar view.
The scrollbar layer would contain a "custom control" mimicking a standard scrollbar control.
At this stage I have a couple if questions:
What would be the best approach for synchronizing the different layers from an event handling perspective? For example if the user click's on the scrollbar's down arrow shape, I would need to "scroll" all layers one unit down.
How does the Konva coordinate system work? Is the drawing of shapes done relative to the containing layer?
What's the difference between a layer and a group? Does it make more sense to use a group instead of layers?
I realize my questions are very broad in nature, but at this point I need to get the design right.
I am responding here rather than as a comment because I have more to say than a comment allows.
I have made Gantts with both HTML elements, and another canvas lib, and Konva. I used Divs with jquery first and it was viable but I felt it got quite complicated and it ran out of steam in the area of zooming the view. You can't hide from the complexity of course. Switching to HTML5 canvas I realised that a lib like Konva would accelerate production. And zooming in canvas is simple.
As per #lavrton's comment, the text is primitive on HTML5 canvas when compared to GDI, or other, more mature tech. My answer for the labels on tasks was to use off-screen text drawing then converting to images which works very well. For popup editing, I revert to HTML divs etc. I did not use animations in the Gantt but I have elsewhere and canvas should be fine - there are plenty of bouncy-ball / particle tests around to confirm that.
As a coding design suggestion, the data model and functionality of the Gantt is consistent whatever tech you use to draw it with. I recommend you consider proceeding with a layered approach where your interaction with drawing functions is wrapped as class methods in a drawing class so that you can switch out the drawing tech itself should you feel the need. You could insulate yourself from the choice of tech and/or library that way.
Turning to aspects of your question:
layers are a useful concept. Physically each layer is an HTML5 canvas element. So multiple layers in one diagram are really multiple canvases over the same stage. The benefit here is in redrawing specific layers instead of the entire canvas where there are performance savings. But mostly you can ignore the physical and just get on and use the concept which works well.
groups: a group is a collection of shapes on a layer. If you have to draw things made of many shapes, grouping them is very useful because you can move the group as a whole, hide it, delete it, etc. You might, for example, consider making each taskbar, composed of at least a rectangle and text, as being a group. One consideration for groups is that the location and size of the group is that of the bounding rectangle that encloses the shapes within it. This can cause some confusion until you work out an approach. You will find yourself using layers and groups, but mostly groups for drawing controls.
Zooming / scaling: this is easy with a canvas. Less easy is the math for how to change the offset to keep the same view as you zoom, but again it is achievable.
Synchronised scrolling layers is not going to take any time to develop - just set the layer y-position for each layer.
Drawing the grid of rows for activity and columns for days/weeks/months/etc should not be underestimated as a task, but as you develop it you will learn the fundamentals of working with Konva.
Final point - the docs and examples for Konva could be a bit better, but the community support here and at https://konvajs.github.io/docs/ is good, and the Konva source code is also at that site so you can delve right in to understand what is happening, though you do not need to do that at all if it is not your thing.
A little background: I'm working on an iOS app that has a variety of status icons for various states. These icons are used in a variety of places and sizes including as UITableViewCell imageViews, as custom MKMapAnnotations and a few other spots. I actually have a couple sets which include a more static status icon as well as ones that have dynamic text injected into the design.
So at first I went the conventional route of using static raster assets, but because the sizes were dynamic this wasn't always the best solution and I wasn't thrilled with the quality of the scaling using CGAffineTransforms. So instead I changed gears a bit and tried something else:
Created a custom UIView subclass for each high level class of icon. It takes as input the model object that derives the status from (I suppose I could have also just used an enum and loaded this into some kind of model constructor but this is how I did it) so it can decide what it needs to draw, then does the necessary drawing in drawRect. Since all of the drawing is based on the view bounds it scales to any reasonable dimensions.
Created a Category which has class method constructors that take the model inputs as well as the size you want to use and constructs the custom views.
Since I also wanted the option to have rasterized versions of these icons to plug into certain places (such as a UITableViewCell imageView) I also created constructors that build the view and return a UIImage using the fast iOS7 snapshotting functions.
So what does this give me? Well here's the pros/cons that I can see.
Pros
Completely scalable graphics that can easily be used in a variety of different scenarios and contexts.
Easy compatibility with adding dynamic info to the graphics such as text. Because I have the exact shape data on everything I'm drawing I don't need to guesstimate on the bounds for a text box since I know how everything is laid out.
Compatibility with situations where I might want a rasterized asset but I still get all the advantages of the dynamic view since I'm not rasterizing it till I need it.
Reduces the size of the application since I don't need to include raster assets.
Cons
The workflow for creating the draw code in the first place isn't ideal. For simple stuff I can do it straight in code but for more complex things I'll need to create the vector asset in Illustrator or Sketch then bring it into PaintCode and clean up the generated draw code into something more streamlined. This is not the most ideal process.
So the question is: does anyone have any better suggestions for how to deal with this sort of situation? I haven't found an enormous amount of material on techniques for this sort of thing and I'm wondering if I'm missing a better way of handling this or if there are any hidden gotchas here...performance doesn't seem to be an issue from my testing with my approach but I haven't tested it on the iPad3 or iPhone 4 yet so there could still be some unknowns.
You could try SVGKit, which draws SVG files, and can export to a UIImage, if desired.
I am making a game where bullets are involved. Its a machine gun, so there will be more than one bullet on the screen at the same time. How to I write the code for the properties and actions of one bullet and apply that to all of them, like multiple instances of the one bullet?
The key point to making a game is the concept of sprite, i.e., a light-weight object that has a graphical representation and that you can move around (managing collisions, etc).
You could try to implement sprites on top of CALayers, using Core Animation, or you might decide to use a game framework like Cocos2D.
For the first approach have a look at this short tutorial. This could also help you if you want to implement your sprites using UIImageViews, although you have to keep in mind that CALayer are light-weight, UIView are not, so if you plan to have many of them that could make a difference.
As to the question of replicating the bullet, basically the key suggestion would be using some form of caching, so that you do not end up replicating the same image in memory multiple times. A very basic caching mechanism is available with the UIImage class if you use the convenience constructor imageNamed.
Again, if you plan to make a full fledged game with a good performance (say 40-60 fps), the best suggestion is using Cocos2D, which will offer you all the power of Open GL graphics wrapped in a simple interface.
Have you tried subclassing UIImageView? That way you can have a function createBullet that creates a subclassed UIImageView and adds it to the screen, and in the subclass it can contain functions and properties for animating etc...
I've been looking at a lot of iOS user interfaces that have been customized. I wonder, is it better to customize the UI using images or using libraries like CoreGraphics and Quartz, or is it on a per case basis, as in I use libs for some elements and images for others?
It is very hard to guess your particular situation. I can state that iOS gives us a lot of leverages to make any custom interface. I would use:
images for complicated graphic elements, buttons, icons, arrows, etc.
images + stretching to get complicated backgrounds/elements
custom drawing all that contain lines, ellipses, squares, lineral and/or circular gradients, simple image preprocessing, etc.
The key idea is - to find balance between memory usage and processing time. Note: from my experience - interfaces based on images which created by professional designer looks awesome.
Case-by-case basis. Images can be drawn more quickly but use more memory; custom drawing, whether via Core Graphics or Quartz, uses less memory but takes more time.
Case by case. If you want a lot of complex graphics that aren't lines and don't change much, use images. If you just need lines/gradients, or if you want things to move and morph, you'll need to use quartz.
It depends on you, as well. Would you rather write code for quartz for an hour and debug it, or would you rather spend an hour in photoshop? How fast are you at PS? Do you already know Quartz?
It depends on a lot of things, so "case-by-case".
Determine the complexity of each approach. (nontrivial) Icons are a good example of an image, while large gradients are a good use for drawing. Drawing can take some time/experience to get right, compared to graphic assets, but you can reuse that implementation later and use less memory in many cases (images can also use less memory - depending on what you're drawing). Complex static images can take time to render if drawn so... there are a number of things to consider in order to achieve the best balance. Using the gradient vs. image example, quality and time are also factors -- resizing/scaling a simple image can take a lot of CPU or have artifacts a rendered gradient would not have. Much of it comes down to experience, knowing the implementations you use well, and a lot of sampling/profiling to determine what is simple/complex/consumes a lot of memory, and so on.
I'm trying to figure out the best way to procedurally animate the growing of a 2D plant in iOS.
I want the plant to animate to give an encroaching feeling to the user.
Basically, to animate the growing of a branch, with little buds that will eventually animate into full grown leaves.
To breathe a little life into it, I'd also like the plant to sway a bit as it grows, rather than feeling hand painted on the screen.
One way I've thought of is to use CGPaths and Bezier curves to create the shape of the stalk and the leaves, but I'm not entirely sure how to animate the drawing of the paths. Once I get the "drawing" of the stalk, i'd like to "plant" little buds at certain points on the stalk, as the line is growing/animating and these buds will also start to grow outwards from the plant.
Any suggestions on what route to take to accomplish this task? I'd prefer to procedurally animate as opposed to hand drawing each frame and animating that way. My reasoning is that I imagine procedurally animating will be less time consuming, give me more control over different aspects of the animation, and be reusable in other projects (not to mention, it will be fun to program!)
I've come across this blog posting for the drawing of animated lines:
http://oleb.net/blog/2010/12/animating-drawing-of-cgpath-with-cashapelayer/
Perhaps this would be a starting approach for achieving the results I want, I need to sit down and go through the code he posted.
Also, maybe this is something that would be easier to do using cocos2d or something similar? Or perhaps quartzcore and core animation will work fine.
Thanks for any suggestions you might have, any information is helpful at this point.
(Great question! Posting this as a "community wiki" since it is not an answer but just some references and I didn't want the links to get screwed up in comments. Perhaps people want to add to this?)
I did a simple search on "procedural tree branching code" and there were lots of interesting hits - really rich area.
A post on gameDev.stackExhange pointed to this great resource: Algorithmic Botany
Also Snappy Tree is pretty amazing and the source code is available.
These two also sound interesting:
TReal is a program capable of generating realistic 3D tree models.
Arbaro is an implementation of the tree generating algorithm described in Jason Weber & Joseph Penn: "Creation and Rendering of Realistic Trees" written in Java.
Perhaps more accessible to the OP and with a less complex result are these actionScript tutorials on fractal trees. ActionScript drawing code is pretty easily translated to Core Graphics.