Please use Derelict3 bindings insteard of extern(c) about dsfml HOT 11 CLOSED

(currently SFML can be built only as shared library on linux)

from dsfml.

(I am make a derelict branch right now)

from dsfml.

hoho! I think I got a little excited!
graphics.d easier to rewrite again :( It does not uses OOP from CSFML

from dsfml.

I don't use Derelict style bindings because it will unload everything at a modular scope, which will not let the destructors work the way they do. I do this as a "just in case" sort of thing so that memory is still released upon exit of the program.

Also, the Derelict binding is still extern(C), since it relies on the C binding of SFML, which can only be built as a shared library no matter what OS you are using. The difference between the way DSFML and Derelict-SFML links with the shared library is that DSFML requires the user to link against the import libraries when building(for you it would be something like libcsfml-system.a for example), but Derelict does not. You can still run a DSFML program on linux. I know some people already do.

from dsfml.

If it is alright with you, I think we can close this. You are more than welcome to do something with Derelict to make a wrapper, but DSFML will continue to use static bindings instead of dynamic ones.

I'll also be working more on making sure there are good tutorials for the library soon after the next version is released, but feel free to post on the SFML forums or email me with questions about how to build using DSFML.

from dsfml.

...Honestly, I still did not understand the arguments against the use of Derelict.

(I made SFML2 wrapper for Derelict, it placed here: https://github.com/denizzzka/SFML2_wrapper )

from dsfml.

I can give you an example for what I mean as well as some other reasons why I don't use Derelict any longer with my binding.

Consider a SFML object with a destructor. Let's say CircleShape. You make a CircleShape object in your program, and then your program ends. If using Derelict, upon exit of the program the system tries to run GC to clean up any object, but for some reason you get an error that looks like "core.exception.InvalidMemoryOperationError." You got this error because the shared library is unloaded by the module destructor before the GC runs on exit of the program, so the sfCircleShape_destroy method no longer exists in memory to be used. When your program tries to call the function it produces the error. This will cause the CircleShape to stay in memory and never be freed. DSFML doesn't have this problem since the program links with the shared libraries statically.

Another reason I don't use Derelict is so that I don't require user to need Derelict in order to use DSFML. It should be a stand alone library.

Third, as I am making a new C back end to make the binding better I don't want to have to keep a version of Derelict up to date along with the C code AND the OO code. It would also be more work considering that one has to update the mangled names, then the function pointers, AND the code that loads and binds the two together.

Lastly, by mapping function pointers to functions in a shared library the way Derelict does creates some overhead when calling those functions. Sure it is a minimal amount, but when you want your game to be as fast as possible every little bit helps.

The only reason I can see one would want to use Derelict instead of creating a static binding would be the ease of loading the libraries since it does it automatically. Once you get the command line set for loading the shared libraries the way DSFML does it, you should never have to change that again so that argument is kind of moot.

Can you provide any arguments for why I should use Derelict?

from dsfml.

Just to clarify something, DSFML is a static binding, but that doesn't mean it uses static libraries. All versions use shared libraries since that is the only way to build them.

from dsfml.

I understand this point of view, thanks for the clarification. I think I really got excited.

from dsfml.

Hey, no worries. I'm pretty excited to! D is a cool new language and it deserves really cool game dev stuff. I just want to make sure it is designed well, the code is well managed, and it performs well, you know?

from dsfml.

I just need some simple graphics by simple way - I write a navigation program

from dsfml.