LÖVE

RaptrStudios wrote:Make a table to hold the data.

Code: Select all

window_table = {
    x = {
        value = love.window.getWidth()
    }

    y = {
        value = love.window.getHeight()
    }
}

That's what i use but it might not work.
Its nice and organized.

Not sure what you're trying to say here, mate, but I've pretty much got it handled for the most part when it comes to that.

Only two cases one would need to consider with multi-screen setups if you are programmatically moving the window at times:
- Whether the code moved the window
- Whether the user moved the window
The first may have issues if the topleft of the window is already near a monitor's edge, but that one thing i never tested when i was messing around with ffi getting the "global" desktop coordinates of the löve window... may work, or may die stating the position is errorenous;
The second has the problem that to my knowledge, there's no callback present for when a user moves the window and releases the drag; might be an useful thing... Anyway, that probably leaves you with checking the current display at all times, and adjusting accordingly;

3 variables should be enough to save the position of the window; x (left), y (top) and the current display.

Kingdaro wrote:

S0lll0s wrote: There's a really, really high chance you're not using the latest version of love.

Oh right, I downgraded recently to test something. It works now.

Runs just fine on my Win8.1 box. No performance issues, and the effect is really neat. But it's important that something like this can be turned off in the settings.

zorg wrote:Only two cases one would need to consider with multi-screen setups if you are programmatically moving the window at times:
- Whether the code moved the window
- Whether the user moved the window
The first may have issues if the topleft of the window is already near a monitor's edge, but that one thing i never tested when i was messing around with ffi getting the "global" desktop coordinates of the löve window... may work, or may die stating the position is errorenous;
The second has the problem that to my knowledge, there's no callback present for when a user moves the window and releases the drag; might be an useful thing... Anyway, that probably leaves you with checking the current display at all times, and adjusting accordingly;

3 variables should be enough to save the position of the window; x (left), y (top) and the current display.

In theory, the display shouldn't need to be saved as a variable, for reasons I couldn't really explain.

T-Bone wrote:Runs just fine on my Win8.1 box. No performance issues, and the effect is really neat. But it's important that something like this can be turned off in the settings.

Definitely, yeah. Good to know it works, though.

Kingdaro wrote:In theory, the display shouldn't need to be saved as a variable, for reasons I couldn't really explain.

You're right in that you could just get the current display and use that in your window shake function, but that still might move the window outside of one display, meaning wrapping will occur, and the window will appear on the opposite side of the screen (happens now as well)
This really can't be solved imo without getting the desktop coordinates of the window, though there may be ways i haven't considered...

on my machine it works wonderfully except that it moved quite a bit to right from the original position. My os is ubuntu if it makes a difference.

zorg wrote:

Kingdaro wrote:In theory, the display shouldn't need to be saved as a variable, for reasons I couldn't really explain.

You're right in that you could just get the current display and use that in your window shake function, but that still might move the window outside of one display, meaning wrapping will occur, and the window will appear on the opposite side of the screen (happens now as well)
This really can't be solved imo without getting the desktop coordinates of the window, though there may be ways i haven't considered...

I'm not sure. I think it really works either way, though. I thought of this example in the time I worked on other things.

Let's say, for all intents and purposes and for easy math, that the monitor width is 2000, and there's another monitor beside that with the same width. Then we'll say that the window is at x 1995, and the screenshake would put it at x 2005 on the next frame, so the WindowShake module says "alright, we're currently at display 1, so we'll go to x 2005 using display 1".

There are two things that could happen here. The first being that it'll loop to the second window, in which case, the second display will be used on the next frame. The second being that it's still registered as being on display 1 at that position, which is unlikely, but should still work all the same.

The module already accounts for the user moving the window (by using two separate coordinate variables, window(X/Y) to keep track of the "base" window position, and offset(X/Y) for how much to change it the next frame), so either way, just checking the display on the current frame should in theory work out fine. If there's anything wrong with my logic, let me know.

bobbyjones wrote:on my machine it works wonderfully except that it moved quite a bit to right from the original position. My os is ubuntu if it makes a difference.

Huh. I'm not sure what would cause that, other than perhaps ignored calls to love.window.setPosition()? Last I checked, there wasn't a way to see if the call successfully went through, but I guess that's why it's good to just make it an option, then.

Kingdaro wrote:(...) If there's anything wrong with my logic, let me know.

A bit tired tonight, and got work tomorrow, and still gotta work on my own things; i'll do some tests whenever i have time, allright?