Jump to content


Photo

Extra view messes up code


  • Please log in to reply
7 replies to this topic

#1 whothat

whothat

    GMC Member

  • New Member
  • 18 posts
  • Version:GM8

Posted 11 June 2012 - 10:25 PM

I have this code, that controls the movement and zoom of view 0. I'm trying to add my HUD to view 1, but whenever I make view 1 visible, it messes up the scrolling of view 0, the zoom seems fine still, but the scrolling becomes jittery and intermittent. I'm not sure why view 1 is affecting this code at all because I made sure to include [0] after every view_xxxx function. please help.

Spoiler

Edited by whothat, 12 June 2012 - 02:39 AM.

  • 0

#2 nikkolausc

nikkolausc

    GMC Member

  • New Member
  • 6 posts

Posted 11 June 2012 - 10:51 PM

well, its just a suggestion, but maybe the mouse is being affected by view1 and its causing view0 to be jumpy. where are you drawing view1 in relation to view0? you could also check to make sure the mouse is in view0 before it starts the scrolling. like i said, its just a theory
  • 0

#3 torigara

torigara

    GMC Member

  • GMC Member
  • 6483 posts

Posted 12 June 2012 - 12:52 AM

Your calculation seems to assume that mouse_x/y are always relative to view 0. That will break when the mouse enters view 1. Try using window_view_mouse_get_x/y(0) instead.
  • 1

#4 whothat

whothat

    GMC Member

  • New Member
  • 18 posts
  • Version:GM8

Posted 12 June 2012 - 12:56 AM

Your calculation seems to assume that mouse_x/y are always relative to view 0. That will break when the mouse enters view 1. Try using window_view_mouse_get_x/y(0) instead.


aren't the mouse coordinates relative to the room and not the view?

but i will try it anyways

edit:
didn't work, behaves the same as with mouse_x/y



well, its just a suggestion, but maybe the mouse is being affected by view1 and its causing view0 to be jumpy. where are you drawing view1 in relation to view0? you could also check to make sure the mouse is in view0 before it starts the scrolling. like i said, its just a theory


the views are the same size, view1 stays at (0,0)  while view0 can move around the room

Edited by whothat, 12 June 2012 - 12:59 AM.

  • 0

#5 nikkolausc

nikkolausc

    GMC Member

  • New Member
  • 6 posts

Posted 12 June 2012 - 02:14 AM

Me and the other guy are getting around to the same point. i dont so much care where the views are in the room, i meant on screen. the mouse could be entering a seperate view, even for just a moment, and causes the scrolling screen to shutter like that.
  • 0

#6 whothat

whothat

    GMC Member

  • New Member
  • 18 posts
  • Version:GM8

Posted 12 June 2012 - 02:25 AM

Me and the other guy are getting around to the same point. i dont so much care where the views are in the room, i meant on screen. the mouse could be entering a seperate view, even for just a moment, and causes the scrolling screen to shutter like that.


is mouse_x/y relative to the room or to the view, because i've always assumed it was relative to the room.

the manual isnt very clear

mouse_x* X-coordinate of the mouse in the room.

when there are multiple views, these variables give the mouse position with respect to the view the mouse is in


edit:
@ torigara

sorry, i just realized i tried display_mouse_get_x/y instead of window_view_mouse_get_x/y , i should read more carefully xD
it worked
thanks

Edited by whothat, 12 June 2012 - 02:37 AM.

  • 0

#7 nikkolausc

nikkolausc

    GMC Member

  • New Member
  • 6 posts

Posted 12 June 2012 - 03:04 AM

mouse_x is relative to the room, as long as its in a view of course. as far as i know anyways.
  • 0

#8 torigara

torigara

    GMC Member

  • GMC Member
  • 6483 posts

Posted 12 June 2012 - 08:21 AM

It is both true that mouse_x/y are relative to the room and they respect with views. To be precise, it is the coordinates of the point in the room that is seen through the view right beneath the mouse cursor. Well, I know this description is accurate but confusing. Probably a few illustration will help.

Let's imagine a big room. At the bottom right corner is the player A, and the top left is the player B. You have one view for each player. Each view will show the following region in the room, respectively.
(0,0)
+-----------+------------------------+
|           |                        |
|     B     |                        |
| (100,100) |                        |
|           |                        |
+-----------+                        |
|     ^                              |
|     |                              |
|   View 1                   View 0  |
|                              |     |
|                              |     |
|                   (800,800)  v     |
|                        +-----------+
|                        |           |
|                        |     A     |
|                        | (900,900) |
|                        |           |
+------------------------+-----------+

view_xview[0] = 800, view_yview[0] = 800
view_xview[1] = 0, view_yview[1] = 0
They will be shown on the window side-by-side as follows.
   View 0      View 1
+-----------+-----------+
|           |           |
|           |           |
|     A     |     B     |
| (900,900) | (100,100) |
|           |           |
+-----------+-----------+

view_xview[0] = 800, view_yview[0] = 800
view_xview[1] = 0, view_yview[1] = 0
When you click on A, mouse_x and mouse_y will be (900,900). Because that is A's x and y. Click on B, and mouse_x and mouse_y will become (100,100) because that is the B's position in the room. You will see it logical. They indeed represent the position in the room coordinates, choosing the region that corresponds to the view the mouse cursor is in. (To the room's standpoint, the cursor jumps from one region to another when the mouse moves across the view boundary.)

Ok, back to the original problem and suppose that you want to take the cursor's relative position with respect to the point A. That is, when you drag the mouse from A all the way to B, you want the mouse position to change from (900,900) to (1100,900) continuously. As we have seen above, mouse_x/y won't work; it will suddenly jump to another side of the room when you enter view 1. To make it work, you have to pretend as if there is only view 0 (extended to cover the entire window) so that the mouse cursor always resides on view 0. Window_view_mouse_get_x/y does that job.

Edited by torigara, 12 June 2012 - 12:29 PM.

  • 1




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users