Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
December 18, 2013 DSFML | ||||
---|---|---|---|---|
| ||||
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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeremy DeHaan | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeremy DeHaan | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeremy DeHaan | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeremy DeHaan | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kelet | 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 Re: DSFML | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jeremy DeHaan | 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. |
Copyright © 1999-2021 by the D Language Foundation