Cocos2d : tile maps VS 1 giant image - iphone

I have been doing some reading and tutorials on tile maps in cocos2d, but what i want is to have a large graphic map, not made up of tiles that the user can drag around. so my question is this.
Is it going to cause performance issues to have a large map, (this will be on the ipad so maybe x4 the screen size)?

The maximum texture size you can have is 2048x2048 for any device above the iPhone 3G (This includes all iPads, although it may be larger on the iPhone 4S, but I doubt it). You can find tons of links on google by a simple search of iphone max texture size. That means that the largest image you can have is between 4-6 iPad screens. If this is enough for you, great! If not, you'll have to tile the screen anyways, regardless of the size of your tiles. Hope that Helps!

Related

Gamekit multiplayer and different screen sizes

I am very new to gamekit, so I am starting with a basic game. 2 players on the screen and allow them to just move around at this point.
I am testing the game with an ipad and a phone, so I am quickly realizing the ipad user has a lot more real estate instead of the same space being resized.
How do I setup the level to be the same amount of space on any device, but just magnified accordingly?
Try this for all the nodes that you want to be resized use the .setScale() method:
let scale = frame.width/667
node.setScale(scale)
667 is the approximate width of an iPhone 6. Feel free to play around with the number 667 to get the right magnification.
Basically what this does is it scales the node according to the size of the screen.
Note: Scaling may decrease resolution of any sprites used.

OS X Sprite Kit Game Optimal Default Window Size

I am looking to port an iOS Sprite Kit game to OS X. I'd like to provide the sharpest image quality possible. Since iOS device support only a handful of resolutions and I believe 3 aspect ratios this is done fairly easily by providing different sprite sheets, backgrounds, etc. based on the device.
I'm unable to find what the best practices are for the Window sizes in OS X. I know where and how to set the default and the constraints. I'm just not clear on what I should default the resolution to and as a result, what size images to include.
I am aware that my graphic will scale upon the window resizing, I just want the game's element's to look their best regardless of window size.
I was thinking of just looking up Apple highest resolution monitor and starting there, but wanted to ask first if there was a generally accepted approach to this before going that route.
I'm aware that this is a fairly basic question, but I have yet to find a reasonably articulated approach. Please forgive me in advance if there is something available that I overlooked, it was not for lack of trying.
Thank you.
You should target the smallest, not the largest, supported pixel resolution by the devices your app can run on.
Say if there's an actual Mac computer that can run OS X 10.9 and has a native screen resolution of only 1280x720 then that's the resolution you should focus on. Any higher and your game won't correctly run on this device and you could as well remove that device from your supported devices list.
You can rely on upscaling to match larger screen sizes, but you can't rely on downscaling to preserve possibly important image details such as text or smaller game objects.
The next most important step is to pick a fitting aspect ratio, be it 4:3 or 16:9 or 16:10, that ideally is the native aspect ratio on most of the supported devices. Make sure your game only scales to fit on devices with a different aspect ratio.
You could scale to fill but then you must ensure that on all devices the cropped areas will not negatively impact gameplay or the use of the app in general (ie text or buttons outside the visible screen area). This will be harder to test as you'd actually have to have one of those devices or create a custom build that crops the view accordingly.
Alternatively you can design multiple versions of your game for specific and very common screen resolutions to provide the best game experience from 13" through 27" displays. Optimized designs for iMac (desktop) and a Macbook (notebook) devices make the most sense, it'll be harder to justify making optimized versions for 13" and 15" plus 21" and 27" screens.
But of course this depends a lot on the game. For example a tile-based world game could simply provide a larger viewing area onto the world on larger screen resolutions rather than scaling the view up. Provided that this does not alter gameplay, like giving the player an unfair advantage (specifically in multiplayer).
You should provide #2x images for the Retina Macbook Pro and future Retina Macs.

Preloading a large image

I have an image with the dimensions of 5534 × 3803, and size of 2.4mb. The UIView references notes that:
"In iOS 3.0 and later, views are no longer restricted to this maximum
size but are still limited by the amount of memory they consume."
When the image loads, it lags for half a second, then slides in. The image sits in the UIImageView at 1024x704, but can be scaled up to 4x that size for the purpose of my app.
Are you able to preload the image in the AppDelegate? Or is there another way of working around having such a large image?
Thanks
EDIT: The scaling is done via UIPinchGestureRecognizer, and scales up and done (scale x4 - x1) based on the image's center point. There is no panning of the image when zoomed in.
Personally, I would try to write a tile-based system (think Google Maps) that slices your big image into a grid of small images to avoid loading in that gigantic image all at once into RAM. I don't really know what your user interactions are for this image, or whether the images are changing or baked into your project, but I'd assume you can let users scroll around since that image is bigger than any iOS screen. With a tile-based system, you only load the images that are on-screen. CATiledLayer is an Apple class for doing just such a thing. That's probably what you want to look into.
See this StackOverflow question for some different approaches. The accepted answer uses code from Apple's sample PhotoScroller project, which may work for your needs and uses CATiledLayer.
This ScrollViewSuite Apple code might also get on your way (check out the Tiling code).

Pixelation issues on iPhone Air game

I am working on a cross-platform mobile game for Android and iOS devices. I am using Adobe Flash with AIR and AS3 to code the game. I am drawing my character, obstacles, and backgrounds in Adobe Illustrator. The canvas in Flash is set to 960x640. The character was intended to be 1/3 of the screen height so around 213 pixels high. I designed the character in Adobe Illustrator to be somewhere around 900 pixels high. When I imported the character into Flash I animated him, instantiated him using var player:Player = new Player(), and scaled him down to size using the scaleX and scaleY properties. I tested it out on the desktop and Android phone and it looked wonderful. However, when I tested it out on an iPhone, the player was unacceptably pixelated around the edges. I figured the fact that I drew the animation much larger than the intended height must be the problem, so I redrew the player to exactly 213 pixels high and retested on the iPhone without any improvement in the quality of the animation. I also tried converting the MovieClip to a Bitmap vector explained here but that also had no effect on the quality of the animation.
At this point, I am at a loss. Does anyone have any suggestions on how to avoid this pixelation issue that I am experiencing when going from Adobe Illustrator to Flash to the iPhone?
For a more optimised iPhone route you might want to consider creating your animation as a set of bitmap graphics, i.e. create them as png files using PhotoShop at the size you want them to be displayed at.
By doing this you'll save CPU activity in having Flash create smoothed bitmaps
Try to set smoothing to true for your bitmap.
yourbitmap.smoothing = true;
I have some solutions for your problems.
Character should not have dark outlines. Use gradients for better effects.
Color combination should understand for your character. which background you use and other things.

Why do images for textures on the iPhone need to have power-of-two dimensions?

I'm trying to solve this flickering problem on the iphone (open gl es game). I have a few images that don't have pow-of-2 dimensions. I'm going to replace them with images with appropriate dimensions... but why do the dimensions need to be powers of two?
The reason that most systems (even many modern graphics cards) demand power-of-2 textures is mipmapping.
What is mipmapping?
Smaller versions of the image will be created in order to make the thing look correctly at a very small size. The image is divided by 2 over and over to make new images.
So, imagine a 256x128 image. This would have smaller versions created of dimensions 128x64, 64x32, 32x16, 16x8, 8x4, 4x2, 2x1, and 1x1.
If this image was 256x192, it would work fine until you got down to a size of 4x3. The next smaller image would be 2x1.5 which is obviously not a valid size. Some graphics hardware can deal with this, but many types cannot.
Some hardware also requires a square image but this isn't very common anymore.
Why do you need mipmapping?
Imagine that you have a picture that is VERY far away, so far away as to be only the size of 4 pixels. Now, when each pixel is drawn, a position on the image will be selected as the color for that pixel. So you end up with 4 pixels that may not be at all representative of the image as a whole.
Now, imagine that the picture is moving. Every time a new frame is drawn, a new pixel is selected. Because the image is SO far away, you are very likely to see very different colors for small changes in movement. This leads to very ugly flashing.
Lack of mipmapping causes problems for any size that is smaller than the texture size, but it is most pronounced when the image is drawn down to a very small number of pixels.
With mipmaps, the hardware will have access to 2x2 version of the texture, so each pixel on it will be the average color of that quadrant of the image. This eliminates the odd color flashing.
http://en.wikipedia.org/wiki/Mipmap
Edit to people who say this isn't true anymore:
It's true that many modern GPUs can support non-power-of-two textures but it's also true that many cannot.
In fact, just last week I had a 1024x768 texture in an XNA app I was working on, and it caused a crash upon game load on a laptop that was only about a year old. It worked fine on most machines though. It's a safe bet that the iPhone's gpu is considerably more simple than a full PC gpu.
Typically, graphics hardware works natively with textures in power-of-2 dimensions. I'm not sure of the implementation/construction details that cause this to be the case, but it's generally how it is everywhere.
EDIT: With a little research, it turns out my knowledge is a little out of date -- a lot of modern graphics cards can handle arbitrary texture sizes now. I would imagine that with the space limitations of a phone's graphics processor though, they'd probably need to omit anything that would require extra silicon like that.
You can find OpenGL ES support info about Apple Ipod/Iphone devices here:
Apple OpenES support
OpenGL ES 2.0 is defined as equal to OpenGL 2.0
The constraint about texture size's has been disappear only from version 2.0
So if you use OpenGL ES with version less then 2.0 - it is normal situation.
I imagine it's a pretty decent optimization in the graphics hardware to assume power-of-2 textures. I bought a new laptop, with latest laptop graphics hardware, and if textures aren't power-of-2 in Maya, the rendering is all messed up.
Are you using PVRTC compression? That requires powers of 2 and square images.
Try implementing wrapping texture-mapping in software and you will quickly discover why power-of-2 sized are desirable.
In short, you will find that if you can assume power-of-2 dimensions then a lot of integer multiplications and divisions turn into bit-shifts.
I would hazard a guess that the recent trend in relaxing this restriction is due to GPUs moving to floating-point maths.
Edit: The "because of mipmapping" answer is incorrect. Mipmapped, non-power-of-two textures are a common feature of modern GPUs.