1. Anders Ruud
  2. love
  3. Issues


Issue #653 resolved

Removing checkMode

created an issue

Checking whether a mode is supported or not seems like a reasonable mechanism to offer. However, I'm not sure if it's so useful. :D

love.window.getModes returns the supported fullscreen modes, so surely checking whether a fullscreen mode is supported using checkMode is useless.

So what about windowed modes? Let's say the user can pick their own window size, and you want to check if it will work. checkMode seems like it would be useful for this, however there are two problems:

  • setMode returns whether it was successful or not. If the user enters something which isn't supported, the return value of setMode can be checked. (I've heard that setMode isn't perfect in this regard, so if this is the case I suggest that setMode do whatever checkMode does so it is perfect.)
  • checkMode will return true even if the specified dimensions are beyond the dimensions the screen. For example, love.window.checkMode(1000000000, 1000000000) returns true for me.

Comments (5)

  1. Alex Szpakowski

    checkMode (and getModes) are very useful because you can determine whether a resolution is supported without changing any state.

    This is particularly important for avoiding calls to love.window.setMode because calling that function will affect a great many things, including the user's computer's display mode and much of love.graphics.

    Having checkMode while getModes exists is not strictly necessary, but it's very handy when you don't want to have to search through a table and compare your suggested resolution to the list of supported ones.

    I believe it's technically possible for the window to be much larger than the desktop resolution in windowed mode, but it probably isn't desired. Changing checkMode to test against the current desktop resolution if the fullscreen boolean isn't set might be a good idea, but I don't think it's possible to get the current desktop resolution without SDL 2.0.

    EDIT: apparently my SDL 2 branch already does the check against desktop resolution, go figure. :P

  2. hahawoo reporter
    • changed status to open

    Ahahaha, your SDL 2 branch is ruining all my issues! :P

    So, with SDL 2, if the following two things are true:

    • getModes returns all the supported fullscreen modes.
    • All windowed modes within the desktop dimensions are supported.

    Then checkMode is what I call a "shortcut": something which does something you could do otherwise, and isn't there for performance.

    However, it breaks a couple of The Indisputably Questionable Laws of Shortcuts:

    1. Shortcuts are equivalent to a very small amount of code. (They're about making mechanisms nice to use, not about making policy, after all.)
    2. It's super useful. Like, seriously. You will use this all the time.

    I think that all (maybe) of the shortcuts in the API (which I haven't made issues for already :P) follow the above rules, but I don't think checkMode follows either.

    On why I don't think it's super useful, I should say first that it could be totally useful, I'm not saying this function could never be used, because it definitely could. But, I don't think it's super super common.

    Let's say you have a game, and it can be fullscreen. And, the user can change the fullscreen resolution. You're probably going to want a list of avaiable fullscreen resolutions for the player to choose from. This will use getModes, and it's guaranteed to be supported, no need for checkMode.

    But of course, if the user types in their own resolution for some reason, you are going to want to check it against what it returned by getModes.

    Now let's say you have a game which can be windowed, and the user can change the window resolution to whatever they want. Maybe the game has some "scale" setting, or maybe the game can adapt to any window size. And, you don't want the user to be able to select dimensions which would go off their screen. If the game has a scale setting, you'd probably want to get the desktop dimensions and limit the scale options accordingly. Or, if the user can set whatever dimensions they want for some reason, you would indeed want something like checkMode.

    And on the point of shortcuts being equivalent to small amounts of code, it just seems to be how LÖVE does it. Here are some examples:

    • love.graphics.getHeight is equivalent to select(2, love.graphics.getMode())
    • love.graphics.rectangle is equivalent to love.graphics.polygon(mode, x,y, x+w,y, x+w,y+h, x,y+h)
    • love.mouse.getPosition is equivalent to love.mouse.getX(), love.mouse.getX()

    Can anyone find a shortcut function which is equivalent to more than a few lines? I don't think this is random, I think it's because if takes more lines to write, it's probably saying how things should be done, i.e. policy stuff, rather than being helpful functions to make using what LÖVE does nice to use.

    On the other hand, checkMode is more code, although it's still trivial to implement. For illustration, and the for the copy and paste pleasure of anyone who this function could be useful for, here's checkMode in Lua:

    function checkMode(width, height, fullscreen)
        if fullscreen then
            local modes = love.window.getModes()
            for _, mode in pairs(modes) do
                if mode.w == width and mode.h == height then
                    return true
            return false
            local desktopWidth, desktopHeight = love.window.getDesktopDimensions()
            return width <= desktopWidth and height <= desktopHeight
  3. hahawoo reporter
    • changed status to open

    I'm not entirely sure why I marked this as on hold, heh. I still think it should be removed. Basically:

    • The only use case seems to be for user-specified screen dimensions. This seems relatively rare.
    • It's trivial to loop through the getModes table if the need does arise.
  4. Log in to comment