December 14, 2014
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.
December 14, 2014
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.
December 14, 2014
What my problem is, why hasnt the D standard library implemented
a multimedia library from the ones already available? instead of
having to go and look for one.

Im sure this would cause alot of controversy because "NO MY
LIBRARY IS BETTER AND HAS MORE FEATURES THAN HIS".

Its not about features. Its about its ease of use and learning.
OP is right though.

If we want to gain some momentum we need libraries that are
easier to use and learn than the standard C/C++ syntax that
plagues SDL/Derelict.

Because cleaning up the previous mess is what made C better than
Assembly, C++ better than C, and C#/Java better than C++.
December 14, 2014
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".


December 14, 2014
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?


December 14, 2014
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.
December 14, 2014
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 !

December 14, 2014
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.


December 14, 2014
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).
December 14, 2014
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.