Hi,

I have some experience with c++, and am considering using either D or python for a game.

1. It is going to be online-based, would D be a good choice for writing both the client and server? I haven't seen any online games using D yet.

2. A concern is interfacing with c++. I'll like to use the RakNet networking library, but there aren't any bindings for it.
a) Are there instructions available for using Calypso on windows? Couldn't find any, and it looks like a good alternative to writing one by hand.
b) How well would SWIG work? I haven't used multiple programming languages in a project before, so have no experience doing this sort of thing.

You can safely forget about RakNet by the looks.

"While I still get some inquiries, as of as of March 13, 2015 I've decided to stop licensing so I can focus on changing the world through VR."

So based upon this, what would you like to do? Scratch or another pre-existing protocol like proto-buffers?

On Saturday, 6 August 2016 at 04:01:03 UTC, rikki cattermole wrote:
> You can safely forget about RakNet by the looks.
>
> "While I still get some inquiries, as of as of March 13, 2015 I've decided to stop licensing so I can focus on changing the world through VR."
>
> So based upon this, what would you like to do? Scratch or another pre-existing protocol like proto-buffers?

It is a mature library, which has been open sourced under the BSD license when Oculus baught it. Hence why I want to use this instead of reinventing the wheel.

On 06/08/2016 6:28 PM, Neurone wrote:
> On Saturday, 6 August 2016 at 04:01:03 UTC, rikki cattermole wrote:
>> You can safely forget about RakNet by the looks.
>>
>> "While I still get some inquiries, as of as of March 13, 2015 I've
>> decided to stop licensing so I can focus on changing the world through
>> VR."
>>
>> So based upon this, what would you like to do? Scratch or another
>> pre-existing protocol like proto-buffers?
>
> It is a mature library, which has been open sourced under the BSD
> license when Oculus baught it. Hence why I want to use this instead of
> reinventing the wheel.

They really need to update its old website then.

I've had a look at the code, its mostly classes and is very c style.
You won't have trouble making bindings.

The main steps if you want to give it a go are:
1. Compile via MSVC (either 32 or 64bit are fine) can be static of dynamic
2. Compile D with -m32mscoff or -m64 and link against above binary

You will almost definitely want to use 64bit binaries not 32bit if you use dub.

I know there is a D target for SWIG but I have never really used it. But I do not believe you need any magical tool to do the binding creation for you. The headers should convert over nicely as is for you.

On Saturday, 6 August 2016 at 08:04:45 UTC, rikki cattermole wrote:
> On 06/08/2016 6:28 PM, Neurone wrote:
>> On Saturday, 6 August 2016 at 04:01:03 UTC, rikki cattermole wrote:
>>> You can safely forget about RakNet by the looks.
>>>
>>> "While I still get some inquiries, as of as of March 13, 2015 I've
>>> decided to stop licensing so I can focus on changing the world through
>>> VR."
>>>
>>> So based upon this, what would you like to do? Scratch or another
>>> pre-existing protocol like proto-buffers?
>>
>> It is a mature library, which has been open sourced under the BSD
>> license when Oculus baught it. Hence why I want to use this instead of
>> reinventing the wheel.
>
> They really need to update its old website then.
>
> I've had a look at the code, its mostly classes and is very c style.
> You won't have trouble making bindings.
>
> The main steps if you want to give it a go are:
> 1. Compile via MSVC (either 32 or 64bit are fine) can be static of dynamic
> 2. Compile D with -m32mscoff or -m64 and link against above binary
>
> You will almost definitely want to use 64bit binaries not 32bit if you use dub.
>
> I know there is a D target for SWIG but I have never really used it. But I do not believe you need any magical tool to do the binding creation for you. The headers should convert over nicely as is for you.

Do I use the DMD compiler? Also, would Dub not work with 64-bit executables? I still need to use 32-bit to support systems that aren't 64-bit yet.

Also, is it possible to use D like a traditional scripting language? The use case is adding content to the server (which may contain D scripts) without restarting it for a full recompile.

On 06/08/2016 10:53 PM, Neurone wrote:
> On Saturday, 6 August 2016 at 08:04:45 UTC, rikki cattermole wrote:
>> On 06/08/2016 6:28 PM, Neurone wrote:
>>> On Saturday, 6 August 2016 at 04:01:03 UTC, rikki cattermole wrote:
>>>> You can safely forget about RakNet by the looks.
>>>>
>>>> "While I still get some inquiries, as of as of March 13, 2015 I've
>>>> decided to stop licensing so I can focus on changing the world through
>>>> VR."
>>>>
>>>> So based upon this, what would you like to do? Scratch or another
>>>> pre-existing protocol like proto-buffers?
>>>
>>> It is a mature library, which has been open sourced under the BSD
>>> license when Oculus baught it. Hence why I want to use this instead of
>>> reinventing the wheel.
>>
>> They really need to update its old website then.
>>
>> I've had a look at the code, its mostly classes and is very c style.
>> You won't have trouble making bindings.
>>
>> The main steps if you want to give it a go are:
>> 1. Compile via MSVC (either 32 or 64bit are fine) can be static of
>> dynamic
>> 2. Compile D with -m32mscoff or -m64 and link against above binary
>>
>> You will almost definitely want to use 64bit binaries not 32bit if you
>> use dub.
>>
>> I know there is a D target for SWIG but I have never really used it.
>> But I do not believe you need any magical tool to do the binding
>> creation for you. The headers should convert over nicely as is for you.
>
> Do I use the DMD compiler? Also, would Dub not work with 64-bit
> executables? I still need to use 32-bit to support systems that aren't
> 64-bit yet.

Yes to dmd.

$ dub build --arch=x86_64

For 32bit I use a hack of a workaround to make it work recursively.

$ DFLAGS="-m32mscoff" ; dub build

Sadly this is not full proof or much help.

The reason why you must use -m32mscoff or -m64 is to use the COFF binary format as OMF (which is default for 32bit) will not link against any binaries produced by MSVC.

Of course if you can build it as a shared library and get an OMF import library you're good to go as well. But just easier to keep everything the same.

> Also, is it possible to use D like a traditional scripting language? The
> use case is adding content to the server (which may contain D scripts)
> without restarting it for a full recompile.

I would not attempt this. Its not worth your time or worry. Instead I would use D for infrastructure but Lua for logic that is likely to change often.

On Saturday, 6 August 2016 at 11:18:11 UTC, rikki cattermole wrote:

> For 32bit I use a hack of a workaround to make it work recursively.
>
> $ DFLAGS="-m32mscoff" ; dub build
>
> Sadly this is not full proof or much help.

For clarity, what rikki is getting at here is that DUB does not yet support compiling to the 32-bit COFF format. The --arch switch for dub has two options: x86 and x86_64. The former will cause it to call dmd with the -m32 switch. The only way to get use -m32mscoff is to specify it manually. Doing so in the dflags entry of your dub configuration will certainly cause errors if you have any dependencies in your configuration (your source will be compiled with -m32mscoff, while dependencies are compiled with -m32). I've not tried the environment variable approach that rikki shows here, so I have no comment on that.

There is an issue in the DUB bug tracker to for this [1].

[1] https://github.com/dlang/dub/issues/628

On 07/08/2016 1:08 AM, Mike Parker wrote:
> On Saturday, 6 August 2016 at 11:18:11 UTC, rikki cattermole wrote:
>
>> For 32bit I use a hack of a workaround to make it work recursively.
>>
>> $ DFLAGS="-m32mscoff" ; dub build
>>
>> Sadly this is not full proof or much help.
>
> For clarity, what rikki is getting at here is that DUB does not yet
> support compiling to the 32-bit COFF format. The --arch switch for dub
> has two options: x86 and x86_64. The former will cause it to call dmd
> with the -m32 switch. The only way to get use -m32mscoff is to specify
> it manually. Doing so in the dflags entry of your dub configuration will
> certainly cause errors if you have any dependencies in your
> configuration (your source will be compiled with -m32mscoff, while
> dependencies are compiled with -m32). I've not tried the environment
> variable approach that rikki shows here, so I have no comment on that.
>
> There is an issue in the DUB bug tracker to for this [1].
>
> [1] https://github.com/dlang/dub/issues/628

What happens is dub uses DFLAGS as part of the identifier for builds and will propagate it to dependencies. As long as you don't miss-match the values of DFLAGS, you're good to go.