This is for Unity3D 4.3+
I have a ridiculously large background I wish to use for a 2D scroller game. The background is 10 times the width of a landscape device (10240 x 1024). (The basic loop background goes behind that and is not an issue.)
I understand I can cut the background into 10 images of 1024 x 1024 each (basic sprites). But, I'm unsure of the best approach to go forward...
One way is to pre-load all the background sprites and then do a simple scrolling of them all. But take too much memory.
However, keeping in mind this is aimed for mobiles and tablets, isn't possible to do a loading/offloading of the background as the player progresses? Like this: Initially load 2 background images (bg-1 and bg-2).
Once the camera has passed bg-1, the unload bg-1 and load bg-3. Then when player passes bg-2, then offload bg-2 and load bg-4 and repeat. Thus only 2 bg images loaded at a time.
The player can not go backwards, so that helps me in this scenario.
Any thoughts on the best approach?
Thank you.
You can use Resources.Load function to load assets dynamically(link). Or just load them all in a list and reference from there.
Related
I want to port a game I've made which renders the screen itself 50 fps (doesn't use opengl).
What is the best way to port this to the iPhone?
I was reading about Framebuffer Objects. Is this a good approach to render a buffer of pixels to the screen at high speeds?
The fastest way to get pixels on the screen is via OpenGL.
Need more info about how your game currently renders to the screen, but I don't see how FBOs will help as they're usually used for getting a copy of the render buffer, i.e. for creating a screen recording, or compositing custom textures on fly.
If i ever need to create an app where I have to access the pixels directly and dont have direct access to the hardware I use SDL as it just requires you to create a surface and from there you can manipulate the pixels directly. and as far as im aware you can use SDL on the Iphone, maybe even accelerate it using opengl too
I have created a project .
and there are three groups of images need to display , and every group has 5 images .
In the app , the image will be changed once per 0.2 seconds .
and the size of the image is only 30*30 , so there are about 80 images on screen , they all have the animation .
But when I test this , I feel the fps seems become 0.8 seconds , it was very slow .
All the images are drawn in ONE UIView . I use [image drawInRect:] in the method -(void)drawRect .
So is there any suggestions for me to make the fps more faster ?
Have you tried putting 80 UIImageViews on the screen? If you only set the new image on each of these when required, you should see an improvement.
The reason is that each UIView has its own CALayer, which is copied to the graphics memory when required. It's quite slow to copy across a pixel (but once it's there it's cached), so if you only update one 30x30 tile at a time you should see better performance than if you were constantly updating the screen.
You could of course manually manage 80 CALayers within a single UIView but that would be much more difficult than using 80 UIImageViews.
Any time you override -(void)drawRect you're likely to hurt performance a lot, because of the way CALayers interact with graphics memory. The iPhone's Quartz graphics system is optimised for having lots of static layers than can then be manipulated with graphics commands (transform, opacity etc).
Profile. Use the Instruments application to find out which part of your code is running slowest, and then see whether you can either speed it up or avoid calling it so often. For example: do you really need to re-draw all of the images all of the time? Could you replace some Cocoa Touch code with the same behaviour using Core Animation or OpenGL ES?
Iterate. Once you've made a tweak, profile again. Did it get better? If it did, then look for the next thing to speed up. If it didn't, decide whether it's at all helpful or should be reverted.
well, every time you draw something... it's a work... you probably can get better performances just loading all your images at the beginning and then just swap them on screen (with hide/show your UIImageView), if images are so small you won't have memory problems...
Im working on an iphone platforms game developed using cocos2d and box2d which has to use a very large image as a background, my question is this:
-which is the better way to load the image?? (I'm talking about an image which can be 14K pixels long), is it better to cut in smaller images an keep loading them as the player moves??
-Should I keep in memory as invisible or use the addChild method to load them as I need them and the removeChild to remove the previous one?
Thanks in advance, any answer will be welcome :)
You can't use textures larger then 1024x1024 or 2048x2048 for iphone/ipod 4 (maybe iPad too). So the only way to render such big image is rendering it's parts.
I would try to load the parts as the player moves (better in a separate thread).
Also maybe it is possible for you to use Parallax background. If so - use it.
If your image is made from a lot of identical parts then it's a good idea to use CCTMXTiledMap.
I have a problem when try to load the big animation with about 54 images (320x480 each image) into CCSpriteFrameCache, I can't use plist for this. How can I make the animation work? At this time, my animation can't work on iPhone 2G, 3G, and iPod.
Thank for your help,
John
You won´t be able to do it...
Consider playing a video or just animating an small portion of the screen.
Your best bet is to determine why the animation has 54 images that are all the width/height of the screen. This is an unnecessary number of images.
Break the animation down:
Is the background 'static' (does it move around, change constantly, etc?)
If it moves around a bit, but is really part of a much larger "canvas" then simply export out the entire background canvas and perform the movements yourself using the Cocos2D Actions available to you (CCMoveTo, CCJumpTo, CCDelayTime, CCSequence, etc)
What in the animation moves around, and how does it move around?
Can it be broken into much smaller bits and the frames for the various "characters"
or "movable objects" within the scene be exported out onto a sprite sheet (saved out
via Zwoptex?)
A good animation sequence should be a series of much smaller images, all working together in unison to create the final "animation sequence".
If you break it down, I wouldn't be surprised if you were able to reduce your 54 images at 320x480 each down to a handful of 512x512 spritesheets (ala Zwoptex).
If your having trouble breaking it down, I would be available to look at the final animation and help you determine what could be minimized to reduce the overhead.
I'm developing a 2D game for the iPhone using OpenGL ES and I'd like to use a 320x480 bitmapped image as a persistent background.
My first thought was to create a 320x480 quad and then map a texture onto it that represents the background. So... I created a 512x512 texture with a 320x480 image on it. Then I mapped that to the 320x480 quad.
I draw this background every frame and then draw animated sprites on top of it. This works fine except that the drawing of all of these objects (background + sprites) is too slow.
I did some testing and discovered that my slowdown is in the pixel pipeline. Not surprisingly, the large background image is the main culprit. To prove this, I removed the background draw and everything else rendered very fast.
I am looking for advice on how to keep my background and also improve performance.
Here's some more info:
1) I am currently testing on the Simulator (still waiting on Apple for the license)
2) The background is a PVR texture squeezed down to 128k
3) I had hoped that there might be a way to cache this background into a color buffer but haven't had any luck with that. that may be due to my inexperience with OpenGL ES or it just might be a stupid idea that won't work :)
4) I realize that the entire background does not always have to refresh, just the parts that have been drawn over by the moving sprites. I started to look into techniques for refreshing (as necessary) parts of the the background either as separate textures or with a scissor box, however this seems less than elegant.
Any tips/advice would be greatly appreciated...
Thank you.
Do not do performance testing on the simulator. Ever!
The differences to the real hardware are huge. In both directions.
If you draw the background every frame:
Do not clear the framebuffer. The background will overdraw the whole thing anyway.
Do you really need a background texture ?
What about using a color gradient via vertex colors ?
Try using the 2bit mode for the texture.
Turn of all render steps that you do not need for the background.
E.g.: Lighting, Blending, Depth-Test, ...
If you could post some of your drawing code it would be a lot easier to help you.
If you're making a 2D game, is there any reason you aren't using an existing library? Specifically, the cocos2d for iPhone may be worth your time. I can't answer your question about how to fix the issue doing it all yourself, but I can say that I've done exactly what you're talking about (having one full screen background with sprites on top) with cocos2d and it works great. (Assuming 60 fps is fast enough for you.) You may have your reasons for doing it yourself, but if you can, I would highly suggest at least doing a quick prototype with cocos2d and seeing if that doesn't help you along. (Details and source for the iPhone version are here: http://code.google.com/p/cocos2d-iphone/)
Thanks to everyone who provided info on this. All of the advice helped out in one way or another.
However, I wanted to make it clear that the main issue here turned out to be the behavior of simulator itself (as implied by Andreas in his response). Once I was able to get the application on the device, it performed much, much better. I mention this because, prior to developing my game, I had seen a lot of posts that indicated that the device was much slower than the simulator. This might be true in some instances (e.g. general application logic) but in my experience, animation (particularly 3d transformations) are much faster on the device.
I dont have much experience with OpenGL ES, but this problem occurs generally.
Your idea about the 'color buffer' is good intuition, essentially you want to be storing your background as a frame buffer and loading it directly onto your rendering buffer before drawing the foreground.
In OpenGL this is fairly straight forward with Frame Buffer Objects (FBO's). Unfortunatly I dont think OpenGL ES supports them, but it might give you somewhere to start looking.
you may want to try using VBOs (Vertex Buffer Objects) and see if that speeds up things. Tutorial is here
In addition, I just saw, that since OpenGL ES v1.1, there is a function called glDrawTex (Draw Texture) that is designed for
fast rendering of background paintings, bitmapped font glyphs, and 2D framing elements in games
You could use frame buffer objects similar to the GLPaint example from Apple.
Use a texture atlas to minimize the number of draw calls you make. You can use glTexCoordPointer for setting your texture coordinates that maps each image to its correct position. Remember to set your vertex buffer too. Ideally one draw call will render your entire 2D scene.
Avoid enabling/disabling states where possible.