Guys. I'm writing a scrolling shooter game that has a very large Background image chopped up into smaller images to make it more manageable. Right now it is setup so when the GameNode is init'd. A big long list of Images are added to the ParallaxNode and it is added to the Game.
I thought I might save a lot of memory if I only kept one or two loaded into memory and swap them out as the Hero Character moves through the level. The problem is I can't seem to create a parallax background in another method that's called later. No errors it just doesn't show and seems to be the same code. Any Ideas?
Well I created the parallax layer having four layers in it and added it to the level layer which is extending from GameNode.
If you can post some code, that may help.
Related
I want to make an endless vertical scrolling layer that gives the impression that the main character is moving upwards. I have been brainstorming on how to achieve this.
My issue is that I want objects to appear as if they are coming from above and below the screen at the same time. Secondly, I want to be able to move the main character to create and destroy box2d joints between it and some of the objects appearing on the screen. What is the best way to achieve this with consuming too much memory? I would appreciate any help on this.
Apple did a wonderful tutorial of this in a WWDC 2011 video session. It was "UITableView Changes, Tips & Tricks" and it's about 35m40sec into the video.
Since the use of the UITableView is really just a UIScrollView for the purposes of the background, you could just use a UIScrollView and you can either have it move on timer or events as needed.
Think of your player as moving within a stationary bounding box. The background can scroll using the aforementioned pooling method (as the background tile scrolls off the screen it is placed into a pool, and before a new tile is instantiated the pool is checked for available reusable tiles). Thirdly, your enemy objects will simply approach from either the bottom of the screen or the top.
Imagine your idea without the scrolling background (flying effect) and you should find that the problem is relatively straightforward.
I also needed and endless scrolling background layer. This can do exactly that, and it is super simple to set up and use. Just copy the four files in to the cocos2d folder in your project, then follow the quick tutorial seen on the github. Make sure the image you use is seamless (when you line them up vertically you can't tell where one ends.
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'm making an iPhone game and using UIView objects to draw sprites. Most of the time, I have no performance problems. However, once I have around 15 to 20 objects on the screen (and maybe 5 of them moving around), the game becomes considerably slower, especially on the iPhone 3G. The frame rate can drop to as low as a single frame per second.
Is this simply a limitation of using UIView objects, or should iOS be able to handle this many UIView objects on screen at the same time?
In order to isolate the problem, I've made drawing my views very simple — drawing a red rectangle. drawRect is only getting called once per view. The view hierarchy is very simple and shallow. I'm using CADisplayLink to update the UIView locations every frame.
There's very little else going on, so I'd like to hear if anyone else has had success using this number of UIView objects.
The key to my problems ended up being that I had labels on top of my game content. The labels are not opaque, which likely was a large part of the problem, as phix23 suggested.
The first thing that made a big difference was removing a frames per second label that was on top of the content. Having a label that changed content on every frame caused a lot of slowdown.
I also had a large label that displayed on top of much of the game and changed shape when you level up. It turned out that drawing this label on top of everything caused a lot of slowdown as well.
In answer to my original question, I've found that on an iPhone 3G I can support about 30-40 opaque UIViews onscreen at the same time, with 2 or 3 non-opaque views as well. Non-opaque UIViews that change size, shape, or location are by far the worst, and even one of these that covers a significant amount of the screen can quickly cause problems.
If you're setting the opaque property of each view to NO, keep in mind that this seriously affects the speed of drawing the views. If your views aren't transparent, you should leave this set to YES, which is default.
for such type of application you should use CoreGraphics / Quartz / OpenGL but anyway I don't think there is a limitation on such low count. For example if I have a table view with 9 rows and each row has 5 subviews its still displayed acceptable fast. Have you tried using UIView animation to change the position in view?
good luck in learning OpenGL ;)
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 have a sprite which i animate using CCAnimate. the animation is composed of 4 spritesheets that i swap when needed. everything works pretty good except for some flickering when swapping spritesheets.
any ideas on what to do?
i've found a solution in case anyone is interested.
it seems theres a lag when switching between CCAnimation objects, that make the frame be blank for a split second. the solution is to manually set the sprite to the first frame of the coming animation immediately after ditching the old one.
more info here:
http://www.cocos2d-iphone.org/forum/topic/8729
Do you preload the spritesheets using CCTextureCache's addImage? If not, you'll notice a lag whenever you switch to a spritesheet for the first time.
Also, unless your spritesheets are so big that you can't fit all animations into a 1024x1024 texture you should simply put all of the sprites into one sheet, instead of using multiple like for example four 256x256 spritesheets. You hardly gain anything from doing that, at worst you lose the benefit of spritesheets because as soon as you render from two different spritesheets it'll be two draw calls instead of one. Texture atlases are not for organizing your animations but to keep as much as possible of all of your graphics into as few as possible textures.