I guess we could also replace all the functions relating to Sources with justspill wrote:...
Code: Select all
Source:set(playing=true, volume=1.0, loop=false, data=<something>,...)
Code: Select all
love.graphics.primitive('rectangle',0,0,10,10)
I guess we could also replace all the functions relating to Sources with justspill wrote:...
Code: Select all
Source:set(playing=true, volume=1.0, loop=false, data=<something>,...)
Code: Select all
love.graphics.primitive('rectangle',0,0,10,10)
Code: Select all
function setAll(subject, table)
for k, v in pairs(table) do
if type(v) == "table" then
subj["set"..k](subj, unpack(v))
else
subj["set"..k](subj, v)
end
end
end
Heh, I did pretty much exactly that in one of my projects.S0lll0s wrote:If you want it you could write a function that turns {key = value} tables into :setKey(value) calls with ease:
As usual; untested, written on mobileCode: Select all
function setAll(subject, table) for k, v in pairs(table) do if type(v) == "table" then subj["set"..k](subj, unpack(v)) else subj["set"..k](subj, v) end end end
Yeah, I think it's an incremental improvement because it reduces the amount of duplicated code a bit. The problem I have with the current API is that you have to pour a bucket of data through a hundred pinholes, instead of one bucket-sized hole.slime wrote:That just swaps function calls for table fields, without changing the number of things you need to set or what you're able to do with particle systems.
How do ParticleSystems do efficient batch rendering? I was skimming through the source code and I saw that they're internally stored as a doubly linked list (the way random insertion is implemented is really clever by the way), but I don't see the drawing code anywhere in ParticleSystem.cpp. I kind of assumed that SpriteBatch could use the same storage/rendering techniques that ParticleSystem does, which allows for constant-time insertion/removal.S0lll0s wrote:@Spill you cannot do that since the graphics interface (opengl) requires the data be in an array (a SpriteBatch is basically a VBO: https://en.wikipedia.org/wiki/Vertex_Buffer_Object).
No, you're not hallucinating. I deleted it because I wanted to recheck my facts.S0lll0s wrote:edit: what the hell? am I hallucinating or was that post removed just now?
Sprite batches already render in the exact same way particle systems do – as a straight array with a single draw call. The internal representation of particles is separate from the per-vertex particle sprite data that's drawn. The former has a ton of stuff that's useless for the latter, including velocity, acceleration, etc., and reducing the number of draw calls is very important for rendering performance and GPU utilization.spill wrote:How do ParticleSystems do efficient batch rendering? I was skimming through the source code and I saw that they're internally stored as a doubly linked list (the way random insertion is implemented is really clever by the way), but I don't see the drawing code anywhere in ParticleSystem.cpp. I kind of assumed that SpriteBatch could use the same storage/rendering techniques that ParticleSystem does, which allows for constant-time insertion/removal.S0lll0s wrote:@Spill you cannot do that since the graphics interface (opengl) requires the data be in an array (a SpriteBatch is basically a VBO: https://en.wikipedia.org/wiki/Vertex_Buffer_Object).
Code: Select all
spritebatch:clear()
local particle = particles.start
while particle ~= nil do
spritebatch:add(particle.x, particle.y, ...)
particle = particle.next
end
love.graphics.draw(spritebatch)
I think you overestimate the importance of algorithmic time compared to real-world factors like cache misses (which are in the ballpark of 200 cycles per cache miss!), draw call overhead, and GPU underutilization due to few vertices per draw call.spill wrote:I'm pretty sure you could balance it so that it would be amortized constant insertion/removal time from arbitrary points. Or you could just have a linked list of blocks size K, so that there are N/K OpenGL draw calls per SpriteBatch, but insertion/removal is O(K) instead of O(N). Both of these cause OpenGL to do a little bit more work, but it sounds like it would improve the drawing performance of ParticleSystems.
Users browsing this forum: No registered users and 0 guests