www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D game development: a call to action

reply "Jonathan A Dunlap" <jdunlap outlook.com> writes:
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!
Aug 05 2013
next sibling parent reply Justin Whear <justin economicmodeling.com> writes:
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).
Aug 05 2013
parent reply "Jonathan A Dunlap" <jdunlap outlook.com> writes:
 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.
Aug 05 2013
parent reply Justin Whear <justin economicmodeling.com> writes:
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.
Aug 05 2013
parent reply "Israel" <tl12000 live.com> writes:
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

Dec 13 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 14 Dec 2014 01:28:45 +0000
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?
Dec 13 2014
prev sibling next sibling parent reply "Borislav Kosharov" <bosak gmail.com> writes:
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.
Aug 05 2013
parent reply "Jonathan A Dunlap" <jdunlap outlook.com> writes:
 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.
Aug 05 2013
parent reply "Borislav Kosharov" <bosak gmail.com> writes:
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.
Aug 05 2013
parent "Borislav Kosharov" <bosak gmail.com> writes:
 ...
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 parses the data into appropriate structires that the renderer will use later. The renderer part is gameengine-specific (for 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
Aug 05 2013
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
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.
Aug 05 2013
next sibling parent reply "Borislav Kosharov" <bosak gmail.com> writes:
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).
Aug 05 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
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. ;)
Aug 05 2013
prev sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
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!
Aug 05 2013
prev sibling next sibling parent "luminousone" <rd.hunt gmail.com> writes:
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.
Aug 05 2013
prev sibling next sibling parent reply "qznc" <qznc web.de> writes:
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
Aug 05 2013
parent reply "Joel" <joelcnz gmail.com> writes:
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.
Dec 13 2014
parent reply "uri" <uri.grill gmail.com> writes:
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
Dec 13 2014
parent reply "Joel" <joelcnz gmail.com> writes:
[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.
Dec 13 2014
next sibling parent reply "Joel" <joelcnz gmail.com> writes:
I'm using Windows. I get this error trying to compile the demo on 
DGame.

C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\build>dmd build.d
Using the Digital Mars DMD compiler.

C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\build>build.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!
Dec 13 2014
parent "Namespaces" <rswhite4 gmail.com> writes:
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\build>dmd build.d
 Using the Digital Mars DMD compiler.

 C:\jpro\dpro2\OtherPeoples\Dgame-0.3.2\build>build.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.
Dec 16 2014
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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
Dec 13 2014
parent "Joel" <joelcnz gmail.com> writes:
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.
Dec 13 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 6 August 2013 at 04:18, Jonathan A Dunlap <jdunlap 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!
Dec 13 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 !
Dec 13 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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).
Dec 13 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 13 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Dec 14 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 14 2014
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
 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.
Dec 15 2014
next sibling parent "bitwise" <bitwise.pvt gmail.com> writes:
Actually, iOS and Android both have x86 emulators don't they?
Dec 15 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 15 Dec 2014 23:40:43 +0000
bitwise via Digitalmars-d <digitalmars-d puremagic.com> wrote:

  manu
=20
 I'm a little confused.. Looking through your Fuji/Source/Drivers=20
 folder, I see folders for IPhone and Android, among others...=20
 does your engine actually run on these platforms?
=20
 I was under the impression that D could not compile to those=20
 targets yet.
Fiji is not written in D, but it has extensive D API.
Dec 16 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 16 2014
next sibling parent reply "bitwise" <bitwise.pvt gmail.com> writes:
 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.
Dec 16 2014
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
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...
Dec 17 2014
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 >_<
Dec 18 2014
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
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?
Dec 16 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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).
Dec 16 2014
parent Johannes Pfau <nospam example.com> writes:
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.
Dec 17 2014
prev sibling next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
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;-)
Dec 17 2014
parent reply Johannes Pfau <nospam example.com> writes:
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).
Dec 18 2014
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 ;)
Dec 18 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 ;)
Dec 18 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 December 2014 at 11:00, Manu <turkeyman gmail.com> wrote:
 On 6 August 2013 at 04:18, Jonathan A Dunlap <jdunlap 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.
Dec 13 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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".
Dec 13 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 13 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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".
=20 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.
Dec 13 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Dec 13 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
=20 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. ;-)
Dec 14 2014
parent reply "Sebastiaan Koppe" <mail skoppe.eu> writes:
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 :)
Dec 18 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Dec 18, 2014 at 05:33:24PM +0000, 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.
Dec 18 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 +0000, 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.
Dec 18 2014
prev sibling parent reply "LaMainNoire" <lamainnoire zabajak.ca> writes:
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.
Dec 16 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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...
Dec 16 2014
parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
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)
Dec 17 2014
next sibling parent reply "bitwise" <bitwise.pvt gmail.com> writes:
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 =/
Dec 17 2014
parent "Mengu" <mengukagan gmail.com> writes:
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.
Dec 17 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Dec 18 2014