Best practices and things you'd like changed about Love2D

[zorg]

What if, there was some sort of priority system?
For example:
I need draw rectangle with specific color, but i already have modified colors
<snip>
What about that?

There is, kind of; you can do the following:

Code: Select all

love.graphics.setColor(1, 0.5, 1)
love.graphics.rectangle("fill", 200, 200, 100, 100)
love.graphics.push('all') -- saves most graphics state, including colors
love.graphics.setColor(0.4, 1, 0.5)
love.graphics.rectangle("fill", 0, 0, 100, 100)
love.graphics.pop() -- restore graphics state

Push/Pop can also be nested, of course, to some reasonable degree.

[GVovkiv]

What if, there was some sort of priority system?
For example:
I need draw rectangle with specific color, but i already have modified colors
<snip>
What about that?

There is, kind of; you can do the following:

Code: Select all

love.graphics.setColor(1, 0.5, 1)
love.graphics.rectangle("fill", 200, 200, 100, 100)
love.graphics.push('all') -- saves most graphics state, including colors
love.graphics.setColor(0.4, 1, 0.5)
love.graphics.rectangle("fill", 0, 0, 100, 100)
love.graphics.pop() -- restore graphics state

Push/Pop can also be nested, of course, to some reasonable degree.

Yeah, but it still not that good, than just set "love.graphics.rectangle("line", 0, 0, 100, 100, {colors}), without need to wrap things inside another function

[Nelvin]

Just replace the function with one using the parameters you prefer

Code: Select all

local lg_rectangle = love.graphics.rectangle

love.graphics.rectangle = function( mode, x, y, width, height, color )
    if color then
        local cur_r, cur_g, cur_b, cur_a = love.graphics.getColor()
        love.graphics.setColor( color )
        lg_rectangle( mode, x, y, width, height )
        love.graphics.setColor( cur_r, cur_g, cur_b, cur_a )
    else
        lg_rectangle( mode, x, y, width, height )
    end
end

[zorg]

Yeah, but it still not that good, than just set "love.graphics.rectangle("line", 0, 0, 100, 100, {colors}), without need to wrap things inside another function

It's not wrapped in another function; you just have 2+1 extra function calls.

[grump]

Why even stop at color? There's so many more states that could be passed to the function instead.

Code: Select all

function love.graphics.rectangle(mode, x, y, w, h, rx, ry, segments, r, g, b, a, blendmode, alphamode, angle, sx, sy, ox, oy, kx, ky, linestyle, linewidth, shader, canvas, ...)

[GVovkiv]

It's not wrapped in another function; you just have 2+1 extra function calls.

So, you want say, that:

Code: Select all

	love.graphics.setColor(1, 1, 1)
	love.graphics.setShader(shader)
	*etc*
	love.graphics.rectangle(...)
	
	-- draw object with some specific colors, etc
	love.graphics.push("all")
	love.graphics.setColor(...)
	love.graphics.setShader(...)
	love.graphics.rectangle(...)
	love.graphics.pop()
	
	*OR if i want to draw that object again somewhere, i wrap it in*
	
	function draw(...)
		love.graphics.push("all")
		love.graphics.setColor(...)
		love.graphics.setShader(...)
		love.graphics.rectangle(...)
		love.graphics.pop()
	end

Better, then:

Code: Select all

	love.graphics.setColor(1, 1, 1)
	love.graphics.setShader(shader)
	*etc*
	love.graphics.rectangle(...)
	
	-- draw object with some specific colors, etc
	love.graphics.rectangle(drawMode, x, y, w, h, r, g, b, a, shader, etc)

[grump]

Doing it your way would either involve a lot of branches, or a lot of potentially superfluous saving and restoring of graphics state. Both of those are bad for performance. The way it is implemented now is close to how the underlying OpenGL API works and what GPUs are optimized for. Engines and frameworks are specifically optimized to make use of batching, with the goal being to avoid these state changes as much as possible, because they are so slow.

A well programmed game sorts its primitives anyway, in a way that makes it easier for the framework to batch drawcalls and for the GPU to perform well. Your proposal would only make it easier to write bad/slow code, for no real benefit.

If you want things to work this way, you can easily write the code once on top of the existing API, and use it in your projects. It won't be very performant though.

[GVovkiv]

Doing it your way would either involve a lot of branches, or a lot of potentially superfluous saving and restoring of graphics state. Both of those are bad for performance. The way it is implemented now is close to how the underlying OpenGL API works and what GPUs are optimized for. Engines and frameworks are specifically optimized to make use of batching, with the goal being to avoid these state changes as much as possible, because they are so slow.

A well programmed game sorts its primitives anyway, in a way that makes it easier for the framework to batch drawcalls and for the GPU to perform well. Your proposal would only make it easier to write bad/slow code, for no real benefit.

If you want things to work this way, you can easily write the code once on top of the existing API, and use it in your projects. It won't be very performant though.

ok