Camera Too Big!!!

#1 I should mention it is 1.4 that I am using.



Thanks.

#2 I believe the camera is set to iphone resolution now (by pressing one of the options like iPhone portrait or iPhone landscape).

For iPhone it's always better to use the actual resolution as the camera size so that you can position and size your images in real pixel coordinates.

#3 fully agree. I've always used 480x320 actually as 100x75 is great if you do all in code but I did work with tilemaps especially and as such working with the real resolution saved a lot of time.

#4 So, why then when I bring in objects that are set in 480x320px in Illustrator are they abnormally huge?


Basically, what are the settings you all use?
Camera?
Resolution?

#5 Working with the real resolution is easier, but sometimes it is better to use a different camera size. In the beginning, I experimented a lot with different camera/resolution values and I had some problems with certain movement functions being too sluggish. In the end I decided to use the following settings:

resolution: 480x320
camera: 120x80

I don't think it is a good idea to use 100x75 because that will change the aspect ratio and it will distort the image slightly (although it probably won't be noticeable).

#6 By the way, if you're making text objects, set your camera to 100x75 temporarily while you make it, then resize your camera back to normal. If you don't do this they'll appear blurred. It's a bug.

#7 Hmm, I had written a better explanation but lost my reply, so forgive if this one is not as clear,
but I had used png's as text objects, only in that they "held" text. Some appeared slightly blurry with my camera at 100x75, in my last project, Temple Racer, but nothing too bad. Every thing else looked fine.


---
I just did a test at Camera 480x320 and everything is fine, just larger, but proportionate. Why was I under the impression that the camera needed to be at 100x75?

Anyhow, No worries I am just going to use my camera settings and resolution at 480x320.


Thanks!

#8 I actually do have a question tho I think I know the answer. Obviously by leaving all at 480x320, what happens when a version is used on the iPad? Less distortion I am guessing. Or must I set up a completely separate file for the app to be run on the iPad with out distortion?

#9 I think you can use whatever you want. The only issue I am aware of is that when the camera and screen resolution are not the same, an objects world position will be different from the actual screen position, which means that you will have to make a conversion for certain functions that use world position (tilemaps for example, as Marc pointed out). You just need to make sure not to hard code anything in your worldPosition to screenPosition conversion function, so that it will always work correctly for different screen resolutions.

In my case I use 120x80 as my camera, so there is a simple integer scaling factor between camera and screen (4x, for 480x320 ipod screen, for example, for both x and y axes). If you use 100x75, that makes things more complicated because the x-axis then scales by 4.8x, and the y-axis scales by 4.27x, and in this case the scaling becomes non precise, which results in some distortion. As long as you use variables in you program for screen and camera size (as apposed to hard coded numbers), and choose a camera size that has an interger scaling relationship to the screen size, the scaling should always work correctly for any screen size. It's a bad idea to always assume that the screen size is the same as the camera, because if you do that you'll have problems when the screen size changes (iPad, newer versions of iPod etc..).

#10 benefit if you use 480x320 is that you can use the iOS own content scaling factor to get the actual value (its 2 / contentScale), that can save you headache.
though you naturally also can expand iTGB to set the camera resolution to the screen resolution of the device automatically for example and alike

#11 That's a good idea. I like the idea of detecting the device and setting the camera resolution to the screen resolution automatically. I think that's the best solution actually.

#12 @Mark,
in Temple Racer, my last project, there were plenty of times I had to contract collisionPoly's as inexplicably, objects would collide. They were close, but not touching, however a collision, was sometimes set off. Do you think this may be a factor? So in direct scale, the positions are locked my clearly?


@Marc,
By setting it to 480x320, when I pull in an object, it is much larger than when it is pulled in at 100x75. On this theory, if my app, is played on an iPad, I would think that the resolution, lack of distortion by expanding the images size, would be less since the object is bigger to begin with. Do you think this is a factor to consider?

#13 Hmm, not sure, I think the problem you are talking about might be just an issue (bug?) in the collision system. When you use a non-integer scaling between camera and screen, there is a possibility of error due to rounding errors, but that would only be +/- 1 pixel so that would not be so noticeble. The only time I've seen this problem is when I use the CIRCLE collision mode, and in that case I always end up setting the CollisionCircleScale to something like 0.7 or 0.6 otherwise I see a similar problem where the object will register a collision before it is actually touching anything. When I use my own custom collision polygons I've not experienced any problems actually. Having said that, yes, I think everything will be more precise if you have the camera set the same as the screen resolution. I agree with Marc and Connor that this is definitely the way to go.

I actually started off with my camera size set to the 480x320, but I had a problem with the MoveTo() function. This is something that is specific to my game though. I wanted to move an object very quickly from one position to another, and with my camera set to 480x320 I was unable to make the object move fast enough. In the end, I found a workaround, which was to set the camera to 4x smaller than the screen, and I was then able to achieve the desired effect. SetPosition() would have been a better solution, since that is immediate, but I found I couldn't use that because I have mounted objects and these did not move at the same time as the main object, which caused a weird lag effect that didn't look right. So, really, at the end of the day it depends on what you're trying to do, and sometimes there are bugs in the iTGB engine that might force you to have a different camera setting.

Ideally, unless you experience problems, I think the best solution is to have the camera size set to the screen resolution, as this makes life a lot simpler for certain functions.

#14 @Mark,
Regarding the collisions. I noticed when I set my view to see the collision boundaries, I notice that the collisionPoly actually shoots ahead of the objectImageMap by, I would say up to a centimeter (when moving, using moveTo()). I say that viewing the screen, unable to convert for pixels...


So that in itself is a problem. I am not sure if that is the cause, but it is a concern, perhaps something iTGB staff should fix or explain.






Interesting what you say about the mount factor and working around, your game requirements and the engine. Thanks. But what, if anything do you make of my theory that if, camera size 480x320, one will experience less distortion, on an iPad than if camera size set to 100x75 for example? AND are all iPhone iTGB games playable on iPad? Sorry if this is a dumb question.

#15 That's interesting about the collision boundaries. I will take a look at mine to see if I see the same thing. If that's the case, then it appears to be an issue in iTGB. I haven't actually noticed this, but it's possible I have the same problem and just never noticed it. I will get back to you on this issue.

Regarding the iPad, I'm really not sure to be honest. I don't have an iPad or a new iPod v4 so I've not tried running my game on anything other than 480x320. I don't think you can automatically assume that your game will work on the iPad without some changes though. I remember when Scott was porting his IWT game to the iPad he had to make some changes to make it work correctly on the iPad. I was hoping that the game would be automatically scaled up to the higher resolution without issues, but I don't think that is the case.

#16 All iPhone apps work on the iPad without any work, they just look like crap. By default an app made for iPhone will start at 480x320, but there is a little button on the bottom right that will let you double the size.

What Scott is doing is naively porting IWT to the iPad, which requires a universal build (or a completely new build) and higher resolution art.

#17 Justin, thanks for the clarification. What about the new 960x640 iPods/iPhones? Since the screen is still the same size physically, will a regular iPhone app that is written for 480x320 still look bascially the same? I hope so! I have no intention of producing an iPad app, but I would like my game to work on all iPods and iPhones. Once I'm done with this game I'm off to Unity 3D.

#18 Mark, it will work on the iPad and as Justin says you can double the screen size of the app by pressing a button. However, you will notice that the gfx don't look so good when scaled by 2, more so if you have any PVR (I don't think you do?). At norma scaling it just looks like the iPhone version e.g. 480x320 but the experience IMO is pretty poor.

#19 ok IWT, what is this? and new 960x640 iPods and iPhones? Since this is resolution, I am thinking that, if, an iPhone/iPod game is built to this new resolution, when expanded on an iPad it will loose less clarity?

#20 Also, do you think we should practice setting the resolution to the new resolution? What happens if I set my resolution to 960x640 and someone with an iPod of 480x320 resolution plays it? What happens if someone with a 060x640 resolution iPod plays a game where the resolution is 480x320? All very confusing/intriguing/good to know.