On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote:
On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d
<[email protected]> wrote:
On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote:
On 18 January 2015 at 19:56, Joakim via Digitalmars-d
<[email protected]> wrote:
On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote:
At Remedy, we ran D code on xbone with no opposition from MS.
For xbone, we wanted to maintain compatibility with the rest of our
MSVC code, which meant we needed to produce COFF output that the MSVC
linker accepts. Walter implemented DMD-Win64 with these requirements
in mind.
PS4 should be easier using LDC, but I don't know if Sony would take
issue with this. I expect them to take less issue than MS, so I'd give
good odd's that they'd be fine with it.
Short answer, D works on modern consoles just fine, and there were no
political blocks for us. GC is a demonstrated problem; avoid it. DMD's
codegen is also a problem; it uses x87 to perform operations, despite
the fact the x64 ABI uses SSE regs for float passing. That results in
a lot of register switching, and poor float performance as a result.
As an (awkward) workaround, you can use explicit SSE intrinsics to
keep working in XMM, but I haven't tested the optimiser's quality in
that case, and the std library obviously doesn't do that.
Thanks for the detailed answer. Sounds like the only thing holding D
back
is someone putting in the effort to integrate it with the console runtime
and APIs. It's not going to be me, as I haven't owned a console or even
played a console game in a decade. Yes, I know I'm an old fogey. :)
I don't think there's any particularly compelling reason to make
runtime calls from D. You can link C/C++ and D code together just
fine. If you're a gamedev, there's a very high chance that you already
have an engine (presumably C/C++) in place. You'll need to bind the
engine api, not the OS api.
Trouble with the console OS api's are that they're protected by NDA;
it would probably be pretty dubious to release any such foreign
language binding here, so each studio would have to do that work
themselves... unless it were posted on the official dev forums or
something.
$ dub add-local .
Could be rather useful here!
I don't know what that means?
You don't need to register packages of the dub repository for dub to be
able to use a package. In this case its registered locally instead.
In terms of NDA's, can definitely be used to make e.g. wrappers of
bindings private and then use them to publically distribute the usage of
them.
