Hello,
I'm trying to write some SDL wrapper. After a long fight against objconv, implib and optlink I finally got SDL loading. 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)?

Mafi wrote:

> Hello,
> I'm trying to write some SDL wrapper. After a long fight against
> objconv, implib and optlink I finally got SDL loading. 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.

Also, sdl surfaces may take lots of space, so if possible I would free them when no longer in use. The GC may not collect at all, or late. But this may or may not be a problem.

Lutger wrote:
> Mafi wrote:
> 
>> Hello,
>> I'm trying to write some SDL wrapper. After a long fight against
>> objconv, implib and optlink I finally got SDL loading. 

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.

>> 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.

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.

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.

> 
> Also, sdl surfaces may take lots of space, so if possible I would free them when no longer in use. The GC may not collect at all, or late. But this may or may not be a problem. 

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.

Am 19.10.2010 23:39, schrieb Stanislav Blinov:
> Lutger wrote:
>> Mafi wrote:
>>
>>> Hello,
>>> I'm trying to write some SDL wrapper. After a long fight against
>>> objconv, implib and optlink I finally got SDL loading.
>
> 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.

>>> 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.
>
> 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.
>
> 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.

 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.