Can D get on XBone and PS4?

[Manu via Digitalmars-d]

On 19 January 2015 at 09:50, Rikki Cattermole via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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
>>
>> <digitalmars-d at puremagic.com> 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
>>>> <digitalmars-d at puremagic.com> 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.

...I don't follow.