Lovely-Windows

Showcase your libraries, tools and other projects that help your fellow love users.
Post Reply
User avatar
yetneverdone
Party member
Posts: 446
Joined: Sat Sep 24, 2016 11:20 am
Contact:

Lovely-Windows

Post by yetneverdone »

Hi, im excited to share with you lovely people my very first module/library for Love2D called Lovely-Windows.

See the github repo for more info
MrFariator
Party member
Posts: 509
Joined: Wed Oct 05, 2016 11:53 am

Re: Lovely-Windows

Post by MrFariator »

It's a pretty simple and straight forward library, but there are a few things I could comment on.

Firstly, passing a list of window sizes like this...

Code: Select all

local width = {
	f1 = 1024,
	f2 = 720,
}
local height = {
	f1 = 720,
	f2 = 640
}
...as opposed to...

Code: Select all

local table = { 
  f1 = {1024, 720 },
  f2 = {720,  640 }
}
...feels a bit haphazard, because it makes it harder to read the different window sizes available from each key. Even with relying on that "keys should match in width and height tables" recommendation is a bit of a misnomer, because unless the width and height tables match in terms of their keys, you WILL pass nil values in WINDOW.switch over to love.window.setMode. You could add small exception handling to WINDOW.addInputTable in order to avoid such troubles.

Additionally, looking at your WINDOW.update and WINDOW.switch methods, you could just remove the update method altogether and change the switch method to be like the following:

Code: Select all

-- At the top
local currentMode = "[default mode here]" 
-- ...
function WINDOW.switch(key)
  if key ~= currentMode then
    love.window.setMode(WIDTH[key], HEIGHT[key])
    WINDOW.initialize(_window.gameWidth,_window.gameHeight)
    currentMode = key
  end
end
This would allow you to forego the timer based approach to resolving an user holding a button down and thus having their resolution changed rapidly. Of course, you could still keep the timer to avoid rapid-fire window size switching if necessary (user could be pressing F1 and F2 very rapidly).

Also of note is your use of love.window.setMode. I might be remembering things wrong or think of outdated stuff from few LÖVE versions ago, but unless you pass the flags table as the third parameter, changes to the window's option flags won't persist. This could cause issues such as vsync turning on when it could be against the user's (and developer's) wishes.
User avatar
yetneverdone
Party member
Posts: 446
Joined: Sat Sep 24, 2016 11:20 am
Contact:

Re: Lovely-Windows

Post by yetneverdone »

MrFariator wrote: Mon Jun 05, 2017 5:25 pm It's a pretty simple and straight forward library, but there are a few things I could comment on.

Firstly, passing a list of window sizes like this...

Code: Select all

local width = {
	f1 = 1024,
	f2 = 720,
}
local height = {
	f1 = 720,
	f2 = 640
}
...as opposed to...

Code: Select all

local table = { 
  f1 = {1024, 720 },
  f2 = {720,  640 }
}
...feels like you'd have better success reinforcing the "tables should match" recommendation you have in the sample code. Even that recommendation is a bit of a misnomer, because unless the width and height tables match in terms of their keys, you will be nil values in WINDOW.switch. You could add small exception handling to WINDOW.addInputTable in order to avoid such troubles.

Additionally, looking at your WINDOW.update and WINDOW.switch methods, you could just remove the update method altogether and change the switch method like the following:

Code: Select all

-- At the top
local currentMode = "[default mode here]" 
-- ...
function WINDOW.switch(key)
  if key ~= currentMode then
    love.window.setMode(WIDTH[key], HEIGHT[key])
    WINDOW.initialize(_window.gameWidth,_window.gameHeight)
    currentMode = key
  end
end
This would allow you to forego the timer based approach to resolving an user holding a button down and thus having their resolution changed rapidly. Of course, you could still keep the timer to avoid rapid-fire window size switching if necessary (user could be pressing F1 and F2 very rapidly).

Also of note is your use of love.window.setMode. I might be remembering things wrong or think of outdated stuff from few LÖVE versions ago, but unless you pass the flags table as the third parameter, changes to the window's option flags won't persist. This could cause issues such as vsync turning on when it could be against the user's (and developer's) wishes.
Thanks for the feedback, as of now, the first problem/issue you presented has already been fixed and changed, also thanks to Positive07 for specifying also.

Indeed, omitting the update function is better. I will make changes, thank you.

EDIT:
It's updated now
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest