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.

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...

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?

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).

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...

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.

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)

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 =/

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.

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;-)