Is there a way to check when a SKSpriteNode / SKNode is onscreen (i.e. visible) I have a large scrolling background where I am spawning mobs, but I want to limit their animations and sounds if they are not visible. Is there a way to do this, I could write something in the update loop but I wanted to see if there was anything I could test before I start querying mob positions every frame?
I think you are doing this wrong. You should stick to the MVC pattern. As such, you only have data/points that are moving in a large area and in update method, if any data is within screen area, only would you draw them. If it is out, remove them.
Related
I am creating an app for practice that is a simple drawing app. The user drags his/her finger along the screen and it colors in a 100px x 100px square.
I currently achieve this by creating a new colored UIView where the user taps, and that is working. But, after a little time coloring in, there is substantial lag, which I believe is down to there being too many UIViews as a subview of the main view.
How can I, and others who similarly create UIViews on dragging a finger reduce the lag to none at all, no matter how many UIViews there are. I also think that perhaps this is an impossible task, so how else can someone like me color a cube of the size stated above in the main view on a finger dragged along the screen?
I know that this may seem like a specific question, but I believe that it could help others understand how to reduce lag if there are a very large amount of UIViews where a less performance reducing option is available.
One approach is to draw each square into an image and display that image, rather than keeping around an UIView for each square.
If your drawing is simple enough, though, you can use OpenGL to do this, which is much faster. You should look at Apple's GL Paint Sample Code which shows how to do this in OpenGL.
If your drawing is too complex for OpenGL, you could create, for example, a CGBitmapContext, and draw each square into that context when the user drags their finger. Whenever you draw a new square into that bitmap, you can turn the bitmap into an image (via CGBitmapConxtextCreateImage) and display that image an a UIImageView.
There are two things that come to my mind:
1- Use Instruments tool to check if you are leaking any memory
2- If you are just coloring the views than instead of creating images for each of them, either set the background color property of UIView or override the drawRect method to do custom drawing
I think what you are looking for is the drawRect: method of UIView. You could create your custom UIView (you propably have that already) and override the drawRect method and do your drawing there! You will have to save your drawings in an array or another container and call the setNeedsDisplay method whenever the array content is changed.
I have a uitableview, where custom tableview cell inserts another uiview subclass to its contentView to display each cell content, I use the views drawRect method to write more than 20 numbers on each cell.
Now I need to animate the color of each numbers depending on whether its value has increased or decreased from its previous value.
I am using CATextLayer for this purpose, so that I can animate the foregroundColor property using CAAnimation. But in this process iOS is trying to trigger almost 400 CAAnimation simultaneously as I have 20 or more rows too. And this is seriously affecting the performance.
I found CAShapeLayer far more heavier for this job.
And moreover when I am using CATextLayer my font looks really jagged, and edgy.
My question is what would be the best method to do such thing.
Does a collection of animations in a CAAnimationGroup run under one thread, actually my point is will it improve the performance if I try to group 20 CAAnimations for a particular row into a CAAnimationGroup, than firing them individually.
For one of my requirement i was also requiring animation group and here is the reference:
How to animate one image over the unusual curve path in my iPad application?
Hope this will help you out.
Enjoy Coding :)
i want my app to be able to track a person when he moves 2 dimensionally upwards. I already have a vertical scroll view, and it works, but when i press a button i want it to track a little stick figure as he walks vertically, how can i control this? i thought of setting the scrollview.contentoffset to a certain position, but it just changes it one time when i want it to change it fluidly. i suppose i could make a timer that updates the contentOffSet every like .001 seconds or something, but i thought there maybe a better way.
Also, while i was searching the UIScrollView's methods, one of them was an isTracking method, which is a boolean, and I'm assuming it returns yes if the scrollview is tracking something, so given that i assume there is a feature in scrollview so that you can track things. Also, if to track things you have to use some other framework thing that would be helpful to know too
THANKYOU FOR ANY HELP!
The property tracking tells if the scroll view is currently tracking the user's movement. So that definitely won't help you out. (See David H's post for a better explanation for what the property indicates.)
However, you could use setContentOffset:animated: and set animated to YES. That results in a smooth transition to the new content offset.
Instead of calculating a reasonable content offset you might find it easier to specify an area that contains the stick figure. If so use scrollRectToVisible:animated:. Obviously animated should be set to YES.
1) don't use contentOffset = x;, use "- (void)setContentOffset:(CGPoint)contentOffset animated:(BOOL)animated". Experiment how often you need to send this message, but I'm guessing you can do it no more than 10 times a second and get nice results.
2) isTracking means the user has their finger on the scrollView but has not started dragging it. By testing "isTracking" and "isDragging" you can determine if the user is fiddling with your scrollView or not.
How do I add some extra drag to the UIScrollView physics. It scrolls just a little too fast for what I am doing. (I don't want to disable altogether, I still like the rubber band effect when you get to the end or beginning of the view.) Is there any way to slow it down?
Actually, after reading the Documentation I discovered the property for UIScrollView that slows down the scrolling, so Apple does make this readily available for anyone else looking for this:
scrollView.decelerationRate = UIScrollViewDecelerationRateFast;
Even though it says fast, it is speeding up deceleration which in effect slows the scrolling down. This was exactly what I needed. And no worry of patents. :)
Actually you can make block animation with ScrollToRowAtIndexPath:... with animated set to NO. This way block animation will animate underlaying variables manually using selected time.
As UICollectionView is subclass of UIScrollView You can use scroll view delegate method.
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset {
targetContentOffset->x = (targetContentOffset->x - scrollView.contentOffset.x) / 6 + scrollView.contentOffset.x;
targetContentOffset->y = (targetContentOffset->y - scrollView.contentOffset.y) / 6 + scrollView.contentOffset.y;
}
This is simply not possible right now. Maybe Apple will one day extend the API to allow it, but until that day, you're stuck with the default speed.
The only other option would be your own scrolling implementation. This isn't trivial if you want all the nice polish such as the rubber band effect and the way the scrolling will lock horizontally or vertically. Not to mention flicking to scroll.
Also, Apple has a patent for some of those scrolling behaviours, so writing your own might even be dangerous. Source: "Apple's touch-screen patent".
A computing device, comprising: a touch screen display; one or more processors; memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including: instructions for detecting one or more finger contacts with the touch screen display; instructions for applying one or more heuristics to the one or more finger contacts to determine a command for the device; and instructions for processing the command; wherein the one or more heuristics comprise: a vertical screen scrolling heuristic for determining that the one or more finger contacts correspond to a one-dimensional vertical screen scrolling command rather than a two-dimensional screen translation command based on an angle of initial movement of a finger contact with respect to the touch screen display; a two-dimensional screen translation heuristic for determining that the one or more finger contacts correspond to the two-dimensional screen translation command rather than the one-dimensional vertical screen scrolling command based on the angle of initial movement of the finger contact with respect to the touch screen display; and a next item heuristic for determining that the one or more finger contacts correspond to a command to transition from displaying a respective item in a set of items to displaying a next item in the set of items.
But of course, I am not a lawyer.
I'm trying to draw a graph that is indefinitely large horizontally, and the same height as the screen. I've added a UIScrollView, and a subclass of a UIView within it, which implements the -drawRect: method. In the simulator, everything works fine, but on the device, it can't seem to draw the graph after it reaches a certain size.
I'm already caching pretty much everything I can, and basically only calling CGContextAddLineToPoint in the -drawRect: section. I'm only drawing what's visible on the screen. I have a delegate to the UIScrollView which listens for -scrollViewDidScroll: which then tells the graph to redraw itself ([graphView setNeedsDisplay]).
I found one method that tells me to override the +layerClass method and return [CATiledLayer class]. This does allow the graph to actually draw on the device, but it functions very poorly. It's incredibly slow to actually draw, and the fade in that occurs is undesirable.
Any suggestions?
Well, here's my answer: I basically did something similar to how the UITableView works with cells: I have an NSMutableSet of GraphView objects which store unused graphs. When a section of the scroll view becomes visible, I take a graph view from that set (or make a new one if the set is empty). It already had a scrollX property to determine which part of it was supposed to draw. I set the scrollX property to the correct value and, instead of using the screen width, I gave it an arbitrary width to draw. When it goes out of the scroll view, it is removed from the UIScrollView and added to the set.
I wonder though if I really even need to remove them when they go outof the view? It may be prudent to try leaving them in and remove the ones not on screen only if I get a low memory warning? This might get rid of the pause whenever it needs to redraw a section of graph that hasn't changed.
My saving grace here was that my GraphView already was set up to draw only a portion of the graph. All I needed to do then was just make more than one of them.
I think this is a limitation of the iPhone graphics hardware. Through experimentation, I have seen that the iPhone will refuse to draw a frame that is bigger than 2000 pixels in either height or width. It probably has something to do with limited size for frame buffers in hardware.
Watch the 2011 WWDC session video entitled "Session 104 - Advanced Scroll View Techniques".
Thanks, that's helpful. One question -- what did you use for the contentSize of the UIScrollView? Does UIScrollView tolerate large content sizes (over 2000 px) as long as you're not creating buffers to fill the entire space in your content view? Or are you keeping the UIScrollView a constant size (say, 2 screen widths) and resting the UIScrollView contentOffset property each time you draw (using scrollX instead of the contentOffset to store your position)?
I think I answered my own question (the latter seems like a better alternative), heh, but I'll go ahead and post this in case other people need clarification.