20.10.2010 14:35, Mafi wrote:
Am 19.10.2010 23:39, schrieb Stanislav Blinov:
Have you tried Derelict? (dsource.org/projects/derelict). There is a
branch called Derelict2 which is D2-compatible. Derelict does not
require import libraries, only DLLs/SOs - it does run-time dynamic
linking (i.e. loads dynamic library and binds function pointers at
runtime). The only major caveat with Derelict at the moment is lack of
proper support for 'shared' directive, which leads to chaos in
multithreaded applications. Some work has been done to fix that, but
much is to be done still.
I've tried Derelict2 first. I'm using D2 so Dererelict1 was no option.
After svn checkout (I know it could be broken but I found no
'stable'-link) I tried to compile and got a bunch of immutability
errors. I thought that it must be an yet uncomplete port so I went
with static linking but I tried to write everything so I could use
Derelict in some future.
Hm, I remember checking out trunk not so long ago. I had no trouble
building it (though I did that on Linux). Were those errors, by chance,
string-related? Before we completely go off-topic: you might try posting
to Derelict forum on dsource, I'm sure this is not something that would
be hard to fix.
Hurray! Now I'm going to write a wrapper for SDL_Surface. I will only
use surface
poiters so my questions is if I can safely put these pointers into
class
instances which on destruction free the surface (iff it's no display)?
Some caveats apply:
iirc with SDL you typically initialize and close down the different
subsystems. With the GC finalizing surfaces will be freed after sdl
shutdown, dunno if that's legal.
Generally, it's not.
Mafi, if you really want to wrap up SDL handles into classes, I'd advise
you to either:
1) Rethink your design. For example, you could store references to all
objects that are bound to SDL handles and free resources before
SDL_Quit()/SDL_QuitSubSystem() call.
That sounds good. It isn't even reference counting.
Sort of, actually :)
2) Manually 'tell' classes they should free SDL resources via some
method. Even in C++ you'd delete all your heap-allocated objects anyway,
so there's no difference, except that instead of calling delete you'd
call some custom method.
Yea, I didn't want to prevent people from using from using some close
moethod but D has a GC included so why don't use it? Now I know it's a
horrible idea.
Things get even worse if you plan to use Derelict when it's stable,
because the whole SDL DLL/SO may get unloaded before GC starts calling
destructors, and you end up calling no-longer-existing functions thus
having a (not quite so) fun time tracing bugs.
Pretty much anything that concerns video in SDL should go into one and
only thread, so you should "be doubly careful, for all manner of stupid
mousetraps await our toes in the dark" if you think of multithreaded
application. This means that lazy SDL resource management is in no way
an option.
[...]
I very much like the design decision made by Eric Poggel in Yage
(yage3d.net). This mostly concerns OpenGL resources, but generalization
is clear enough: GL resources are allocated and initialized on demand
(i.e. when first used) and freed if not used in some time. Similar
approach may be taken with SDL as well, I think.
I think you can't do it with sdl. If I understood this bit right, you
want to free resources when not used and reload them later again. A
problem with this is that loaded-and-then-manipulated surfaces would
loose their change and completely code generated surfaces would be
completly lost.
That's a matter of implementation, I think. For example, when 'freeing'
surfaces that may be called upon later, you might fetch surface
(meta)data, compress it (zlib/tga/png come to mind) and store it till
it's required again.
