Edited by whothat, 12 June 2012 - 02:39 AM.
Extra view messes up code
#1
Posted 11 June 2012 - 10:25 PM
#2
Posted 11 June 2012 - 10:51 PM
#3
Posted 12 June 2012 - 12:52 AM
#4
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.
#5
Posted 12 June 2012 - 02:14 AM
#6
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.
#7
Posted 12 June 2012 - 03:04 AM
#8
Posted 12 June 2012 - 08:21 AM
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] = 0They 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] = 0When 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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users











