I'm considering implementing my own (toy) MVC framework, mainly just for practise and to have fun with it. I worked with such frameworks in the past but when thinking about how I would go about it a couple of questions arose.
So what puzzles me the most is how I should tackle the drawing of the visual elements. My idea was to implement each item's drawing logic in the item's class, organize them into a tree structure, like in WPF and and pass down some sort of canvas that the elements can draw on when traverse the tree.
I'm having doubts though, whether I should pass a canvas down an entire visual tree. Another interesting thing is the handling of overlaping elements and which to draw first. I thought the visual tree would take care of that by drawing elemtns in the order they appear in a depth first search. But then I thought that the newest element should be on top no matter how close it is to the root in the tree.
So basically I couldn't really find anything on implementation best practises or details when it comes to drawing the elements and I could use some friendly advice on this or if you could point to some material that covers this it would be more than welcome.
The MVC pattern typically doesn't tackle such granular details. It ultimately comes down to decomposing the problem into three broad domains: data and logic, user input, and user output.
I'm having doubts though, whether I should pass a canvas down an
entire visual tree.
How come? From a performance or coupling/responsibility perspective?
If it's performance, this is a very solid start. You do have to descend down the tree and redraw everything by default, but that can be mitigated by turning your hierarchy into an accelerator and keeping track of which portions of the screen/canvas/image need to be redrawn ("dirty regions"). Only descend down the branches that overlap this dirty region.
For the dirty regions, you can break up your canvas into a grid. As widgets need updating, mark the region(s) they occupy as needing to be redrawn. Only redraw widgets occupying those grid cells which are marked as needing to be redrawn. If you want to get really elaborate and mitigate overdraw to a minimum, you can use a quad-tree (but typically overkill for all but the most dynamic kind of systems with elaborate animating content and things like that).
It might be tempting to make this problem easier to solve to double-buffer everything and have children draw into their parents' canvases, but that's a route to gain some immediate performance in exchange for a large performance barrier at a design-level in the form of memory consumption and cache efficiency. I don't recommend this approach: double-buffer the window contents to avoid flickery artifacts, but not every single control inside of it.
If it's about coupling and responsibilities, often it's overkill from a UI context to try to decouple the rendering of a widget from the widget itself. Decoupling rendering from entities is common in game architectures through entity-component systems which would provide rendering components (typically in the form of dumb data) and defer the rendering functionality to systems, but those take a great deal of work upfront to implement for tremendous flexibility which you might never need in this kind of context.
Another interesting thing is the handling of overlaping elements and
which to draw first. I thought the visual tree would take care of that
by drawing elemtns in the order they appear in a depth first search.
But then I thought that the newest element should be on top no matter
how close it is to the root in the tree.
The tree doesn't have to be this rigid thing. You can send siblings to the front of a child list or to the back to affect drawing order. Typically z-order changes don't occur so frequently and most of the time you'd be better off this way than transferring a great overhead to sorting the drawing on the fly as you are rendering.
Mostly I just recommend keeping it simple, especially if this is your first attempt constructing a general-purpose MVC framework. You're far more likely to err on the side of making things too complicated and painting yourself in a corner. Simple designs are pliable designs.
Related
Is there a way to animate wind for certain game objects?
For example, branches of trees should gently move, like there's a breeze in game. Not gameplay, more like a special background effect.
If it's not possible in code, what would be the best way to create proper sprite images?
I see a few options to actually achieve that Wind Effect.
SKFieldNode, It allows you to actually apply physics effects to nodes. And if you want real tree branches that can move based on the physics, you should combine SKFieldNode with SKPhysicsJoint. When you combine those two you can actually create indepedent Branch Nodes to receive some kind of force to simulate a wind effect. To understand what you can do with SKPhysicsJoint, check out this guide. This solution can get really complex and hard to achieve with superficial understanding of SpriteKit Engine, but you can create an amazing effect using it. Personally, I would not recommend if you have deadlines to attend, physics always get buggy if you lose your grasp on what you are doing, you may invest a lot of time trying to achieve this using physics.
Create different animation of your tree responding to wind movement and control which animation frame you should use at that specif case. I Would highly recommend this one, because you will have control over what is going on with you tree and people that play games don't pay that much attention to what is going on with background, altho is a good thing to think about it from the game experience.
Create your tree textures and change the anchor point to be at the place you want the effect to be more effective and responsive. The farthest the coordinate in the node is from the anchor points coordinate, less effect from your SKAction it will get.
Sorry for my English, is not my native language.
I want create a simple 2D game in Unity3D, in which one of the entities has to grow and shrink. This is done by merging simple shapes.
A rough example in the picture below just to show what I mean:
It grows by adding components and shrinks by removing them. There will be a lot of entities on the screen so the performance is very important.
Is it possible to change dynamically the shape of one gameobject? If not, which of the following solutions is more suitable and why?
Constantly add new gameobjects (shapes) to the previous one and then remove them?
Create an animation. In this case is it possible to change the animation speed at runtime so for example first it grows faster and then grows slower or shrinks? My issue is whether the change of speed will apply to the whole loop of the animation or is it possible to apply it in the middle (so that the speed of shrinking and growing is different)? I would prefer the latter to happen.
If you have any other suggestions I'd be glad to hear them.
Create an empty game object and add all of these small pieces as its child. Then you can disable/enable whichever you want with gameObject.SetActive(false/true);
Depends what is "lots of objects" and what is the target platform.
You can easily have hundreds of sprites on screen in any case, especially if they get batched : http://docs.unity3d.com/Manual/DrawCallBatching.html
And there is big performance benefit to use object pooling,
instead of instancing new objects and destroying old ones.
Having hundreds of animated objects would cause slowdown,
Mecanim Animator seems to be slower than the original Animation component.
Other options:
- Create custom mesh that you modify at runtime (by adding/removeing vertices to it), this also allows to freely modify the shapes (by moving the vertices) : http://docs.unity3d.com/ScriptReference/Mesh.html
I am currently working on a user interface, in which it is possible, to add objects by clicking on the screen. I don't want any overlapping objects. While it is easy to detect, whether a collision between 2 objects occurred, i am still struggling with resolving these conflicts.
Currently, i am resolving the conflicts locally by moving the intruding object away from the collision. This, however, may lead to new collisions, which are resolved in the same manner. Unfortunately, there is no guarantee, that this process will ever stop.
Are there any standard problems this relates to or algorithms to use? Or any efficient solutions which are not prone to endless recursion?
Now that I thought of it more I think you just move all the objects that lie in the direction of the move that you are already doing. Doing it this way you basically solve the problem of possible endless recursion.
Since you should know the size of your objects to move and the direction of a smart movement this should solve the problem
"grid snap" is avoiding the problem but not a solution to the problem.
As Sarah pointed out you can solve this by moving your objects a random distance into one direction and then check again if there is a collision, then move the colliding object. However, this can lead to exponential growth of the problem.
Instead you can try to implement a light physics engine where your objects "bounce" against each other and using friction come to a halt after some time. Try to google for continuous collision avoidance.
The easiest way I can think of how you can resolve your problems is by implementing a "grid snap" behavior.
Basically, there are only predefined areas in your frame where the user can add UI elements---the grid cells. When a user drops a UI element on your frame, you should detect where in the grid does it fall mainly (you can choose your own behavior in case it falls equally across two or more grid cells). This way, you need not detect collision between two UI elements at all.
Edit
Well, I certainly did not anticipate the cases you outlined in your comment. If the sizes of your objects will vary by that much, I admit that "grid snap" may not be applicable to your situation---you might end up with a lot of empty space. I was thinking of something along the lines of Visual Basic when I composed my answer (VB, as far as I remember does implement some sort of grid snap behavior).
A minor point though: while you may have your user's best interests at heart by letting them have an exact control of the positioning of UI elements, think of how your users will interface with your program. Positioning things exactly on the screen using a mouse can be punishment and it may just backfire on you. The same, however, cannot be said if you are guaranteed that your users will always use a touchscreen device.
I would like to design a GUI for a multi-touch device to navigate through a feed of articles. The articles are tagged and organized in a few hierarchies (e.g. topic hierarchy, GEO hierarchy if the articles come from different locations, etc.)
The purpose of the GUI is to navigate quickly through the tags and hierarchies and find interesting articles.
I would like to build a tree map, so that each tile represents either a hierarchy or a tag. The tile displays its hierarchy/tag name and a "pile" of articles. The "pile" actually displays only the preview of the top article.
User can zoom the entire tree map to see more elements of the hierarchy and enlarge the previews of the articles. User can also select a tile (or article) and zoom it separately.
Does it make sense ?
It makes sense for me. Some questions come to my mind which should be considered early with design:
Alignment
Are your tiles hierarchical? (i.e. the tile "programming" has sub-tiles "java", "c++", "python", ...) In this case it makes perfectly sense to use a tree map. But you have to keep in mind how you will arrange tiles and also previews. It is quite hard to find enough space if you want to label your different tiles. Unfortunately text is in most cases much wider than high. And therefore you soon come to something which looks more like a flat tree than actually a map.
Hierarchy
If you have previews on different levels of your hierarchy make a clear distinction on which level they are place. Either by color-coding them or by different sizes.
Readability
If you have a deep hierarchy you may not see much detail in the separate panels any more. Therefore consider a very basic "preview" and add detail when you zoom in. Or add new levels only when zoom factor is good enough to display them in a readable manner.
Heap effect
If you have much panels on the same level it may easily become crowded. Use the tree-map configuration to scale you parent-tile according to the number of child-items.
Although this is not an answer to your question it may help you in your design decision. I would be happy to hear of your further steps.
This is a difficult question to search in Google since it has other meaning in finance.
Of course, what I mean here is "Drawing" as in .. computer graphics.. not money..
I am interested in preventing overdrawing for both 3D Drawing and 2D Drawing.
(should I make them into two different questions?)
I realize that this might be a very broad question since I didn't specify which technology to use. If it is too broad, maybe some hints on some resources I can read up will be okay.
EDIT:
What I mean by overdrawing is:
when you draw too many objects, rendering single frame will be very slow
when you draw more area than what you need, rendering a single frame will be very slow
It's quite complex topic.
First thing to consider is frustum culling. It will filter out objects that are not in camera’s field of view so you can just pass them on render stage.
The second thing is Z-sorting of objects that are in camera. It is better to render them from front to back so that near objects will write “near-value” to the depth buffer and far objects’ pixels will not be drawn since they will not pass depth test. This will save your GPU’s fill rate and pixel-shader work. Note however, if you have semitransparent objects in scene, they should be drawn first in back-to-front order to make alpha-blending possible.
Both things achievable if you use some kind of space partition such as Octree or Quadtree. Which is better depends on your game. Quadtree is better for big open spaces and Octree is better for in-door spaces with many levels.
And don't forget about simple back-face culling that can be enabled with single line in DirectX and OpenGL to prevent drawing of faces that are look at camera with theirs back-side.
Question is really too broad :o) Check out these "pointers" and ask more specifically.
Typical overdraw inhibitors are:
Z-buffer
Occlusion based techniques (various buffer techniques, HW occlusions, ...)
Stencil test
on little bit higher logic level:
culling (usually by view frustum)
scene organization techniques (usually trees or tiling)
rough drawing front to back (this is obviously supporting technique :o)
EDIT: added stencil test, has indeed interesting overdraw prevention uses especially in combination of 2d/3d.
Reduce the number of objects you consider for drawing based on distance, and on position (ie. reject those outside of the viewing frustrum).
Also consider using some sort of object-based occlusion system to allow large objects to obscure small ones. However this may not be worth it unless you have a lot of large objects with fairly regular shapes. You can pre-process potentially visible sets for static objects in some cases.
Your API will typically reject polygons that are not facing the viewpoint also, since you typically don't want to draw the rear-face.
When it comes to actual rendering time, it's often helpful to render opaque objects from front-to-back, so that the depth-buffer tests end up rejecting entire polygons. This works for 2D too, if you have depth-buffering turned on.
Remember that this is a performance optimisation problem. Most applications will not have a significant problem with overdraw. Use tools like Pix or NVIDIA PerfHUD to measure your problem before you spend resources on fixing it.