Thread overview
DSFML
Dec 18, 2013
Jeremy DeHaan
Dec 18, 2013
Jeremy DeHaan
Dec 19, 2013
Kagamin
Dec 19, 2013
Jeremy DeHaan
Dec 19, 2013
Jeremy DeHaan
Dec 23, 2013
Kagamin
Dec 19, 2013
Jacob Carlborg
Dec 22, 2013
Kelet
Dec 22, 2013
evilrat
December 18, 2013
I have worked on this for a while, but I think things are finally to the point where I am feeling good about announcing this!

Introducing(kind of) DSFML, a D binding of the Simple and Fast Multimedia Library.

github link: https://github.com/Jebbs/DSFML
Info on SFML: http://www.sfml-dev.org/index.php

Snippet from the github readme:
DSFML is a static binding of SFML, which let's you use SFML in your D programs. DSFML attempts to be as compatible with SFML as possible, but does so in a way that makes sense for the D language.


Some might be familiar with the SFML binding found in Derelict3, but DSFML is a little different. As stated above, it is a static binding instead of a dynamic one. It is also set up to be a wrapper around the C code so that you can use DSFML in much the same way one would use SFML. Lastly, I created a modified version of the C library used to access SFML, mainly so that compiling in 64bit mode will still work. (see http://d.puremagic.com/issues/show_bug.cgi?id=5570)


Please feel free to check things out and let me know what you think! One of the hardest parts for me so far has been a lack of general feedback.

Also, what took me so long to announce this was that I was a bit self conscious about posting my code when so many great programmers frequent these forums. I'm feeling a little bit better about that, but please know that the library is in active development and I am always finding things that can be improved.

This is my first open source project that I expect other people to use. Be gentle. :P
December 18, 2013
On a side note, deadalnix and previously worked on a D binding for SFML of the same name, but it had been 2 years since his last github commit so I thought to work on my own.

I hope he doesn't mind!
December 19, 2013
https://github.com/Jebbs/DSFML/blob/master/src/dsfml/graphics/text.d#L241
Destructors are called by GC during the collection cycle, and writeln may want to allocate, which is not allowed during collection, it may be safer to use printf.
December 19, 2013
On Thursday, 19 December 2013 at 07:27:14 UTC, Kagamin wrote:
> https://github.com/Jebbs/DSFML/blob/master/src/dsfml/graphics/text.d#L241
> Destructors are called by GC during the collection cycle, and writeln may want to allocate, which is not allowed during collection, it may be safer to use printf.

Ah, interesting. Was not aware of that. I do have this issue in the tracker though: https://github.com/Jebbs/DSFML/issues/62

Basically, I was going to remove those anyways in favor of the internal error output system, which is just a static File instance(in case people are logging errors and such and want to see when objects are destroyed). Would that have the same issues? If not, it looks like I might as well get that done sooner rather than later.
December 19, 2013
On Thursday, 19 December 2013 at 08:17:36 UTC, Jeremy DeHaan wrote:
> On Thursday, 19 December 2013 at 07:27:14 UTC, Kagamin wrote:
>> https://github.com/Jebbs/DSFML/blob/master/src/dsfml/graphics/text.d#L241
>> Destructors are called by GC during the collection cycle, and writeln may want to allocate, which is not allowed during collection, it may be safer to use printf.
>
> Ah, interesting. Was not aware of that. I do have this issue in the tracker though: https://github.com/Jebbs/DSFML/issues/62
>
> Basically, I was going to remove those anyways in favor of the internal error output system, which is just a static File instance(in case people are logging errors and such and want to see when objects are destroyed). Would that have the same issues? If not, it looks like I might as well get that done sooner rather than later.

Wow, brain fart.

Let me ask this instead. Under what circumstances would a File want to allocate? The output that an object was destroyed was really only put in there because I thought it could be useful. It can be removed if this turns out to be an unsafe action. I haven't had any problems with it that I can think of so far though.
December 19, 2013
On 2013-12-19 08:27, Kagamin wrote:
> https://github.com/Jebbs/DSFML/blob/master/src/dsfml/graphics/text.d#L241
> Destructors are called by GC during the collection cycle, and writeln
> may want to allocate, which is not allowed during collection, it may be
> safer to use printf.

Isn't it allowed to do new allocations but not refer to existing memory allocated by the GC?

-- 
/Jacob Carlborg
December 22, 2013
Thanks for all of the hard work, Jeremy.

DSFML is definitely one of the libraries helping D move forward
as a first class game development platform.

Regards,
Kelet
December 22, 2013
On Sunday, 22 December 2013 at 01:24:50 UTC, Kelet wrote:
> Thanks for all of the hard work, Jeremy.
>
> DSFML is definitely one of the libraries helping D move forward
> as a first class game development platform.
>
> Regards,
> Kelet

oh and i guess no one use DirectX in AAA titles now, such a shame...
December 23, 2013
On Thursday, 19 December 2013 at 08:38:15 UTC, Jeremy DeHaan wrote:
> Let me ask this instead. Under what circumstances would a File want to allocate?

In the case of a simple string it won't allocate, it's only for formatting. I could only find alloca, so it's probably fixed.


On Thursday, 19 December 2013 at 12:46:12 UTC, Jacob Carlborg wrote:
> Isn't it allowed to do new allocations but not refer to existing memory allocated by the GC?

AFAIK, there were problems with allocation too.