On 19 January 2015 at 09:50, Rikki Cattermole via Digitalmars-d <[email protected]> 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 >> >> <[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.
...I don't follow.
