Re: D game development: a call to action
Am Thu, 18 Dec 2014 00:58:02 +0100 schrieb Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com: On 17/12/14 08:53, Manu via Digitalmars-d wrote: Errors should be fine... I imagine assert is an intrinsic defined by the backends(?). TBH I think it was a daft question. An Error thrown by assert failure ought to bring down the whole program anyway, and probably for a game you'd use the -release flag to strip out asserts for release builds. In Fuji, I register an assert handler (core.exception.assertHandler = myAssert) which is implemented by Fuji and is portable. Oh yeah, TLS, that's another one that tends to require special treatment. Basically, the language will produce working code for all platforms I've tried if you avoid: exceptions, TLS, GC. I'm fine with this, that's how I write code anyway. In the case of Fuji, there are Fuji API's to do most of the low-level druntime/phobos stuff that might not be supported (threads, synchronisation, allocation, etc). Sounds interesting -- can you clarify the issue with TLS? (Apologies if you've already explained this in earlier discussions, feel free to tell me to just search the forums if so;-) Native TLS can allocate in some cases. For example if you access the TLS block of a library for the first time in a thread, it might allocate this block. Not sure if there are any other issues. Or maybe he's referring to the fact that some platforms (Android, I guess most of the consoles as well) don't support TLS at all. GCC Emulated TLS is slow, allocates and doesn't work with the GC. DMD emulated TLS doesn't work with shared libraries afaik. TLS constructors are also problematic, although not necessarily for games. But they complicate shared library loading a lot, some special cases are almost impossible to implement (Running a TLS ctor of a dynamically loaded library in already running threads).
Re: D game development: a call to action
On 18 December 2014 at 01:19, bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 16 December 2014 at 15:39:06 UTC, bitwise wrote: You'll notice that the engine code is not D code... Hmm... Indeed.. I just assumed when I saw Walter get all excited ;) D will work on most of those platforms just fine if you abandon the GC and exception handler. Unfortunately, I don't know D-compiler/runtime well enough to actually try to get this to work, so I'll have to wait for an official port =/ Just out of curiosity though, what do you use for a level editor? I usually use 3dsmax/blender for scene layout, but there is some turbulence in that area as I often consider other options. Otherwise I often use Lua for scripting things and various descriptors. Scene management isn't really baked into Fuji. It's usually highly game-specific, so I don't like to insist on scene management strategy in the engine. One of my main interests in D is the reflection system for runtime script-tweaking and auto-serialization. Reflection is one of the key reasons that D will appeal to gamedevs. I've had good success. I made some comments about this in my dconf lecture wrt Remedy's implementation. I have an engine of my own, but it's development slowly ground to a halt as I got fed up trying to achieve all the features I wanted using C++. Lately, I've been learning D and starting to look into porting it. I'd be apprehensive to write something like an engine library in any style other than extern(C) functions and opaque types. But I'm obsessed with portability, and I like the idea that a large and ambitious project like a game engine should be able to front-end with any language. Fortunately, D makes it really easy to wrap up a low-level engine library API for convenient front-end use. ^^^ @manu I think my question got barried... Sorry _
Re: D game development: a call to action
On 18 December 2014 at 02:18, CraigDillabaugh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 17 December 2014 at 01:28:55 UTC, Manu via Digitalmars-d wrote: The average gamer today is aged 30. I for one haven't gotten any money from my mum for games recently... Christmas is right around the corner ... you should reminder her :o) :P
Re: D game development: a call to action
On 18 December 2014 at 09:58, Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On 17/12/14 08:53, Manu via Digitalmars-d wrote: Errors should be fine... I imagine assert is an intrinsic defined by the backends(?). TBH I think it was a daft question. An Error thrown by assert failure ought to bring down the whole program anyway, and probably for a game you'd use the -release flag to strip out asserts for release builds. This is all true :) In Fuji, I register an assert handler (core.exception.assertHandler = myAssert) which is implemented by Fuji and is portable. Oh yeah, TLS, that's another one that tends to require special treatment. Basically, the language will produce working code for all platforms I've tried if you avoid: exceptions, TLS, GC. I'm fine with this, that's how I write code anyway. In the case of Fuji, there are Fuji API's to do most of the low-level druntime/phobos stuff that might not be supported (threads, synchronisation, allocation, etc). Sounds interesting -- can you clarify the issue with TLS? (Apologies if you've already explained this in earlier discussions, feel free to tell me to just search the forums if so;-) Just that it depends on threading and synchronisation features in druntime, which probably isn't implemented for arbitrary console platforms ;)
Re: D game development: a call to action
On 18 December 2014 at 21:31, Johannes Pfau via Digitalmars-d digitalmars-d@puremagic.com wrote: Am Thu, 18 Dec 2014 00:58:02 +0100 schrieb Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com: TLS constructors are also problematic, although not necessarily for games. But they complicate shared library loading a lot, some special cases are almost impossible to implement (Running a TLS ctor of a dynamically loaded library in already running threads). Fortunately, most consoles don't usually have shared libraries... which eliminates one major source of problems ;)
Re: D game development: a call to action
On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote: I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market. ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-) Programming is a wicked problem; you only know how to do it after you done it. So my suggestion is to just write the damn thing, and then rewrite the whole thing if it bugs you too much. Essentially a lot of rinse-and-repeat. I always do refactoring manually, so I developed a nack for knowing how to write quick code that is easy to refactor. Ofcourse having clients screaming in your neck helps alot too :)
Re: D game development: a call to action
On Thu, Dec 18, 2014 at 05:33:24PM +, Sebastiaan Koppe via Digitalmars-d wrote: On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote: I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market. ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-) Programming is a wicked problem; you only know how to do it after you done it. So my suggestion is to just write the damn thing, and then rewrite the whole thing if it bugs you too much. Essentially a lot of rinse-and-repeat. I always do refactoring manually, so I developed a nack for knowing how to write quick code that is easy to refactor. Ofcourse having clients screaming in your neck helps alot too :) IME, starting out with abstraction rarely works well. If you're a one-man team, you'll never finish abstracting; if you're a multi-person team, the whole thing will be so over-engineered, baroque, and inefficient, that by the time you're halfway through it you already feel like rewriting it (again). What works best IME is to just have a quick initial design to guide you (don't worry too much about abstracting it to the ideal, just have enough overall target items to set the direction so that you aren't getting yourself into the forest, and so that you have a rough high-level overview of how the whole thing is gonna fit together), then start coding. Most of the abstractions will come from refactoring, which should be done frequently. Abstractions derived in this way tend to be far more effective, because they will arise from actual usage patterns in your code, rather than some ivory-tower idealistic theoretically-beautiful model that will either never get implemented or is so far removed from reality that it's completely impractical and doesn't work well in practice. T -- Microsoft is to operating systems security ... what McDonalds is to gourmet cooking.
Re: D game development: a call to action
On 19 December 2014 at 03:44, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thu, Dec 18, 2014 at 05:33:24PM +, Sebastiaan Koppe via Digitalmars-d wrote: On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote: I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market. ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-) Programming is a wicked problem; you only know how to do it after you done it. So my suggestion is to just write the damn thing, and then rewrite the whole thing if it bugs you too much. Essentially a lot of rinse-and-repeat. I always do refactoring manually, so I developed a nack for knowing how to write quick code that is easy to refactor. Ofcourse having clients screaming in your neck helps alot too :) IME, starting out with abstraction rarely works well. If you're a one-man team, you'll never finish abstracting; if you're a multi-person team, the whole thing will be so over-engineered, baroque, and inefficient, that by the time you're halfway through it you already feel like rewriting it (again). What works best IME is to just have a quick initial design to guide you (don't worry too much about abstracting it to the ideal, just have enough overall target items to set the direction so that you aren't getting yourself into the forest, and so that you have a rough high-level overview of how the whole thing is gonna fit together), then start coding. Most of the abstractions will come from refactoring, which should be done frequently. Abstractions derived in this way tend to be far more effective, because they will arise from actual usage patterns in your code, rather than some ivory-tower idealistic theoretically-beautiful model that will either never get implemented or is so far removed from reality that it's completely impractical and doesn't work well in practice. I agree. My rule for abstraction is to apply it as minimally as possible to avoid any platform-specific api being called from front-end code. That should be a good initial target. Further refinement will reveal it's self in practise, in the way that you say.
Re: D game development: a call to action
On Tuesday, 16 December 2014 at 15:39:06 UTC, bitwise wrote: You'll notice that the engine code is not D code... Hmm... Indeed.. I just assumed when I saw Walter get all excited ;) D will work on most of those platforms just fine if you abandon the GC and exception handler. Unfortunately, I don't know D-compiler/runtime well enough to actually try to get this to work, so I'll have to wait for an official port =/ Just out of curiosity though, what do you use for a level editor? One of my main interests in D is the reflection system for runtime script-tweaking and auto-serialization. I have an engine of my own, but it's development slowly ground to a halt as I got fed up trying to achieve all the features I wanted using C++. Lately, I've been learning D and starting to look into porting it. ^^^ @manu I think my question got barried...
Re: D game development: a call to action
Am Wed, 17 Dec 2014 17:53:25 +1000 schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com: Errors should be fine... I imagine assert is an intrinsic defined by the backends(?). IIRC not really: It is recognized by the backends but we only call the external _d_assert function but it's not a true intrinsic, for example it's not inlined. However, as it's possible to override the assert handler we can't really inline lots of code anyway. We could only get rid of the _d_assert function call.
Re: D game development: a call to action
On Wednesday, 17 December 2014 at 01:28:55 UTC, Manu via Digitalmars-d wrote: The average gamer today is aged 30. I for one haven't gotten any money from my mum for games recently... Christmas is right around the corner ... you should reminder her :o)
Re: D game development: a call to action
On Wednesday, 17 December 2014 at 16:18:19 UTC, CraigDillabaugh wrote: On Wednesday, 17 December 2014 at 01:28:55 UTC, Manu via Digitalmars-d wrote: The average gamer today is aged 30. I for one haven't gotten any money from my mum for games recently... Christmas is right around the corner ... you should reminder her :o) All I want for Christmas is a mobile port of D =/
Re: D game development: a call to action
On Wednesday, 17 December 2014 at 21:26:11 UTC, bitwise wrote: On Wednesday, 17 December 2014 at 16:18:19 UTC, CraigDillabaugh wrote: On Wednesday, 17 December 2014 at 01:28:55 UTC, Manu via Digitalmars-d wrote: The average gamer today is aged 30. I for one haven't gotten any money from my mum for games recently... Christmas is right around the corner ... you should reminder her :o) All I want for Christmas is a mobile port of D =/ i'd kill for that.
Re: D game development: a call to action
On 17/12/14 08:53, Manu via Digitalmars-d wrote: Errors should be fine... I imagine assert is an intrinsic defined by the backends(?). TBH I think it was a daft question. An Error thrown by assert failure ought to bring down the whole program anyway, and probably for a game you'd use the -release flag to strip out asserts for release builds. In Fuji, I register an assert handler (core.exception.assertHandler = myAssert) which is implemented by Fuji and is portable. Oh yeah, TLS, that's another one that tends to require special treatment. Basically, the language will produce working code for all platforms I've tried if you avoid: exceptions, TLS, GC. I'm fine with this, that's how I write code anyway. In the case of Fuji, there are Fuji API's to do most of the low-level druntime/phobos stuff that might not be supported (threads, synchronisation, allocation, etc). Sounds interesting -- can you clarify the issue with TLS? (Apologies if you've already explained this in earlier discussions, feel free to tell me to just search the forums if so;-)
Re: D game development: a call to action
On Mon, 15 Dec 2014 23:40:43 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: @manu I'm a little confused.. Looking through your Fuji/Source/Drivers folder, I see folders for IPhone and Android, among others... does your engine actually run on these platforms? I was under the impression that D could not compile to those targets yet. Fiji is not written in D, but it has extensive D API. signature.asc Description: PGP signature
Re: D game development: a call to action
On Sunday, 14 December 2014 at 00:30:22 UTC, Joel wrote:
I'm using Windows. I get this error trying to compile the demo
on DGame.
C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\builddmd build.d
Using the Digital Mars DMD compiler.
C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\buildbuild.exe
Assume 'C:\jpro\dpro2\OtherPeoples\derelict' as derelict path.
Verify...
Building all packages.
Building Dgame/Audio
..\Audio\all.d
..\Audio\Internal\core.d
..\Audio\Listener.d
..\Audio\Sound.d
..\Audio\SoundFile.d
..\Audio\VorbisFile.d
..\Audio\WaveFile.d
dmd -lib -O -release -inline -wi
-of..\lib\Release/DgameAudio.lib
..\Audio\all.
d ..\Audio\Internal\core.d ..\Audio\Listener.d ..\Audio\Sound.d
..\Audio\SoundFi
le.d ..\Audio\VorbisFile.d ..\Audio\WaveFile.d
-IC:\jpro\dpro2\OtherPeoples -I..
/../
..\Audio\Internal\core.d(32): Error: module Log is in file
'Dgame\Internal\Log.d
' which cannot be read
import path[0] = C:\jpro\dpro2\OtherPeoples
import path[1] = ../../
import path[2] = C:\jpro\dmd2\windows\bin\..\..\src\phobos
import path[3] =
C:\jpro\dmd2\windows\bin\..\..\src\druntime\import
import path[4] = C:\jpro\dmd2\windows\bin\..\import
import path[5] =
C:\jpro\dmd2\windows\bin\..\..\windows\import\gtkd\src
Build Failed!
It seems, Dgame is searching for a path which does not exists
('Dgame/Internal/Log.d'). You should set the path where Dgame
lies to the global PATH (assuming you're using Windows), (e.g. if
it is C:/Foo/Bar/Dgame set 'C:/Foo/Bar/' into PATH). Then Dgame
should be able to find 'Dgame/Internal/Log.d'.
I havent maintained Dgame a long time (since I left D), maybe I
will find some time in the next year. ;)
Sorry for your trouble.
Re: D game development: a call to action
On 16 December 2014 at 09:40, bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: @manu I'm a little confused.. Looking through your Fuji/Source/Drivers folder, I see folders for IPhone and Android, among others... does your engine actually run on these platforms? I was under the impression that D could not compile to those targets yet. You'll notice that the engine code is not D code... Most of those platforms run fine, although some are out of date. I only tend to maintain the ones I'm actively using, some needs some updates, but I'm good at that, and it's nice to dig out the consoles from time to time to get them up to latest. D will work on most of those platforms just fine if you abandon the GC and exception handler. PS2 is probably the only platform that will never work. GC and exceptions typically require druntime port work.
Re: D game development: a call to action
You'll notice that the engine code is not D code... Hmm... Indeed.. I just assumed when I saw Walter get all excited ;) D will work on most of those platforms just fine if you abandon the GC and exception handler. Unfortunately, I don't know D-compiler/runtime well enough to actually try to get this to work, so I'll have to wait for an official port =/ Just out of curiosity though, what do you use for a level editor? One of my main interests in D is the reflection system for runtime script-tweaking and auto-serialization. I have an engine of my own, but it's development slowly ground to a halt as I got fed up trying to achieve all the features I wanted using C++. Lately, I've been learning D and starting to look into porting it.
Re: D game development: a call to action
On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! Games are the definition of time loss. Industry based on the idea of stealing money to the parent. A bit like music. The entertainment society. I'm totally against that. Work against the chineses. The sooner the better. Work the sooner the better.
Re: D game development: a call to action
On 17 December 2014 at 07:24, LaMainNoire via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! Games are the definition of time loss. Industry based on the idea of stealing money to the parent. The average gamer today is aged 30. I for one haven't gotten any money from my mum for games recently... A bit like music. The entertainment society. I'm totally against that. Okay, but get your facts straight. Work against the chineses. The sooner the better. Wtf? Work the sooner the better. Okay...
Re: D game development: a call to action
On Tuesday, 16 December 2014 at 12:56:48 UTC, Manu via Digitalmars-d wrote: D will work on most of those platforms just fine if you abandon the GC and exception handler. I'm out of date on the progress in getting @nogc and @nothrow rolled out as widely as possible across the codebase, but doesn't no GC and no exceptions still rule out quite a large chunk of Phobos? :-( Also, what about Errors? Is use of assert() OK?
Re: D game development: a call to action
On 17 December 2014 at 11:44, Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 16 December 2014 at 12:56:48 UTC, Manu via Digitalmars-d wrote: D will work on most of those platforms just fine if you abandon the GC and exception handler. I'm out of date on the progress in getting @nogc and @nothrow rolled out as widely as possible across the codebase, but doesn't no GC and no exceptions still rule out quite a large chunk of Phobos? :-( Also, what about Errors? Is use of assert() OK? Phobos only has limited use in realtime code anyway. Errors should be fine... I imagine assert is an intrinsic defined by the backends(?). In Fuji, I register an assert handler (core.exception.assertHandler = myAssert) which is implemented by Fuji and is portable. Oh yeah, TLS, that's another one that tends to require special treatment. Basically, the language will produce working code for all platforms I've tried if you avoid: exceptions, TLS, GC. I'm fine with this, that's how I write code anyway. In the case of Fuji, there are Fuji API's to do most of the low-level druntime/phobos stuff that might not be supported (threads, synchronisation, allocation, etc).
Re: D game development: a call to action
@manu I'm a little confused.. Looking through your Fuji/Source/Drivers folder, I see folders for IPhone and Android, among others... does your engine actually run on these platforms? I was under the impression that D could not compile to those targets yet.
Re: D game development: a call to action
Actually, iOS and Android both have x86 emulators don't they?
Re: D game development: a call to action
On 12/13/2014 11:39 PM, Manu via Digitalmars-d wrote: On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote: my engine: https://github.com/TurkeyMan/fuji Please set fuji up at http://code.dlang.org ! It's totally incompatible with dub. How does code.dlang.org deal with foreign build systems? It's very complex to package, since it supports so many optional features, platforms, and various multimedia API's for each platform. I use premake to create projects/makefiles, which I've been maintaining D support for years. The typical way is to just make the engine repo a submodule and extend the buildsystem to the host app (FeedBack is the best example). The thing is, merely having the code there on github and referring to it now and then in the n.g. will result in likely: 0 users. People are going to look for code like yours on code.dlang.org, and if it isn't there, they will assume it does not exist. Build it and they will come is a stupid hollywood myth. It will never happen. So many excellent D projects have died because the creators did: 0 promotion, and nobody used it. Please do not let this happen to your work! I recommend: 1. find a way to make it work on dub. Ask for help. (Martin and Dmitry have been graciously helping me get my code up on dub.) 2. write article(s) about it, post them on your blog site, and ask someone to link 'em to Reddit. 3. announce it on gamedev.net 4. talk about it everywhere on the internet where game devs hang out 5. submit a presentation proposal about it for Dconf 2015, and every other programming conference. How about YOW 2015, it's even in Australia! P.S. This applies to everyone writing open source D projects.
Re: D game development: a call to action
On Sun, 14 Dec 2014 17:45:06 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: Hard to describe... just the sort you'd find in a big commercial game. Perhaps I could say something like, highly optimised and purpose specific, as opposed to generalised and flexible/object oriented. i've seen such code. it's... ah, it's terrible. unmaintainable. and becomes garbage just when the next 3d-accel or processor is out. sure, nobody cares as it is sold million times already and everyone is working on another pile of shit now. libraries? code reusability? design? architecture? screw that! i moved out of that industry 'cause i couldn't take it anymore. they almost ruined my programming skills. that's why i was so wondered. Where did you work? It sounds like you had a bad experience. I've worked in a few such environments, I can say we only got the balance right once. ah, that was... outhouse team, i think. we were not officialy part of the main firm, but were working on their titles. it doesn't really matter, i don't know what's going on there now, so let it be the nameless one. ;-) maybe i was just unlucky. i've dreamt of creating videogames from my childhood and was very excited to work in real videogaming industry. that was more than decade ago, though, but i don't believe that things are changed radically since then. i was talking with some old mates recently (they are still making videogames) and was really wondered: they know alot about overhead of memory allocation, processor caches, videodriver glitches, but failing at basic CS things, such as why crc32 isn't good function for hashing?. they know that crc32 should not be used in hashtables, but for what reason... it's mystery. I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market. ah, that's the other end of the spectrum (and my own problem too ;-). i'm still searching for good heuristic that will tell me when i should stop abstracting and just write the damn thing. ;-) signature.asc Description: PGP signature
Re: D game development: a call to action
I did some googling on your game engine: http://fujiengine.org/ Good, but needs more info on why someone should invest time learning it. https://code.google.com/p/fuji/wiki/Platforms Not so good. Says it's Not maintained/out of date. That's about it for its presence on the intertoobs. Also, it's variously called Mount Fuji Engine, Fuji Engine, Mt Fuji Engine and just Fuji. Need to pick one moniker for it and use that consistently everywhere in order to tie your brand together. Need a logo to tie it all together. Sorry to be so blunt about this, but I want you to succeed!
Re: D game development: a call to action
On 14 December 2014 at 17:55, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 11:39 PM, Manu via Digitalmars-d wrote: On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote: my engine: https://github.com/TurkeyMan/fuji Please set fuji up at http://code.dlang.org ! It's totally incompatible with dub. How does code.dlang.org deal with foreign build systems? It's very complex to package, since it supports so many optional features, platforms, and various multimedia API's for each platform. I use premake to create projects/makefiles, which I've been maintaining D support for years. The typical way is to just make the engine repo a submodule and extend the buildsystem to the host app (FeedBack is the best example). The thing is, merely having the code there on github and referring to it now and then in the n.g. will result in likely: 0 users. That's fine, I'm not selling a product or anything. It's for personal use... but I'm perfectly happy for other people to take an interest if they want a professional engine dev helping on their project, and portability to a very wide range of systems. People are going to look for code like yours on code.dlang.org, and if it isn't there, they will assume it does not exist. Well it's not really D code, it just has quite comprehensive support for D. I've taken a lot of time with the bindings, and making sure D game projects can effectively be developed against my engine. I still consider the D bindings experimental though, and I keep tweaking them ;) I can't make D engine code until D is supported on the menagerie of console platforms that I support. We need better bare-metal support and more working toolchains. Build it and they will come is a stupid hollywood myth. It will never happen. So many excellent D projects have died because the creators did: 0 promotion, and nobody used it. Please do not let this happen to your work! I recommend: 1. find a way to make it work on dub. Ask for help. (Martin and Dmitry have been graciously helping me get my code up on dub.) Trouble with this is, I'm not interested in dub. An exclusive language-specific build ecosystem is of absolutely no use to me! If I'm mistaken about dub though and I could theoretically somehow make this work, I'm certainly willing to work with anyone who knows better than me how to get it working? 2. write article(s) about it, post them on your blog site, and ask someone to link 'em to Reddit. 3. announce it on gamedev.net 4. talk about it everywhere on the internet where game devs hang out These are all good ideas, but I'm not really actually pimping a project here. I'm not sure it's a project that I'll ever consider 'finished'. It's had 12 years of work, and it's pretty robust and capable, but I just don't have the time to finish/polish off all the stuff I want to. I tend to work in a reactionary manner to emergent requirements :/ I am super happy for those requirements to be someone elses requirements though, and I'm all good to give some of my time to help get other peoples cool projects running well. 5. submit a presentation proposal about it for Dconf 2015, and every other programming conference. How about YOW 2015, it's even in Australia! P.S. This applies to everyone writing open source D projects. Maybe one day I will, I like that idea, but I don't think that day is particularly soon with this project. I need to give it more undivided attention to get it to that state.
Re: D game development: a call to action
On Tuesday, 6 August 2013 at 06:23:09 UTC, qznc wrote: On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5 Who else uses DAllegro 5? I like it, just can't get it to work on OS X.
Re: D game development: a call to action
On Saturday, 13 December 2014 at 22:49:10 UTC, Joel wrote: On Tuesday, 6 August 2013 at 06:23:09 UTC, qznc wrote: On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5 Who else uses DAllegro 5? I like it, just can't get it to work on OS X. I'm also using the Allegro bindings for a project and have run into no issues on Linux. I'm using Dgame on another project on and that also works very well. @SiegeLord: It would be good to get those bindings listed on the main Allegro site here: http://alleg.sourceforge.net/bindings.html (there is an old listing for Allegro 4 but not 5) and in their news here if possible: http://alleg.sourceforge.net/news.html I believe you just need to send a request to the mailing list here: http://sourceforge.net/p/alleg/mailman/?source=navbar Cheers uri
Re: D game development: a call to action
[snip] I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5 Who else uses DAllegro 5? I like it, just can't get it to work on OS X. I'm also using the Allegro bindings for a project and have run into no issues on Linux. I'm using Dgame on another project on and that also works very well. [snip] I would really like to get DGame (for not just games) working on my OS X. At lest Windows. I've been making terminal programs in OS X. Derelict3 is now not maintained.
Re: D game development: a call to action
I'm using Windows. I get this error trying to compile the demo on DGame. C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\builddmd build.d Using the Digital Mars DMD compiler. C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\buildbuild.exe Assume 'C:\jpro\dpro2\OtherPeoples\derelict' as derelict path. Verify... Building all packages. Building Dgame/Audio ..\Audio\all.d ..\Audio\Internal\core.d ..\Audio\Listener.d ..\Audio\Sound.d ..\Audio\SoundFile.d ..\Audio\VorbisFile.d ..\Audio\WaveFile.d dmd -lib -O -release -inline -wi -of..\lib\Release/DgameAudio.lib ..\Audio\all. d ..\Audio\Internal\core.d ..\Audio\Listener.d ..\Audio\Sound.d ..\Audio\SoundFi le.d ..\Audio\VorbisFile.d ..\Audio\WaveFile.d -IC:\jpro\dpro2\OtherPeoples -I.. /../ ..\Audio\Internal\core.d(32): Error: module Log is in file 'Dgame\Internal\Log.d ' which cannot be read import path[0] = C:\jpro\dpro2\OtherPeoples import path[1] = ../../ import path[2] = C:\jpro\dmd2\windows\bin\..\..\src\phobos import path[3] = C:\jpro\dmd2\windows\bin\..\..\src\druntime\import import path[4] = C:\jpro\dmd2\windows\bin\..\import import path[5] = C:\jpro\dmd2\windows\bin\..\..\windows\import\gtkd\src Build Failed!
Re: D game development: a call to action
On 14/12/2014 1:25 p.m., Joel wrote: [snip] I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5 Who else uses DAllegro 5? I like it, just can't get it to work on OS X. I'm also using the Allegro bindings for a project and have run into no issues on Linux. I'm using Dgame on another project on and that also works very well. [snip] I would really like to get DGame (for not just games) working on my OS X. At lest Windows. I've been making terminal programs in OS X. Derelict3 is now not maintained. Whats not been converted over to DerelictOrg[0] that you want? (Each of derelict3's bindings has its own repo under DerelictOrg). [0] https://github.com/DerelictOrg
Re: D game development: a call to action
On 6 August 2013 at 04:18, Jonathan A Dunlap jdun...@outlook.com wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! You could consider engines that bind to D. I don't think it's particularly important that the engine is written in D, as long as the binding is in the D style, and convenient. It's no different than OpenGL isn't written in D, but there are some bindings, and people tend to wrap them up for convenience. This is precisely what I've been doing for 5-6 years now with my engine: https://github.com/TurkeyMan/fuji If people want to do D gamedev, but don't want to worry about the engine component, they're more than welcome to use my engine. I'm always available to offer full engine support to users writing interesting software!
Re: D game development: a call to action
On 14 December 2014 at 11:00, Manu turkey...@gmail.com wrote: On 6 August 2013 at 04:18, Jonathan A Dunlap jdun...@outlook.com wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! You could consider engines that bind to D. I don't think it's particularly important that the engine is written in D, as long as the binding is in the D style, and convenient. It's no different than OpenGL isn't written in D, but there are some bindings, and people tend to wrap them up for convenience. This is precisely what I've been doing for 5-6 years now with my engine: https://github.com/TurkeyMan/fuji If people want to do D gamedev, but don't want to worry about the engine component, they're more than welcome to use my engine. I'm always available to offer full engine support to users writing interesting software! I'm also very interested in experiments writing game code on commercial-style engines. Hobby engines are nice, but we will get a much better feel for using D in the AAA games industry if a commercial-style engine is used. My project FeedBack in an attempt to explore this sort of D code (https://github.com/FeedBackDevs/feedback), but it's somewhat limited by my free time at the moment.
Re: D game development: a call to action
On Sunday, 14 December 2014 at 00:51:24 UTC, Rikki Cattermole wrote: On 14/12/2014 1:25 p.m., Joel wrote: [snip] I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5 Who else uses DAllegro 5? I like it, just can't get it to work on OS X. I'm also using the Allegro bindings for a project and have run into no issues on Linux. I'm using Dgame on another project on and that also works very well. [snip] I would really like to get DGame (for not just games) working on my OS X. At lest Windows. I've been making terminal programs in OS X. Derelict3 is now not maintained. Whats not been converted over to DerelictOrg[0] that you want? (Each of derelict3's bindings has its own repo under DerelictOrg). [0] https://github.com/DerelictOrg It's just that it was mentioned with using DGame.
Re: D game development: a call to action
What my problem is, why hasnt the D standard library implemented a multimedia library from the ones already available? instead of having to go and look for one. Im sure this would cause alot of controversy because NO MY LIBRARY IS BETTER AND HAS MORE FEATURES THAN HIS. Its not about features. Its about its ease of use and learning. OP is right though. If we want to gain some momentum we need libraries that are easier to use and learn than the standard C/C++ syntax that plagues SDL/Derelict. Because cleaning up the previous mess is what made C better than Assembly, C++ better than C, and C#/Java better than C++.
Re: D game development: a call to action
On Sun, 14 Dec 2014 11:04:45 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm also very interested in experiments writing game code on commercial-style engines. Hobby engines are nice, but we will get a much better feel for using D in the AAA games industry if a commercial-style engine is used. what is commercial-style engine? as far as i know, commercial-style means unmaintainable pile of shit. signature.asc Description: PGP signature
Re: D game development: a call to action
On Sun, 14 Dec 2014 01:28:45 + Israel via Digitalmars-d digitalmars-d@puremagic.com wrote: What my problem is, why hasnt the D standard library implemented a multimedia library from the ones already available? instead of having to go and look for one. exactly why any other language except C hasn't one. what is wrong with derelict? signature.asc Description: PGP signature
Re: D game development: a call to action
On 14 December 2014 at 16:57, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 14 Dec 2014 11:04:45 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm also very interested in experiments writing game code on commercial-style engines. Hobby engines are nice, but we will get a much better feel for using D in the AAA games industry if a commercial-style engine is used. what is commercial-style engine? as far as i know, commercial-style means unmaintainable pile of shit. Hard to describe... just the sort you'd find in a big commercial game. Perhaps I could say something like, highly optimised and purpose specific, as opposed to generalised and flexible/object oriented. The industry needs anecdotal experience with the types of tools that are already in use to gain confidence.
Re: D game development: a call to action
On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote: my engine: https://github.com/TurkeyMan/fuji Please set fuji up at http://code.dlang.org !
Re: D game development: a call to action
On Sun, 14 Dec 2014 17:20:48 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 14 December 2014 at 16:57, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 14 Dec 2014 11:04:45 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm also very interested in experiments writing game code on commercial-style engines. Hobby engines are nice, but we will get a much better feel for using D in the AAA games industry if a commercial-style engine is used. what is commercial-style engine? as far as i know, commercial-style means unmaintainable pile of shit. Hard to describe... just the sort you'd find in a big commercial game. Perhaps I could say something like, highly optimised and purpose specific, as opposed to generalised and flexible/object oriented. i've seen such code. it's... ah, it's terrible. unmaintainable. and becomes garbage just when the next 3d-accel or processor is out. sure, nobody cares as it is sold million times already and everyone is working on another pile of shit now. libraries? code reusability? design? architecture? screw that! i moved out of that industry 'cause i couldn't take it anymore. they almost ruined my programming skills. that's why i was so wondered. signature.asc Description: PGP signature
Re: D game development: a call to action
On 14 December 2014 at 17:25, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/13/2014 5:00 PM, Manu via Digitalmars-d wrote: my engine: https://github.com/TurkeyMan/fuji Please set fuji up at http://code.dlang.org ! It's totally incompatible with dub. How does code.dlang.org deal with foreign build systems? It's very complex to package, since it supports so many optional features, platforms, and various multimedia API's for each platform. I use premake to create projects/makefiles, which I've been maintaining D support for years. The typical way is to just make the engine repo a submodule and extend the buildsystem to the host app (FeedBack is the best example).
Re: D game development: a call to action
On 14 December 2014 at 17:38, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 14 Dec 2014 17:20:48 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 14 December 2014 at 16:57, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 14 Dec 2014 11:04:45 +1000 Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm also very interested in experiments writing game code on commercial-style engines. Hobby engines are nice, but we will get a much better feel for using D in the AAA games industry if a commercial-style engine is used. what is commercial-style engine? as far as i know, commercial-style means unmaintainable pile of shit. Hard to describe... just the sort you'd find in a big commercial game. Perhaps I could say something like, highly optimised and purpose specific, as opposed to generalised and flexible/object oriented. i've seen such code. it's... ah, it's terrible. unmaintainable. and becomes garbage just when the next 3d-accel or processor is out. sure, nobody cares as it is sold million times already and everyone is working on another pile of shit now. libraries? code reusability? design? architecture? screw that! i moved out of that industry 'cause i couldn't take it anymore. they almost ruined my programming skills. that's why i was so wondered. Where did you work? It sounds like you had a bad experience. I've worked in a few such environments, I can say we only got the balance right once. I've never had trouble migrating to a new platform though, failure to abstract a platform effectively sounds like a pretty big mistake. I find a much bigger problem is tendency for some programmers to commit over-abstraction, sacrificing heaps of efficiency/performance in the process. Most open-source engines are this kind, and will never release a AAA game in a competitive market.
Re: D game development: a call to action
On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5
Re: D game development: a call to action
On Mon, 05 Aug 2013 20:18:29 +0200, Jonathan A Dunlap wrote:: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! A) I recommend using Derelict3--it's kept up to date, looking at the commit log shows work in the last 24 hours to update the bindings. It's also well designed and works well. B) If using Derelict3, you simply need to: build Derelict3 (it's as simple as running build/build.d) and have recent builds of whatever libraries you're using through it. How difficult the shared libraries dependencies are is project by project and not really a D-specific issue. C) Derelict3 is basically just bindings over the C functions--you should use any and all documentation, references, and tutorials against the C libraries. E.g. any C language tutorials on SFML, OpenGL, etc. are trivially translatable once you understand how to load the Derelict modules (again, look at the Derelict README).
Re: D game development: a call to action
On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! Take a look at https://github.com/Jebbs/DSFML The autor, aubade, me and few other guys are trying to maintain the project. I wrote a small tutorial on the wiki. And we have plans on documenting it, adding unittests and much more. The autor announced today that he will soon update the C bindings to SFML 2.1 If you have any problems using it just open an issue on github.
Re: D game development: a call to action
C) Derelict3 is basically just bindings over the C functions--you should use any and all documentation, references, and tutorials against the C libraries. Thanks Justin for the response. Derelict3 does seem to be the library with the most activity by far. However, it's simply not good enough to just say that since these are just bindings that the documentation/examples in the host language is adequate. This is true under the assumption that: the developer already is comfortable in the D language to know the usage difference, are familiar with the lib API to know when these differences apply, or even know to translate dependent idioms outside the actual library usage (like loading an image from disk, to apply to a texture, may be a separate but related learned task to the library). If we are looking for a broader adoption of D, we should be in the mindset of someone who may not even have a background in computer science here.
Re: D game development: a call to action
Take a look at https://github.com/Jebbs/DSFML The autor, aubade, me and few other guys are trying to maintain the project. I wrote a small tutorial on the wiki. And we have plans on documenting it, adding unittests and much more. Great stuff, Borislav. The basic tutorial https://github.com/Jebbs/DSFML/wiki/Short-example helps a lot to grok how to get your feet wet. I'm looking forward to seeing more tutorials like this.
Re: D game development: a call to action
On Monday, 5 August 2013 at 19:03:29 UTC, Jonathan A Dunlap wrote: Take a look at https://github.com/Jebbs/DSFML The autor, aubade, me and few other guys are trying to maintain the project. I wrote a small tutorial on the wiki. And we have plans on documenting it, adding unittests and much more. Great stuff, Borislav. The basic tutorial https://github.com/Jebbs/DSFML/wiki/Short-example helps a lot to grok how to get your feet wet. I'm looking forward to seeing more tutorials like this. Thanks! Bear in mind that the autor is working on splitting the 5 modules into separate files for each class. That is because currently everything is too cluttered into one file for each sfml sub-module. See the Experimental branch, it is almost done. After the change you would be able to more easily browse code and the only change you would have to make is in the imports. So instead of: import dsfml.system; - import dsfml.system.all; or import specific classes: import dsfml.system.vector; //or something like that Also about building and assembling everything together, see https://github.com/Jebbs/DSFML/issues/34 A build.d script is being worked on and things like adding more documentation, unittests and examples are being worked on too. Also an suggestion has been made to add dsfml to the DUB package manager(that is used by vibe.d) and is something similar to ruby's gems manager. And now that Direlict has been mentioned, I suggest you to not use it for sfml. It is just a collection of c-bindings of popular libraries.
Re: D game development: a call to action
I'm working currently on Dgame: http://dgame-dev.de/ I'm almost finished, but the documentation, the tutorials and the download there is not up to date, but that will change in the next few days (now that I had my last exam today). My fellow students and I also work with Dgame on a 2D sidescroller. The work on it was stopped because of exams, but it will continue in the coming weeks.
Re: D game development: a call to action
... Oh and I completely forgot to mention that I am working on a D version of the spine runtime (http://esotericsoftware.com/). If you haven't heard of it it is a 2D skeletal animation tool that exports to bin or json(other formats too). And there are many runtime libraries for many languages(currently no D support) and popular game engines. Although the tool isn't free ($70), it helps development A LOT. However the 'format' is open, so one could write his own editor/exporter. Runtimes are usually split up in two - engine and renderer. The engine part is language-specific (for example C#) and it only parses the data into appropriate structires that the renderer will use later. The renderer part is gameengine-specific (for example Unity, XNA, MonoGame for C#) and uses the engine part's source. Then the renderer part just implements one or two classes that do the actual rendering and logic updates that are engine-specific. And yeah, I decided to make a D runtime for spine: https://github.com/nikibobi/spine-d - engine part (pure D) https://github.com/nikibobi/spine-dsfml - renderer part (D + DSFML) Also I forgot to mention that aubade made an separate repository for SFML extensions ported to D like sfMod and sfMidi https://github.com/aubade/dsfml-contrib Also about your original post you mentioned SFML-D and if you have looked the original SFML site's bindings page(http://www.sfml-dev.org/download/bindings.php) it is indicated that SFML-D is inactive. And there is Jebbs DSFML marked as active along with Direlict 3
Re: D game development: a call to action
On Monday, 5 August 2013 at 19:33:59 UTC, Namespace wrote: I'm working currently on Dgame: http://dgame-dev.de/ I'm almost finished, but the documentation, the tutorials and the download there is not up to date, but that will change in the next few days (now that I had my last exam today). My fellow students and I also work with Dgame on a 2D sidescroller. The work on it was stopped because of exams, but it will continue in the coming weeks. Wow that's great news! I will try it and maybe try to help you test it and improve it. I will look more into it tomorrow when I have more time. But from the first looks, I like the site design and the engine looks a lot like SFML(a good thing).
Re: D game development: a call to action
On Mon, 05 Aug 2013 20:59:32 +0200, Jonathan A Dunlap wrote: C) Derelict3 is basically just bindings over the C functions--you should use any and all documentation, references, and tutorials against the C libraries. Thanks Justin for the response. Derelict3 does seem to be the library with the most activity by far. However, it's simply not good enough to just say that since these are just bindings that the documentation/examples in the host language is adequate. This is true under the assumption that: the developer already is comfortable in the D language to know the usage difference, are familiar with the lib API to know when these differences apply, or even know to translate dependent idioms outside the actual library usage (like loading an image from disk, to apply to a texture, may be a separate but related learned task to the library). If we are looking for a broader adoption of D, we should be in the mindset of someone who may not even have a background in computer science here. All Derelict3 usage differences are clearly documented in a wonderfully short section in the README. I don't think it's a problem to assume that someone who wants to write a video game in the D programming language has a basic working knowledge of D and of the various aspects of language agnostic game programming; i.e. documentation on how to invent the universe should not be a prerequisite for baking an apple pie. That said, I will seriously consider writing an article on getting started with modern OpenGL with Derelict3.
Re: D game development: a call to action
On Monday, 5 August 2013 at 19:47:40 UTC, Borislav Kosharov wrote: On Monday, 5 August 2013 at 19:33:59 UTC, Namespace wrote: I'm working currently on Dgame: http://dgame-dev.de/ I'm almost finished, but the documentation, the tutorials and the download there is not up to date, but that will change in the next few days (now that I had my last exam today). My fellow students and I also work with Dgame on a 2D sidescroller. The work on it was stopped because of exams, but it will continue in the coming weeks. Wow that's great news! I will try it and maybe try to help you test it and improve it. I will look more into it tomorrow when I have more time. But from the first looks, I like the site design and the engine looks a lot like SFML(a good thing). Yes SFML was one of my inspirations. I'll hurry to bring everything up to date. And of course I'd be happy about any help. ;)
Re: D game development: a call to action
On Monday, 5 August 2013 at 19:33:59 UTC, Namespace wrote: The work on it was stopped because of exams, but it will continue in the coming weeks. That's the exact same problem I am having with DSFML! I was making good progress until my teacher stated giving me tests and homework! What a jerk!
Re: D game development: a call to action
On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for real would usage e.g. how to create an OpenGL window or how to render a triangle versus something like how to load from disk an image texture onto a quad and move it around using keyboard events SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! I am working on a media/gaming library for D, its not even pre alpha, and I am learning parts of the language as I go so the code is very ugly, and the naming conventions are scatter brained. However I don't use any wrappers of other media libraries such as sfml, I only have the minimal bindings required to link with X11 and opengl(I do plan on windows bindings as well, but i haven't done that yet). At the moment I am tackling concurrency, That bit is giving me endless headaches, I am trying to setup a seperate thread to handle opengl calls and a seperate thread for handling object updates. https://github.com/luminousone/dmedia I haven't picked a license yet, but it will be something that is rather open but leaves me the option to staticly link it in closed projects. I still think you might find a few interesting bits in that link, but it does have a while to go before it is remotely useable. I am open to working with others, or making changes to what I have done if anyone is interested.
