I have a MonoTouch OpenGL app that has a bunch of textures. When the user hits the iPhone button to move the app to the background, all my texture data seems to go away. I just see a solid color filling the triangles that I'm drawing with the textures that were loaded originally.
Any new textures that I load after resuming from the background state show up properly. It's just the textures that were loaded before the app was moved to the background that show up solid.
The docs state that "Your application should keep textures, models and other assets in memory" when it is moved to the background. I'm not doing anything to my textures, but something is forcing them out.
Any ideas?
My solution was to not use iPhoneOSGameView. That fixed all problems related to textures disappearing when my app went background. The code to manage the framebuffers and update timer yourself is pretty simple and I found the extra clarity (and working restore-from-background) to be worth the effort.
Not using iPhoneOSGameView also makes me feel better about the application's timer actually running at full speed when the app is active:
Related
I have some assets for my game that are being loaded when the gameplay layer is loaded. I'd prefer to load them when the application launches in a loading screen, which is obviously a pretty standard thing to do.
My problem is the way in which new scenes are launched within cocos2D. Consider the following code which occurs (with some variations) in several places throughout the project:
[[CCDirector sharedDirector] replaceScene:[CCTransitionShrinkGrow transitionWithDuration:0.5f scene:[GameplayLayer scene]]];
This is the standard way of replacing the current scene with a new one. My question is, given that format, how would I pass a preloaded asset to the new GameplayLayer? Is there an accepted way of doing this in cocos2D? I have a feeling that I'm missing something incredibly simple, but as of now it's a mystery to me.
Cocos2d uses a texture cache that persists between scenes. You can preload assets into this cache in a loading scene and they will still be available from your game scene. How you load these are up to you. For images you can opt to do it asynchronously, to allow your loading scene to maintain a decent framerate and render a progress bar.
This post gets the basic idea across.
This thread may also be of use to you in that regard: http://www.cocos2d-iphone.org/forum/topic/2242
If you have your own class of assets (i.e. not a supported cocos2d image, or something), you could create your own cache singleton class (look at how the sharedManager instances of various cocos2d classes are implemented) and load your assets into that. As far as memory management goes you'd have to release those assets yourself whenever you deem necessary, but that's rather beyond the scope of this question.
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 an OpenGL view that renders a 3D model. It is a basic modification on Apples EAGLView. This view is added to a controller's .view and displayed with presentModalViewController: . I would like to do all of the model loading, and OpenGL state configuration in a background thread at app launch before the user chooses to display the view. Is this possible? Can I load textures, setup lighting, and generally just get everything ready to render in a background thread? My fear is that the Cocoa touch portions of the app on the main are going to manipulate the OpenGL state while I am setting up my renderer in the background. The controller will be displayed from the main thread of course. This level of understanding of OpenGl-ES is not something I deal with often, so please be gentile if my question is strange in any way :)
You absolutely can do background loading on a thread. Some of the key points:
- There is probably not much of a win to moving OGL state setup to a background thread - the total amount of change you'd induce in a context before the start of the first draw doesn't add up to a ton of time. Background loading is useful for textures and VBOs, as well as the load time that has to happen first to get the data to feed to the GL.
- You'll need to detach the context from the main thread and move it to the worker thread. We do this using pthreads to "send" the context to the worker.
- In our use, we hide the GL view to ensure that it doesn't need to be drawn while in a load state. (Frankly during load it may not contain anything useful.) So during async load the visible UI is all non-GL Cocoa.
This approach is more difficult than what you would do on the desktop: simply share the objects in two contexts (so that you can load and draw at the same time). When we looked at that approach more than a year ago, it wasn't possible on IOS; it may be possible now, I do not know.
I've heard that OpenGL ES and standard iPhone UI controls don't play well together, but I'm wondering if anyone knows why, and what the effects are? I'm writing an OpenGL based game, and the view is loaded from a nib file with ui controls, and it seems to work ok, but the game is really simple at this point... does using ui controls cause some kind of performance hit?
UI events momentarily pause timers, like when scrolling a tableview. You can get around this by using the common runtime mode when creating a timer. It may slow down your rendering if you have a lot of layers because they all need to get redrawn every-time you refresh. So if your game runs at 60fps it will also redraw everything on top of the GLView, like UIImageViews, buttons etc. 60 times a second, which is a huge waste. It might not make a huge impact on your frame rate but it may make the device run hotter and drain the battery faster. Its best to draw your HUD using OpenGL, but it depends on the situation. For something that will be displayed only for a short time, like a menu I think you can get away with it.
Theres nothing wrong with it, its just wasteful.
I'm making an openGL game for iPod/iPhone.
At start I load at once all the textures I need. At first loading times where small, but as I kept developing and adding new textures the loading times have been increasing, to the point of taking many seconds before the game start.
Recently a new problem appeared, when I build the game in the device It takes too long and the game quits. At the app is installed correctly and i can test It, but never while being connected to xcode. Sometimes even the app quits, when too many elements are dran on screen.
Right now I use 6 files , with about 2 Mbs of size in total.
Is there a form to create a loading screenor the such ?
What other meassures can I take so solve this issues ?
If you're decoding PNG files at startup using Core Graphics, I would suggest using PVRTexTool to create PVR data files instead. The contents of PVR files can be uploaded directly to OpenGL; no need to use Core Graphics to decode them.
PVRTexTool can also do neat stuff like generate mipmaps (another thing you might want to avoid at startup time) and encode to compressed formats (reducing your texture size will help too).
Besides encoding your textures as PVR-textures there are a few more solutions.
One is to defer texture loading to a later point. Let your app bring up its user interface and maybe show a progress bar to the user while you're loading your textures. This will stop iPhoneOS from killing your app.
You'll probably also need to look into what kind of textures you are creating. Some formats are much more expensive than others to create from you png:s.
As a last resort you could save your textures as uncompressed raw textures. This will make your app larger but cut down loading time.