On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote:
> On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote:
>>
>> It's good to hear that. Maybe you could write a short article about that once you've moved to D. "Porting games to D" or something like that. With D you can develop fast due to short compilation times, that's important for testing and prototyping.
>>
>
> I actually was planning on something like that. I am still thinking about writing on automatic binding generation between D and Lua using D's compile-time reflection. Add a UDA to a function, class, method a voila! You can call it from Lua. Magic!

I presume you're familiar with http://code.dlang.org/packages/luad

On Tuesday, 30 September 2014 at 10:39:53 UTC, John Colvin wrote:
> On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote:
>> On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote:
>>>
>>> It's good to hear that. Maybe you could write a short article about that once you've moved to D. "Porting games to D" or something like that. With D you can develop fast due to short compilation times, that's important for testing and prototyping.
>>>
>>
>> I actually was planning on something like that. I am still thinking about writing on automatic binding generation between D and Lua using D's compile-time reflection. Add a UDA to a function, class, method a voila! You can call it from Lua. Magic!
>
> I presume you're familiar with http://code.dlang.org/packages/luad

I am, but it is incredible how much of the binding-code can be generated with just few lines of D.

Please, does anybody know anything about my original question? :P

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:
> On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote:
>> On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote:
>>
>>
>> Is that all it would take? Do you also need a GC-free standard library, which seems to be the need of all the others saying "do this and I'll switch from C++"? Are the tools good enough?
>
> Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. - Especially- that native executable is being built in case of D.

BlueByte latest games are done in Flash.

There is an article on the German magazine Making Games about their experience switching from being hardcore C++ guys into the world of Flash and Stage3D.

>
> I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway.

Which also offers a C++ GC API, although quite limited from what I have read.

Sometimes it seems the whole Assembly vs C vs Pascal, followed by C vs C++ performance discussions all over again.


--
Paulo

On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote:
> On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote:
>>
>> It's good to hear that. Maybe you could write a short article about that once you've moved to D. "Porting games to D" or something like that. With D you can develop fast due to short compilation times, that's important for testing and prototyping.
>>
>
> I actually was planning on something like that. I am still thinking about writing on automatic binding generation between D and Lua using D's compile-time reflection. Add a UDA to a function, class, method a voila! You can call it from Lua. Magic!

Great. I'm interested in Lua-D interaction. Would you share it on GitHub once it's done?

Have you had a look at DerelictLua: https://github.com/DerelictOrg/DerelictLua

On Tuesday, 30 September 2014 at 11:46:30 UTC, Chris wrote:
>
> Great. I'm interested in Lua-D interaction. Would you share it on GitHub once it's done?
>
> Have you had a look at DerelictLua: https://github.com/DerelictOrg/DerelictLua

I was thinking about maybe just posting snippets on the blog but GitHub should be doable. I am not much of a blogger tho... Anyway, I would be nothing new to D programmer but I think it would be quite interesting for C++ programmer dealing with variadic marcos and boost.mpl for (the half of) similar result.

On Tuesday, 30 September 2014 at 11:46:30 UTC, Chris wrote:
>
> Have you had a look at DerelictLua: https://github.com/DerelictOrg/DerelictLua

Forgot to reply to 2nd part: yes I looked at it and in fact I
tried my code using it.

> All true again, pre-allocation can fix lots of pause issues. And simply not using GC in tight loops. While not the greatest fan of Unity, it proved that GC (on top of of VM) is not a concern for (I argue) most of gamedev. Minecraft was originally written in Java for crying out loud yet it didn't stop it from becoming gigantic success.

 Unity the engine is written in C++. When you create a game using Unity you are merely scripting the C++ engine using C#, no different than the countless games that do the same using Lua.

On Tuesday, 30 September 2014 at 13:29:15 UTC, po wrote:
>
>> All true again, pre-allocation can fix lots of pause issues. And simply not using GC in tight loops. While not the greatest fan of Unity, it proved that GC (on top of of VM) is not a concern for (I argue) most of gamedev. Minecraft was originally written in Java for crying out loud yet it didn't stop it from becoming gigantic success.
>
>  Unity the engine is written in C++. When you create a game using Unity you are merely scripting the C++ engine using C#, no different than the countless games that do the same using Lua.

This will most likely change when they get their IL2CPP production ready and start moving code from C++ to C#.

Or when Microsoft finishes the ongoing work on .NET Native.

--
Paulo

> This will most likely change when they get their IL2CPP production ready and start moving code from C++ to C#.
>
> Or when Microsoft finishes the ongoing work on .NET Native.
>
> --
> Paulo

 I'd not seen IL2CPP before, but from this link:

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/

It appears to act as a replacement for the mono VM, allowing for AoT compilation of .Net IL into C++, so that they can benefit from existing C++ compiler tech.

 It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.

On Tuesday, 30 September 2014 at 13:59:01 UTC, po wrote:
>  It doesn't mention anything about moving C++ into C#.
> Even with IL2CPP, C# has fundamental design trade offs that make it slower than C++(GC is just one of them), so it wouldn't make much sense to port engine code to C# unless they wanted it to run slower.

Yes, the info on CIL instruction set suggests that is a very simple IR, which is an advantage if you want to prove safety or write portable code, but that also means CIL will have a hard time beating llvm. Some performance related decisions have to be taken at a higher abstraction level than CIL.