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

Manu turkeyman at gmail.com
Sun Jan 8 03:05:59 PST 2012


On 8 January 2012 08:03, F i L <witte2008 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120108/33215443/attachment.html>


More information about the Digitalmars-d mailing list