Messages

1

General discussions / Re: SFML bindings (information for the new website)

« on: March 17, 2013, 09:55:37 am »

Already mentioned above, but here's the full info:

DerelictSFML2 (part of the Derelict 3 bindings collection)
D Programming Language
Mike Parker (aldacron@gmail.com)
https://github.com/aldacron/Derelict3/

2

D / Re: Destroy destructor crashes?

« on: December 18, 2012, 02:32:02 am »

A scoped object wouldn't be a part of the GC, would it? This sounds more like a RAII technique to me.

That is correct.

And like Nekroze was wondering, they would be allocated on the stack instead of the heap, correct?

Correct.

That said, if we were to use the sfXXX objects directly, they would be allocated on the stack anyways so using a struct or scoped object doesn't sound like the worst thing to do even if they are long-lived.

It's really going to complicate your game design. All of your scoped objects would have to be declared in a function. Then you'd have to create a scheme to share them with the rest of the program. It would create a whole host of challenges for things like level loading.

This sort of technique is only useful for things you need inside a specific scope. It's not going to be useful at all for anything that lives for the life of the program.

3

D / Re: Destroy destructor crashes?

« on: December 17, 2012, 10:17:58 am »

Is caused by the Derelict library unloading the .dll's before the objects are deleted. Since the Derelict maps the functions to function pointers, when Derelict unloads first the function sfImage_destroy no longer exists and we get the error.

Derelict will *always* unload the library before any destructors are run. The library is unloaded in a module destructor. When an app is exiting, the D Runtime always calls module destructors before call the GC's cleanup method. So when the app exits, any objects still around in the GC that call into sfml (or any bound library) in the class destructor will always cause the app to crash because the DLL/so/dynlib will have been unloaded already.

As soon as I am 100% sure of what we should be doing when wrapping sfObjects in a D class, I will post it here for others to know!

The D documentation explicitly says not to rely on destructors to release system resources. Because objects are GCed, there is never any guarantee the destructors will be run. And when they *are* run, there's no guarantee in which order. My approach is to do it manually, with a little help from scope(exit). Others use structs or scoped objects (part of the language in D1, a Phobos template in D2) when possible to cleanup when an object goes out of scope. Personally, I just pretend the destructors don't even exist.

4

D / Re: Destroy destructor crashes?

« on: December 17, 2012, 05:42:15 am »

Please see my answer to your post in the D newsgroups.

5

C / Re: RenderState proper usage?

« on: November 22, 2012, 10:57:44 am »

I have the version that does not take a sfTransform* but just a normal sfTransform so i am up to date.

You were up to date on the C side, but the binding, unfortunately, did not track the changes to sfTransform. It was still declared as an opaque type. I've gone through and made the relevant corrections and added a constant sfTransform_Identity, so you should be able to do this now:

state.shader = shader;
state.blendMode = sfBlendAlpha;
state.transform = sfTransform_Identity;
state.texture = NULL;
 

Hope it works for you now.

6

D / New D Binding to SFML2

« on: June 29, 2012, 11:01:41 am »

I've recently completed a binding to SFML2 as part of the Derelict 3 project. To use it, just checkout the Derelict 3 source from git and follow the instructions in the readme to build Derelict. You'll need to link with DerelictUtil and DerelictSFML2. You don't need to link any SFML libraries as Derelict loads the shared libs when you tell it to. For example, DerelictSFML2System.load(), DerelictSFML2Window.load() and so on. Make sure you have the CSFML2 shared libraries you want to use somewhere on your system lib path (in the app directory on Windows, for example). Derelict will automatically unload the libraries on shutdown.

Please be aware that this is untested at the moment. Also, Derelict 3 currently lacks documentation. If you're new to Derelict, the core of the documentation for Derelict 2 still mostly applies (FYI, there's a similar binding for SFML 1.6 in Derelict 2 if you prefer). Also, you can ask for help in the Derelict forums or in #D on freenode.