I have the following problem: I want to draw many pictures in a row on the same place using cycles with a short brake (using sleep(n);) between each of them. But the only picture draws always after ale cycles are ended up. Is there any possibility to abort the cycle for a while, draw on a canvas and then repeat it until the cycle is at the end? Thank you for your answer and sorry for my strange explanation.
Not by simple draw and sleep sequences. The LCL is event driven and drawing is done in .paint methods in an event triggered by the mainloop.
The best way to do this is use a TTimer, set it to the frequency, and draw the next one if the timer fires.
Related
I want to make a game in which sprites fall from the sky and stack up on the floor, however when there is a lot of layers the camera will move up so you can continue playing. After a while more and more rows of sprites will become invisible as the camera moves up. I want to delete these unused sprite-nodes to keep the performance as good as possible. But when I delete the nodes at the bottom of the stack, won't the entire thing collapse? Or should I detect when the bottom row is unused and then turn off physics for the row above it so it wont fall down and won't affect the rows above it or something of that nature.
I haven't actually made any code yet, I just wanna have a good idea of what I'm doing before I start the wrong way.
Yeah I totally agree, you would really have to be clever about it. Well setting the background image coordinates and looping the background for a "continuous scroll effect" would be Step NO.1 Then using particle physics or actually rendering Nodes would be Step NO.2 The tricky part like you said would be getting the ones below the scene to be destroyed, but I think that if you try and set boundaries, and maybe an if statement that runs the destruction of the particles below the boundaries. So the particles fall down slowly pile up but as the scene scrolls upwards the particles will be destroyed when the their anchor point goes below the x,y boundaries you set and thus keeping those still visible in the scene alive... That would be my way of going about it.
I am drawing a graph with UIKIT and I want to show before it is finished a preloader (spinning circle)
Another solution should be before start drawing set the alpha of my view to 0.0 and when it's done fade it to 1.0.
Someone did this before and/or know how to do this?
If using UIKit, you could draw the path, fill and stroke, then draw another path. This is resource-intensive as you will be calling drawRect: often.
The other way is to create animation. I'll let someone else as I have no experience in creating animation in iOS.
You could add an activity indicator to the view, send the view setNeedsDisplay and remove the activity indicator at the end of the drawRect:, but I doubt you will see the activity indicator at all. Activity indicators are only useful when you are performing some lengthy operations, taking at least several seconds to complete. If drawing the graph is that long, you should either optimize it or consider drawing it on a secondary thread into a CGImage. In the latter case, I'm afraid, you restrict yourself to Core Graphics.
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 attempting to make a ripple tank such as this in VB 2010. I'm not trying to make it as complicated as that, at the moment I am making each wavefront from an e.graphics.DrawEllipse. The problem I am having at the moment is making the ellipse expand properly. I'm using a timer to add one the the ellipse's radius on every tick. Another problem following that is how to make it continuously fire wavefronts so that more than one is on the form at a time.
Can anybody help?
Thanks
Nick
Just in case you're thinking of pushing pixels around, that's not going to work. You need to make a mathematical model of the wave propagation first. Ten-thousand feet view is a class Ripple that can model the propagation of a wave. Then a List(Of Ripple) that stores the state of the box. Every time the timer ticks, update the state of the ripples. And draw the image to go with that.
Key point is that the image gets recreated from scratch on each tick. One important reason why the web site's image is so small.
So in my XIB I have a few graphics that need to reveal in order.. say every one second, the next thing will reveal..
I assume I am going to need something involving viewdidload, starting an NSTimer, then animate the revealing of my graphics with the timer. Can anyone please drop me a few ideas, hints or lines of code to get started?
Thanks!
You could use Quartz Composer to build your image sequence, and then render that to a QCView or OpenGL context.