Can D get on XBone and PS4?

Rikki Cattermole via Digitalmars-d digitalmars-d at puremagic.com
Sun Jan 18 20:27:20 PST 2015


On 19/01/2015 5:13 p.m., Manu via Digitalmars-d wrote:
> 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.

Because of an NDA's, we may not be able to release bindings to the 
native API's but we can release wrapper interfaces. So long as they are 
not one for one. Atleast theoretically.
Assuming the bindings/wrapper implementation is distributed via official 
means e.g. a forum which is non public and approved of.
Dub could be used, as the build manager for any projects using the 
bindings. As long as when the bindings/wrappers are released, they are 
built as dub packages.
Once downloaded they merely need to be added as a local package into 
dub. Ensuring NDA and the ability to public publically engines and such.


More information about the Digitalmars-d mailing list