www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Previously: DMD - Windows -> C# in gamedev

reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 15:24, Paulo Pinto <pjmlp progtools.org> wrote:


 Hi Manu,



 I am a bit of half-insider in the game industry, being
 a IGDA member for some years and also attended two
 GDCE so far.

 Several reasons have kept me from getting a job in the
 industry, but I still follow what's happening quite closely.

 From what I know here in Europe, many studios have been slowly

 are also experimenting with it in their engines.

 How does it look like from your side?

 I think this is important to know, because in what concerns

 with good quality AOT compilers. Not sure how good Mono's AOT

 language for the PlayStation VITA and the PlayStation Suite.

 And game development is probably one of the few areas where D could get
 an entry to.




obvious choice if you want to remove your tools from C++/MFC/whatever.

bat, and tend to keep on that wagon.
I think it started like this; some coder decides he hates writing tools in

They give it a go (...see my previous post).

I don't know if you're on the mark saying studios that 'target mostly

instance of that outside indy-games.
The most interesting trend I think is the Unity effect. They embed mono
into their engine (ie, NON-windows machines), and all high level game code

This seems an amazingly sensible idea, and most people seem to agree. I
love the idea of Unity, and on small games, handhelds and stuff, it seems
to work really well.


affiliated with Microsoft, although I am very surprised by Sony's move, so
maybe I'm way off the mark.
Also, for AAA mainstream titles, I don't think there's any choice other
than C++. Game engines are aggressively tuned at very low level to the
hardware. I don't think any non-C++-like systems language can take that
away (D may have a chance here, but the GC might be a problem at the engine
level).

I think it's likely that the shift more towards mono (or some other
script-ish language) taking over the high level logic code will continue
though. Mono just happens to have a great AOT experience, familiar
IDE's/integration into workflow, and familiarity to most devs now via
working on tools.

One of the biggest challenges for the gamedev world is adapting high-level
game code to scalable SMP systems. Engine is easy to make scale, game
logic, not so much. Strong OOP is the problem here.
With the current trend of using an auxilliary language to write this logic
code, there's opportunity for a language that totally nails SMP scalability
to really make a dent... but it's hard to predict :)

I don't think I can emphasise enough though the point I made in my last
post where the successful language will likely NOT be the language with the
best merits towards that end. It will be the one that is most easily

is so popular atm.

All that said, I'm just an engine programmer. I write C++ to the metal. I'm
not the best authority on the topic :)
Jan 07 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Thanks for the explanation.

I am convinced that eventually AAA game engines can be
made in a GC enabled language like D, they just need to
be coded in a different way, more GC-friendly.

But this is just a wish about progress, and I don't have
any real industry experience to say it will really happen.

Thanks again for the feedback,
Paulo

Am 07.01.2012 15:34, schrieb Manu:

 On 7 January 2012 15:24, Paulo Pinto <pjmlp progtools.org
 <mailto:pjmlp progtools.org>> wrote:

     Hi Manu,



     I am a bit of half-insider in the game industry, being
     a IGDA member for some years and also attended two
     GDCE so far.

     Several reasons have kept me from getting a job in the
     industry, but I still follow what's happening quite closely.

      >From what I know here in Europe, many studios have been slowly

     are also experimenting with it in their engines.

     How does it look like from your side?

     I think this is important to know, because in what concerns

     with good quality AOT compilers. Not sure how good Mono's AOT

     language for the PlayStation VITA and the PlayStation Suite.

     And game development is probably one of the few areas where D could get
     an entry to.



 the obvious choice if you want to remove your tools from C++/MFC/whatever.

 the bat, and tend to keep on that wagon.
 I think it started like this; some coder decides he hates writing tools

 it. They give it a go (...see my previous post).

 I don't know if you're on the mark saying studios that 'target mostly

 instance of that outside indy-games.
 The most interesting trend I think is the Unity effect. They embed mono
 into their engine (ie, NON-windows machines), and all high level game

 This seems an amazingly sensible idea, and most people seem to agree. I
 love the idea of Unity, and on small games, handhelds and stuff, it
 seems to work really well.


 affiliated with Microsoft, although I am very surprised by Sony's move,
 so maybe I'm way off the mark.
 Also, for AAA mainstream titles, I don't think there's any choice other
 than C++. Game engines are aggressively tuned at very low level to the
 hardware. I don't think any non-C++-like systems language can take that
 away (D may have a chance here, but the GC might be a problem at the
 engine level).

 I think it's likely that the shift more towards mono (or some other
 script-ish language) taking over the high level logic code will continue
 though. Mono just happens to have a great AOT experience, familiar
 IDE's/integration into workflow, and familiarity to most devs now via
 working on tools.

 One of the biggest challenges for the gamedev world is adapting
 high-level game code to scalable SMP systems. Engine is easy to make
 scale, game logic, not so much. Strong OOP is the problem here.
 With the current trend of using an auxilliary language to write this
 logic code, there's opportunity for a language that totally nails SMP
 scalability to really make a dent... but it's hard to predict :)

 I don't think I can emphasise enough though the point I made in my last
 post where the successful language will likely NOT be the language with
 the best merits towards that end. It will be the one that is most easily
 integrated into developers workflows, and I think this is the key reason


 All that said, I'm just an engine programmer. I write C++ to the metal.
 I'm not the best authority on the topic :)
Jan 07 2012
parent reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 17:27, Paulo Pinto <pjmlp progtools.org> wrote:


 Thanks for the explanation.

 I am convinced that eventually AAA game engines can be
 made in a GC enabled language like D, they just need to
 be coded in a different way, more GC-friendly.


I tend to disagree. I see it trending in the opposite direction.
Tight pooling of resources and updating in finer grained (probably
threaded) tight loops across neatly (cache friendly) packed bundles of like
objects. That's where engines are going.
Engines are becoming more and more memory-layout aware, not less... GC is
the opposite of rigid memory layout.
It's great for high level sugar that glues the whole thing together, but
the engine is heading the opposite way; everything works more like a video
card, small repetitive streamed jobs, with memory carefully managed.
Jan 07 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Manu:


 and updating in finer grained (probably
 threaded) tight loops across neatly (cache friendly) packed bundles of like
 objects. That's where engines are going.


I agree. Something related:

http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

A language designed for games has to help this style of coding.

Bye,
bearophile
Jan 07 2012
parent reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 17:55, bearophile <bearophileHUGS lycos.com> wrote:


 Manu:


 and updating in finer grained (probably
 threaded) tight loops across neatly (cache friendly) packed bundles of


 like

 objects. That's where engines are going.


 I agree. Something related:


 http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

 A language designed for games has to help this style of coding.


Hehe, Tony's a good mate of mine (that lecture) :)
He's become quite a prominent figure in Australia after taking the Sony
job. He quit now though.
Amusingly, he managed to convince Mike Acton to speak at the recent GCAP,
even though the Australian industry has disintegrated ;)

This is my biggest fear with investing in D. It's not incompatible with D,
but liberal use of the GC in the language and/or in the libraries scares me.
The tendency to encourage use of dynamic arrays will be a major problem.

I don't think it's reached a point of no return yet, but it needs to be
carefully considered, and I really would like support for allocators in D.
I *need* to be able to assign class memory out of pools, ideally without
making my code archaic and/or breaking the language usage paradigms.
Jan 07 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Manu:


 The tendency to encourage use of dynamic arrays will be a major problem.


I don't know how much big that problem will be, D dynamic arrays are quite
handy, but I agree that static arrays need to be encouraged more in D (and
currently most algorithms of Phobos don't work with static arrays (you need to
slice them first)).

Currently even this code with a stack-allocated fixed size array causes a heap
allocation (DMD):

void main() {
    int[2] a = [1, 2];
}

ASM, optimized build:

__Dmain comdat
    push EAX
    push EAX
    mov EAX,offset FLAT:_D12TypeInfo_xAi6__initZ
    push EBX
    push 8
    push 2
    push EAX
    call near ptr __d_arrayliteralTX ; heap allocation
    add ESP,8
    mov EBX,EAX
    mov dword ptr [EAX],1
    mov ECX,EBX
    push EBX
    lea EDX,0Ch[ESP]
    mov dword ptr 4[EBX],2
    push EDX
    call near ptr _memcpy
    add ESP,0Ch
    xor EAX,EAX
    pop EBX
    add ESP,8
    ret


I have suggested to add a safer version of VLAs to avoid some heap-allocated
dynamic arrays:
http://d.puremagic.com/issues/show_bug.cgi?id=5348

Most people here seem to not care of the Ada language, but if you take a look
at Ada code you see how often it doesn't use heap allocations.

Bye,
bearophile
Jan 07 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 07.01.2012 19:59, schrieb bearophile:

 Manu:


 The tendency to encourage use of dynamic arrays will be a major problem.


 I don't know how much big that problem will be, D dynamic arrays are quite
handy, but I agree that static arrays need to be encouraged more in D (and
currently most algorithms of Phobos don't work with static arrays (you need to
slice them first)).

 Currently even this code with a stack-allocated fixed size array causes a heap
allocation (DMD):

 void main() {
      int[2] a = [1, 2];
 }

 ASM, optimized build:

 __Dmain comdat
      push EAX
      push EAX
      mov EAX,offset FLAT:_D12TypeInfo_xAi6__initZ
      push EBX
      push 8
      push 2
      push EAX
      call near ptr __d_arrayliteralTX ; heap allocation
      add ESP,8
      mov EBX,EAX
      mov dword ptr [EAX],1
      mov ECX,EBX
      push EBX
      lea EDX,0Ch[ESP]
      mov dword ptr 4[EBX],2
      push EDX
      call near ptr _memcpy
      add ESP,0Ch
      xor EAX,EAX
      pop EBX
      add ESP,8
      ret


 I have suggested to add a safer version of VLAs to avoid some heap-allocated
dynamic arrays:
 http://d.puremagic.com/issues/show_bug.cgi?id=5348

 Most people here seem to not care of the Ada language, but if you take a look
at Ada code you see how often it doesn't use heap allocations.

 Bye,
 bearophile


The Ada standard also allows for some form of optional automatic memory 
management, even if only some of the compilers offer it.


http://en.wikibooks.org/wiki/Ada_Programming/Types/access
Jan 07 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 20:59, bearophile <bearophileHUGS lycos.com> wrote:


 Manu:


 The tendency to encourage use of dynamic arrays will be a major problem.


 I don't know how much big that problem will be, D dynamic arrays are quite
 handy, but I agree that static arrays need to be encouraged more in D (and
 currently most algorithms of Phobos don't work with static arrays (you need
 to slice them first)).


A slice doesn't produce a GC allocation does it?
I thought a slice was just a pointer-length pair. Should live on the
stack/in regs?

...so slicing static arrays shouldn't be a problem right?



 Currently even this code with a stack-allocated fixed size array causes a
 heap allocation (DMD):

 void main() {
    int[2] a = [1, 2];
 }

 ASM, optimized build:

 __Dmain comdat
    push EAX
    push EAX
    mov EAX,offset FLAT:_D12TypeInfo_xAi6__initZ
    push EBX
    push 8
    push 2
    push EAX
    call near ptr __d_arrayliteralTX ; heap allocation
    add ESP,8
    mov EBX,EAX
    mov dword ptr [EAX],1
    mov ECX,EBX
    push EBX
    lea EDX,0Ch[ESP]
    mov dword ptr 4[EBX],2
    push EDX
    call near ptr _memcpy
    add ESP,0Ch
    xor EAX,EAX
    pop EBX
    add ESP,8
    ret


What the hell is it allocating?
Surely that's not necessary... that's gotta be fixable?



 I have suggested to add a safer version of VLAs to avoid some
 heap-allocated dynamic arrays:
 http://d.puremagic.com/issues/show_bug.cgi?id=5348



+1!!
I'm surprised this already isn't supported!
Jan 07 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 08-01-2012 00:06, Manu wrote:

 On 7 January 2012 20:59, bearophile <bearophileHUGS lycos.com
 <mailto:bearophileHUGS lycos.com>> wrote:

     Manu:

      > The tendency to encourage use of dynamic arrays will be a major
     problem.

     I don't know how much big that problem will be, D dynamic arrays are
     quite handy, but I agree that static arrays need to be encouraged
     more in D (and currently most algorithms of Phobos don't work with
     static arrays (you need to slice them first)).


 A slice doesn't produce a GC allocation does it?
 I thought a slice was just a pointer-length pair. Should live on the
 stack/in regs?


AFAIK yes.


 ...so slicing static arrays shouldn't be a problem right?

     Currently even this code with a stack-allocated fixed size array
     causes a heap allocation (DMD):

     void main() {
         int[2] a = [1, 2];
     }

     ASM, optimized build:

     __Dmain comdat
         push EAX
         push EAX
         mov EAX,offset FLAT:_D12TypeInfo_xAi6__initZ
         push EBX
         push 8
         push 2
         push EAX
         call near ptr __d_arrayliteralTX ; heap allocation
         add ESP,8
         mov EBX,EAX
         mov dword ptr [EAX],1
         mov ECX,EBX
         push EBX
         lea EDX,0Ch[ESP]
         mov dword ptr 4[EBX],2
         push EDX
         call near ptr _memcpy
         add ESP,0Ch
         xor EAX,EAX
         pop EBX
         add ESP,8
         ret


 What the hell is it allocating?
 Surely that's not necessary... that's gotta be fixable?

     I have suggested to add a safer version of VLAs to avoid some
     heap-allocated dynamic arrays:
     http://d.puremagic.com/issues/show_bug.cgi?id=5348


 +1!!
 I'm surprised this already isn't supported!



-- 
- Alex
Jan 08 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 3:06 PM, Manu wrote:

 A slice doesn't produce a GC allocation does it?


Nope.


 I thought a slice was just a pointer-length pair. Should live on the stack/in
regs?

 ...so slicing static arrays shouldn't be a problem right?


Right.



 What the hell is it allocating?
 Surely that's not necessary... that's gotta be fixable?


It's fixable, just haven't spent the time to do it.
Jan 08 2012
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 07.01.2012 16:44, schrieb Manu:

 On 7 January 2012 17:27, Paulo Pinto <pjmlp progtools.org
 <mailto:pjmlp progtools.org>> wrote:

     Thanks for the explanation.

     I am convinced that eventually AAA game engines can be
     made in a GC enabled language like D, they just need to
     be coded in a different way, more GC-friendly.


 I tend to disagree. I see it trending in the opposite direction.
 Tight pooling of resources and updating in finer grained (probably
 threaded) tight loops across neatly (cache friendly) packed bundles of
 like objects. That's where engines are going.
 Engines are becoming more and more memory-layout aware, not less... GC
 is the opposite of rigid memory layout.
 It's great for high level sugar that glues the whole thing together, but
 the engine is heading the opposite way; everything works more like a
 video card, small repetitive streamed jobs, with memory carefully managed.



The reason I am conviced is that C++ was the last systems programming 
language with manual memory management. All the languages people are
developing as possible C++ replacement do have some form of automatic
memory management.

Meanwhile smart pointers and a GC API became part of the C++ language 
standard. In the future, if you want to target Windows 8 Metro games, 
you will need to use WinRT which requires C++/CX and makes use of 
reference counting in the language.

Apple added GC to Objective-C, which has some problems with existing 
frameworks, so their next step was to introduce ARC.

This is why I think that eventually even games engines will be developed
in a language that supports some kind of automatic memory management be
it GC or reference counting.

Naturally such language also needs to provide the possibility to disable
the memory management in critical code paths.

If you go to my web site, the mini games I have there are a joke, they
cannot even be called games, maybe half-finished prototypes. I just 
spent too much time in the university with compiler programming and
UNIX system programming, only to start looking at game development when 
life start making me busy with other stuff.

Anyway, I still remember the days when C was too high level to be used 
for games.

Then again, I don't have any experience in the game industry, so you are 
much better qualified to say if what I say makes any sense.

--
Paulo
Jan 07 2012
parent reply "Froglegs" <lugtug gmail.com> writes:
 The reason I am conviced is that C++ was the last systems 
 programming language with manual memory management. All the 
 languages people are
 developing as possible C++ replacement do have some form of 
 automatic
 memory management.

 Meanwhile smart pointers and a GC API became part of the C++ 
 language standard. In the future, if you want to target Windows 
 8 Metro games, you will need to use WinRT which requires C++/CX 
 and makes use of reference counting in the language.

 Apple added GC to Objective-C, which has some problems with 
 existing frameworks, so their next step was to introduce ARC.

 This is why I think that eventually even games engines will be 
 developed
 in a language that supports some kind of automatic memory 
 management be
 it GC or reference counting.




  Well games often already integrate scripting languages, 
generally Lua or Mono, which are both GC based. But this is for 
the game logic, not for the high performance parts of the code.


   For a GC to be used at the C++/D layer it would need to be

1) optional always, D makes it optional but you loose a solid 
chunk of the language if you ditch GC, what remains is in some 
ways inferior to C++(no escaping lambda without GC, /cry)
2) no long pauses ever


  I think most game engine stuff will continue to be written 
without GC, as it doesn't really add much if what you are after 
is raw performance. And C++ does have smart pointers which 
perform much of what a GC does, but without the long pauses or 
non deterministic destruction.
Jan 07 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 11:00 AM, Froglegs wrote:

 For a GC to be used at the C++/D layer it would need to be

 1) optional always, D makes it optional but you loose a solid chunk of the
 language if you ditch GC, what remains is in some ways inferior to C++(no
 escaping lambda without GC, /cry)
 2) no long pauses ever


 I think most game engine stuff will continue to be written without GC, as it
 doesn't really add much if what you are after is raw performance. And C++ does
 have smart pointers which perform much of what a GC does, but without the long
 pauses or non deterministic destruction.


There are more options with D:

3) Disable GC from collecting during critical parts of the code, i.e. you can 
still new all you want, it just won't run collection cycles.

4) Pre-allocate all necessary data before entering the critical sections. You 
have to do this anyway with C++ if you have hard realtime constraints, as C++ 
makes no guarantees about how long new or malloc() will take (and it cannot).

BTW, in C++ a lambda cannot escape, so C++ has no advantage there.
Jan 07 2012
parent reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 23:26, Walter Bright <newshound2 digitalmars.com> wrote:


 There are more options with D:

 3) Disable GC from collecting during critical parts of the code, i.e. you
 can still new all you want, it just won't run collection cycles.


This may be nice, but there is never a 'non-critical' part of a game where
I can spare 5...10...15ms (I hear 15ms quoted often, that's a *whole*
frame) to let the GC do its thing.



 4) Pre-allocate all necessary data before entering the critical sections.
 You have to do this anyway with C++ if you have hard realtime constraints,
 as C++ makes no guarantees about how long new or malloc() will take (and it
 cannot).


This will obviously happen anyway (and with strict allocation
requirements... I'd like D allocators at some point, or this'll get messy
with pointers), but that doesn't help, for instance, bearophile's example
of a pointless allocation assigning a literal to a stack array, or various
other trivial allocations that go on here and there like that...

I'm also dubious about string allocations. I'd quite like a way to have
strings allocate in their own little self contained heap. They can use GC,
but they need to be separated into their own little memory region, and not
pollute/fragment the rest of the heap.
Engine code tends to create large allocations, megabytes in size, and with
very course alignment rules, 4k for instance, and little allocations
fragmenting memory can cause major problems/gaps...
Jan 07 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 3:30 PM, Manu wrote:

 On 7 January 2012 23:26, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

     There are more options with D:

     3) Disable GC from collecting during critical parts of the code, i.e. you
     can still new all you want, it just won't run collection cycles.


 This may be nice, but there is never a 'non-critical' part of a game where I
can
 spare 5...10...15ms (I hear 15ms quoted often, that's a *whole* frame) to let
 the GC do its thing.


It should also be possible to do the gc in another thread running at low 
priority, if the only other running thread is doing the critical stuff and is 
not the sole holder of references to any GC allocated memory it is using.
Jan 07 2012
parent reply Manu <turkeyman gmail.com> writes:
On 8 January 2012 03:46, Walter Bright <newshound2 digitalmars.com> wrote:


 It should also be possible to do the gc in another thread running at low
 priority, if the only other running thread is doing the critical stuff and
 is not the sole holder of references to any GC allocated memory it is using.


... sound like unreliable restrictions. Now sure I follow exactly what you
mean by 'only other running thread', and 'critical stuff'.
Jan 07 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 5:54 PM, Manu wrote:

 On 8 January 2012 03:46, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

     It should also be possible to do the gc in another thread running at low
     priority, if the only other running thread is doing the critical stuff and
     is not the sole holder of references to any GC allocated memory it is
using.


 ... sound like unreliable restrictions. Now sure I follow exactly what you mean
 by 'only other running thread', and 'critical stuff'.


The gc pauses all threads to run the collection cycle. But if a thread does not 
uniquely hold roots to gc memory, then it can be left running. The gc thread
can 
then be made low priority, and the other running thread(s) high priority. 
Presumably those other running threads would then be the time critical ones.
Jan 07 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 21:00, Froglegs <lugtug gmail.com> wrote:


  Well games often already integrate scripting languages, generally Lua or
 Mono, which are both GC based. But this is for the game logic, not for the
 high performance parts of the code.


Indeed. And this is usually just to mitigate the fact that C++ is so crap
at this sort of code. Maybe D will be tolerable, and this breaking out to
script won't be necessary? (though I'm dubious)

 For a GC to be used at the C++/D layer it would need to be

 1) optional always, D makes it optional but you loose a solid chunk of the
 language if you ditch GC, what remains is in some ways inferior to C++(no
 escaping lambda without GC, /cry)
 2) no long pauses ever

  I think most game engine stuff will continue to be written without GC, as
 it doesn't really add much if what you are after is raw performance. And
 C++ does have smart pointers which perform much of what a GC does, but
 without the long pauses or non deterministic destruction.


I must generally agree, I expect the GC would offer me basically nothing
but nuisance in engine level code. I'm generally shovelling large, strictly
controlled buffers which need proper placement/alignment, pool allocation,
or allocation from temporal ring buffers and that sort of thing.
I don't typically find C/C++ intolerable, or even particularly unpleasant
for engine level code as it is, it's the higher level code I'm keen to
escape.
Jan 07 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 7/01/12 11:17 PM, Manu wrote:

 On 7 January 2012 21:00, Froglegs <lugtug gmail.com
 <mailto:lugtug gmail.com>> wrote:

       Well games often already integrate scripting languages, generally
     Lua or Mono, which are both GC based. But this is for the game
     logic, not for the high performance parts of the code.


 Indeed. And this is usually just to mitigate the fact that C++ is so
 crap at this sort of code. Maybe D will be tolerable, and this breaking
 out to script won't be necessary? (though I'm dubious)


The main advantage of Lua for game code (in my opinion) is runtime 
reloading, and the ability to avoid recompiles just to test some new 
game logic. That's not so easy with C++.
Jan 07 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 4:12 PM, Peter Alexander wrote:

 The main advantage of Lua for game code (in my opinion) is runtime reloading,
 and the ability to avoid recompiles just to test some new game logic. That's
not
 so easy with C++.


D is far faster at compiling than C++.
Jan 07 2012
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 8/01/12 4:11 AM, Walter Bright wrote:

 On 1/7/2012 4:12 PM, Peter Alexander wrote:

 The main advantage of Lua for game code (in my opinion) is runtime
 reloading,
 and the ability to avoid recompiles just to test some new game logic.
 That's not
 so easy with C++.


 D is far faster at compiling than C++.


True, but:

- It's not orders of magnitude faster. You still have to wait for a 
re-compile of large projects.

- Linking takes just as much time as compiling.

- Can't account for the time it takes to boot your application back up 
after compiling and get back into the state you were in when you wanted 
to make the change.

- Also, DMD is slow at optimising. 
http://d.puremagic.com/issues/show_bug.cgi?id=7157
Jan 08 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 4:01 AM, Peter Alexander wrote:

 On 8/01/12 4:11 AM, Walter Bright wrote:

 On 1/7/2012 4:12 PM, Peter Alexander wrote:

 The main advantage of Lua for game code (in my opinion) is runtime
 reloading,
 and the ability to avoid recompiles just to test some new game logic.
 That's not
 so easy with C++.


 D is far faster at compiling than C++.


 True, but:

 - It's not orders of magnitude faster. You still have to wait for a re-compile
 of large projects.

 - Linking takes just as much time as compiling.

 - Can't account for the time it takes to boot your application back up after
 compiling and get back into the state you were in when you wanted to make the
 change.


All true.


 - Also, DMD is slow at optimising.
 http://d.puremagic.com/issues/show_bug.cgi?id=7157


When you're in the edit-compile-debug loop, it's normal to turn off the
optimizer.
Jan 08 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 11:46 AM, Walter Bright wrote:

 True, but:




And as mentioned elsewhere, if the game logic is in plugin, like a dll, it can 
be compiled/linked/loaded without touching the main code base.
Jan 08 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:jebvvg$2orl$1 digitalmars.com...

 On 8/01/12 4:11 AM, Walter Bright wrote:

 On 1/7/2012 4:12 PM, Peter Alexander wrote:

 The main advantage of Lua for game code (in my opinion) is runtime
 reloading,
 and the ability to avoid recompiles just to test some new game logic.
 That's not
 so easy with C++.


 D is far faster at compiling than C++.


 True, but:

 - It's not orders of magnitude faster. You still have to wait for a 
 re-compile of large projects.

 - Linking takes just as much time as compiling.


They should both be more than fast enough in D if you're just compiling 
gameplay scripts. Especially on typical game-dev machines, which are 
above-average spec anyway.


 - Can't account for the time it takes to boot your application back up 
 after compiling and get back into the state you were in when you wanted to 
 make the change.


So compile the scripts to a dynamic lib instead of a static one. Shoot, id 
was already doing that back with Quake 1 or 2, weren't they?


 - Also, DMD is slow at optimising. 
 http://d.puremagic.com/issues/show_bug.cgi?id=7157


Yea, like Walter said, just don't use that in the middle of an 
"edit-comple-test-edit" loop.
Jan 08 2012
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 8/01/12 8:55 PM, Nick Sabalausky wrote:

 "Peter Alexander"<peter.alexander.au gmail.com>  wrote in message
 news:jebvvg$2orl$1 digitalmars.com...

 On 8/01/12 4:11 AM, Walter Bright wrote:

 On 1/7/2012 4:12 PM, Peter Alexander wrote:

 The main advantage of Lua for game code (in my opinion) is runtime
 reloading,
 and the ability to avoid recompiles just to test some new game logic.
 That's not
 so easy with C++.


 D is far faster at compiling than C++.


 True, but:

 - It's not orders of magnitude faster. You still have to wait for a
 re-compile of large projects.

 - Linking takes just as much time as compiling.


 They should both be more than fast enough in D if you're just compiling
 gameplay scripts. Especially on typical game-dev machines, which are
 above-average spec anyway.


Here's a quote for you:

http://www.gamasutra.com/view/news/39368/InDepth_Incremental_Linking_And_The_Search_For_The_Holy_Grail.php

"As an example, for me within our current code at Bungie, a single file 
change in the code I usually work on can cost as much as 10mins in 
linking (many targets). If I opt to build a single target (say the 
runtime), then this is reduced to ~2 mins. This is without any linker 
optimization such as Link Time Code Generation which is known to heavily 
increase Link time."

The rest of the article is about trying to get incremental linking 
working. At the end he says:

"Once you have resolved all the issues that can stop incremental linking 
from working, you are a short step from the Holy Grail. Something I 
personally have never had working before but will be actively fighting 
for in the near future."

So Bungie can't get incremental linking working. Good luck for the rest 
of us.



 - Can't account for the time it takes to boot your application back up
 after compiling and get back into the state you were in when you wanted to
 make the change.


 So compile the scripts to a dynamic lib instead of a static one. Shoot, id
 was already doing that back with Quake 1 or 2, weren't they?


On PC, yes. It's not so simple on consoles.



 - Also, DMD is slow at optimising.
 http://d.puremagic.com/issues/show_bug.cgi?id=7157


 Yea, like Walter said, just don't use that in the middle of an
 "edit-comple-test-edit" loop.


You often have to. The norm in the games industry is to always run with 
optimisations on unless you are debugging. The game simply runs too slow 
without them.
Jan 08 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:jed20n$1e23$1 digitalmars.com...

 On 8/01/12 8:55 PM, Nick Sabalausky wrote:

 They should both be more than fast enough in D if you're just compiling
 gameplay scripts. Especially on typical game-dev machines, which are
 above-average spec anyway.


 Here's a quote for you:

 http://www.gamasutra.com/view/news/39368/InDepth_Incremental_Linking_And_The_Search_For_The_Holy_Grail.php

 "As an example, for me within our current code at Bungie, a single file 
 change in the code I usually work on can cost as much as 10mins in linking 
 (many targets). If I opt to build a single target (say the runtime), then 
 this is reduced to ~2 mins. This is without any linker optimization such 
 as Link Time Code Generation which is known to heavily increase Link 
 time."

 The rest of the article is about trying to get incremental linking 
 working. At the end he says:

 "Once you have resolved all the issues that can stop incremental linking 
 from working, you are a short step from the Holy Grail. Something I 
 personally have never had working before but will be actively fighting for 
 in the near future."

 So Bungie can't get incremental linking working. Good luck for the rest of 
 us.


FWIW, that *is* C++. Even without that, D compiles/links an order of 
magnitude faster.


 - Can't account for the time it takes to boot your application back up
 after compiling and get back into the state you were in when you wanted 
 to
 make the change.


 So compile the scripts to a dynamic lib instead of a static one. Shoot, 
 id
 was already doing that back with Quake 1 or 2, weren't they?


 On PC, yes. It's not so simple on consoles.


I see. That's very unfortunate.


 - Also, DMD is slow at optimising.
 http://d.puremagic.com/issues/show_bug.cgi?id=7157


 Yea, like Walter said, just don't use that in the middle of an
 "edit-comple-test-edit" loop.


 You often have to. The norm in the games industry is to always run with 
 optimisations on unless you are debugging. The game simply runs too slow 
 without them.


Engine, yes, but gameplay scripts?
Jan 08 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 1:42 PM, Peter Alexander wrote:

 "As an example, for me within our current code at Bungie, a single file change
 in the code I usually work on can cost as much as 10mins in linking (many
 targets). If I opt to build a single target (say the runtime), then this is
 reduced to ~2 mins. This is without any linker optimization such as Link Time
 Code Generation which is known to heavily increase Link time."


D should be faster at linking, even with the same linker, because if you use it 
carefully a lot fewer redundant template instantiations get written to the 
object file (which must be culled by the linker).

For example, if you use shared_ptr in C++, every single file that uses 
shared_ptr will produce an object file containing the same compiled version of
it.
Jan 08 2012
parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 8/01/12 11:00 PM, Walter Bright wrote:

 On 1/8/2012 1:42 PM, Peter Alexander wrote:

 "As an example, for me within our current code at Bungie, a single
 file change
 in the code I usually work on can cost as much as 10mins in linking (many
 targets). If I opt to build a single target (say the runtime), then
 this is
 reduced to ~2 mins. This is without any linker optimization such as
 Link Time
 Code Generation which is known to heavily increase Link time."


 D should be faster at linking, even with the same linker, because if you
 use it carefully a lot fewer redundant template instantiations get
 written to the object file (which must be culled by the linker).

 For example, if you use shared_ptr in C++, every single file that uses
 shared_ptr will produce an object file containing the same compiled
 version of it.


Most game studios tend to use unity builds, precisely to minimize things 
like this. Generally there is very little duplicated code in object 
files. I did measure it at some point in the past and it was fairly 
negligible.
Jan 08 2012
prev sibling parent reply "Froglegs" <lugtug gmail.com> writes:
 Indeed. And this is usually just to mitigate the fact that C++ 
 is so crap
 at this sort of code. Maybe D will be tolerable, and this 
 breaking out to
 script won't be necessary? (though I'm dubious)


Yeah C++ is a migraine for that type of code:(  I think D would 
be nicer than C++ for gameplay code, but another reason for 
scripts is the ability to modify the script while the game is 
running, and just the general lack of compilation time which is 
soo nice.

Perhaps if D gets ported to mono? Though even then I think I'd 
prefer Lua, since it is quite good at acting as both a language 
and data description.



 I don't typically find C/C++ intolerable, or even particularly 
 unpleasant
 for engine level code as it is, it's the higher level code I'm 
 keen to
 escape.


Yes I agree!

I tend to think of the code I work with as having three levels

1) low level - high performance, optimal memory layout/access, 
alignment concerns, intrinsic, not much 
abstraction(unfortunately..). C++ works pretty well here(though 
any improvements are welcome..), certainly I'm not aware of 
anything else that is better

2) mid level - good performance, fairly optimal memory, no 
intrinsics, fairly abstract. C++ works OK here, but I think D 
could be better at this

3) high level - moderate/low performance, GC memory, JIT'd if you 
are lucky, but possibly interpreted, can reload scripts while 
program is executing. Neither D nor C++ work here.



the majority of its time executing it, so it is pretty important



Also in reply to Walter-- for me the problem with pausing the GC, 
and then running it at certain times, is that there is actual no 
time when it is alright for the GC to take any significant amount 
of time to collect( a couple milliseconds might be acceptable, 
but can that be guaranteed?).  Some games don't have load 
screens, or levels, but just an endless streaming world.
Jan 07 2012
next sibling parent Danni Coy <danni.coy gmail.com> writes:
On Sun, Jan 8, 2012 at 10:12 AM, Froglegs <lugtug gmail.com> wrote:


  Indeed. And this is usually just to mitigate the fact that C++ is so crap

 at this sort of code. Maybe D will be tolerable, and this breaking out to
 script won't be necessary? (though I'm dubious)


 Yeah C++ is a migraine for that type of code:(  I think D would be nicer
 than C++ for gameplay code, but another reason for scripts is the ability
 to modify the script while the game is running, and just the general lack
 of compilation time which is soo nice.

 Perhaps if D gets ported to mono? Though even then I think I'd prefer Lua,
 since it is quite good at acting as both a language and data description.



D currently does several things that I would find useful doing game logic
level code (my day job) and if it were simultaneously able to keep engine
coders and people like me happy I can see a future for it. These are the
things I see as important.

Fast vector/matrix maths. (thankyou Manu for getting the ball rolling on
this)
some form of realtime friendly (semi) automatic memory management.
Ability to write correct code easily.
Ability to drop down to the metal style coding if there is a serious
bottleneck and a deadline.
Jan 07 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Froglegs" <lugtug gmail.com> wrote in message 
news:lwcqnrvamqlnjjlxzbqa dfeed.kimsufi.thecybershadow.net...

 can reload scripts while program is executing. Neither D nor C++ work 
 here.


Why not a dll? Those can be compiled/loaded/reloaded at runtime. And since 
it's just scripts, it wouldn't take long to compile at all, at least in D 
(maybe not so much in C++).
Jan 07 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 8 January 2012 03:40, Nick Sabalausky <a a.a> wrote:


 "Froglegs" <lugtug gmail.com> wrote in message
 news:lwcqnrvamqlnjjlxzbqa dfeed.kimsufi.thecybershadow.net...

 can reload scripts while program is executing. Neither D nor C++ work
 here.


 Why not a dll? Those can be compiled/loaded/reloaded at runtime. And since
 it's just scripts, it wouldn't take long to compile at all, at least in D
 (maybe not so much in C++).


It's common for designers to edit scripts, and they don't usually have
coding environments on their machines.
Jan 07 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/07/2012 08:47 PM, Manu wrote:

 On 8 January 2012 03:40, Nick Sabalausky <a a.a> wrote:
 
     "Froglegs" <lugtug gmail.com <mailto:lugtug gmail.com>> wrote in message
     news:lwcqnrvamqlnjjlxzbqa dfeed.kimsufi.thecybershadow.net...
     >
     > can reload scripts while program is executing. Neither D nor C++ work
     > here.
     >
 
     Why not a dll? Those can be compiled/loaded/reloaded at runtime. And
     since
     it's just scripts, it wouldn't take long to compile at all, at least
     in D
     (maybe not so much in C++).
 
 
 It's common for designers to edit scripts, and they don't usually have
 coding environments on their machines. 


Meh, just link/package a D compiler into/with the game and
recompile/reload a file whenever it changes.  It would probably help if
DMD ditched its non-redistributable license stuff, but there's also
LDC/GDC (LDC is probably the most promising for this kind of thing).
Jan 07 2012
parent reply "F i L" <witte2008 gmail.com> writes:
Chad J wrote:

 On 01/07/2012 08:47 PM, Manu wrote:

 On 8 January 2012 03:40, Nick Sabalausky <a a.a> wrote:
 
  "Froglegs" <lugtug gmail.com <mailto:lugtug gmail.com>> wrote 
 in message
  news:lwcqnrvamqlnjjlxzbqa dfeed.kimsufi.thecybershadow.net...
  >
  > can reload scripts while program is executing. Neither D 
 nor C++ work
  > here.
  >
 
  Why not a dll? Those can be compiled/loaded/reloaded at 
 runtime. And
  since
  it's just scripts, it wouldn't take long to compile at all, 
 at least
  in D
  (maybe not so much in C++).
 
 
 It's common for designers to edit scripts, and they don't 
 usually have
 coding environments on their machines.


 Meh, just link/package a D compiler into/with the game and
 recompile/reload a file whenever it changes.  It would probably 
 help if
 DMD ditched its non-redistributable license stuff, but there's 
 also
 LDC/GDC (LDC is probably the most promising for this kind of 
 thing).


My thoughts exactly. A D compiler/linker should be able to be 
packaged with an game engine editor rather easily, and if I'm not 
mistaken LDC has the potential to offer JIT/AOT compiling.




Manu wrote:

 I'm generally shovelling large, strictly controlled buffers 
 which need
 proper placement/alignment, pool allocation, or allocation from 
 temporal
 ring buffers and that sort of thing. I don't typically find 
 C/C++
 intolerable, or even particularly unpleasant for engine level 
 code as it
 is, it's the higher level code I'm keen to escape.


As I understand it, most low level game engine code deals with 
reusable memory pools to reduce memory thrashing with large 
amounts of dynamically allocated/deallocated objects (correct me 
if I'm wrong). C/C++ is great for this because in C memory is 

purpose memory pools difficult to manage. I know there are 
engines like the Delta Engine which, to my knowledge, is written 

I'm currently porting over our Reign SDK 
(code.google.com/p/reign-sdk) which is a modest set of libraries 
attempting to wrap DirectX, OpenGL, and other 3D media libraries 
into a universal interface. I've plans on enhancing, d-atizing, 
and expanding these libraries into a more full featured game 
engine one day. I've got some interesting ideas on how 
pre-written code packages could be easily designer-style 
assembled in-editor and compiled into efficient native logic 
blocks "on the fly". Only D's fast native compile times and 
easy-to-grasp syntax would really allow for what I'm thinking.

Given your experience in this area, I would appreciate any 
insight you could offer about the potential pros/cons for writing 
low level game engine components in D. Would you say D is a 
effective tool to write a general purpose memory pool, or would 
something like that be better written in C? Or.. is it common to 
have an array of specialized object pools? I'd imagine such an 
engine would sacrifice flexibility and eat up more memory, but 
most likely easier to implement.
Jan 07 2012
parent reply Manu <turkeyman gmail.com> writes:
On 8 January 2012 08:03, F i L <witte2008 gmail.com> wrote:


 I've got some interesting ideas on how pre-written code packages could be
 easily designer-style assembled in-editor and compiled into efficient
 native logic blocks "on the fly". Only D's fast native compile times and
 easy-to-grasp syntax would really allow for what I'm thinking.


If you're talking about stringing together pre-written code blocks with
some editor, then this might be an interesting approach.
I'm not so sure how 'easy-to-grasp' D is, or why that's important if you're
providing an editor?
I tend to think D is considerably less simple than C, possibly more complex
(but less archaic) than C++... It's not really something you could expose
to a designer.



 Given your experience in this area, I would appreciate any insight you
 could offer about the potential pros/cons for writing low level game engine
 components in D. Would you say D is a effective tool to write a general
 purpose memory pool, or would something like that be better written in C?



I'm probably not the best to comment, because I still haven't internalised
all the possibilities of D's powerful language features.
But I think C is basically a subset of D, so I don't see any inhibiting
reason why it couldn't all be done in D. My concern is mainly over whether
D makes it easy, or ugly to manage all the resources as strictly as
required, and how much of D's idioms/paradigms you need to subvert to
actually do it.

Writing an engine in 'C-ish' D is surely possible, writing it in 'D'...
potentially problematic.
I'm keen to have a go in the near future as an experiment, I expect in
engine level code, the GC might frustrate me.
Writing various memory managers/pools/buffers themselves is surely fine in
D, no problem... but USING them in an idiomatic way to allocate objects,
there's no support in D.

D:
MyObject obj = new MyObject(x, y, z);

D (subverting GC):
MyObject* obj = (MyObject*)someManager.Alloc(MyObject.sizeof);
....? how do I even perform a placement new?

I wouldn't want to be doing that everywhere.
If D implements allocators, then I can see that being much better, enabling
one to still write fairly conventional D code.

Or.. is it common to have an array of specialized object pools? I'd imagine

 such an engine would sacrifice flexibility and eat up more memory, but most
 likely easier to implement.



I fail to see where this is sacrificing flexibility, but yes, you do tend
to over-reserve in these sorts of pools, but there's no real alternative
(although I use a lot of tricks).

Cache efficiently is all about memory locality, and pooling 'like' things
together and stream processing them in batches is the most efficient way to
do work on ANY computer.
Once you write your systems this way, they tend to thread+scale well, and
automatically. You could even easily offload them to a video card, or other
sort of DSP.

What I usually do to avoid major over-reservation of memory is to break the
pools into smaller 'buckets' (some multiple-of and aligned-to the systems
most course grained cache), and extend/contract the pool size as needed.
Cache alignment is very important, I was surprised+concerned the other
night when Walter mentioned that D does NOT support aligning anything to
any power of 2 using the align() attribute.
I'm curious to know under what circumstances it actually works?
Jan 08 2012
next sibling parent Joshua Reusch <yoschi arkandos.de> writes:
Am 08.01.2012 12:05, schrieb Manu:

 On 8 January 2012 08:03, F i L <witte2008 gmail.com
 <mailto:witte2008 gmail.com>> wrote:

     I've got some interesting ideas on how pre-written code packages
     could be easily designer-style assembled in-editor and compiled into
     efficient native logic blocks "on the fly". Only D's fast native
     compile times and easy-to-grasp syntax would really allow for what
     I'm thinking.


 If you're talking about stringing together pre-written code blocks with
 some editor, then this might be an interesting approach.
 I'm not so sure how 'easy-to-grasp' D is, or why that's important if
 you're providing an editor?
 I tend to think D is considerably less simple than C, possibly more
 complex (but less archaic) than C++... It's not really something you
 could expose to a designer.

     Given your experience in this area, I would appreciate any insight
     you could offer about the potential pros/cons for writing low level
     game engine components in D. Would you say D is a effective tool to
     write a general purpose memory pool, or would something like that be
     better written in C?


 I'm probably not the best to comment, because I still haven't
 internalised all the possibilities of D's powerful language features.
 But I think C is basically a subset of D, so I don't see any inhibiting
 reason why it couldn't all be done in D. My concern is mainly over
 whether D makes it easy, or ugly to manage all the resources as strictly
 as required, and how much of D's idioms/paradigms you need to subvert to
 actually do it.

 Writing an engine in 'C-ish' D is surely possible, writing it in 'D'...
 potentially problematic.
 I'm keen to have a go in the near future as an experiment, I expect in
 engine level code, the GC might frustrate me.
 Writing various memory managers/pools/buffers themselves is surely fine
 in D, no problem... but USING them in an idiomatic way to allocate
 objects, there's no support in D.

 D:
 MyObject obj = new MyObject(x, y, z);

 D (subverting GC):
 MyObject* obj = (MyObject*)someManager.Alloc(MyObject.sizeof);
 ....? how do I even perform a placement new?


Just an idea how it could look whith allocators: What about adding an 
argument to the new operator for the allocator struct (like GC), and let 
the user define an default one ? I think something similar can already 
be done by overloading the new  and assignment operator:

Runtime.setDefaultAllocator!GC();
auto refcounted = new!RefCounter MyObject();


 I wouldn't want to be doing that everywhere.
 If D implements allocators, then I can see that being much better,
 enabling one to still write fairly conventional D code.

     Or.. is it common to have an array of specialized object pools? I'd
     imagine such an engine would sacrifice flexibility and eat up more
     memory, but most likely easier to implement.


 I fail to see where this is sacrificing flexibility, but yes, you do
 tend to over-reserve in these sorts of pools, but there's no real
 alternative (although I use a lot of tricks).

 Cache efficiently is all about memory locality, and pooling 'like'
 things together and stream processing them in batches is the most
 efficient way to do work on ANY computer.
 Once you write your systems this way, they tend to thread+scale well,
 and automatically.. You could even easily offload them to a video card,
 or other sort of DSP.

 What I usually do to avoid major over-reservation of memory is to break
 the pools into smaller 'buckets' (some multiple-of and aligned-to the
 systems most course grained cache), and extend/contract the pool size as
 needed.
 Cache alignment is very important, I was surprised+concerned the other
 night when Walter mentioned that D does NOT support aligning anything to
 any power of 2 using the align() attribute.
 I'm curious to know under what circumstances it actually works?
Jan 08 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.198.1326020770.16222.digitalmars-d puremagic.com...

 I tend to think D is considerably less simple than C,


Except for the lack of dealing with headers and preprocessor. And D has a 
lot of other nicities that do make it simpler to use, like slicing and 
numbers with underscore separators.


 possibly more complex
 (but less archaic) than C++... It's not really something you could expose
 to a designer.


I'd expose D to a designer long before I'd expose them to C. C's too 
low-level and, a bit anachronistic in some ways (like headers).

Although, this is one thing I have to agree with Carmack on: Non-programmers 
have no business writing production code anyway.


 D:
 MyObject obj = new MyObject(x, y, z);

 D (subverting GC):
 MyObject* obj = (MyObject*)someManager.Alloc(MyObject.sizeof);
 ....?


More likely something closer to this:

MyObject obj = fooAlloc!MyObject(x, y, z);

Or, of course:

auto obj = fooAlloc!MyObject(x, y, z);


 how do I even perform a placement new?


emplace: http://www.d-programming-language.org/phobos/std_conv.html

auto obj = emplace!MyObject(pointerOrVoidArray, x, y, z);


 I wouldn't want to be doing that everywhere.
 If D implements allocators, then I can see that being much better, 
 enabling
 one to still write fairly conventional D code.
Jan 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jed10v$1cf3$1 digitalmars.com...

 "Manu" <turkeyman gmail.com> wrote in message 
 news:mailman.198.1326020770.16222.digitalmars-d puremagic.com...

 I tend to think D is considerably less simple than C,


 Except for the lack of dealing with headers and preprocessor. And D has a 
 lot of other nicities that do make it simpler to use, like slicing and 
 numbers with underscore separators.


 possibly more complex
 (but less archaic) than C++... It's not really something you could expose
 to a designer.


 I'd expose D to a designer long before I'd expose them to C. C's too 
 low-level and, a bit anachronistic in some ways (like headers).


Also, with D it would be much easier to provide the designer with 
abstractions that have a very nice and tidy API/syntax.
Jan 08 2012
prev sibling parent "F i L" <witte2008 gmail.com> writes:
Manu wrote:

 On 8 January 2012 08:03, F i L <witte2008 gmail.com> wrote:


 I've got some interesting ideas on how pre-written code 
 packages could be
 easily designer-style assembled in-editor and compiled into 
 efficient
 native logic blocks "on the fly". Only D's fast native compile 
 times and
 easy-to-grasp syntax would really allow for what I'm thinking.


 If you're talking about stringing together pre-written code 
 blocks with
 some editor, then this might be an interesting approach.


That's basically it. The idea is to have an editor which allows 
creating generic objects with dynamic attributes, eg, meshes, 
vectors, sounds, etc. Each object would have a basic state 
machine with each state being an order dependent list of 
"Command" objects. Command objects would be drag-n-drop style 
logic blocks with GUI properties (though keyboard editing would 
be a priority as well). Command objects would be represented in 
immediately executable core command objects (math, io, network, 
etc) but would get silently compiled into efficient D execution 
objects in a separate thread, then used instead. Advanced custom 
Command objects could also be hand written in D (preferably in 
editor).
Prebuilt command objects would be everything from simple 
transform manipulation and logic (lookat, IK chains, triggers, 
conditions, etc) to entire character control schemes (FPS, race 
car, etc).

Because all command property linking would be known by the 
editor, that information could be used to build efficient 
dependency graphs.

I'm still working out the kinks in the theory, but I feel the 
concept has potential.



 I'm not so sure how 'easy-to-grasp' D is, or why that's 
 important if you're providing an editor?


D can get complicated real quick, but features like GC, auto 
keyword, and the lack of '->' makes writing simple functions 
easier to understand than C, IMO. Simple functions is basically 
the extent of what I have in mind for the editor, so it seems 
like a good fit.


Thanks for all the insight.




Nick Sabalausky wrote:

 how do I even perform a placement new?


 
 emplace: 
 http://www.d-programming-language.org/phobos/std_conv.html
 
 auto obj = emplace!MyObject(pointerOrVoidArray, x, y, z);


Awesome, didn't know about this.
Jan 08 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-08 02:40, Nick Sabalausky wrote:

 "Froglegs"<lugtug gmail.com>  wrote in message
 news:lwcqnrvamqlnjjlxzbqa dfeed.kimsufi.thecybershadow.net...

 can reload scripts while program is executing. Neither D nor C++ work
 here.


 Why not a dll? Those can be compiled/loaded/reloaded at runtime. And since
 it's just scripts, it wouldn't take long to compile at all, at least in D
 (maybe not so much in C++).


Yeah, that's pretty cool. This was show at the Tango conference: 
http://vimeo.com/2264486 around 30:35

-- 
/Jacob Carlborg
Jan 08 2012