Post-0.10.0 feature wishlist

[airstruck]

The rationale is that it's worse to have the code work flawlessly in your computer, and then crash when the program is made public (case in point), than to have a hard time debugging shader code because of a mistyped variable, because when it works, it will (in principle) work for everyone.

Also, the status code provides debuggability.

That sounds more in line with the guidelines described in PIL: https://www.lua.org/pil/8.3.html

Since you can't easily check for the error yourself beforehand, it should return nil and a status message rather than throwing an error (as a general guideline, according to PIL). Then if you want to throw on failure you can do assert(Shader:send(...)) and your status message will show up as the error message, being the second argument to assert. If you just want to check if there was an error without throwing, leave out the assert. With the current behavior, you don't have that choice.

[slime]

Also, the status code provides debuggability.

OpenGL does not provide a way for love to expose more than "true/false" as a status code. (OpenGL does not indicate whether the variable was optimized out or not, it simply exists in the final compiled Shader, or it does not.)

Shader:send in LOVE 0.10.2+ does argument type and count checking based on the shader uniform's type (and count, for arrays). This is not possible without the variable existing in the final compiled OpenGL shader, so if love were to do something other than error for optimized out or missing variables, then it would fail to properly check its arguments - which means you'd have a worse situation than before, because if driver A optimizes it out and driver B doesn't, you will get confusing errors on some computers if your arguments to shader:send don't match the variable's type information.

[raidho36]

I have to believe this has to do with nVidia GPU compilers being far more lenient about throwing errors, and willing to chew through poorly written code. This have caused many pains to many developers, since they didn't know the error was there until someone else ran into it, and then they also had problems debugging it since to them it was fine to start with, so they can't see the improvement. One way around it is to force yourself to strictly follow the DirectX and (for LÖVE specifically) OpenGL specifications. Another option is to test GPU code on an AMD or Intel GPUs. The simplest solution is, of course, to use static analyzer, but it's not a silver bullet.

[pgimeno]

Also, the status code provides debuggability.

OpenGL does not provide a way for love to expose more than "true/false" as a status code. (OpenGL does not indicate whether the variable was optimized out or not, it simply exists in the final compiled Shader, or it does not.)

I'm not suggesting to return a status telling whether the variable was optimized or not. I'm suggesting what airstruck said: to return either true if the send succeeds, or false (or nil) plus a message if it fails, leaving it up to the application whether to throw an error or not. That provides debuggability for the case where you mistyped the name of the uniform.

Shader:send in LOVE 0.10.2+ does argument type and count checking based on the shader uniform's type (and count, for arrays). This is not possible without the variable existing in the final compiled OpenGL shader, so if love were to do something other than error for optimized out or missing variables, then it would fail to properly check its arguments - which means you'd have a worse situation than before, because if driver A optimizes it out and driver B doesn't, you will get confusing errors on some computers if your arguments to shader:send don't match the variable's type information.

(emphasis mine). Do you mean it's not possible to return the message instead of throwing it as an exception? That's very odd.

[slime]

Do you mean it's not possible to return the message instead of throwing it as an exception? That's very odd.

It's possible, but doing so prevents love from erroring due to incorrect arguments (for example, passing a string instead of a number, or passing the wrong number of components to a vector uniform) in situations where the uniform variable was optimized out or was typo'd. That's much more insidious and harmful behaviour in my opinion, since it will cause subtle bugs that are hard to track down, so I'd rather stick with what we have right now.

It can't do argument validation in those situations because it doesn't know what to check for.

[drunken_munki]

(...)

It may or may not be practical, but iirc the colors work as (extra) vertex attributes for each defined sprite in the batch; as far as i know, you can't set the blendMode like that. (Or at the least, you can't have separate blendmodes in one draw call, which is i think what spritebatches do) This is something probably relevant that i've found.

That is interesting, I'll check it out. In the mean time I'll have to keep my weird buffered spritebatch thing that I made :/

[drunken_munki]

Keep in mind love is open source and anyone is welcome to contribute! I don't really have the capacity to significantly improve distribution workflow myself, right now.

Hiho, I know man.

I will be trying my hand soon enough, the problem I have is that I have no idea how compiling cpp works and every time I try everything explodes.

I want to learn... and edit the notepad++ code as well as Love code, but alas I'm on windows and I can't ever get it to compile. There is always nth number of additional libraries I must get (and possibly self compile as well) and I just can't find a guide to help set it all up :/

[raidho36]

But are you proficient with c++? It's not the easiest, simplest and straightforward language out there. Wrapping your head around how LÖVE works takes a while, too. Having to learn c++ is hard enough on its own, but if you're not already good with and you're gonna use it to patch the framework you haven't yet dive into then you're in for a vertical cliff of a learning curve.

If you really want it, consider simply using Linux on your development machine. That way at least the build process is completely streamlined and requires no setup not tinkering.

[pgimeno]

Do you mean it's not possible to return the message instead of throwing it as an exception? That's very odd.

It's possible, but doing so prevents love from erroring due to incorrect arguments (for example, passing a string instead of a number, or passing the wrong number of components to a vector uniform) in situations where the uniform variable was optimized out or was typo'd.

I don't get it. In these situations, the error message is "Shader uniform 'name' does not exist. A common error is to define but not use the variable." Am I wrong? That's the error I'd like to see removed, as that situation is harmless when it's the result of optimizing out a uniform, yet throwing an error is harmful in situations where it goes undetected in the developer's machine. And yes, I'm aware that mistyping a variable name can be much harder to debug when you don't have an error message, and that's why I'm proposing to return a status. In my opinion it's much better to have something that is difficult to debug, than to have something that you think is flawless and then have it crash when it's released.

[slime]

I don't get it. In these situations, the error message is "Shader uniform 'name' does not exist. A common error is to define but not use the variable." Am I wrong? That's the error I'd like to see removed, as that situation is harmless when it's the result of optimizing out a uniform

Consider this situation:

Code: Select all

shader = love.graphics.newShader[[
uniform vec4 I;
vec4 effect(vec4 vcolor, Image tex, vec2 tc, vec2 pc) {
    vcolor *= I;
    return Texel(tex);
}
]]

shader:send("l", 1) -- oops, I made two mistakes: I used lower-case L instead of upper-case i, and I sent a float instead of a vec4.

Your graphics driver will likely optimize the "I" variable away.

With the current system, love will error when that happens, and then if you fix that (which is almost guaranteed to be necessary to get your game working) it will error again because you sent a float instead of a vec4 to a vec4 variable.

With what you propose, the first error will be silent unless you actively go out of your way to check for it. This will lead to many situations where people will struggle to understand why things are not visually looking as they'd expect. In addition, if it doesn't optimize the variable away on a system, that system will not error at all even though you're sending the wrong argument values (float instead of vec4) to the uniform variable. So it now breaks almost silently in both of those cases.