Using C code from D is actually a fairly straightforward to do, all you need to do is write a D version of the function signature you want to call and tell D to mangle it as a C function eg extern(C) { int SDL_Init(uint flags); } now you just need to tell the linker to link in libsdl and you are ready to go.
I have personally found Derelict adds too much complexity and breaks too often for my liking. If you want to play with a cross platform game engine with D bindings you could look at https://github.com/TurkeyMan/fuji On Fri, Jul 31, 2015 at 11:53 AM, Mike Parker via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Everyone always references Minecraft, but that's not the only Java game out > there. There are quite a few on Steam. You'll never even know they're Java > if you don't follow their development, as they ship with a bundled JRE. The > Java games that perform poorly or hog resources are always held up as an > example of why Java is a dog or why GC for games is a problem, but then the > ones that perform well don't even become part of the conversation. > > Experienced Java game developers know how to code to the GC and tune their > apps to maximize performance. There's quite a lot of knowledge tucked away > in the posts at java-gaming.org, where they've shared their experience and > their games. The GC itself is not a deal breaker, nor is the Java language. > People prove it every day. > > The same can be true of D. When enough D experience has been accumulated and > shared, people will be writing games that take the GC into account. There's > no reason to avoid it completely. It can be made to work for you. Even > today, games in C and C++ focus on minimizing allocations, using the stack > as much as possible and setting aside as much heap memory up front as they > can. Given that collections in D only run during allocations, there's no > reason why that same strategy won't work in D. It's all about strategy and > profiling, finding what hurts performance and learning how to avoid it.