I have a timeline where I basically want the user to have the ability to tap on the screen to fast forward the animation (well, more like skip part of the animation) to a later part. Obviously, this would have to be done using code.
I've researched this quite a bit and I don't think there's an easy solution. CCBSequence and CCBSequenceProperty offer a bit of hope, but my ideas have run dry and can't see a way to do it.
Obviously I'm aware of the animation manager and using it to run timelines and stop timelines, or even call something when the timeline is completed, but my capabilities with manipulating timelines made in Spritebuilder doesn't extend too far beyond that.
I can think of a messy workaround, where basically I just duplicate the section of the timeline I want to skip to and when the screen is tapped stop the current timeline and go to that, but it seems cumbersome and messy and I'd like to avoid that if possible.
Thanks for help!
I found the easy solution after a bit more looking
So if you have a look in CCAnimationManager there is a method for this called:
- (void)jumpToSequenceNamed:(NSString*)name time:(float)time;
So with your node you can call
[node.animationManager jumpToSequenceNamed:#"MyTimeline" time:1.0]; // 1 Second
If your animations aren't extremely complicated, try to implement it via cocos2d actions http://www.cocos2d-swift.org/docs/api/index.html
Using engine API you can create animation with custom speed on every tap.
Related
According to a Qt blog post from 2011, there is supposed to be an environment variable QML_FLASH_MODE that can be set to 1 to see which areas of a QML application are being repainted.
I have set this variable for a Qt Quick 2 application that I'm writing and there is no visual difference to running the application without this variable.
Is there any other way to see QML redrawing activity? I'm trying to troubleshoot performance issues.
It looks like QML_FLASH_MODE was removed in this commit as part of refactoring to support separate rendering loops per window. Reason why it was removed is not obvious, but anyway its gone now.
If you think QML_FLASH_MODE will help you to analyse your scene, you can always get back to Qt 5.1.1 where it still should be present.
On the other hand, to visually analyse scene is not always efficient. I suggest to use qtcreator's profiling. Take a look at property bindings that reevaluated just before painting happens. This should help you to figure which property changes have triggered redraw and could give you some hints on how to optimise your scene.
If you just want to count fps or log when frames being painted, check QQuickWindow::frameSwapped signal.
I already have my app finished but i want to polish it with some nice animations. Nothing to crazy, I just need to loop through some sprites to make it look like a plant is growing. For obvious reasons, I don't want to try and work this into a cocos2d framework. I found a couple animation classed on the web, but the animation look crappy and unnatural. Any ideas as to how I can best achieve this?
UIImageView animations would be the easiest. http://mobile.tutsplus.com/tutorials/iphone/uiimageview-animation/
First of all, I know there are a few other StackOverflow questions about this subject, but I have read them all and I still am confused about what to do for my situation. I'm probably missing something obvious here, if you could help clarify that would be much appreciated!
I have a app which is doing a lot of work to animate images within a view - mainly comprised of a number of images moving in straight lines for a second or two at a time. I considered at first making them all simple, once off animations using UIView animateWithDuration for the whole duration of the movement. But I found that didn't give me a lot of power to intercept the movement or stop it or check where it was up to, so I scrapped that. My new approach is to use an NSTimer, firing 20 times per second, doing incremental movements. This way I also can intervene (almost) instantly to change the animation or stop it or update a status label based on how far through it is, etc, etc.
First of all...there probably is a better way than this. Feel free to suggest something better!
Assuming this is acceptable though, my issue now is that while these animations are happening, I can't click any of the other controls on the UI. I get no response. It's not like it's just slow or delayed either - the click never comes through. It seems that the NSTimer processing totally locks the UI - but only from new interactions. Changes I make to the UI within the timer processing method happen just fine, and are very snappy.
From what I've read this shouldn't happen. However I also saw a comment on this question saying that if the timer processing is intensive then it could lock the UI thread. I don't see my processing to be that intensive here - certainly no resource requests, just a bit of data manipulating and animating some objects - but I could be underplaying it.
What are my options here? At first I thought I might create a new thread to kick off the timer. But I remember reading that the UI updates have to happen on the main thread anyway. Why is this? And plus, would that really solve the issue? Am I just asking too much of the device to process this timer as well as UI interactions? Is there something else I'm missing?
Any and all advice would be appreciated.
Edit:
I've just found the cause of my UI blocking problem. I was using the animateWithDuration with blocks, but was not setting the options. Therefore UIViewAnimationOptionAllowUserInteraction was not set. I changed it to set this option and my UI is happily responding now.
That said, I'll still leave this question open for specific suggestions regarding my overall approach. Thanks.
I would consider using CADisplayLink. From the documentation:
A CADisplayLink object is a timer object that allows your application to synchronize its drawing to the refresh rate of the display.
Your application creates a new display link, providing a target object and a selector to be called when the screen is updated. Next, your application adds the display link to a run loop.
Once the display link is associated with a run loop, the selector on the target is called when the screen’s contents need to be updated. The target can read the display link’s timestamp property to retrieve the time that the previous frame was displayed. For example, an application that displays movies might use the timestamp to calculate which video frame will be displayed next. An application that performs its own animations might use the timestamp to determine where and how displayed objects appear in the upcoming frame. The duration property provides the amount of time between frames. You can use this value in your application to calculate the frame rate of the display, the approximate time that the next frame will be displayed, and to adjust the drawing behavior so that the next frame is prepared in time to be displayed.
Your application can disable notifications by setting the paused property to YES. Also, if your application cannot provide frames in the time provided, you may want to choose a slower frame rate. An application with a slower but consistent frame rate appears smoother to the user than an application that skips frames. You can increase the time between frames (and decrease the apparent frame rate) by changing the frameInterval property.
When your application finishes with a display link, it should call invalidate to remove it from all run loops and to disassociate it from the target.
CADisplayLink should not be subclassed.
I'm not totally sure how everything is handled in your program, but you might want to just consider having one thread/timer that controls all of the objects and their movements. There's really no need to create a separate thread/timer for every single object, as that will easily cause problems.
You can just create a class for your moving items with some variables that contain information about their direction, speed, duration, etc, and then have a controlling thread/timer calculate and move the objects. You can then intervene onto the one main controller object instead of having to deal with many other objects.
I think you'll find that even if you optimize this, timer based animation like this is not going to perform well.
You might want to ask about the specific things that you think you couldn't do with CoreAnimation. If you solve those issues, you'll end up with a much better result than trying to roll your own.
I'm working on a little program and would like to implement a menu in the style that is used in the Front Row application. I know this is an extremely open ended question but what would be the best way to go about creating such a thing?
I thought I could maybe use a NSTableView but from the looks of it, that seems overly complicated to get the scrolling to work correctly.
I'm wondering if I should just code my own menu view from scratch but wouldn't really know where to begin to start that.
Any thoughts or pointers would be great.
Thanks,
Apple provides sample code that shows how to implement a fullscreen, list-like menu:
https://developer.apple.com/library/mac/#samplecode/CoreAnimationKioskStyleMenu/Introduction/Intro.html
The code uses no AppKit classes (like NSTableView). The UI is made with Core Animation.
Another good core animation sample to create Front Row like Menus can be found in the following blog post:
http://bill.dudney.net/roller/objc/entry/20080111
I am using a NSSearchField to run a query over the internet and display the results in a table view. Whilst the query is running I would like to display a progress indicator inside an NSSearchField? I think I have seen this done in another application before.
Is there an open source component that I could use to accomplish this?
How would I go about doing this? What is the best way? What are the pitfalls?
The easiest way is to put the progress indicator above (atop) the search field and leave them as separate views. It used to be that view z-ordering would give unpredictable results and weren't encouraged. That's not been true for several OS X versions, now, so if it looks good and behaves as expected, I say go for it.
The harder way would be to subclass NSSearchField and muck around according to the goodies found in the Control and Cell Programming Topics for Cocoa guide.
I'd go for a custom subclass of UISearchFieldCell. Find the method that draws the background and try to add your custom drawing code there. I'd rather not fiddle with nested components. I think the one used in safari is also a custom control.
This is not my solution but I came across this question and I eventually found someone that worked out a solution and it worked for me:
https://github.com/owainhunt/UAShared/blob/master/UAShared/NSSearchField%2BSpinner.m