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
Lovely-Windows
- yetneverdone
- Party member
- Posts: 446
- Joined: Sat Sep 24, 2016 11:20 am
- Contact:
Lovely-Windows
My GameDev Website
Going Home:A Pixelated Horror Game
My Repositories!
Follow me lovingly!
Nga pala, pinoy ako.
Going Home:A Pixelated Horror Game
My Repositories!
Follow me lovingly!
Nga pala, pinoy ako.
-
- Party member
- Posts: 512
- Joined: Wed Oct 05, 2016 11:53 am
Re: Lovely-Windows
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...
...as opposed to...
...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:
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.
Firstly, passing a list of window sizes like this...
Code: Select all
local width = {
f1 = 1024,
f2 = 720,
}
local height = {
f1 = 720,
f2 = 640
}
Code: Select all
local table = {
f1 = {1024, 720 },
f2 = {720, 640 }
}
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
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.
- yetneverdone
- Party member
- Posts: 446
- Joined: Sat Sep 24, 2016 11:20 am
- Contact:
Re: Lovely-Windows
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.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......as opposed to...Code: Select all
local width = { f1 = 1024, f2 = 720, } local height = { f1 = 720, f2 = 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.Code: Select all
local table = { f1 = {1024, 720 }, f2 = {720, 640 } }
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:
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).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
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.
Indeed, omitting the update function is better. I will make changes, thank you.
EDIT:
It's updated now
My GameDev Website
Going Home:A Pixelated Horror Game
My Repositories!
Follow me lovingly!
Nga pala, pinoy ako.
Going Home:A Pixelated Horror Game
My Repositories!
Follow me lovingly!
Nga pala, pinoy ako.
Who is online
Users browsing this forum: No registered users and 167 guests