LÖVE

Posted: **Sun Dec 20, 2015 6:58 am**

I think the current graphics api style is the most new user friendly. I don't think switching it up will make it anymore nice. Especially considering this is a framework that is used by a ton of noobs.

Posted: **Sun Dec 20, 2015 12:16 pm**

zorg wrote:
bobbyjones wrote:Love can't become 1.0 until is has HTTPS and microphone support lol.
And an expanded (better) audio API in general

You really dont want to mess around with audio and openal!

Posted: **Sun Dec 20, 2015 4:15 pm**

Murii wrote:
zorg wrote:
bobbyjones wrote:Love can't become 1.0 until is has HTTPS and microphone support lol.
And an expanded (better) audio API in general
You really dont want to mess around with audio and openal!

Believe me, i intend to!

Posted: **Mon Dec 21, 2015 5:11 am**

kikito wrote:
The graphics library will be separated. Object creation (like newCanvas, newQuad), window functions (like setCaption) and system stuff (like getRendererInfo) will remain in love.graphics. Drawing (line, circle) as well as state (push, pop, etc) will be moved to the Canvas object. So you will do canvas:circle(...) instead of love.graphics.circle(...).

Related to the previous one, love.draw will receive the "default canvas" as a parameter, just like love.update receives dt. The default canvas will be "special" in the sense that the LÖVE loop is the one which maintains it, and also will expand/contract if the window size changes.

What are the reasons for these changes? What do they achieve that can't be done now?

Posted: **Mon Dec 21, 2015 6:57 am**

slime, I have a question: I remember you saying that the new Mesh Attributes will be able to solve the following problem of texture distortion (AKA the resulting image not having perspective correctness), when drawing "textured polygons":

How would that look in code? Also, would it be theoretically possible to use the attribute system in order to have a sort of depth-buffer?

Posted: **Mon Dec 21, 2015 10:19 am**

adnzzzzZ wrote:What are the reasons for these changes? What do they achieve that can't be done now?

Main reason is removing global state. The fact that LÖVE has a "global current canvas" makes all drawing-related code not pure. Yes, this means that all drawing functions would get a 'canvas' param. That's worth it in my mind. "update" functions already get a "dt" parameter and that's ok. Pure functions are always prefearable to non-pure ones (Don't take my word for that).

I also suspect that the LÖVE internal code would get simplified if it didn't have to keep track of the global state. At the very least you would remove set/getCanvas.

The interface would also look similar to what you find in other environments like javascript and the browser, where the "canvas" abstraction is the one used to draw.

When I proposed this change I didn't know that OpenGL needed a "current canvas" for performance reasons though.

Posted: **Mon Dec 21, 2015 10:26 am**

kikito wrote: I also suspect that the LÖVE internal code would get simplified if it didn't have to keep track of the global state. At the very least you would remove set/getCanvas.

On the contrary, it probably requires more work since OpenGL is very stateful itself.

Although I would like a more explicit API, it's very easy to make things very expensive without noticing. If you keep having to change (practically) all state between two alternating calls, the code itself may hide this.

Posted: **Mon Dec 21, 2015 2:43 pm**

kikito wrote:When I proposed this change I didn't know that OpenGL needed a "current canvas" for performance reasons though.

bartbes wrote:On the contrary, it probably requires more work since OpenGL is very stateful itself.

In this case it's not just OpenGL that has this state – GPUs themselves only operate on one (set of) render targets / Canvases at a time, and switching that set to a different one can be very expensive in the hardware. That will remain true even if DirectX 12 or Vulkan or Metal is used.

Those newer APIs do have ways to schedule different lists of commands at once to be executed for different sets of render targets, by having 'command list' / 'draw pass' objects you can create and pass around. But the order that those command lists will be executed in still needs to be determined at some point, so exposing that capability would make the API more complicated.

Posted: **Sat Dec 26, 2015 10:59 am**

slime wrote:
pgimeno wrote:
Code: Select all
function Canvas:circle(...)
  love.graphics.setCanvas(self)
  love.graphics.circle(...)
end

Or, make a pseudo-canvas :

Code: Select all

-- In a a file :
local GlobalCanvas = Object:new ()

function GlobalCanvas:circle (...)
     love.graphics.circle (...)
end

function love.graphics.getCanvas ()
    -- Code for checking if a real canvas is setted
    -- If no canvas is setted :
    return GlobalCanvas
end

This method allow the two usage :

The current usage, so with love.graphics.* functions ;
The "new" usage, so with canvas:* functions ;

And, for the problem of efficiency of ".setCanvas" :

Code: Select all

-- In a file lol

-- A tracking variable
local currentCanvas = nil

function love.graphics.setCanvas(canvas)
    if canvas == currentCanvas then
        return
    end
    -- Set the current Canvas.
end

-- In another file

function Canvas:circle (...)
    love.graphics.setCanvas (self)
    love.graphics.circle (...)
end

With this, we set the canvas only once, even with multiple call of .setCanvas. ( BTW, I think this check is already done internally, but I add it anyway

)

LÖVE

Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0

Re: Requesting 1.0.0 instead of 0.10.0