Requesting 1.0.0 instead of 0.10.0

[Linkpy]

Löve can have many, MANY more thing. It go forward a "professional framework". Look, there are no API for handling sub-process. No compression API, audio/video device API, no IPC API, etc etc.

A pro framework needs many feature, no only features that users see, also features which give powerful abilities to the game. You can do a game right know, but you may need to do many features yourself (like IME input : you need to make your own IME-like system if you want something like this in your game).

By the way, I not only use Löve for games, but also for software, which may need advanced features like IPC, or sub-process handling. Just for example, I am making a game with Löve, and I need an editor which can create ".zip" file. I can't do it with my beloved Löve framework, because there no way, directly in Löve or Lua, to create ZIP files. For me, Löve can go much further.

(And if I need to wait HL3 for this, I'll wait HL3, just for Löve )

[zorg]

Love can't become 1.0 until is has HTTPS and microphone support lol.

And an expanded (better) audio API in general

[Jasoco]

Löve is extremely capable and stable as it is now. It doesn't need a silly version number to be accepted as legit. Things change with every version. It's going to creep towards 1.0 at the pace they want it to.

You want 1.0, feel free to download it from a server in the future.

[kikito]

Since we are talking (more or less) about predictions for breaking things for 1.0.0, here are my expectations/hopes:

• There will be a way to easily play the same source simultaneously multiple times. (I have already suggested one possible way of doing this, by making play() return the source)
• 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.
• LÖVE will continue to provide a basic default, expandable via libraries. Certainly not going in the direction Linkpy is proposing.

[slime]

• 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.

I've actually been thinking about doing something like this. There are a few issues that I can see happening though (which may or may not end up being real issues in practice):

• It might be less pleasant for libraries and other separated bits of game code to draw things, as a Canvas object would probably have to be passed around everywhere.
• It could involve more code to do some things, as you'd have to set the state for each individual Canvas you want to use. Although you often have to do that anyway.
• Because each Canvas would have its own state, the issue of accidentally using old per-frame state set by something else could turn into accidentally using very old state set once somewhere else, and it might be harder to track down where that happened.
• Due to the way graphics hardware works, it'll be impossible to have reasonable performance unless setCanvas (or something similar) still exists – so there would only be a single Canvas active at any given time, and draws to inactive canvases would have to fail. Which is kind of an unintuitive API to explain.

Those last two might be solved if (the equivalent of) setCanvas returned an object that has draw and state methods, rather than said methods operating on the Canvas itself. I want to experiment with stuff like this after 0.10.0 is out.

(also, "setCaption" has been in love.window as love.window.setTitle for a couple years now. )

Löve can have many, MANY more thing. It go forward a "professional framework". Look, there are no API for handling sub-process. No compression API, audio/video device API, no IPC API, etc etc.

A pro framework needs many feature, no only features that users see, also features which give powerful abilities to the game. You can do a game right know, but you may need to do many features yourself (like IME input : you need to make your own IME-like system if you want something like this in your game).

LÖVE 0.10.0 has some APIs for compression (not zip files though, as it doesn't deal with folders or multiple files) and video playback, and it already has some functions to deal with IME input ([wiki]love.keyboard.setTextInput[/wiki] and [wiki]love.textinput[/wiki]).

LÖVE will always be game-focused though, and I don't see it getting sub-process or IPC functionality beyond what you can do right now with Lua's APIs and luasocket.

And an expanded (better) audio API in general

I definitely want this, but I'm not very good at designing audio APIs. Suggestions are welcome!

[kikito]

• It might be less pleasant for libraries and other separated bits of game code to draw things, as a Canvas object would probably have to be passed around everywhere.

That argument almost gets cancelled by the fact that canvas:circle is shorter to write than love.graphics.circle. The real one for me is that explicit dependencies are better than relying on globals (which is what setCanvas does right now).

• Because each Canvas would have its own state, the issue of accidentally using old per-frame state set by something else could turn into accidentally using very old state set once somewhere else, and it might be harder to track down where that happened.

In the current system, if someone is using several canvases and they forget to call setCanvas once, tracking that bug down can be equally difficult (if they are using a significant number of canvases, in any case).

• Due to the way graphics hardware works, it'll be impossible to have reasonable performance unless setCanvas (or something similar) still exists – so there would only be a single Canvas active at any given time, and draws to inactive canvases would have to fail. Which is kind of an unintuitive API to explain.

I didn't know that. Very unfortunate, then.

(also, "setCaption" has been in love.window as love.window.setTitle for a couple years now. )

Heh. You know what I meant

And an expanded (better) audio API in general

I definitely want this, but I'm not very good at designing audio APIs. Suggestions are welcome!

My suggestion is: make love.audio maintain a "pool" of "currently playing sources", and make .play() create (and return) one of those sources demand, if none is available. Also, clean up the pool regularly.

I made a Lua-only implementation here: https://github.com/kikito/ld-30/blob/ma ... source.lua

It requires a manual "cleanup" call per source, which is not ideal.

[pgimeno]

[*]Because each Canvas would have its own state,

Why not make that optional? Have a canvas.state pointing to the global state, and do this if you want it separate:

Code: Select all

canvas.state = love.graphics.newState()

Too much burden?

[*]Due to the way graphics hardware works, it'll be impossible to have reasonable performance unless setCanvas (or something similar) still exists – so there would only be a single Canvas active at any given time, and draws to inactive canvases would have to fail. Which is kind of an unintuitive API to explain.

Is this too misguided?

Code: Select all

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

(that's a sketch, of course - needs state tracking as above for one; take it as pseudocode)

[zorg]

And an expanded (better) audio API in general

I definitely want this, but I'm not very good at designing audio APIs. Suggestions are welcome!

My suggestion is: make love.audio maintain a "pool" of "currently playing sources", and make .play() create (and return) one of those sources demand, if none is available. Also, clean up the pool regularly.
I made a Lua-only implementation here: https://github.com/kikito/ld-30/blob/ma ... source.lua
It requires a manual "cleanup" call per source, which is not ideal.

My suggestions would be more along the line of how we could allow dynamically generated music (along with access to aural input devices like microphones, though solutions to both do exist, it's just external to love, and it could probably be made internal as well)

On another note, currently the API treats module files just like wave, mp3 and ogg files; they are decoded linearly into streams as well, not allowing more fine-grained access to raw module file data, like position jumping (or even reading out notational data). Then again, i'm only bringing such things up since supporting module files themselves already means having the necessary library included to actually do more with them... at least in a more advanced playback sense. I do see that this would mean that the API would not be homogenous across different audio data types.

[slime]

Code: Select all

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

Unfortunately that would encourage code that would murder performance for no apparent reason. Switching canvases is probably the most expensive operation love.graphics can do (aside from creating new objects of course.) On mobile devices, even a single additional canvas change per frame can be the difference between vsync'd 60fps and vsync'd 30fps – you generally shouldn't have more than a dozen per frame (and hopefully much fewer), on iOS and Android. On desktops it's still relatively really expensive, but not quite as much.

Something as "simple" as this would be far far far more expensive than it seems:

Code: Select all

function love.draw()
    for i=1, 10 do
        canvases[i]:circle("fill", 10, 10, 10)
    end
end

Another issue with having draw calls as methods on Canvases is that in LÖVE 0.9 and 0.10 it's possible (and necessary, for some advanced graphics techniques) to output different things to multiple canvases within the same draw call, whereas that API would kind of make it impossible. LÖVE currently allows you to pass in multiple different canvases to [wiki]love.graphics.setCanvas[/wiki], and Shaders can output different values to each.

If setCanvas returned an object that has drawing and state methods, rather than the drawing methods being part of the Canvas object itself, multi-canvas rendering would still be possible and graphics drawing-related state wouldn't be global, but I think it still might have some usability issues (passing objects around, library functions invalidating the current 'draw pass' object, etc.)

[pgimeno]

Switching canvases is probably the most expensive operation love.graphics can do

Ouch, and here I was, thinking that Canvas:getImageData trumped them all...

I get your point. Shame. Trading the convenience of writing it that way for the performance problems it will bring to unwary users is probably not worth it, then. Even wary users still have to design it so that drawing happens in as big batches as possible. Extending Canvas themselves rather than having it in the API would perhaps be an option for such power users.

Is that even possible? To extend an existing class such as Canvas? Sorry for the novice question, I'm still quite new to Lua.