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.

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.

"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.

"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.
>

"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.

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.

"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?

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.

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.

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.