Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Zooming and viewoffset

Author
Message
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 11th Feb 2014 04:11
I'm having a major lapse in mathematic ability.
Hopefully someone can help me out.
I'm trying to determine the minimum and maximum Y offset allowed for the following example. The goal is to make it so that the board can move half of its height plus the height of one tile. I seem to have the calculation for max and min for the x offset OK, but y is not cooperating. I can fudge it, but I'd like to understand the calculation so that I can use different zoom levels.

Here's the code (offending lines are 150 and 153):


My current (incorrect) calculation for max and min camera Y offsets are:
minCamY# = -0.5 * 15.0 * h# / z# + h# * z#
and
maxCamY# = 0.5 * 15.0 * h# / z# - h# * z#

Where h# is the height of one of the game board tiles.
And z# is the zoom level.

All help is greatly appreciated!

Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 11th Feb 2014 11:05 Edited at: 11th Feb 2014 11:13
I've always had issues working out the offset with SetViewZoomMode(1). I always use mode 0 and re-center it after a zoom change.

Maths for this always do my head in, so rather than attempting to decode your code, here's the thinking behind how I approach it;

Quote: " the board can move half of its height plus the height of one tile."

overshoot X = ( board width / 2.0 + tile width )
overshoot Y = ( board height / 2.0 + tile height )

Positioning the board at 0,0 on the world plane, the minimums are minus whatever you want to go past the left / top edge.

min X = -overshoot X
min Y = -overshoot Y

The maximums are the width / height of the board, plus the overshoot, minus the amount on visible on screen (display size adjusted by the zoom).

max x = board width + overshoot X - (display width / zoom)
max y = board height + overshoot Y - (display height / zoom)

This a simplified algorithm to try to show how the maths works, hopefully it shows that this isn't as complicated as it often seems when your bogged down in the maths and code.
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 11th Feb 2014 19:14
Thanks, that might work with SetViewZoomMode(0), but I'd prefer to use centered. If I use 0 then I have to go back and reqrite this entire thing because I use some tweening and scissors.
I'd really prefer to understand the math behind this using zoom mode 1.

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 11th Feb 2014 19:51
OK well I seem to have figured it out, but I don't quite understand it.
zf# = (z# - 1.0)
boardHeight# = 15.0 * h#
minCamY# = -zf# * boardHeight# / (2.0 * z#) - h#
maxCamY# = zf# * boardHeight# / (2.0 * z#) + h#

Let me talk it out and the explanation may become a little more clear.
For some reason my brain's not quite grasping why this equation works, but it does. I've tested it for multiple zoom levels and it seems fine. *shrug*

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 11th Feb 2014 20:10 Edited at: 11th Feb 2014 20:16
Every time I start a new project I take a new crack at this. What I've found is it's far easier to use the none centralised view because of the fact that a centralised view gives the view offsets as if the view was NOT zoomed. Confusing and irritating. Just stick to using the top left of the view it's much easier.

I find that if I want to centralise the view on a point in space I can do it using the centre of the screen as a world co-ordinate:


EDIT: not much help to your problem but might give you another way of thinking about how you work out your positioning and testing what is on screen. I often use the screenToWorld commands to check my view is not going past the edges of what I want visible and this is a simple example of using this method. Hope that makes sense!

oct(31) = dec(25)
Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 12th Feb 2014 00:13 Edited at: 12th Feb 2014 00:28
Quote: "I can do it using the centre of the screen as a world co-ordinate:"
It must be that the subject is counter intuitive or something, because I always have to go through it a few times to get it straight in my head and usually end up doing the same;

"So I wonder where the middle of the screen is right now?"

Quote: "might give you another way of thinking about how you work out your positioning"
This was my point, It's hard enough working through my own offset maths, let alone someone else's.

My first attempts at coding offsets and zooms got awfully complicated, really quickly and I had to take a step back and look at what I wanted. Even sliding one piece of paper over another on the desk to try to see past the numbers.

Hence my very simplistic approach above - as much for my benefit as anyone else. I actually read through it about five times and still have doubts


Quote: "I'd really prefer to understand the math behind this using zoom mode 1."
I wish you luck with that, I seriously do. If you find an answer I for one would be interested because EVERY attempt at this has led to failure and so much wasted time. I found it easier to write a centering routine for mode 0 than to get mode 1 offsets to make any sense.

Edit: in fact the formula for centering mode 0 is something like;

baseOffsetX = ( width# - width# / zoom# ) * 0.5
baseOffsetY = ( height# - height# / zoom# ) * 0.5

Add that to all your offset commands and switch to mode 0
Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 12th Feb 2014 00:25
Right now I have a level of understanding of it that is very abstract. Everything I'm doing seems to be working so far and it works the way I want it to, so that's good...
It is pretty complicated, especially when you have menus to deal with and 2 different views that you're working with. My game has a board in the middle that you can zoom on but everything else stays static, BUT you can move the tiles from you tray to the board, so that's fun
I'm working on the transition between tile tray and board right now. It's not pretty.

Marl
13
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 12th Feb 2014 00:32
Quote: "Right now I have a level of understanding of it that is very abstract."

I think that is all any of us have when it comes to this subject.

I edited the post above with the formula for mode 0 in case it helps

Login to post a reply

Server time is: 2024-11-25 01:41:58
Your offset time is: 2024-11-25 01:41:58