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