LÖVE

OMGAlec wrote:This is a great module though I would like to ask for some clarification on a certain subject as the wiki entry has some ambiguous verbiage that doesn't help to explain a certain functionality.

My inquiry is of the apparent change in working with mouse coordinates that I've seen from an old build from January to the most recent build. In the old build love.mouse.getX() (For example), when the camera is set to my general world camera, would return coordinates of the arbitrary units that CAMERA uses, for clarification let us call these CU for CAMERAunit. The old functionality was that calling a mouse position function would return coordinates of the mouse relative to its position in the window but it would use CU instead of pixels to describe its position. I got used to this.

The new functionality however returns mouse position as coordinates of the mouse in the game-world in CU, and using pos() would translate this into coordinates relative to the window but in pixels. This functionality makes sense as unpos() is used to convert from pixel coordinates and returns in-game CU.

Now my question is; is there a way to convert in-game CU coordinates to CU coordinates that are relative to the window?

Again, this might be explained by using setMouseCamera() but the wording of the documentation doesn't explain it in such a way I can understand.

A description of context:

I'm trying to convert the camera system that I've written for the old design to be used with the new CAMERA, but here's where it gets snagged:

OLD(pseudocode):

Code: Select all

MouseXDistanceFromCenter = MouseX(CUR) - (ScreenWidth(CUR) / 2)
MouseYDistanceFromCenter = MouseY(CUR) - (ScreenHeight(CUR) / 2)

Origin = PlayerX(CUA) + MouseXDistanceFromCenter(CUR), PlayerY(CUA) + MouseYDistanceFromCenter(CUR)

CUR = CAMERAunits relative to the camera
CUA = CAMERAunits absolute definition in the world

The intent was to have the center of the screen be between the mouse and the player so that the camera doesn't stagnate centering on the player but instead follows the mouse to an extent to show more of the world. This implementation worked at the time because mouse positions returned were relative to its position on screen. It even worked with scaling. If the mouse is never moved, then the value is never changed and the mouse stays a constant distance from the player. The scrolling was super smooth when it was done this way.

NEW(pseudocode):

Code: Select all

Origin = (PlayerX(CUA) + MouseX(CUA)) / 2, (PlayerY(CUA) + MouseY(CUA)) / 2

With the new way I've had to average the distance of two absolute CU coordinates to find the middle. This works as intended, but now that even without moving the mouse around, when the player moves the mouse coordinates change. I'm not sure if it's originating from the fact that when one moves the mouse, since the origin moves as well, when the screen moves it also repositions the mouse. What it ends up looking like is that there's a lag when beginning mouse movement and a damping effect when mouse movement is supposed to have stopped for a few frames after the fact. Also, when falling, the origin and player deviates a bit in relation to the mouse.

This is a really hard problem to describe without being able to actually move the mouse and feel the difference in tactile response.

Any help would be appreciated.