"Marcel Strik" <mars_888@hotmail.com> wrote in message news:Xns941E7B4B3935marsvulcanushotmail@63.105.9.61...
> "QUS" <qus@go2.pl> wrote in news:bihnmc$1tg1$1@digitaldaemon.com:
> > Hmm... I just wonder... How would it work performance-wise in a game? I guess each operator overloading function also has to new its return value? Now what if I have a solar system with (currently!) over 100 bodies, for which I have to calculate postions 50 times a second? :-)

In U.S. and Japan it's 60 times per second.  ;)

That would suck.  You should use a struct.  The only thing you lose is ctors.  You gain a heckuva lot of performance.  You can always make "constructor" or "factory" functions, but it would be nice if they could be ctors.  Easy on the namespace.  Your factories can be static functions of the struct I guess.

> I'm actually wondering the same thing. I did a little test where I had a vector like object being created every frame and the memory usage did seem to fluctuate heavily, though the test wasn't extensive enough to decide if performance was influenced. Creating the object once and reusing it resulted in a nice steady memory usage. Perhaps anyone else has more experience with the performance issues.

In real games, the heap is idle while the game is being played, for the most part.  We go to great lengths to ensure nobody is allocating or leaking memory.  All per-frame allocations go thru pools, and that's only if they absolutely have to be allocated per frame.

You have to be that strict to ensure you have consistent framerate, and the game doesn't break after you play it a few hours.  We usually push the limit pretty close on memory usage, so if we don't keep a tight watch on what's allocated where, it won't all fit.  You wouldn't want your game to break if you enter the room from the north, but not if you enter from the south, would you?  That kind of stuff is a testing nightmare waiting to happen.

I like how D has garbage collection and that eliminates a whole class of errors, but I have seen situations where one stray 40-odd-byte allocation causes all kinds of havoc.

Sean

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in news:bnakvr$nss$1@digitaldaemon.com:
> 
> In U.S. and Japan it's 60 times per second.  ;)
> 
> That would suck.  You should use a struct.  The only thing you lose is ctors.  You gain a heckuva lot of performance.  You can always make "constructor" or "factory" functions, but it would be nice if they could be ctors.  Easy on the namespace.  Your factories can be static functions of the struct I guess.
(...)
> In real games, the heap is idle while the game is being played, for the most part.  We go to great lengths to ensure nobody is allocating or leaking memory.  All per-frame allocations go thru pools, and that's only if they absolutely have to be allocated per frame.

That's what I thought and I assume that the same still goes with D, but it would be nice to be able to use vector classes and such without taking a big performance hit.

> You have to be that strict to ensure you have consistent framerate, and the game doesn't break after you play it a few hours.  We usually push the limit pretty close on memory usage, so if we don't keep a tight watch on what's allocated where, it won't all fit.  You wouldn't want your game to break if you enter the room from the north, but not if you enter from the south, would you?  That kind of stuff is a testing nightmare waiting to happen.
> 
> I like how D has garbage collection and that eliminates a whole class of errors, but I have seen situations where one stray 40-odd-byte allocation causes all kinds of havoc.
> 
> Sean

Those kinds of errors are allways the best ;)

- Marcel

"Marcel" <mars_888@hotmail.com> wrote in message news:Xns941E6E23FD5A1marsvulcanushotmail@63.105.9.61...
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in news:bnakvr$nss$1@digitaldaemon.com:
> > That would suck.  You should use a struct.  The only thing you lose is ctors.  You gain a heckuva lot of performance.  You can always make "constructor" or "factory" functions, but it would be nice if they could be ctors.  Easy on the namespace.  Your factories can be static functions of the struct I guess.

> That's what I thought and I assume that the same still goes with D, but it would be nice to be able to use vector classes and such without taking a big performance hit.

In D, what you want is a struct, not a class.

Sean

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in news:bnapbb$1210$1@digitaldaemon.com:

> "Marcel" <mars_888@hotmail.com> wrote in message news:Xns941E6E23FD5A1marsvulcanushotmail@63.105.9.61...
>> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in news:bnakvr$nss$1@digitaldaemon.com:
>> > That would suck.  You should use a struct.  The only thing you lose is ctors.  You gain a heckuva lot of performance.  You can always make "constructor" or "factory" functions, but it would be nice if they could be ctors.  Easy on the namespace.  Your factories can be static functions of the struct I guess.
> 
>> That's what I thought and I assume that the same still goes with D, but it would be nice to be able to use vector classes and such without taking a big performance hit.
> 
> In D, what you want is a struct, not a class.
> 
> Sean

Indeed, but to my mind that kinds of defeats the whole OO paradigm. I personally would prefer to use A + B instead of Vector.Add( A, B ). While  programming in D I get a sense that it allows for clearer OO programming than C++ allows, but it's a shame that you have to use structs for these types of problems to get good performance.

structs can have member functions and operators, just not ctors/dtors.

would be nice if we could overload the name of a struct with a function.. so

struct float4 { ... }

float4 float4(...) { float4 v; ... return v; }

would be possible. that would still non-allow ctors/dtors, but would be nicer than some explicit name like makefloat4 or what ever..

i can A + B with my struct, can you?:D

>Indeed, but to my mind that kinds of defeats the whole OO paradigm. I personally would prefer to use A + B instead of Vector.Add( A, B ). While  programming in D I get a sense that it allows for clearer OO programming than C++ allows, but it's a shame that you have to use structs for these types of problems to get good performance.

> i can A + B with my struct, can you?:D
> 
I will try that today :-)  Well - you see - my game will depend heavily on variable level of detail (have you seen Frontier?) so I think I can't ge away without heap, but vectors allocated on stack will be nice!

davepermen <davepermen_member@pathlink.com> wrote in news:bnb22k$1dmf$1@digitaldaemon.com:

> structs can have member functions and operators, just not ctors/dtors.
> 
> would be nice if we could overload the name of a struct with a function.. so
> 
> struct float4 { ... }
> 
> float4 float4(...) { float4 v; ... return v; }
> 
> would be possible. that would still non-allow ctors/dtors, but would be nicer than some explicit name like makefloat4 or what ever..
> 
> i can A + B with my struct, can you?:D
> 
>>Indeed, but to my mind that kinds of defeats the whole OO paradigm. I personally would prefer to use A + B instead of Vector.Add( A, B ). While  programming in D I get a sense that it allows for clearer OO programming than C++ allows, but it's a shame that you have to use structs for these types of problems to get good performance.



Works like a charm, thanks! I was under the impression that a struct couldn't have member function in D, but I guess I mixed up normal member functions with ctors/dtors when reading the docs.

- Marcel