I really like your style, it has a real sense of both personality and motion.  I wish I had the time and wasn't working on something else right now...

Whatever you end up doing, make sure you post about it here, so we can 'ooooh' and 'ahhh' over it

Kinda. Well, it might be something trivial to you, but, the thing is, I've been repeatedly bashed over the head about how multiple inheritance is evil and how it breaks encapsulation and about the diamond problem and something about vtables I forget and something about pure abstract classes etc. But the more I actually work with OO concepts the more I think it is the best thing since grilled cheese. I just multiply inherited, and it worked like a charm. So I am happy. 

I am currently working up the courage to multiply inherit from THREE base classes. Wish me luck.

I love MI and use it all the time.  Sure, like anything in C++ there are 'potholes' (for lack of a better term), but it also allows you to do some pretty sweet stuff with it.

If done properly it doesn't break encapsulation.  On top of that I feel that encapsulation is a feature not a contract and should be used when it makes coding/maintenance easier; which that might not be all the time, there are good, valid, and wholesome situations where not encapsulating members can be useful.

I don't understand why people think MI is so evil TBH, and I think that sentiment prevents a lot of good MI related info from proliferating over the internet.  There seem to be far more rants on why MI is horrible than articles on what it is useful for and how to use it properly.

So don't let the naysayers dissuade you, if you find it useful then use it ; )  That's the best part about programming, there's no one best way to do it.

If the game logic is the bottle neck... Ermm... Well I'm not sure any technique will help you at that point.

Even when doing your game logic in variable rate time slices, you still have to 'sync' the computations at every game event (player jumps, enemy shoots, explosion hits something ect...).  Like if the time slice is from 0ms to 200ms, and the player hits jump at the 100ms mark, you can only 'simulate' up the that event.  Then you have to adjust velocities/trajectories/ect... then simulate from that event till the end of the time slice.  If you were to simulate the entire 200ms time slice without stopping at game altering events, then your simulation would completely change as the frame rate changed.  So regardless of whether its a fixed rate simulation or not, there's still a minimum of sorts that needs to be computed.  On top of it variable rate physics is usually more costly to compute than discreet.  

At some point if the computer can't keep up with the simulation then either you need to simulate less, need a different algorithm, or you need a faster computer.

Like Jimmy said, I use a fix rate time step in my games.  I just don't draw every frame.  I know a number of commercial games do the same thing (Doom3 for example).  For example the 'internal' frame rate of my last project was 100 fps.  At the end of each frame it'd check to see if the video card was busy.  If it was busy it'd skip that frame, otherwise it'd draw it.

This way you have the ease of fixed-rate physics (which guarantees identical results on different computers, something that's VERY hard to do without fixed-rate), and the frame rate can still vary as needed.

This also has the advantage that your still checking mouse/keyboard/joystick events at a regular interval.  So even at very low frame rates its still responsive.

Purdyyyyy http://www.effectgames.com/effect/article.psp.html/joe/Old_School_Color_Cycling_with_HTML5

Wow... simply amazing.

Speaking of esoteric programming languages. 

The 1-operand languages (http://en.wikipedia.org/wiki/One_instruction_set_computer) are always kinda interesting.  When I have some time I'd like to try my hand at making a 1-op interpreter for a GPU (use either CUDA or maybe OpenCL).  That way instead of being restricted to 1 kernel run over 1000's of threads, you could have each thread run its own 'kernel'.

Now the big question is, how to make use of 1000's of asychrnous threads.  I'm not sure what I'd compute or simulate, but I bet it would be cool.

I'm not. The others are.

I know, I understand where ur coming from, and where they are.  I just want the happy programmers back.  I've been slogging my way through a complete parsing solution.  And though very useful, its also been quite tedious.  So I like coming here and reading what ppl are working on.  It helps motivate me to get it down, so A) I can post in here about the amazing parser framework I finished (eventually) and B) I can get to programming some more cool stuff similar to what I see here (by sheer coincidence my next project is to put the finishing touches on an OS wrapper, similar I imagine to what average software is doing, so I too was curious as to what he had done).

People seem rather angry today in 'The happy programmer room'.

[fluid dynamics particle system]

Just coded a fluid dynamics particle system simulation. It uses Navier-Stokes equations to apply wind velocities.

Video here:



Woopee!!

Pretty, but it seems to be biased towards the diagonals.

I like the artwork and the idea, but sadly I'm not a python programmer.

You love forcing people to hand over personal information? Why not just ask?

You don't need someone's email to be a threat to them.

http://wowriot.gameriot.com/blogs/Americans-are-bad-at-games/Real-Names-on-the-Official-Forums-New-REAL-ID-function?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed&gr_i_ni

I know plenty of women who've had serious trouble from stalkers and have had to change their phone numbers and go to great lengths to conceal their identity from those harrassing them. This sort of thing would make it impossible. Being able to protect your identity online I think is simply a basic right.

I don't like the idea of your name being posted on the forums, but again you don't have to post, and its not like you have to post to enjoy their games.  In fact the blizzard forums (and WoW in particular) should be avoided as much as possible.

No one will see ur info if you don't want them to.  Its not a requirement in any way to use the rest of their products/service.  I could see it being a problem if say, RealId was required to play online in SC2, or was required to join a guild, or something of that nature.  As it stands its pretty much an in-game MSN/AIM.  I don't see how this would subvert your right to online privacy.

I love RealId.  I have a lot of friends who play on other servers, and soon other blizzard games, and its nice I can talk to them.  As far as the cartoon goes, it doesn't make sense.  You don't need to give out your e-mail to anyone, and you don't have to accept invitations if you don't want.

Like I said:

1. It's explained in the comments.
2. I'm not going to have to change the constant. I know this.

In his defense, we can't see the rest of the code, those numbers might make perfect sense in context.  And hidden behind an appropriate interface, magic numbers are fine if properly documented.  Ensuring every single literal is a constant with a really long and ambiguous name (ie. MATRIX_CONSTANT_V1_3_VIIII_PART2) doesn't help understanding.  Obviously tweakable ones should be named, but some are intrinsicly tied to the algorithm, and hence are best left within the code they are married to.

Sure its not what I would've done, but creativity and ingenuity are far too often overlooked in the quest to ensure everyone does things the way we would do them.

That's what I love about programming.  There's no one right way to do it.

If you want to include normal (non-template) functions in a header file, just use inline.

Code:

inline void SomeFunctionICantBeBotheredToPutInCppFile () { /* stuff here */ }

edit: beaten to it again by average ; (

Hmm... I'm a bit confused, wouldn't this work?

Code:

template<class T> T whatever (T t);
// later a the bottom of the header file, or perhaps in another header file...
template<class T> T whatever (T t) { return t; }

or just

Code:

template<class T> T whatever (T t) { return t; }

I don't see why adding it to a namespace (anonymous or otherwise) would change anything.

edit: beaten to it ; )

And stating he is an idiot do not solve the problem and do not prove him wrong.

But now i can see where Erbert is coming from, especiaaly after his review of ratatouille. Game are bad at displaying humanity with depth, it's a given. That and erbert don't have a clue too!

EDIT: let me rephrase, we have barely game that focus on being human aside from "the sims"

Fable comes to mind...

Design patterns compensate for deficiencies in languages.

Ahh ok, now I understand where you're coming from.  Under that assumption it makes perfect sense. 

In university we were taught that design patterns were ways of descibing programs at a high level.  Sort of a shared/common jargon amongst programmers if you will.  When trying to talk about a program or algorithm without using design patterns it becomes quite a headache to properly convey your intention without getting muddled in the details, which is supposedly where design patterns came in.

Now whether or not my professors were correct (hehe... most of them were idiots) is another story, and TBH I haven't read that much on them apart from what was required for the few courses that covered them, and the odd wikipedia/Dr Dobb's article or what-not, so I'm sure your expertise in them are far greater than mine.  So please don't take the above as a 'your wrong I'm right' sort of thing (tone is very hard to convey via text, I really am interested in what you think as you seem to be quite knowledgeable about these things), rather that was just the way I understood it, and perhaps a few others in here as well.

Now just to stimulate a bit more dialog... 

I'm not sure if design patterns can be only used to describe deficiencies in a language.  Since many design patters are quite large implementation-wise even if only describing a simple function/feature that few (if any languages) would have many of them implemented in their entirety.  Which seems kinda silly that 95% of them would be used in normal programming talk/design docs/ect... while 5% of them are ignored because they just happen to (in this particular instance) map directly to language features.  Also it seems a bit weird that if you moved a program mid-design to another language (say from C++ to C#) that 1/2 the terminology/documentation would become erroneous because some design patterns described now map to directly language features where-as before they didn't, and vice-versa.

Also if we can't use design patterns to describe high level programming abstractions...  What else would we use?

Hey, it is an interesting question nonetheless, and a good thread!

Average, good to see that we can use variadic arguments that way. Is there any way of obtaining the return type of the function so we can use that in the template declaration?

I would assume (but haven't tested) you could extract them much like you do now with:

Code:

template <typename T> struct GetReturnType {};
template <typaneme TR, typename... ARGS> struct GetReturnType<TR (ARGS...)> { typedef TR type; };

I can't test it with VC++ yet (no variadic templates yet), and haven't had the time to install GCC.  So its just a guess...

Addendum:  I should perhaps point out that a singleton is a class explicitly designed to allow only one instance.  The module approach happens to use one instance of a private data-type.  Just because a program only uses one instance of something, doesn't make it a singleton.

Isn't that kinda splitting hairs?  If there's only one, and really only supposed to be one, isn't it pretty much a singleton?  Whether its an explicit error creating a 2nd, or simply a requirement somewhere in the documentation, or just something that isn't done, you still have 1 global at the end of the day.

The real issue I find with singletons in C++ is the static intialization order mess.  Singeltons need to be created prior to their 1st usage (often before the program has even hit main() ) and last often long after main has exited.  The only safe solution I could come up with was to use a combination of a Meyer's Singleton (to ensure creation at the proper time) combined with a Nifty Counter (Schwarz Counter I've heard it also called) to ensure it gets destroyed after everything that uses it.  Then you have to run it all through a global critical section.

In the end I made a GetSingleton function that works something like:

Code:

SomeClass& class = GetSingleton<SomeClass>();

and it handles all the mess for you, but its still rather costly in terms of peformance, so I don't use them often.

Personally I find when I need global variables, I tend to use thread locals whenever possible.  They're almost as fast as accessing a 'naked' global, and require none of the mess that true singletons require.

For those who might be following this thread...  I made a really silly mistake   I can't believe it either, I really should've known better. 

So after playing around with what I thought was a fully working recursive decent parser, realized that I can't use recursion in the grammar definition, which means it isn't a true context free parser.  Its pretty much just a fancy (and hence slow) regular expression parser, which would be far better off parsed using a FSM.

The whole reason for this thread (passing functions as template arguments) still stands, but I still feel quite stupid I didn't catch such an obvious mistake FAR earlier.  Thanks for the responses anyways.