dealing with different screensizes when using tiled map files (tmx) - sprite-kit

I'm trying to learn spritekit and I'm a little confused by something. I know that I need to have #2 image files which need to be double the size of the standard ones and that once I name them properly xcode will deal with the rest. But, when dealing with tiled, do I need tiled files that are level1.tmx and level1#2.tmx
So here is what I did as a test today:
created two tilesheets, one was 32x32 and the other is 64x64 (the 2x).
create two levels in tiled, one was 64x64 tile sizes and the level size was 2048x1536 (the 2x one). I used the 64x64 tiles on that one. The other level I created was the exact same, but I created it with 32x32 tile size, which made the level size 1024x768 and I used the tilesheet that was 32x32 on it.
So now I have two tmx files and two spritesheets, for one level, on the ipad.
Am I doing this correctly? Once I start doing the iphone I will have 4 or maybe 6 sets for each level?
I assume xcode won't work the same way with tmx files if I name them level1#2x.tmx, right? If not and assuming everything I'm doing above is correct, how to do load the correct tmx file? Do I need to check for device type, then resolution and load my map file based on that for each level?
I think maybe I'm not doing this right so I wanted to stop here and ask before I get any further.

TMX files are not loaded automatically in iOS so I am guessing you are either using the SKAToolKit or the JSTileMap one of the two most popular to my knowledge. Myself and other Sprite Kit Alliance members put together the SKAToolKit so I think I can answer your questions from that point of view because it should be similar for JSTileMap too.
The short answer is build your map using 1x assets, but provide images for standard and retina in Xcode.
First you create your map using 1x assets. When the map is loaded it uses points not pixels. So for example if you make a 32x32 pixel tile map it will be treated as a 32x32 point map. When the sprites are created it pulls in the correct image based on device. If an image is named tree.png and is 32x32 it will take up the space of a 32x32(point) tile. If you have an image called tree#2x.png 64x64 iOS will use that for retina devices. Because it is an #2x image it will take up 32x32(points) but will be 64x64 pixels.
Hopefully that makes some sense. If not let me know.

Related

SKTileMapNode Pixel to Pixel Aligning

I am working on a tilemap game with Apple's newish SKTileMapNode. The pixels on my tiles do not match up with the pixels on the phone display. My scale mode is set to .resizeFill. My tile's sizes are correctly labeled as 64x64 and each tile's texture's image is sized correctly.
I am using a camera that is a child of the gray circle in the attached image. I believe that the camera will create a pixel to pixel view of the screen size being used and match the resolution, but I am not sure that I can trust this. How can I get my pixels to align correctly to avoid this.
It turns out that SpriteKit's SKTileMapNode really likes assets to be optimized for all resolutions. This fixed my pixel alignment problem entirely. While this may seem obvious, I originally added #1x files in order to use an optimized texture atlas. It took more research to discover how to add different resolutions to a texture atlas.
Since it is different than normal atlases (appending ".atlas" to a folder of images), I will describe how to do so here
Go to the assets.xcassets folder and click "New Sprite Atlas." In here drag in all #2x and #3x images. Delete the [asset-name].atlas folder if you had one before, as this will not support different resolutions natively.
From here on, the atlas can be accessed just as the original [asset-name].atlas folder was accessed in code.

What are the differences between APNG and MNG?

I know that APNG is an extension of PNG, while MNG is more of its own format (albeit developed by the original PNG developers). MNG is barely supported in any browser at all, while APNG almost only has native support in Firefox (for various backward compatibility- and decoding-related reasons, it seems).
Except all of these behind-the-scenes things, what are the differences between APNG and MNG? Does one have features the other doesn't (for example, storing only parts that are modified instead of always whole frames)? Does one have better performance or file size than the other?
APNG can create a new frame by replacing the entire image or by overlaying or blending a smaller image over part of it. To display a "pong" game you'd need a new image of the ball in each different location. APNG has essentially the same capabilities as animated GIF, but also allowing 24bit RGB and 8-bit alpha.
MNG can do that, plus it can also retrieve an image that was previously defined in the datastream and place it over the previous frame in a new location. To display your "pong" game you'd only need to transmit one image of the ball and use it like a sprite.
Much more detail is available in the specifications:
apng: (https://wiki.mozilla.org/APNG_Specification‎)
mng: (http://www.libpng.org/pub/mng/spec/mng-lc.html)

How do you create resizeable header images for iOS in Photoshop?

I'm trying to create assets for a native iOS app. I know that I need to make my header images and buttons resizeable, so I'll need to create slices of the capped ends and a middle slice that stretches to full size.
My question is: how do I do this in Photoshop? Should I use the slice tool to make three separate slices and then export them as three .pngs? Or should I slice the ends and the middle, put it all together and export it as a single .png?
What is the best way to do this?
Thanks!
Native iOS apps have an image API that supports resizing single images based on insets and a tiled inner area. See the documentation, specifically -resizableImageWithCapInsets:. With that method, areas around the edges defined by the insets are not altered, while the remaining center region is tiled to fill any size.
You should aim to produce single images that can be used with that API in mind, while keeping tiled inner region as small as possible

HUGE image to show on the iPhone

Ok, here's my problem. I have a HUGE jpg file, 18000 x 18000 pixels 41MB in size.
If you really need to know, it's a map of a section of the country with services.
My project is really simple. I just need to be able to zoom and display this granddaddy size image. All the way from aspect fit to 100% on the iPhone. I'm not too sure if this can be done or how long it will take. Would appreciate any insights.
I have tried using imageView but I read that it really shouldnt exceed 1024 x 1024. That is way below what I have. If you have an idea how to go about doing this, please share!
You should split the image into tiles, at a range of magnifications. Calculate and build these off-line, and ship them as individual files in the app bundle. Given the zoom in your display, pick the closest zoom size. You then select which tiles are needed to cover the screen, and make a grid of them. As the user zooms, select the appropriate tile size.
The benefit of this is that you don't ever have to load HUGE files into memory, only as much as needed.
This is how Google maps does it.
Can't give you any code, sorry!
You should follow an approach similar to what Google Maps and other map sites do. You need to slice the whole map in sections, so the users don't need to load the whole map if it's not always necessary (plus makes loading time way faster)
There's a couple of solutions that might work for you like OpenLayers or even creating a Custom Google Map with your images as seen here and here
Here is an example from Apple for processing large images called PhotoScroller. The images have already been tiled. If you need an example of tiling an image in Cocoa check out cimgf.com

working with large sprite sheets on iphone

I am trying to use sprite sheet animation in my application.
The first POC with a small sprite sheet worked fine but as i change the sprite sheet to a bigger one, i get "check_safe_call: could not restore current frame" warning and the application quits.
A quick search revealed that this problem meant my app is taking too much memory or the image is too huge in dimension.
My image is 4.9 Mb and dimensions are 6720 * 10080 (oops!!). i read that iphone allows maximum 3 Mb image with dimensions up to 1024 * 1024. Also that the sprite sheet image dimensions should be a power of two.
So please let me know how i can use a sprite sheet this big.
One approach could be to cut the sprite sheet into many smaller sprite sheets and use them one at a time.
Please suggest if you know any other/better approach to accommodate bigger sprite sheets and whether the problem with my sprite sheet is size (4.9 Mb) OR dimensions (6720 * 10080).
(Just FYI, i am not trying to play a movie so using MP4 file instead is not an option for me. i need to animate the sprite sheet based on accelerometer input and i have been able to achieve that in my POC with smaller sprite sheet.)
Thanks,
Swapnil
You should cut up the sprite sheet into multiple textures as you describe. The iPhone's memory and graphics chip simply can't hold an image/texture of that size in memory at once. By splitting up the sprite sheet it will deal with loading/unloading the appropriate textures into memory when you use them.
You might also consider optimizing the image format. Using the PVRTC format can save a huge amount of memory, but it is only well-suited to certain kinds of images. See this Apple page for more information.
definitely keep it within powers of 2. also, keep the sprites within the spritesheet in containers that are powers of 2 (say, you have a 17x31 sprite... put it in a 32x32 container). the problem with your sprite sheet is both the 4.9mb and the dimensions. i would consider using adobe fireworks or pngcrusher to bring the size of your sprite sheet down considerably.
mike weller's right about splitting the sprite sheet up (you simply cannot max 1024). i think the best bet would be to reorganize what you're doing with your sprite sheet into elements (though it's tough to say without knowing particulars). only things that move should have multiple frames. overlay those over a background (from the same spritesheet) by calling there location on the spritesheet and tossing them into play.