I'm using cocos2d-x and want to create a dynamic shape as part of my user interface. I need a circle with an adjustable section removed. I attempted this using the draw method but item would be drawn every frame which required too much processing power. What would be an efficient way to achieve this without drawing the shape every frame? Is it possible to clip a circle sprite to remove a section?
The mathematics behind the implementation is ok, I'm just looking for a high level explanation about how I should approach this.
you can have a try on CCTransitionProgressRadialCW. This class contains something similar to what you want.
Turns out theres a class specifically designed for this, CCProgressTimer.
Related
Hello recently i started to mess around with SDL. Since i was interested in some 2D/2.5D games.So i started messing around with SDL in C++, I was looking to recreate something similar to Original Zelda.
So as far as i understand those game work with some kind of isometric prespective, or standard Orthogonal view but one thing i do not understand is how can you generate 3D-like Collisions between those objects on the map (tiles, sprites etc which are in 2D). Have a look at the video link below. Is this created purely in SDL, is it PerPixel collision or rectangular ? Or it might involve OpenGL as well ?
Link: https://www.youtube.com/watch?v=wFvAByqAuk0
The original was probably a simple Rectangular collision.
I believe that your "3D collision" is the partial collision present in some objects. For example, Link can go through the leaves, but not through the trunk.
You can do it easily in 2 ways:
Layers of rendering and collision. The trunk is located in one layer and is covered by some collision boxes. Link is present in a intermediary layer. And the leaves are in another layer, on top of Link. Then you can check collision between Link's Layer and the layer with the trunk and other objects, for example.
Additionally you can create a property for your tiles in which you can store the type of collision you hope to obtain. For example, 'box' collision will tell your engine that the object is collidable on every side. Or 'bottom' collision will tell your engine that Link will collide with this object only if he is walking down into the object (this is the effect of you will see on some 2D sidescrollers: jump through a tile but then fall into it solid.
Per pixel collision in those simple cases is not worth it. I find it much better to personalize the collision ourselves, using creativity, masks and layers.
BTW: This topic would fit better on https://gamedev.stackexchange.com/
In my case, I'm making a 2D game that camera always follow my character, but there will be scene limitations so I have to stop follow him when he is nearly beside scene borders. I also have to treat camera scale, so I have to decide whether to use CCFollow::actionWithTarget() or CCCamera.
In CCCamera.h it says:
Limitations:
- Some nodes, like CCParallaxNode, CCParticle uses world node coordinates, and they won't work properly if you move them (or any of their ancestors)
using the camera.
- It doesn't work on batched nodes like CCSprite objects when they are parented to a CCSpriteBatchNode object.
- It is recommended to use it ONLY if you are going to create 3D effects. For 2D effecs, use the action CCFollow or position/scale/rotate.
The last sentence is interesting, why ONLY use it in 3D effects? Seems CCCamera is not recommended by its producer. I know it's a shortcut to treat camera movements, but I just don't know why better not to use it in 2D games.
If you notice, the CCCamera.h file also says:
Useful to look at the object from different views.
The OpenGL gluLookAt() function is used to locate the
camera.
There's a good write up in the OpenGL Redbook on how the camera works. My understanding is, the camera is meant to setup the initial orientation, then you move the world by updating the model matrix (which is what I'm guessing CCFollow does for you). There's an answer here that may help if you still want to use the camera:
moving CCCamera
I am trying to visualize a CAD geometry where GL_QUADS is used for the geometry and glutBitmapCharacter to annotate with a text.
The GL_QUADS hides the text partially (e.g 33,32,... here) for some view orientations (picture 1).
If I use glDisable(GL_DEPTH_TEST) to get the text displayed properly, I get the text that is supposed to annotate the back surface is also displayed (picture 2).
My objective is to annotate the visible front surfaces without being obscured but having the annotation on the back surfaces not shown.
(I am able to solve this by slightly offsetting the annotation normal to the quad, but this will cause me some other issues in my program, so I don't prefer this solution)
Could somebody please suggest me a solution ?
Well, as I expect you already know, it looks like the text is getting cut off because of the way it's positioned/oriented - it is drawing from a point and from right-to-left on the screen.
If you don't want to offset it (as you already mentioned, but I still suggest as it's the simple solution) then one way might be to rotate the text the same way the object's being rotated. This would (I'd expect) simply be a matter of changing where you draw the text to the same place you draw each quad (thus using the same Matrix). Of course then the text won't be as legible. This solution also requires the use of a different Object for rendering the text, such as FreeType Fonts.
EDIT 2: another solution would be texture-mapped text
Could somebody please suggest me a solution ?
You need to implement collision detection engine.
If point in 3d space at which label must be displayed is not obscured, render text with depth test disabled. This will fix your problem completely.
As far as I can tell, there's no other way to solve the problem if you want to keep letters oriented towards viewer - no matter what you do, there will always be a a good chance of them being partially obscured by something else.
Since you need a very specific kind of collision detection (detect visibility of a point), you could try to solve this problem using select buffer. On other hand, detecting ray/triangle (see gluUnProject/gluProject) collision isn't too hard to implement, although on complex scenes things will quickly get more complicated and you'll need to implement scene graph and use algorithms similar to octrees.
I'm trying to use Papervision for Flash, for this project of mine, which involves a 3D model of a mechanical frame, consisting of several connected parts. Movement of one of the parts results in a corresponding change in orientation and position of other parts of the frame.
My understanding is that using a scene graph to handle this kind of linked movement would be the ideal way to go, at least, if I were to implement in one of the more established 3D development options, like OpenGL or DirectX.
My question is, is there an existing scene graph implementation for Papervision? Or, an alternative way to generate the required 3D motion?
Thank!
I thought Papervision is basically a Flash-based 3D rendering engine, therefore should contain its own scene graph.
See org.papervision3d.scenes.Scene3D in the API.
And see this article for a lengthier explanation of the various objects in Papervision. One thing you can do is google for articles with the key objects in P3D, such as EngineManager, Viewport3D, BasicRenderEngine, Scene3D and Camera3D.
As for "generating the motion", it depends on what you are trying to achieve exactly. Either you code that up and alter the scene yourself, or use a third-party library like a physics library so as to not have to code all that up yourself.
You can honestly build one in the time it would take you to search for one:
Create a class called Node with a virtual method Render(matrix:Matrix), which holds an array of child nodes.
Create a subclass of Node called TransformNode which takes a reference to a matrix.
Create a subclass of Node called ModelNode which takes a reference to a model.
The Render method of TransformNode multiplies the incoming matrix with its own, then calls the render method of its children with the resulting matrix.
The Render method of ModelNode sends its model off to the renderer at the location specified by the incoming matrix.
That's it. You can enhance things further with a BoundsNode that doesn't call its children if it's bounding shape is not visible in the viewing frustum.
I guess I'll illustrate with an example:
In this game you are able to draw 2D shapes using the mouse and what you draw is rendered to the screen in real-time. I want to know what the best ways are to render this type of drawing using hardware acceleration (OpenGL). I had two ideas:
Create a screen-size texture when drawing is started, update this when drawing, and blit this to the screen
Create a series of line segments to represent the drawing, and render these using either lines or thin polygons
Are there any other ideas? Which of these methods is likely to be best/most efficient/easiest? Any suggestions are welcome.
I love crayon physics (music gets me every time). Great game!
But back to the point... He has created brush sprites that follow your mouse position. He's created a few brushes that account for a little variation. Once the mouse goes down, I imagine he is adding these sprites to a data structure and sending that structure through his drawing and collision functions to loop through. Thus popping out the real-time effect. He is using Simple DirectMedia Layer library, which I give two thumbs up.
I'm pretty sure the second idea is the way to go.
First option if the player draws pure freehand (rather than lines), and what they draw doesn't need to be animated.
Second option if it is animated or is primarily lines. If you do choose this, it seems like you'd need to draw thin polygons rather than regular lines to get any kind of interesting look (as in the crayon example).