View mode: basic / threaded / horizontal-split · Log in · Help
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
"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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
"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.
>
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
"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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
"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?
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 09, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 09, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home