I have this game engine...

[Manu via Digitalmars-d]

On 2 November 2015 at 04:17, Johannes Pfau via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Sun, 1 Nov 2015 11:33:21 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:
>
>> If people find this to be an interesting project, and I do take some
>> time to do this port, what I'd really love is to work together with
>> some of the niche platform support guys and use it to stress test
>> toolchains for various platforms. I'd also like help from guys like
>> Johannes to make regularly released builds of some console
>> cross-compilers available so that it can keep on building.
>> The CI of this project for those platforms would more-or-less verify
>> that the toolchains and druntime+friends are working.
>
> Sounds like a great idea!
>
> I can certainly build the GDC toolchains*. But I guess the first thing
> you'll need if you want to use Dreamcast, NDS and other low memory
> systems is a @nogc druntime port? I had a look at this some time ago and
> there's some work to be done until we can build a druntime completely
> without GC.

Awesome! Your support on this is really encouraging. Almost all
consoles are typically targeted by GCC. PS4 uses Clang officially, but
I'm sure GCC works just as well.

Easiest to start with some of the bigger systems. I think another
benefit of this project may be that building for the smaller systems
will start to reveal binary size issues, and perhaps we can use it as
a vessel to drive some improvements in that area. Binary size is
something that's been really irk-ing me for years.

What implicitly linked parts of druntime are not @nogc?
I have no good reason to say that @nogc should be an absolute
requirement... it is almost certainly preferable to many gamedevs so
it would be nice to support it, but GC should be available if the
developer wants it... I'm not sure what cost that comes at in terms of
binary size. Runtime memory is a matter for the developer, they know
the compromise they are making if they opt to use the GC.


> or better: also provide build scripts. We now use docker.io containers
> to build the binary GDC toolchains. Building a toolchain with the latest
> GDC version is as simple as running one docker command:
>
> docker run
> -v ~/shared-dir/:/home/build/shared #results will be saved here
> -t jpf91/build-gdc /usr/bin/build-gdc build
> --toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32
>
> It should be easy enough to add support for console toolchain build
> scripts.

Awesome, and that would just be run along with the rest of the CI when
producing toolchains? Reliable binary downloads available in known
places? Even the presence of these toolchains (whether people use them
or not) will inspire some confidence in gamedev's that D means
business in gamedev. They are more likely to give D a shot if they
know that toolchains are available should ports need to be made at
some later stage.