Page 18 of 18
Re: Post-0.10.0 feature wishlist
Posted: Fri Jan 06, 2017 10:50 pm
by reno57
First, i would like to say that love2D is very well designed, it is well balanced between easy access and power of game creation.
I don't use it since a long time, but the thing i miss the most is a basic GUI support to design my own game editor and tool.
Re: Post-0.10.0 feature wishlist
Posted: Sat Jan 07, 2017 9:07 pm
by CrackedP0t
reno57 wrote:First, i would like to say that love2D is very well designed, it is well balanced between easy access and power of game creation.
I don't use it since a long time, but the thing i miss the most is a basic GUI support to design my own game editor and tool.
There's currently an issue about this on the repo; the suggested feature is adding the Nuklear GUI library to LÖVE. Here's the link:
https://bitbucket.org/rude/love/issues/ ... s-a-native
Re: Post-0.10.0 feature wishlist
Posted: Thu Feb 09, 2017 12:20 am
by spill
I'm confused by all this argument about return values vs. erroring. If you want shader:send() to return a status code instead of erroring, why not just use pcall()? Doesn't that accomplish what folks are asking for? It seems totally reasonable to me that the default behavior is to error so the developer is aware of the problem. If you want to suppress an error, you can use
Code: Select all
local success, error_msg = pcall(function() shader:send("l", 3) end)
This seems better to me than making everyone wrap every call to shader:send() with assert(), since that makes the dangerous behavior of ignoring errors into the path of least resistance.
Also, FWIW: on my platform (Mac), unused variables are optimized out, but if you put the variable on a line by itself, it does not get optimized out, which I find useful for quickly swapping between two commented-out sections of code during development:
Code: Select all
uniform vec4 I;
vec4 effect(vec4 vcolor, Image tex, vec2 tc, vec2 pc) {
/*
I; // this line guarantees that shader:send("I", ...) won't error
return vec4(1,1,1,1);
*/
// You can uncomment the block above, and comment out the following line, and everything will keep working.
return Texel(tex) + I;
}
Re: Post-0.10.0 feature wishlist
Posted: Thu Feb 09, 2017 2:13 am
by slime
spill wrote:you can use
Code: Select all
local success, error_msg = pcall(function() shader:send("l", 3) end)
This can be reduced to the following code:
Code: Select all
local success, error_msg = pcall(shader.send, shader, "l", 3)
Re: Post-0.10.0 feature wishlist
Posted: Sun Jan 28, 2018 5:36 pm
by pgimeno
Sorry for posting this here. Bitbucket does not like this browser any longer (probably related to something within its ~1Mb JS code).
The 0.10.2 love.event.quit("reload") is nice, but as discussed lately, it doesn't fully allow restarting the application automatically. The hurdle is that when love.quit() returns true, it does nothing, therefore the application needs to be aware of whether there was a restart, to avoid returning true and perform shutdown in that case. An example of this pattern is Thrust II Reloaded, which offers a quit confirmation dialog by using the love.quit event. It doesn't save anything on exit, but there may be programs that do both, ask for confirmation and save on exit. Ignoring the result of love.quit in those cases would be wrong.
The proposed solution is to add two new values to the optional parameter of love.event.quit, namely "force" and "forcereload", and a new parameter to love.quit(). The new parameter would be true if "force" or "forcereload" was used, signalling that the return value of love.quit() will be ignored and that therefore the application needs to take any necessary cleanup actions immediately.
Re: Post-0.10.0 feature wishlist
Posted: Sun Jan 28, 2018 5:47 pm
by zorg
pgimeno wrote: ↑Sun Jan 28, 2018 5:36 pm
...
Do we need it to be this complicated though?
Re: Post-0.10.0 feature wishlist
Posted: Sun Jan 28, 2018 6:05 pm
by slime
Can you just do something like this?
Code: Select all
function restart()
love.event.quit("restart")
restarting = true
end
function love.quit()
if restarting then return end
-- other code does whatever, here.
end
Re: Post-0.10.0 feature wishlist
Posted: Sun Jan 28, 2018 8:04 pm
by pgimeno
The problem with that approach is that it is not transparent. Implementations can then make restart transparent (think an IDE like ZBS), and user programs only need to be aware about the parameter, with the advantage of it being documented as part of the engine.
Another problem with that approach is concurrency, in case love.event.quit("force") is issued from a thread, which sounds like the most convenient implementation of a hot restart library.