My apologies for not replying sooner, as I've been tinkering with this
over a number of days. I can report success on the memory front, and
significantly increased frame-rates as a result of your suggestions.
Ultimately, I think the memory leaks were my buffers I was allocating
that were being copied into the render buffers; yes, that was horribly
slow - I was working on a "make it work first, then make it fast"
approach, which ironically made it worse ;-)
res wrote:
On 25.03.2006 05:04, Craig Miskell wrote:
So, on every call to "GetRenderMeshes()", I update my renderbuffers. For
each of the index, texel, indices, colour and normal buffers I have an
instance variable that holds the result of createRenderBuffer (or
createIndexRenderBuffer as appropriate). I stuff my vertex data into
those renderbuffers, and then setup the RenderMeshes.
Since GetRenderMeshes() may be called multiple times a frame, consider
the optimization of only filling the buffers once a frame.
I didn't realise that - thanks for the pointer (it was an easy fix too)
2) I re-use the renderbuffers every time (no setting to 0, no new calls
to createRenderBuffer). There is no memory increase, strongly implying
that it is the csRenderBuffers that are the source of the leak in 1
above), but because the number of vertices changes every time through, I
think it's just pure luck that i haven't had crashes and lockups yet.
Reallocating buffers every mesh is awful performance-wise; and exceeding
the renderbuffer or not with the vertices to be written is not a matter
of luck either - you could do the following:
if (renderBuffer.NumberOfVertices < VertexCountIHave)
renderBuffer.AttachNew (new RenderBuffer (VertexCountIHave));
... use renderBuffer ...
ie only recreate a renderbuffer when you need to stow away more vertices
than you currently have space for.
I have used this approach, along with copy=false in the
createRenderBuffer call, keeping the main vertex, normal, texel and
colour data in the (permanent) ROAM data structure and copying the
pointer into the render buffer as needed (which, come to think of it,
isn't actually needed after the render buffer is setup)
Again, thanks for the pointers, they set me heading in the right direction.
Craig
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
