I recently created an app in flash cs6 to be used on my iPhone 4.
The app doesnt need to work through the app store its just a tech demo but when i put the app on my device all the animations become really slow/choppy.
My iPhones up to date and im using air3.2 (i did try updating to air 3.7 but then my application just became a white screen)
I have also tried cacheing all the movie clips as bitmaps bit it doesnt seem to make a difference.
(the app works fine inside the flash simulator)
please help?!
There could be a few reasons why this is happening,as I am taking a punt here as you havent gave much information on what your doing.
but your frame rate may have effect.. how are you creating your tweens?timeline animation or tween scripts.I found tween scripting works better as its distance over time opposed to distance over frames.
Also depending on your animation, images sizes, event listeners etc..
You need to take inconsideration your device itself and the resources it has available, free memory or actual storage available.
The reason it will work freely on your PC would be due to the fact of less limitations, your pc has more to computes and resources to throw at your application .
Add this line to your code to check your memory:
import flash.filesystem.File;
this.addEventListener(Event.ENTER_FRAME,performMemTest);
function performMemTest(e:Event):void {
trace(System.totalMemory);
}
I have read anywhere around 14MB++you may experience problems.
Related
I currently work on a 2D project on Unity (for mobiles/tablets), where I download a few heavy pictures by using UnityWebRequestTexture.GetTexture(url), which I then store using File.WriteAllBytes(filePath, webRequest.downloadHandler.data).
Later in the project, I need to show the downloaded picture on a RawImage element. To avoid blocking the app I read the bytes via FileStream on a separate Thread, which works well.
But when I call (from the main thread) ((Texture2D) myRawImage.texture).LoadImage(loadedBytes), my Profiler shows a huge peak, and if most devices handle it correctly, on iPad Mini I often get a MemoryWarning at this very point. Which, when repeated, leads to the app being forced close by iOS.
For info, the downloaded image's size vary depending on the device asking it. We initially intended to display 2048x1536 pictures that way on iPad Mini, but we were getting MemoryWarning on each display. We're now using 750x1334, but we still get MemoryWarning from time to time.
My question then is : is there a better way to do the "LoadImage" step ? I believe that the conversion from byte[] to Texture2D is where my memory problem lies, but I didn't find any workaround to this.
Or eventually: Is there a better way to download/store the image? If the image was in the app's resources from the beginning, I don't seem to have any trouble displaying it on the same device. Maybe there is a way to download the texture while applying it the same compression algorithm that assets receive when building an app ?
Using Texture2D.Compress() after loading the texture compresses the texture by at least 90%.
Reference
I am developing iphone application similar to the Talking Larry Application. I am facing an issue of Low Memory when i pre-load the animations into an NSMutable Array. If i do not pre-load the animations and load it into the Animation Images when the user touch the button then it takes Time and it play back the animation very Slow. And during video making it does not play the complete animations. How can i resolve this issue. I want to play back the animations similar to the Talking Larry app and do not want to get Low Memory Issue.
You have to “juggle” the images, freeing those that are not needed and preload those that will be needed soon. The trick is probably preloading a decent number of images beforehand, so that the animation does not slow down when started. You have to experiment to get the right numbers.
And of course, it also depends on the image resolution. I don’t know Talking Larry, but if you are trying to animate full-resolution retina images, it might be too much for the machine.
I'm about to finish an app and now I wanted to add an animated splash screen with my company logo after the app finishes loading and launching. I can just use an animation with openGL for this, but I was wondering if it would be better to use a video..it's easier for me and the artist because he will only provide with an small video which i would reproduce after my app finish launching..less work.
I wonder if it's a good idea to do so...can I reproduce a small short video with the logo of my company or should i stick to making an animation ?
Also, reproducing video is memory intensive ?, because I'm loading some texture after my app finishes launching, and im wrried about that.
If i end up reproducing an small video, can i make it non interactive ? ( no pause, play stop, ect) so it looks like just as another animation to the eyes of the user ?
My other preocupation is quality...the quality of the video will look dramatically different to my animations in openGL ?
Thanks !
I can't tell you about the technical stuff, but what I can tell you is: don't use a splash screen. Directly from the Human Interface Guidelines:
Supply a launch image to improve user experience; avoid using it as an opportunity to provide:
• An “application entry experience,” such as a splash screen
...
Because users are likely to switch among applications frequently, you should make every effort to cut launch time to a minimum, and you should design a launch image that downplays the experience rather than drawing attention to it.
The HIG guidelines are intended (as far as I can tell) for Apps on the iPhone.
This is different from Games on the iPhone.
If your app provides some utility to the user, I agree completely with #Costique, #fabian789, and the HIG. The app should start instantly, with minimal loading and other distracting crap.
For a game, however, intros and the like are not only expected, but can also lead to a better user experience. My recommendation is to use a UIView Animation for only a small portion of the screen (the logo only). See Angry Birds as an example - their "animation" starts the same time the user's options do, so your animation (while quite pretty) doesn't block the user from using your app.
Disclaimer: the following is an entirely subjective humble user opinion. Please, don't take it to heart.
I hate video splash screens on my iPhone/iPad, however beautiful and stylish. What I like is apps which launch instantaneously. On iOS 4 chances are, I will see the startup animation once a month when the OS decides to terminate your app when the device is low on memory. So, now I tap the app icon and see the animation, now I tap it and don't (because it's already launched). It's inconsistent, out of your (and my) control, and ultimately makes little sense.
From both quality and aesthetics points of view, I think GL animation would better fit (hopefully) intense addictive action which follows. I'm not sure, however, that you will be able to load any resources in the background, while the animation plays, without making the animation stutter.
I have a game that runs fine as is (around 30fps), but fps went down the drain when I tried to implement ads. I tried Greystripe and iAds but with same result (iAds were maybe bit worse). Average fps is almost same, but there are huge spikes all the times (1-2 spikes per second) and game is unplayable.
I guess it is because ad is in another view. I read somewhere that opengl apps on iphone don't like having another views with them, but there is plenty of games with ads on app store. How do they do it?
My implementation should be ok. I did everything as documentation and samples told me. I have my opengl view and ad view as subviews in app window, adview being in front of opengl view and thus covering part of it. Could this be the problem? Is it better to make opengl view smaller to left space for ad so they don't overlap? Do you have any other ideas what could be wrong?
Lope, I've created a gist at this link with a singleton "AdManager" class I wrote to handle iAds using cocos2d. Cocos2d sits on top of OpenGL, of course, and I've found that this code doesn't affect FPS even for relatively complicated games.
You'll have to modify this a bit to work with your application, changing out the cocos2d calls, etc, but this will give you asynchronous loading of iAds, which should help the FPS issue.
To use this class, include its header and call
[[AdManager sharedManager] attachAdToView:self.view];
wherever you need iAds. The ads will remain hidden until an ad loads, at which time they'll pop up at the top of screen. (The class works for iOS 4.0, 4.1 and 4.2).
Also, I should add that I have cocos2d running inside of an overall UIViewController that I call "Cocos2DController". When I attach the ads to a cocos2d view, I'm using
[[AdManager sharedManager] attachAdToView:[[CCDirector sharedDirector] openGLView]];
Best of luck!
We can hit and miss with apple's choices, but go for the sure thing and implement the ads in other parts to be appealing and not intrusive. It will be better for the framerate, and for you.
Try downloading the ads in a seperate, low priority, thread. You can, thus, nsure that the ads loading does not take too much CPU time. With a bit of CPU synchronisation you can make sure you don't try to display the new ad until it is completely ready to display. Sure it will suck some CPU time away from what you are trying to do but set your priorities right and it should only suck time when you are busy doing nothing.
Please excuse the thread necro'ing here, but I've used Stack Overflow a lot to help me through the problems I've had during coding, and thought my experience might be useful to someone in the future.
My simple cocos2d game ran with decent FPS (rarely changed the FPS display at all) until I implemented AdWhirl (integrating AdMob + iAd only). It would then run OK for the first few iterations, but upon upon the 9th or 10th scene refresh (single screen game, time in each scene < 5 seconds on average) the FPS would dive to ~20FPS, and drop again each time the scene refreshed.
Turns out, in my n00biness (this may be particular to me :) ), I was calling the scene from within itself. That is, once the actions had finished, the last action was to call the main scene again (a lazy way of rebuilding the scene for the user to have another go). This init'd the views and view controllers I had inserted to handle the AdWhirl ads all over again, and not only did I have a memory leak, I had 10+ view controllers all trying to request and service ads from AdWhirl. Once I got a clue and took that self-referring loop out, all was good.
Does anyone know what will happen with existing apps when they run on the iPhone 4.0 in terms of the new screen resolution? I am assuming, just like developing for the iPad that there should be no hard coded screen resolutions in your code.
I'd also like advice on the best way of writing robust code to work well on any device. For instance, detecting the screen resolution is not enough - on the iPad the screen is physically bigger so you can display more items on it. On the new iPhone the screen is the same physical size but higher resolution, so the likely thing is that you wont want to display more items, just higher resolution versions of them.
Any help would be useful,
Regards
Dave
EDIT: I have read the other similar posts, I guess what I really would like to know is what is the recommended way to write code for all App Store devices in a robust way so they a) all work b) make best use of the device.
UIKit has be redesigned so that old apps just work unmodified in the iPhone 4. There are then several things you can do, some programmatic and some by just adding higher resolution images to you app bundle.
Firstly, and most simply you can include new double res images that are used by your app with a suffix of #2x in the name. i.e., Event.png as well as Event#2x.png. [UIImage ImageNamed:] will automatically look for the a file with this suffix if it is running at the higher res.
All the other UIKit stuff now uses points instead of pixels. So for both old and new apps full screen is still 320 x 480 points. This pretty much means everything will work including touches, etc. Although they may now return fractions of a point.
The only real gotcha so far seems to be if you use CGBitmapContextCreate as this uses pixels and requires some jiggery - pokery.