Cocos2d and usage of CCAnimationCache - animation

I'd like to understand the usage of CCAnimationCache.
I have a cache of enemies objects. Each object has two CCAnimations member variables, a standard animation and a special animation. The frames in the animation varies according to the type property of the enemy object.
#interface EnemyEntity : Entity
{
EnemyTypes type;
CCAnimation * animation;
CCAnimationCache * animationCache;
}
As it is often the case that in the screen I do have several instances of the same enemy type I am wondering if I should use a CCAnimationCache instead a CCAnimation member variable.
And if so where should I put the CCAnimationCache instance?

Huh. Don't you read comments in headers?
/** Singleton that manages the Animations.
It saves in a cache the animations. You should use this class if you want to save your animations in a cache.
Before v0.99.5, the recommend way was to save them on the CCSprite. Since v0.99.5, you should use this class instead.
#since v0.99.5
*/
This comment is in the CCAnimationCache.h file. So, this is a cocos2d singleton as others (CCTextureCache, CCSpriteFrameCache). If you want to use it, just call
CCAnimationCache* animationCache = [CCAnimationCache sharedAnimationCache];

Related

How to properly position a QGraphicsTextItem on a QGraphicsScene

The probelm I have is that I am trying to position a QGraphicsTextItem on a specific location of my QGraphicsScene , to be precise in the center of the speedometer below. But nothing I tried seems to work properly. Despite I clearly provided the coordinates I want the QGraphicsTextItem, it still anchored on top-left as shown below:
Below the snippet of code:
speedwidget.cpp
SpeedWidget::SpeedWidget(QWidget *parent)
: QWidget(parent)
, ui(new Ui::SpeedWidget)
{
ui->setupUi(this);
mScene = new Scene(this);
ui->graphicsView->setScene(mScene);
io = new QGraphicsTextItem;
io->setPos(210,240);
QFont *f = new QFont;
f->setPointSize(18);
io->setFont(*f);
mScene->addText("Odometer :")->setDefaultTextColor(Qt::red);
mScene->addItem(io);
}
speedwidget.h
class SpeedWidget : public QWidget
{
Q_OBJECT
public:
SpeedWidget(QWidget *parent = nullptr);
~SpeedWidget();
private:
Ui::SpeedWidget *ui;
Scene *mScene;
QGraphicsTextItem *io;
};
#endif // SPEEDWIDGET_H
What I tried so far to solve the problem was:
I consulted this post which explained the idea but I don't need to change the background color in this example.
This one had a good snippet, but I am not trying to highlight the color. I am only trying to position the text on a specific location.
If I change io->setPos(210,240); and give different numbers, I still see it anchored on top-left.
Thanks for pointing to the right direction for solving this issue.
The Qt Graphics View framework implements a parent-child mechanism. Simply make your QGraphicsTextItem become a child of your odometer's dial item. From then on, your text label's position will be relative to the one of the dial:
io = new QGraphicsTextItem(this);
// Position text item so that it's centered on the dial
...
Furthermore, note that this line:
mScene->addText("Odometer :")->setDefaultTextColor(Qt::red);
Means that you create yet another text item. A pointer to the newly created item is being returned. Either use & retain that one or use the one that you explicitly created with the new expression.
Furthermore you might want to reconsider your choice of using a QGraphicsScene for one simple "widget". While the Qt graphics framework is not necessarily heavy, it certainly brings quite a lot of overhead for just rendering an odometer.
You can simply overwrite the QWidget::paint() function in your SpeedWidget subclass and render everything using QPainter. That will be a lot lighter and also a lot less hassle.

Libgdx - Image class dispose

I am using LibGDX to create an Android game on Eclipse. I created an instance of Image class. I am not sure if I should dispose it. I created it like this;
img = new Image(new Texture("img.png"));
I created a Texture as well but I could not find a way to dispose it. What should I do?
It's very error-prone to be storing your sole reference to a Disposable asset in part of your game's object graph. Use an AssetManager, or at least use one class that keeps track of all your textures and sounds, etc., (but seriously, use AssetManager--it has built-in reference counting). Then only that class has to handle disposing of all Disposables. Your actor can have a reference to a Texture, but it shouldn't hold the only reference, nor be responsible for disposing of the asset.
assetManager.load("img.png", Texture.class);
assetManager.finishLoading();
img = new Image(assetManager.get("img.png", Texture.class));
//...
assetManager.dispose();
Well, it looks like Texture implements disposeable so that would be the native object that needs to be disposed. You can read through this documentation.
You created an Image with an anonymous texture which just means you don't have a name you can reference it with so you can't dispose it. Your Texture asset needs to be referenced somewhere in your code so that you can dispose it at some appropriate time. Usually I would have a static Assets class which handles disposing all assets when needed (when stopping the app). Classes like Image use these assets but they don't have to worry about disposing them. Hope that helps.

How can I dynamically change keyframe values from code in Unity 5?

I have gameObject with animator attached to it, it has animation curves, I need to dynamically change keyframe values from code. How do I access them?
Already asked this in the Live Session. The Answer is you can't since the anim file is the core for running the Animation Controller.
The alternate way that they gave me is to use the legacy SpriteRenderer instead.
Animation Controller doesn't support Dynamic changing of the values. Instead they provided Animator for you to make Dynamic changes of path from anim files, so consider making different anim files and path to your Animator if you don't like to work with SpriteRenderer.
If "dynamically" still means editor-time, then you could use UnityEditor.AnimationUtility, which provides methods to get and set curves and key frames and more.
One can retrieve the bindings with AnimationUtility.GetCurveBindings() or AnimationUtility.GetObjectReferenceCurveBindings(). And with AnimationUtility.GetObjectReferenceCurve() one can get the key frames, make modifications and apply it with AnimationUtility.SetObjectReferenceCurve()
At runtime - probably only with workarounds.
For example via some animated relay value within a certain custom script that then applies the wanted value to the actual property on Update() - a kind of custom constraint if you will. And within that you could apply then again custom modifications via code on runtime. But on editor time and when animating, the preview would be broken because you would not directly animate the property, but only that relay value. Maybe one could use [ExecuteInEditMode] in that custom constraint behaviour and AnimationMode.InAnimationMode() to simulate a preview. But all of this would be experimental.

iPhone iOS5 querying OpenGL ES 2.0 pipeline objects if they are hidden in the view or not..."Occlusion"

EXT_occlusion_query_boolean is new with OS5.0,
it looks to me like not a single person on the entire internet has posted about these new extensions nor used this code....
so here they are set up properly...which is not documented anywhere as far as i can tell... you can imagine how they would go in your code from this little sudo code here:
import UIKit/UIKit.h
import GLKit/GLKit.h
import "GLProgram.h"
GLuint testBox,hasBeenTested,theParams;
//...
glGenQueriesEXT(1, &testBox);
glBeginQueryEXT(GL_ANY_SAMPLES_PASSED_EXT, testBox);
//... draw an object .......
glEndQueryEXT(GL_ANY_SAMPLES_PASSED_EXT);
glGetQueryObjectuivEXT(testBox, GL_QUERY_RESULT_AVAILABLE_EXT, &hasBeenTested);
if (hasBeenTested) glGetQueryObjectuivEXT(testBox, GL_QUERY_RESULT_EXT, &theParams);
glDeleteQueriesEXT(1, &testBox);
if (!theParams) object is hidden; don't draw next time;
hopefully some here can use this code, i've tested it and it works,
however, there appears to be a bug in GLKit, where if you use self.effect2 = [[GLKBaseEffect alloc] init]; type of GLKit code to render an object, rather than a normal GLES2.0 pipeline, the queries will fail to give you the correct answer... (never hidden) although i tested a pipeline object hiding a GLKBaseEffect object, (which fails) so it could be there is a bug just mixing the two types, if you go the other way, have a GLKBaseEffect object hide a pipeline object, it gives the correct answer, i did not test further yet.
so the question is, I bet i can go further with this and create collision detection in the vertex/fragment shader somehow... this code i found looks like a start... given these two pieces of sudo code, can someone get me closer to collision detection that just triggers when a "part" goes completely inside another part? a quicker easier/firststep could be to have the entire object hidden inside another object before a positive is triggered, this would be a great start, any ideas?
http://ucv.academia.edu/RhadamésCarmona/Papers/743483/Volume-Surface_Collision_Detection

How are the classes in the Sketch example AppKit application separated into Models/Views/Controllers?

I am a little confused as to the definition of classes as Models or Views in the Sketch example AppKit application (found at /Developer/Examples/AppKit/Sketch). The classes SKTRectangle, SKTCircle etc. are considered Model classes but they have drawing code.
I am under the impression that Models should be free of any view/drawing code.
Can someone clarify this?
Thanks.
The developer of Sketch outlines his/her rationale a bit in the ReadMe file:
Model-View-Controller Design
The Model layer of Sketch is mainly the SKTGraphic class and its subclasses. A Sketch Document is made up of a list of SKTGraphics. SKTGraphics are mainly data-bearing classes. Each graphic keeps all the information required to represent whatever kind of graphic it is. The SKTGraphic class defines a set of primitive methods for modifying a graphic and some of the subclasses add new primitives of their own. The SKTGraphic class also defines some extended methods for modifying a graphic which are implemented in terms of the primitives.
The SKTGraphic class defines a set of methods that allow it to draw itself. While this may not strictly seem like it should be part of the model, keep in mind that what we are modelling is a collection of visual objects. Even though a SKTGraphic knows how to render itself within a view, it is not a view itself.
I don't know if that is a satisfying answer for you or not. My personal experience with MVC is that while separation of model, view and controller is a "good thing" oftentimes in practice the lines between layers become blurred. I think compromises of design are frequently made for convenience.
For Sketch in particular, it makes sense to me that the model knows how to draw itself inside a view. The alternative to having each SKTGraphic subclass knowing how to draw itself would be to have a view class with knowledge of each SKTGraphic subclass and how to render it. In this case, adding a new SKTGraphic subclass would require editing the view class (adding a new clause to an if/else or switch statement, likely). WIth the current design, an SKTGraphic subclass can be added with no changes required to the view classes to get things working.
I'm not aware of the particular example that you're refering to, but here's my guess on the reason for that design:
Perhaps the Models (the SKTRectangle, SKTCircle that you mention) know enough to draw themselves but not enough to actually perform the drawing to the screen. The drawing to the screen is handled by the View, where the View will call the Models to find out how to draw them on the screen.
By taking this approach, the View won't have to know how to draw every single Model that it may encounter -- the View only needs to know how to ask the Model to draw itself on the screen.
I'm thinking that it's a trade-off between the MVC model and the object-oriented programming model -- strictly separating along the line of MVC will mean that the View will become extremely large and not very flexible when it comes to adding support for other Models that need to be displayed. With object-orientated design, we'd want the Models themselves to be able to be able to draw themselves on the screen, and we'd want the View to be able to handle new types of Models through facilities such as interfaces.

Resources