I recently chose to switch to a method where my library is totally empty and I embed every image/animation/sound that I need via the Embed tag because it would make my life easier. Having a lot of symbols in my library causes CS5 to run extremely slowly and it was really annoying me.
This was totally fine for making games for computers but I'm currently working on my first iPhone game and I'm noticing that the game starts lagging after a few seconds of play. It's not even a complex game but it does have a lot of images with transparency. So I'm wondering if it would run faster if I forget about the empty library method. I don't really know how that would affect performance but this is the first time that I have to worry about performance. But I am aware of other things that affect performance like transparency and object pooling (just read about this one).
Also the exact same game runs worse on an iPad even though it's a more powerful device?
Having images in your library means that Flash will compress them when it exports the SWF/SWC. This may or may not be desirable.
Using the [Embed] tag means that you can compress them yourself in something like Photoshop and have complete control over the output.
You say that your "game starts lagging after a few seconds of play". This seems to be a memory/design problem rather than whether or not your images are embedded through code or as library symbols. Do some profiling to see where you're spending most of your time, and to check that you don't have a memory leak.
Both using the library and the [Embed] metatags influence performance of your IDE, but they are evaluated at compile time and will produce just about the same byte code.
The performance of your game at runtime is an entirely different issue, though you might be able to get good results by rethinking which images to embed as bitmaps and which to use as vector sprites, how to organize larger images (e.g. creating one basic player sprite and adding individual looks by composition, instead of making each player variation a full sized animation) and trying to reduce the use of transparency and alpha masks.
There are many good articles about improving ActionScript performance both on the AVM2 and on iOS devices. Try searching for "ActionScript optimization runtime" - it should yield plenty of results.
Related
I'm working on an iPhone App where I rely heavily on timers and animations, but I've realized my game is really slowing down and lagging on certain aspects of the game. I'm not quite sure how to improve this without removing any animations or anything.
Essentially what I'm using is the accelerometer to update my character's position (Left/Right). I also use several timers to read from different URLs, update images and the one that lags the most is one that loops an image to move from left to right.
Basically I'm using about 6 or 7 timers and the Accelerometer, is there a way I can improve the performance of my game without having to remove any of my animations or changing the interval of the timers?
Thanks in advance!
Try use Allocation
RUN-> RUN WITH PERFORMANCE TOOLS->Allocation
to see which part is overload in the application
Instead of using NSTimer to animate, you might want to look at using the animationImages property in UIImageView (which lets you show multiple frames of animation, possibly looping) or beginAnimations within UIView (which lets you move an object along a path, among other things).
A good place to start is with this question on recommend reading for iPhone animation, although for reference the documentation in XCode and Apple's programming guides are good sources by themselves.
What others have suggested - in terms of using a game loop - make sense, too, but depending on the complexity of your game, sometimes just letting the iOS SDK take care of your animations for you can be good enough.
I'm currently using this method from Apple to take screenshots of my OpenGL ES iPhone game. The screenshots look great. However taking a screenshot causes a small stutter in the game play (which otherwise runs smoothly at 60 fps). How can I modify the method from Apple to take lower quality screenshots (hence eliminating the stutter caused by taking the screenshot)?
Edit #1: the end goal is to create a video of the game play using AVAssetWriter. Perhaps there's a more efficient way to generate the CVPixelBuffers referenced in this SO post.
What is the purpose of the recording?
If you want to replay a sequence on the device you can look into saving the object positions etc instead and redraw the sequence in 3D. This also makes it possible to replay sequences from other view positions.
If you want to show the game play on i.e. youtube or other you can look into recording the game play with another device/camera or record some game play running in the simulator using some screen capture software as ScreenFlow.
The Apple method uses glReadPixels() which just pulls all the data across from the display buffer, and probably triggers sync barriers, etc, between GPU and CPU. You can't make that part faster or lower resolution.
Are you doing this to create a one-off video? Or are you wanting the user to be able to trigger this behavior in the production code? If the former, you could do all sorts of trickery to speed it up-- render to a smaller size for everything, don't present at all and just capture frames based on a recording of the input data running into the game, or other such tricks, or going even further run that whole simulation at half speed to get all the frames.
I'm less helpful if you need an actual in-game function for this. Perhaps someone else will be.
If all else fails.
Get one of these
http://store.apple.com/us/product/MC748ZM/A
And then convert that composite video to digital through some sort of external device.
I've done this when I converted vhs movies to dvd a long time ago.
I was wondering if there is a difference between using .xib files for GUI design and doing this programmatically.
As it is a compiler I would assume that there is no relevant time lost.
Am I wrong?
(Note: Tapping this out on my phone, so I apologize ahead of time for any weird formatting or grammar - if there are issues, I'll fix them when I'm back at my laptop.)
I've done some quick, dirty, and extremely informal tests to check this out for myself, and here's what I found (note that the app I built for the tests was just scratch and not necessarily representative of a "real" app):
Startup time was faster when when the initial screen was a nib
For all subsequent screens, performance increased when coding the UI by hand
It's odd at first, but when you think about it, maybe it isn't really all that strange.
The startup issue confuses me, but I assume it's because Apple, being Apple and being obsessed with startup times (in a good way, of course), just optimized the phone's unarchiver in such a way that loading from an archive (nib) can be faster than coding by hand.
That said, most people write apps that aren't going to be significantly affected by any differences. My (again: quick and dirty) tests showed that, from a cold start (you haven't run the app yet or in a while), the nib-based app consistently loaded its initial screen about twice as fast as the hand-coded version. While that sounds like a big deal, we're talking just a few milliseconds. That difference will be imperceptible to users. For a warm start (you've already opened and closed the app), the differences for startup time were much smaller.
For this reason, I like to use nibs for laying out the foundation of an app: any top-level navigation (tab controllers, nav controllers, etc.), and then code the rest of the UI by hand.
Plus, because the iPhone UI is so specific to, well, the iPhone (surprise!), coding UIs by hand isn't difficult the way it is when writing desktop apps. You use the same UI components over and over - once you've got that down, whipping up a UI in code is easy. You don't have eight-billion widgets to choose from as you would developing a Windows/OS X/whatever application. The iPhone's consistency makes it the easiest platform I've developed against in ages when it comes to hand coding UIs.
I've also found that NSCoding (which is what I use for persisting state across app runs) is much easier to work with when I've hand-coded a UI. I've run into problems where a nib-based screen wouldn't properly archive because of UIImage instances. UIImage (at least the last time I checked) doesn't conform to NSCoding, so the archive process dies (and a rather unpleasant death it is). I used UIImage as an example here, but anything the archiver tries to store that doesn't conform to NSCoding is going to foul up the process, so that's something to think about.
Another time I always code UIs by hand is whenever I'm using a dynamic table. If I'm creating a static table - one whose cells will basically never change - nibs are fine. For any other kind of table, and especially those that have, say, thumbnails and other resource-intensive bits, the control I get when coding by hand makes it possible to get performance you aren't going to get with nib-based table cells. For that, you do have to skip CocoaTouch and work directly with CoreGraphics, but the performance improvements you can make are worth every last line of code you have to write. For examples of table performance from projects I've worked on, see the Barnes and Noble Store (not the ebook reader) and Style.com. We built a framework for those (and other) apps, and the secret to the smooth table scrolling is that we never once used cells loaded from nibs (it's more complex than that, but skipping nibs was the first step to getting the performance you'll see in those apps).
Generally speaking, possibly the most important thing to consider when using nibs is that you need to break your UI up across files. That is, don't stick your app's entire UI into a single nib. When a nib is being loaded, it's the whole thing - there might be a view in the nib your users will rarely, if ever, see, and those get loaded just like everything else, sucking up resources for no reason. If you don't use separate nibs for each of your app's screens, it's easy to run into memory and performance issues.
To further clarify: if you have an app with five view controllers, stick each controller in its own nib. You don't want to load anything until its needed. There are exceptions to this, but that's simply how coding is - given enough time, you'll find a reason to do something "the wrong way," but the a-nib-for-each-screen approach is the way you ought to be doing it unless you have a good reason not to.
I'll leave it there - I hope it helps a little.
Just remember:
My informal mucking around showed that startup was faster with a nib (as long as you keep the nib as simple as possible, keeping only what you need in it).
After startup, performance seemed to improve for hand-coded UIs.
If done correctly, and if you aren't writing a game or something, nibs shouldn't result in perceptible performance issues.
In my experience, tables are different - they're one place I will rarely use nibs.
If you're using NSCoding for persisting app state, nibs can be problematic, and any workarounds probably aren't worth the effort since coding iPhone UIs by hand is relatively easy.
Keep your nibs as simple as possible - I can't say this enough. Wherever possible, create a nib for each screen of your app rather than stuffing your entire app's UI into a single nib.
Ok. Stopping for real this time.
Hope this helps :)
Very little. There are some exceptions. For example, if you use a xib to load the image that goes into a UITableViewCell, then that could be a problem since UITableViews with many cells are sensitive to loading times. However, for all intents and purposes, there should be no noticeable performance hit.
The information in the xib does have to be decoded at runtime and loaded into memory, which is not as fast as just creating UI elements programmatically and directly.
Beware premature optimization, especially when it involves writing a great deal more code than you need to.
Specs: about 320 x 270 px, 5 seconds. I don't know exactly how many images needed for a fluid animation, but let's assume 30.
What would be the best way to playback this? As a movie file in some kind of quicktime view (if available), or as an animated image sequence with UIImageView? I'm not sure but I believe loading 30 images per second is nearby impossible on the ipod touch. Any idea?
In general, a movie will have applied some compression and possibly even used a lossy compression. This means the processor would need to work harder but it has a lot less memory to read. The CPU is a fast resource. Compared to the CPU, memory is slow. Thus a compressed movie would (logically) have the better performance.
In practice, it could depend on a lot of factors, although movies do tend to be better optimized for animations. With a slow CPU and extremely fast memory, a multi-image animation might just be faster. Also, it depends on how you store those many images. But in 99% of all situations, movies will have better performance.
Well, I guess it depends.... if it supposed to be static, than a movie is the most appropriate way... it's hardware accelerated, and easy to write the code for using it. If you plan to modify the animation, and reuse it, you could load and modify images, or load a bunch of them in succession, but I imagine it's quite coding overkill for the task.
Why would you not want to use a video file? If you don't have very specific reasons, I would recommend just using the standard video playback functions provided by Apple.
This gives you several advantages:
Even if your proposed method would run fluidly, it certainly wouldn't be as well optimised for the graphics chip and therefore use up more battery
It's very easy to implement, whereas your idea would be rather complicated, and you'd spend a lot of time on a probably less important part of your app.
It's won't introduce any new bugs and is most likely a lot better tested than your custom solution.
Check out this to get started:
http://developer.apple.com/iphone/library/navigation/index.html?section=Topics&topic=Audio%20%26amp%3B%20Video
Is that an very cost-intensive function that sucky my performance away under my feet? I guess they used that one for the waggling buttons on the home screen + core animation. I just want to know before I start wasting my time ;)
Seems unlikely that it'd be much of a performance problem - it works out to something like a Cosine, a Sine, and a few multiplications. Don't call it thousands of times a second, and you'll be fine.
Very (very) little. This is also something you can easily measure yourself; see the following URLs for examples/information on implementing high-resolution timing:
http://developer.apple.com/qa/qa2004/qa1398.html
http://code.google.com/p/plinstrument/source/browse/trunk/Source/PLInstrumentTime.h
http://code.google.com/p/plinstrument/source/browse/trunk/Source/PLInstrumentTime.m
http://code.google.com/p/plinstrument/
Like with everything, it depends on how and how much you use it. It's used all the time in game development, which the iPhone is very well suited for. CoreAnimation is also very fast. If you're worried about it, my suggestion is to take one of the Apple-provided sample apps and run it through Instruments to preform some of your own benchmarks to see if they are acceptable for your needs.
All CGAffineTransformMakeRotation() does is fill in the matrix for a regular old CGAffineTransform. If you think you can fill (or pre-fill) the matrix faster yourself, then go for it (I'd be really surprised if this wasn't super-optimized already).
Then when it comes time to do the actual work of applying the transform, I'm pretty sure the GPU is told to take care of it so it'll run fast and your main CPU shouldn't take too much of a hit.
If you're really worried about it, then do the transforms in 2D space on top of OpenGL to make sure it's hardware optimized.
I just want to know before I start wasting my time
Optimise the system not the individual lines. Who knows how many times your code will call the transform. Better to get the whole system working, profile it and then optimise the parts that are too slow.
Don't worry about individual calls that people tell you are slow. Use this information as a pointer if your code is slow but always see how the operate in your code.