Destruction in D
bitwise via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sat May 2 14:13:22 PDT 2015
On Fri, 01 May 2015 14:37:40 -0400, Idan Arye <GenericNPC at gmail.com> wrote:
> Structs allow you to implement ref-counting smart pointers like you can
> do in C++. There is an implementation in the standard library:
> http://dlang.org/phobos/std_typecons.html#.RefCounted
Yeah, I guess I should have taken the existence of RefCounted as
confirmation that D has deterministic destruction for structs, but the GC
reference makes some pretty broad generalizations that do not seem to be
entirely true.
> But for something as structured and as heavy as gaming resources, I
> would go for a more manual approach like a repository-style
> architecture, where you manually tell the repository to load/release the
> the resources.
A quick googling of "repository style architecture" yielded a large
variety of pages, including a 143 slide presentation, which I have no
intention of reading =/ I think such an architecture would be overkill for
something like this.
In any case, manually loading/releasing assets is a huge step backward.
On Sat, 02 May 2015 09:22:57 -0400, Márcio Martins <MARCIOAPM at gmail.com>
wrote:
> A very easy and simple solution is to have a queue of unused
> textures in your asset manager, that any thread can push to, but
> only one thread consumes from. Whenever the last ref is released
> you push a texture into this queue, and at the end of each frame,
> while the GPU is busy rendering or flipping, you go through this
> queue on the appropriate thread and delete the textures.
> This has the advantage of making your timings deterministic, i.e.
> a function won't suddently take 200x longer because it happened
> to release the last ref to a texture.
This sounds like it could work.
> Also, remember that aquiring/releasing refs in a threaded
> environment is quite expensive, and you don't want to be doing
> this while passing a texture around in your graphics pipeline, so
> you probably shouldn't be counting texture refs at the texture
> level, but maybe when you load/destroy a material, for example.
True. I was going to pass the RefCounted assets by (ref const), but the
annoyance that brings hardly seems worth it at this point.
I think I would wrap the assets in a class instead though, and let the
destructor decrement a ref count in the asset manager instead of pushing
it to a queue. That way, it would be at the discretion of the asset
manager to destroy the assets as needed. At first, I would most likely
destroy the assets immediately, but eventually, the destruction could be
delayed until memory runs thin to cover awesome code like this:
while(true) {
Texture tex = Asset.GetTexture("card");
drawQuad(tex);
}
More information about the Digitalmars-d-learn
mailing list