This allows a Mesh to be created that doesn't have its own internal vertex buffer and purely references other vertex buffers instead.
The prototype looks like this:
mesh = love.graphics.newMesh(attributelist, drawmode)
where attributelist is an array of tables each with the following fields, similar to Mesh:attachAttribute:
{
buffer = vertexbuffer,
name = "VertexPosition", -- the name this vertex attribute will use in a shader
nameinbuffer = nil, -- the name of the attribute in the vertex buffer. Defaults to the name field.
step = nil, -- vertex attribute step ("pervertex" or "perinstance"), defaults to "pervertex".
startindex = nil, -- 1-based array index within the given vertex buffer where the attribute data will start being pulled from during rendering. Defaults to 1.
}
Sometimes no buffer for tex coords are given, however the shader
still expects some. We can fix this by using a default buffer, which
contains the constant tex coords (0, 0), which is then bound instead.
For systems where VK_EXT_extended_dynamic_state is not supported
it is not valid to extend VkDeviceCreateInfo with an unknown struct.
Todo: if more extensions are supported in the future this code probably
needs adjustments to correctly build a pNext chain.
love.graphics.newVertexBuffer and newIndexBuffer don't do enough to justify their existence since love.graphics.newBuffer already covers all buffer creation functionality.
1-based indices in newIndexBuffer versus 0-based indices in newBuffer(..., {index=true}) was also confusing.
It was being set all the time because of a code bug, but also documentation recommends using it very sparingly - partly because systems have a hard limit on the number of individual allocations (and they can also be a lot slower).
We might want to revisit more selective use of the flag in the future.
There is little to no performance gain, with a lot of burden
to maintenance of the extra path. It's better to unify the code
with the other render pass logic.
Before this patch some common patterns would lead to very suboptimal
render passes.
Consider the following code:
```lua
local canvas = love.graphics.newCanvas(...)
function love.draw()
love.graphics.setCanvas(canvas)
love.graphics.clear(...)
love.graphics.draw(...)
love.graphics.setCanvas()
love.graphics.draw(canvas)
end
```
This would lead to the following rendering:
1) render pass on main window with loadOp=load, followed by an immediate
call to vkCmdClearAttachments
2) render pass on canvas with loadOp=load, followed by an immediate call
to vkCmdClearAttachments
3) render pass on main window with loadOp=load
This patch changes the behaviour to the more performant
(and equivalent) version:
1) render pass on canvas with loadOp=clear
2) render pass on main window with loadOp=clear
This is especially helpful on mobile devices, where creating render
passes is an expensive operation.
niki
Sasha Szpakowski
scurest
Klonan
nikeinikei