Aspect ratio?

Noobboy

hey all. so i have started recently going through all the ionline tutz i cud find. i found this one called"zombiebird" its great!!!!!! its just like flappybird game for the phone. It takes u step by step thru everythin.

but im stuck at this one poitn and dont want to move forward as i dont want to have a a bad shaky foundation. it seems very crucial too.
can someone please explain how the followiung works. the logic behind it. i am a noob afta all.

PLEASE LET ME KNOW IF I DONT PUT ENOUGH INFO UP AND I WILL UPDATE!!!

"What about the y? Based on my calculations, it should be 5 pixels above the vertical middle of the screen. (Remember that we are scaling everything down to a 137 x ??? screen resolution, where the height is determined by getting the ratio between device screen height and screen width, and multiplying by 137)."

THEN he says in the actual coding to calcluate the midpoint

"float screenWidth = Gdx.graphics.getWidth();
float screenHeight = Gdx.graphics.getHeight();
float gameWidth = 136;
float gameHeight = screenHeight / (screenWidth / gameWidth);

int midPointY = (int) (gameHeight / 2);"

thanks u to anybody hu can elp. i know its never fun helping a super beginner

dislekcia

What don't you understand exactly: Why he's trying to calculate the center point of the screen, or how the maths works?

It always helps to draw out graphical math like that :)

quintond

Wow, I struggled to read that. Spelling, Punctuation ... Capitals. ;)

Anyway ... let me check if this is what you mean.

screenWidth is set to the current width, for this example we will say 1024.

screenHeight is to the current height, for this example we will say 768.

The game width is set to 136.

The game height is set to 768 / (1024 / 136) ... so BODMAS or BOMDAS makes this 768 / (7.529411764705882) which is finally 102.

Finally the midPointY is now set to 102 / 2 which is 51.

So in essence the developer is trying to get the midPointY and is using the screen dimensions and the game dimensions and therefore finally getting the exact midpoint of the game screen.

This would therefore imply that midpointX would be 68 (game width / 2), but that is not the point. This does seem a bit of an interesting way to calculate the desired information but anyway as @dislekcia says ... the developer is trying to calculate the center point of the screen.

HTH.

Noobboy

But the prob is that it is a portrait game. Now if the game height is 102 and the game width is 136 that wud make it portrait?
Also why ius he calculating the game height if he set it already? and why not calculate the game width regarding the same thing? ie how is the gamewidth always the same but the height is not.

Here is the page link if it helps:

http://www.kilobolt.com/day-5-the-flight-of-the-dead---adding-the-bird.html

Seriously guys i really appreciate the help. I truelly appreciate it.

dislekcia

Noobboy said:

But the prob is that it is a portrait game. Now if the game height is 102 and the game width is 136 that wud make it portrait?
Also why ius he calculating the game height if he set it already? and why not calculate the game width regarding the same thing? ie how is the gamewidth always the same but the height is not.

The point of this is to make sure that the game is always 136 game units high (let's call that GU), presumably a single GU is supposed to represent an "art pixel". This is different to a screen pixel, which depends entirely on the hardware that the game's running on. Having larger "art pixels" than actual screen pixels is what produces the chunky, pixelated look that Flappy Bird uses - if 1 GU were = 1 screen pixel, the game would be tiny.

Setting up your camera to render things at different sizes like that isn't too complicated, in a 3D game (and pretty-much all games are using 3D systems these days, even 2D games) all you need to do set your aspect ratio correctly, position your camera and set it's view calculations. Those are probably where you're seeing him "set" a height. That doesn't change the size of the screen, only the math that the camera uses to put stuff on the screen.

Don't get confused when someone says "screenWidth is set to a value" - they're not talking about the actual physical screen width, because that can't be changed and comes from the hardware. They're talking about a variable called screenWidth that now contains the width of the screen that it just got from the hardware by asking it through Gdx.graphics.getWidth(). That variable is just a label with a number in it so that they can do math to figure stuff out.

The rest of the math is pretty simple and @quintond explained it perfectly, although he assumed that the game was running in landscape. Presumably if you're telling it to be portrait somehow, then it'll return width and height values in portrait mode and the height of the screen will be larger than the width... That's also why the game is using width in GU as its set number - the width of the game is the important part, the height can be variable because there's the ground and extra sky to fill it up. It's exactly because the game height isn't sure (because it depends on the aspect ratio interacting with the physical size of the screen in pixels) that this math is being done to find out where the center of the screen actually is in GU. If the tutorial doesn't use this position as a reference point to place pretty much everything else, they're doing it wrong ;)

Boss_Fight19

Are there any tutorials on this?

Noobboy

All i can say is god bless you man.
Now if i had to make a game based around this games concept in a landscape form, would the same methods work? Like would the width still be set (different values of course) but still have to work out the heoght midpoint to set all interfaces against?
Like under the GU style of things. Need to read up on that.

Are there any tuts on Gu's and aspect ratios using GU?

leas excuse my ignorance with this stuff. english is not my first langueae so its not so easy to grasp tht programmign side of it.

dislekcia

Noobboy said:

Now if i had to make a game based around this games concept in a landscape form, would the same methods work? Like would the width still be set (different values of course) but still have to work out the heoght midpoint to set all interfaces against?

You'd probably want to use your height as the set parameter in that case, seeing as that's the smallest dimension in landscape mode so that's where you'll have the least freedom. The maths is pretty much exactly the same though.

Noobboy said:

Are there any tuts on Gu's and aspect ratios using GU?

I sorta just made up the term "Game Unit" because it's a useful way to think about your game having different measurements than screen pixels. A GU can be whatever you need it to be, for instance, in Desktop Dungeons a single GU is 1 in-game grid block. That means we have 20 grid blocks vertically and, because we made the game at a 4:3 (old screen size) aspect ratio, that's 26.66666blah horizontal blocks (20 / 3 * 4).

An aspect ratio is just a fraction that gets simplified down to it's smallest possible denominator (hah, maths is useful) - so old PC monitors were at 4:3, 800x600, 1024x768, etc all simplify down to 4:3 if you factorise them. New monitors use 16:9 or 16:10 - what's 1920x1080 at? Phones and tablets are all pretty-much random in terms of their aspect ratios, so you have to figure it out from their actual physical pixels and then make sure your game is displaying itself correctly instead of squishing or stretching weirdly.

Noobboy said:

leas excuse my ignorance with this stuff. english is not my first langueae so its not so easy to grasp tht programmign side of it.

No worries, I know it was frustrating trying to figure out what all these alien words meant when I already spoke english - it's gotta be harder if you're translating them all too... Sorry :(

Noobboy

Thank you Thank you Thanks you!
Im sure ill be back with som ojter question soon . U guys rok!