Post-0.10.0 feature wishlist

General discussion about LÖVE, Lua, game development, puns, and unicorns.
reno57
Prole
Posts: 17
Joined: Thu Apr 14, 2016 9:46 pm

Re: Post-0.10.0 feature wishlist

Post by reno57 » Fri Jan 06, 2017 10:50 pm

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.

User avatar
CrackedP0t
Citizen
Posts: 69
Joined: Wed May 07, 2014 4:01 am
Contact:

Re: Post-0.10.0 feature wishlist

Post by CrackedP0t » Sat Jan 07, 2017 9:07 pm

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
/人 ◕‿‿◕ 人\
Here, have an umlaut. Ö

User avatar
spill
Prole
Posts: 27
Joined: Thu May 07, 2015 1:53 am
Contact:

Re: Post-0.10.0 feature wishlist

Post by spill » Thu Feb 09, 2017 12:20 am

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;
}

User avatar
slime
Solid Snayke
Posts: 2853
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: Post-0.10.0 feature wishlist

Post by slime » Thu Feb 09, 2017 2:13 am

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)

User avatar
pgimeno
Party member
Posts: 1903
Joined: Sun Oct 18, 2015 2:58 pm
Location: Valencia, ES

Re: Post-0.10.0 feature wishlist

Post by pgimeno » Sun Jan 28, 2018 5:36 pm

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.

User avatar
zorg
Party member
Posts: 2731
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Post-0.10.0 feature wishlist

Post by zorg » Sun Jan 28, 2018 5:47 pm

pgimeno wrote:
Sun Jan 28, 2018 5:36 pm
...
Do we need it to be this complicated though?
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

User avatar
slime
Solid Snayke
Posts: 2853
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: Post-0.10.0 feature wishlist

Post by slime » Sun Jan 28, 2018 6:05 pm

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

User avatar
pgimeno
Party member
Posts: 1903
Joined: Sun Oct 18, 2015 2:58 pm
Location: Valencia, ES

Re: Post-0.10.0 feature wishlist

Post by pgimeno » Sun Jan 28, 2018 8:04 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests