www.digitalmars.com         C & C++   DMDScript  

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

reply Manu <turkeyman gmail.com> writes:
--20cf30363f4b9e64da04b5f10fd9
Content-Type: text/plain; charset=UTF-8

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

 Hi Manu,

 nice to hear about your experience with C#.

 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
 migrating to C# for tools, and many that target mostly Windows
 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
 game development, C# might eventually superseed C++, especially
 with good quality AOT compilers. Not sure how good Mono's AOT
 code quality is. From the public information C# is the default
 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.

Most gamedev studios are VS-centric, and from that reason alone, C# is the obvious choice if you want to remove your tools from C++/MFC/whatever. In my experience, most first time C# coders have a great experience off the bat, and tend to keep on that wagon. I think it started like this; some coder decides he hates writing tools in C++. They click new->project-> oh look, C#, everyone's talking about 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 windows' are migrating engines to C#. Actually, I've never heard of an 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 is written in C#. 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. I don't realisticslly see C# 'taking over' gamedev. It's too closely 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 C# 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 :) --20cf30363f4b9e64da04b5f10fd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 15:24, Paulo Pinto <span dir= =3D"ltr">&lt;<a href=3D"mailto:pjmlp progtools.org">pjmlp progtools.org</a>= &gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Manu,<br> <br> nice to hear about your experience with C#.<br> <br> I am a bit of half-insider in the game industry, being<br> a IGDA member for some years and also attended two<br> GDCE so far.<br> <br> Several reasons have kept me from getting a job in the<br> industry, but I still follow what&#39;s happening quite closely.<br> <br>
From what I know here in Europe, many studios have been slowly<br>

are also experimenting with it in their engines.<br> <br> How does it look like from your side?<br> <br> I think this is important to know, because in what concerns<br> game development, C# might eventually superseed C++, especially<br> with good quality AOT compilers. Not sure how good Mono&#39;s AOT<br> code quality is. From the public information C# is the default<br> language for the PlayStation VITA and the PlayStation Suite.<br> <br> And game development is probably one of the few areas where D could get<br> an entry to.</blockquote><div><br></div><div>Most gamedev studios are VS-ce= ntric, and from that reason alone, C# is the obvious choice if you want to = remove your tools from C++/MFC/whatever.</div><div>In my experience, most f= irst time C# coders have a great experience off the bat, and tend to keep o= n that wagon.</div> <div>I think it started like this; some coder decides he hates writing tool= s in C++. They click new-&gt;project-&gt; oh look, C#, everyone&#39;s talki= ng about it. They give it a go (...see my previous post).</div><div><br> </div><div>I don&#39;t know if you&#39;re on the mark saying studios that &= #39;target mostly windows&#39; are migrating engines to C#. Actually, I&#39= ;ve never heard of an instance of that outside indy-games.</div><div>The mo= st interesting trend I think is the Unity effect. They embed mono into thei= r engine (ie, NON-windows machines), and all high level game code is writte= n in C#.</div> <div>This seems an amazingly sensible idea, and most people seem to agree.= =C2=A0I love the idea of Unity, and on small games, handhelds and stuff, it= seems to work really well.</div><div><br></div><div>I don&#39;t realistics= lly see C# &#39;taking over&#39; gamedev. It&#39;s too closely affiliated w= ith Microsoft, although I am very surprised by Sony&#39;s move, so maybe I&= #39;m way off the mark.</div> <div>Also, for AAA mainstream titles, I don&#39;t think there&#39;s any cho= ice other than C++. Game engines are aggressively tuned at very low level t= o the hardware. I don&#39;t think any non-C++-like systems language can tak= e that away (D may have a chance here, but the GC might be a problem at the= engine level).</div> <div><br></div><div>I think it&#39;s likely that the shift more towards mon= o (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, fa= miliar IDE&#39;s/integration into workflow, and familiarity to most devs no= w via working on tools.</div> <div><br></div><div>One of the biggest challenges for the gamedev world is = adapting high-level game code to scalable SMP systems. Engine is easy to ma= ke scale, game logic, not so much. Strong OOP is the problem here.</div> <div>With the current trend of using an auxilliary language to write this l= ogic code, there&#39;s opportunity for a language that totally nails SMP sc= alability to really make a dent... but it&#39;s hard to predict :)</div> <div><br></div><div>I don&#39;t think I can emphasise enough though the poi= nt 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 t= he key reason C# is so popular atm.</div> <div><br></div><div>All that said, I&#39;m just an engine programmer. I wri= te C++ to the metal. I&#39;m not the best authority on the topic :)</div></= div> --20cf30363f4b9e64da04b5f10fd9--
Jan 07 2012
next sibling 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,

     nice to hear about your experience with C#.

     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
     migrating to C# for tools, and many that target mostly Windows
     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
     game development, C# might eventually superseed C++, especially
     with good quality AOT compilers. Not sure how good Mono's AOT
     code quality is. From the public information C# is the default
     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.


 Most gamedev studios are VS-centric, and from that reason alone, C# is
 the obvious choice if you want to remove your tools from C++/MFC/whatever.
 In my experience, most first time C# coders have a great experience off
 the bat, and tend to keep on that wagon.
 I think it started like this; some coder decides he hates writing tools
 in C++. They click new->project-> oh look, C#, everyone's talking about
 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
 windows' are migrating engines to C#. Actually, I've never heard of an
 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 is written in C#.
 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.

 I don't realisticslly see C# 'taking over' gamedev. It's too closely
 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
 C# 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:
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
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 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 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 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 "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 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 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 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
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--00235429dda4d131b204b5f2095a
Content-Type: text/plain; charset=UTF-8

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. --00235429dda4d131b204b5f2095a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 17:27, Paulo Pinto <span dir= =3D"ltr">&lt;<a href=3D"mailto:pjmlp progtools.org">pjmlp progtools.org</a>= &gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks for the explanation.<br> <br> I am convinced that eventually AAA game engines can be<br> made in a GC enabled language like D, they just need to<br> be coded in a different way, more GC-friendly.<br></blockquote><div><br></d= iv><div>I tend to disagree. I see it trending in the opposite direction.</d= iv><div>Tight pooling of resources and updating in finer grained (probably = threaded) tight loops across neatly (cache friendly) packed bundles of like= objects. That&#39;s where engines are going.</div> <div>Engines are becoming more and more memory-layout aware, not less... GC= is the opposite of rigid memory layout.</div><div>It&#39;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.</div> </div> --00235429dda4d131b204b5f2095a--
Jan 07 2012
parent 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
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf302ef92483cc3404b5f28ad0
Content-Type: text/plain; charset=UTF-8

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

 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. --20cf302ef92483cc3404b5f28ad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 17:55, bearophile <span dir=3D= "ltr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophileHUGS lycos.= com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Manu:<br> <div class=3D"im"><br> &gt; and updating in finer grained (probably<br> &gt; threaded) tight loops across neatly (cache friendly) packed bundles of= like<br> &gt; objects. That&#39;s where engines are going.<br> <br> </div>I agree. Something related:<br> <br> <a href=3D"http://research.scee.net/files/presentations/gcapaustralia09/Pit= falls_of_Object_Oriented_Programming_GCAP_09.pdf" target=3D"_blank">http://= research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Or= iented_Programming_GCAP_09.pdf</a><br> <br> A language designed for games has to help this style of coding.<br></blockq= uote><div><br></div><div>Hehe, Tony&#39;s a good mate of mine (that lecture= ) :)</div><div>He&#39;s become quite a=C2=A0prominent=C2=A0figure in Austra= lia after taking the Sony job. He quit now though.</div> <div>Amusingly, he managed to convince Mike Acton to speak at the recent GC= AP, even though the Australian industry has disintegrated ;)</div><div><br>= </div><div>This is my biggest fear with investing in D. It&#39;s not incomp= atible with D, but liberal use of the GC in the language and/or in the libr= aries scares me.</div> <div>The tendency to encourage use of dynamic arrays will be a major proble= m.</div><div><br></div><div>I don&#39;t think it&#39;s reached a point of n= o return yet, but it needs to be carefully considered, and I really would l= ike support for allocators in D.</div> <div>I *need* to be able to assign class memory out of pools, ideally witho= ut making my code archaic and/or breaking the language usage paradigms.</di= v></div> --20cf302ef92483cc3404b5f28ad0--
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 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 next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30051342ccea9d04b5f83889
Content-Type: text/plain; charset=UTF-8

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! --20cf30051342ccea9d04b5f83889 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 20:59, bearophile <span dir=3D= "ltr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophileHUGS lycos.= com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Manu:<br> <div class=3D"im"><br> &gt; The tendency to encourage use of dynamic arrays will be a major proble= m.<br> <br> </div>I don&#39;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&#39;t work with static ar= rays (you need to slice them first)).<br> </blockquote><div><br></div><div>A slice doesn&#39;t produce a GC allocatio= n does it?</div><div>I thought a slice was just a pointer-length pair. Shou= ld live on the stack/in regs?</div><div><br></div><div>...so slicing static= arrays shouldn&#39;t be a problem right?</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">Currently even this code wi= th a stack-allocated fixed size array causes a heap allocation (DMD):<br> <br> void main() {<br> =C2=A0 =C2=A0int[2] a =3D [1, 2];<br> }<br> <br> ASM, optimized build:<br> <br> __Dmain comdat<br> =C2=A0 =C2=A0push EAX<br> =C2=A0 =C2=A0push EAX<br> =C2=A0 =C2=A0mov EAX,offset FLAT:_D12TypeInfo_xAi6__initZ<br> =C2=A0 =C2=A0push EBX<br> =C2=A0 =C2=A0push 8<br> =C2=A0 =C2=A0push 2<br> =C2=A0 =C2=A0push EAX<br> =C2=A0 =C2=A0call near ptr __d_arrayliteralTX ; heap allocation<br> =C2=A0 =C2=A0add ESP,8<br> =C2=A0 =C2=A0mov EBX,EAX<br> =C2=A0 =C2=A0mov dword ptr [EAX],1<br> =C2=A0 =C2=A0mov ECX,EBX<br> =C2=A0 =C2=A0push EBX<br> =C2=A0 =C2=A0lea EDX,0Ch[ESP]<br> =C2=A0 =C2=A0mov dword ptr 4[EBX],2<br> =C2=A0 =C2=A0push EDX<br> =C2=A0 =C2=A0call near ptr _memcpy<br> =C2=A0 =C2=A0add ESP,0Ch<br> =C2=A0 =C2=A0xor EAX,EAX<br> =C2=A0 =C2=A0pop EBX<br> =C2=A0 =C2=A0add ESP,8<br> =C2=A0 =C2=A0ret<br></blockquote><div><br></div><div>What the hell is it a= llocating?</div><div>Surely that&#39;s not necessary... that&#39;s gotta be= fixable?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I have suggested to add a safer version of VLAs to avoid some heap-allocate= d dynamic arrays:<br> <a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D5348" target=3D"= _blank">http://d.puremagic.com/issues/show_bug.cgi?id=3D5348</a></blockquot= e><div><br></div><div>+1!!</div><div>I&#39;m surprised this already isn&#39= ;t supported!</div> </div> --20cf30051342ccea9d04b5f83889--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363f4b2538b504b5f85fce
Content-Type: text/plain; charset=UTF-8

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. --20cf30363f4b2538b504b5f85fce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 21:00, Froglegs <span dir=3D"l= tr">&lt;<a href=3D"mailto:lugtug gmail.com">lugtug gmail.com</a>&gt;</span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">=C2=A0Well games often already integrate scripting langua= ges, generally Lua or Mono, which are both GC based. But this is for the ga= me logic, not for the high performance parts of the code.</div></blockquote=
<div>

++ is so crap at this sort of code. Maybe D will be tolerable, and this bre= aking out to script won&#39;t be necessary? (though I&#39;m dubious)</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">=C2=A0For a GC to be used at = the C++/D layer it would need to be<br> <br> 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 e= scaping lambda without GC, /cry)<br> 2) no long pauses ever<br> <br> =C2=A0I think most game engine stuff will continue to be written without GC= , as it doesn&#39;t really add much if what you are after is raw performanc= e. And C++ does have smart pointers which perform much of what a GC does, b= ut without the long pauses or non deterministic destruction.<br> </blockquote><div><br>I must generally agree, I expect the GC would offer m= e basically nothing but nuisance in engine level code. I&#39;m generally=C2= =A0shovelling=C2=A0large, strictly controlled buffers which need proper pla= cement/alignment, pool allocation, or allocation from temporal ring buffers= and that sort of thing.</div> <div>I don&#39;t typically find C/C++ intolerable, or even particularly unp= leasant for engine level code as it is, it&#39;s the higher level code I&#3= 9;m keen to escape.</div></div> --20cf30363f4b2538b504b5f85fce--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0023544710a801d8c204b5f88d13
Content-Type: text/plain; charset=UTF-8

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... --0023544710a801d8c204b5f88d13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 23:26, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">There are more options with D:</div> <br> 3) Disable GC from collecting during critical parts of the code, i.e. you c= an still new all you want, it just won&#39;t run collection cycles.<br></bl= ockquote><div><br></div><div>This may be nice, but there is never a &#39;no= n-critical&#39; part of a game where I can spare 5...10...15ms (I hear 15ms= quoted often, that&#39;s a *whole* frame) to let the GC do its thing.</div=

ex;border-left:1px #ccc solid;padding-left:1ex">4) Pre-allocate all necessa= ry data before entering the critical sections. You have to do this anyway w= ith C++ if you have hard realtime constraints, as C++ makes no guarantees a= bout how long new or malloc() will take (and it cannot).<br> </blockquote><div><br></div><div>This will obviously happen anyway (and wit= h strict allocation requirements... I&#39;d like D allocators at some point= , or this&#39;ll get messy with pointers), but that doesn&#39;t help, for i= nstance, bearophile&#39;s example of a pointless allocation assigning a lit= eral to a stack array, or various other trivial allocations that go on here= and there like that...</div> <div><br></div><div>I&#39;m also dubious about string allocations. I&#39;d = quite like a way to have strings allocate in their own little self containe= d heap. They can use GC, but they need to be separated into their own littl= e memory region, and not pollute/fragment the rest of the heap.</div> <div>Engine code tends to create large allocations, megabytes in size, and = with very course alignment rules, 4k for instance, and little allocations f= ragmenting memory can cause major problems/gaps...</div></div> --0023544710a801d8c204b5f88d13--
Jan 07 2012
prev sibling next sibling parent "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. #1 isn't actually that much code, but the program probably spends 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
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
--f46d04447ff358916404b5f96326
Content-Type: text/plain; charset=ISO-8859-1

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. --f46d04447ff358916404b5f96326 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sun, Jan 8, 2012 at 10:12 AM, Frogleg= s <span dir=3D"ltr">&lt;<a href=3D"mailto:lugtug gmail.com">lugtug gmail.co= m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Indeed. And this is usually just to mitigate the fact that C++ is so crap<b= r> at this sort of code. Maybe D will be tolerable, and this breaking out to<b= r> script won&#39;t be necessary? (though I&#39;m dubious)<br> </blockquote> <br></div> Yeah C++ is a migraine for that type of code:( =A0I think D would be nicer = than C++ for gameplay code, but another reason for scripts is the ability t= o modify the script while the game is running, and just the general lack of= compilation time which is soo nice.<br> <br> Perhaps if D gets ported to mono? Though even then I think I&#39;d prefer L= ua, since it is quite good at acting as both a language and data descriptio= n.</blockquote><div><br></div><div>D currently does several things that I w= ould find useful doing game logic level code (my day job) and if it were si= multaneously 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.</div> <div><br></div><div>Fast vector/matrix maths. (thankyou Manu for getting th= e ball rolling on this)</div><div>some form of realtime friendly (semi) aut= omatic memory management.</div><div>Ability to write correct code easily.</= div> <div>Ability to drop down to the metal style coding if there is a serious b= ottleneck and a deadline.=A0</div><div><br></div></div> --f46d04447ff358916404b5f96326--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0023544710a8695a1e04b5fa760f
Content-Type: text/plain; charset=UTF-8

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. --0023544710a8695a1e04b5fa760f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 January 2012 03:40, Nick Sabalausky <span d= ir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&q= uot;Froglegs&quot; &lt;<a href=3D"mailto:lugtug gmail.com">lugtug gmail.com= </a>&gt; wrote in message<br> news:lwcqnrvamqlnjjlxzbqa dfeed.kimsufi.thecybershadow.net...<br> <div class=3D"im">&gt;<br> &gt; can reload scripts while program is executing. Neither D nor C++ work<= br> &gt; here.<br> &gt;<br> <br> </div>Why not a dll? Those can be compiled/loaded/reloaded at runtime. And = since<br> it&#39;s just scripts, it wouldn&#39;t take long to compile at all, at leas= t in D<br> (maybe not so much in C++).<br></blockquote><div><br></div><div>It&#39;s co= mmon for designers to edit scripts, and they don&#39;t usually have coding = environments on their machines.=C2=A0</div></div> --0023544710a8695a1e04b5fa760f--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec51ba51f82da8404b5fa8e1a
Content-Type: text/plain; charset=UTF-8

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'. --bcaec51ba51f82da8404b5fa8e1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 January 2012 03:46, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">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 cri= tical stuff and is not the sole holder of references to any GC allocated me= mory it is using.</div> </blockquote><div><br></div><div>... sound like unreliable restrictions. No= w sure I follow exactly what you mean by &#39;only other running thread&#39= ;, and &#39;critical stuff&#39;.</div></div> --bcaec51ba51f82da8404b5fa8e1a--
Jan 07 2012
prev sibling next sibling parent "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 memory, whereas in C#/Java memory is objects. Which makes general purpose memory pools difficult to manage. I know there are engines like the Delta Engine which, to my knowledge, is written entirely in C# (minus a few minor bits). 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
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--0023544710a85c289b04b60244d5
Content-Type: text/plain; charset=UTF-8

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? --0023544710a85c289b04b60244d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 January 2012 08:03, F i L <span dir=3D"ltr"=
&lt;<a href=3D"mailto:witte2008 gmail.com">witte2008 gmail.com</a>&gt;</sp=

border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">I&#39;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 &quot;on the fly&= quot;. Only D&#39;s fast native compile times and easy-to-grasp syntax woul= d really allow for what I&#39;m thinking.</div> </div></blockquote><div><br></div><div>If you&#39;re talking about stringin= g together pre-written code blocks with some editor, then this might be an = interesting approach.</div><div>I&#39;m not so sure how &#39;easy-to-grasp&= #39; D is, or why that&#39;s important if you&#39;re providing an editor?</= div> <div>I tend to think D is considerably less simple than C, possibly more co= mplex (but less archaic) than C++... It&#39;s not really something you coul= d expose to a designer.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "> Given your experience in this area, I would appreciate any insight you coul= d offer about the potential pros/cons for writing low level game engine com= ponents in D. Would you say D is a effective tool to write a general purpos= e memory pool, or would something like that be better written in C?</blockq= uote> <div><br></div><div>I&#39;m probably not the best to comment, because I sti= ll haven&#39;t internalised all the possibilities of D&#39;s powerful langu= age features.</div><div>But I think C is basically a subset of D, so I don&= #39;t see any inhibiting reason why it couldn&#39;t all be done in D. My co= ncern is mainly over whether D makes it easy, or ugly to manage all the res= ources as strictly as required, and how much of D&#39;s idioms/paradigms yo= u need to subvert to actually do it.</div> <div><br></div><div>Writing an engine in &#39;C-ish&#39; D is surely possib= le, writing it in &#39;D&#39;... potentially problematic.</div><div>I&#39;m= keen to have a go in the near future as an experiment, I expect in engine = level code, the GC might frustrate me.</div> <div>Writing various memory managers/pools/buffers themselves is surely fin= e in D, no problem... but USING them in an idiomatic way to allocate object= s, there&#39;s no support in D.</div><div><br></div><div>D:</div><div>MyObj= ect obj =3D new MyObject(x, y, z);</div> <div><br></div><div>D (subverting GC):</div><div>MyObject* obj =3D (MyObjec= t*)someManager.Alloc(MyObject.sizeof);</div><div>....? how do I even perfor= m a placement new?</div><div><br></div><div>I wouldn&#39;t want to be doing= that everywhere.</div> <div>If D implements allocators, then I can see that being much better, ena= bling one to still write fairly conventional D code.</div><div><br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> Or.. is it common to have an array of specialized object pools?=C2=A0I&#39;= d imagine such an engine would sacrifice flexibility and eat up more memory= , but most likely easier to implement.</blockquote><div><br></div><div>I fa= il to see where this is sacrificing flexibility, but yes, you do tend to ov= er-reserve in these sorts of pools, but there&#39;s no real alternative (al= though I use a lot of tricks).</div> <div><br></div><div>Cache efficiently is all about memory locality, and poo= ling &#39;like&#39; things together and stream processing them in batches i= s the most efficient way to do work on ANY computer.</div><div>Once you wri= te 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.= </div> <div><br></div><div>What I usually do to avoid major over-reservation of me= mory is to break the pools into smaller &#39;buckets&#39; (some multiple-of= and aligned-to the systems most course grained cache), and extend/contract= the pool size as needed.</div> <div>Cache alignment is very important, I was surprised+concerned the other= night when Walter mentioned that D does NOT support aligning anything to a= ny power of 2 using the align() attribute.</div><div>I&#39;m curious to kno= w under what circumstances it actually works?</div> </div> --0023544710a85c289b04b60244d5--
Jan 08 2012
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