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.
Related
Im trying to build a replica of the game 'Breakout'.
when i build and run the game in unity it looks good and everything id the correct scale but when i build and run the project on my laptop all the elements change size and some of the elements dont change size and i am not sure if i have done anything wrong or if i have forgotten to do something to stop it from changing.
This is what the game looks like in the unity editor when playing the game:
And this is what it looks like once i build and run the project on my computer:
My resolution is set to stand alone.
is there a way to get it to look like it does in the unity editor when i build and run it on my computer because that is what its supposed to look like.
These days, there are many different screen sizes, and resolutions.
My favorite solution is to use a reference resolution that can expand but never shrink. This allows you to have a safe zone that stays consistent across different screen sizes. For a generic case, you would use 16:9 aspect ratio, with the resolution of either 1280x720 or 1920x1080.
In Unity, on your canvas, modify the Canvas Scaler such that UI Scale Mode is set to Scale with Screen Size. Add your reference resolution, and set the Screen Match Mode to Expand.
In the Game tab you can preview what 16:9 looks like. You can try out other aspect ratios or resolutions.
For example, the iPhone 11 has a much wider resolution, so it expands horizontally. It's up to you to design your UI in a way that makes sense. You can either keep everything in the safe zone or align elements to the corners of the screen.
I'm making a small game of the single-screen, shoot'em up/platformer sort with javafx, and i wish to make it work on screens with different resolutions. All my graphics are made of java shapes in a single Pane, whose positions on the screen are determined by coordinates which correspond to pixels. I'd need the gameplay to be consistent accross platforms, but I'm having trouble since, for example, a velocity of 10 pixels per unit time is faster on a smaller resolution.
The only solution I can think of with what I know is multiplying everything by a ratio between some constant and the resolution, but that seems a little sloppy, so I'm wondering if there's a better way. Could I, for instance, have the game run "internally" at a constant resolution to get the math consistent, then scale that to fit whatever screen the player is using?
Your solution of rendering at a constant scale resolution is generally how it is handled with different aspect ratios getting different treatments in emulators and such. Sometimes revealing more of the background image or adding side bars so the playable space remains constant and it is only upscaled for view.
In general though the way this is best accomplished with modern hardware is probably abstracting away 'pixels' entirely from your game layer. Your game should move '10', 10 what? 10 units. Then when your rendering engine comes in behind it the renderer knows 10 units = 10px or 20px or whatever scale factor. That way your game pieces only worry about playing the game, while your rendering layer worries about how to write it all to image. Then you just have to worry about handling different aspect ratios which you really have to account for no matter what.
Typically with games the only time I use pixels directly is with UI elements.
I am developing a game that uses levels. The levels are made at a default scene width and height resolution.
The thing i am worried about is when the game is played on IPads iphone 5′s etc, the position of sprites loaded from the level xml files will be out of place due to the screen size.
In my case, could someone tell me the best thing to do in this situation or some advice on the approach i should take?
Also if any has experienced this, please let me know.
Thanks. :)
Generally this has nothing to do with how or where you store the level data.
These are the standard approaches, which one works for you depends on your requirements and desired results:
design each screen resolution individually (error-prone, tedious)
design for one screen resolution, then scale up or down according to screen aspect ratio (can lead to skewing as the screen size scaling for width & height are likely to be different)
design for the smallest screen resolution, then center the contents on the screen (this leaves unused areas either at the top/bottom or left/right sides)
same as above, but zoom content to fill the screen (this will remove the letterboxing, but also partially remove one side's content from the view)
In essence this is the same problem as movies have in trying to fit to screens of varying aspect ratios.
In general this is all a matter of scaling the input (positions) to a desirable output. The easiest approach is to maintain aspect ratio and allow for letterboxing. However Apple may reject letterboxing apps if nothing is done to hide the letterboxes (black areas) since Apple requires apps to support widescreen resolution, and letterboxing does not normally fall into their definition of "supporting widescreen".
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!
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.