next »

[st33d]

You could try a ball against the slope instead of a rectangle. It's working for me currently, but I'm doing a sliding game.

[Zaphos]

[1]: http://parashift.com/c++-faq-lite/coding-standards.html#faq-27.4
[2]: http://parashift.com/c++-faq-lite/references.html#faq-8.6
[3]: http://parashift.com/c++-faq-lite/coding-standards.html#faq-27.5
[4]: http://parashift.com/c++-faq-lite/ctors.html#faq-10.6

Since the c++ faq lite can be a bit silly at times, it might be fun to also read the c++ fqa lite's take:
[2] http://yosefk.com/c++fqa/ref.html#fqa-8.6
[4] http://yosefk.com/c++fqa/ctors.html#fqa-10.6

(I wouldn't suggest worrying too much about programming style, though!)

[jmp]

Since the c++ faq lite can be a bit silly at times, it might be fun to also read the c++ fqa lite's take:

Fun, yes. But I for one would not take C++ advice from a self-proclaimed C++ hater.

[Zaphos]

I just mean to say timtowtdi -- there's some reasonable advice in the fqa though, and some questionable advice in the faq.  I would take advice from anyone who says reasonable things, and the fqa does that ... I tend to lean towards the proper faq's opinions on references and initializer lists, but it's good to see the fqa's caveats in addition to the faq's rules of thumb.  (The fqa is increasingly entertaining the more obnoxious the faq gets -- the chapter on exceptions is particularly fun.)

[Garthy]

Another approach is to get everything working with just boxes initially, and go back and add slopes later. That way you can get everything stable, and then make adjustments and improvements later on. If they're a pain at present, I'd leave them out. You may not need them, or might feel more confident implementing them later.

Re special member prefixes (eg. "m_"), I'm in the "don't do it" camp, but to each their own. There are pros and cons. I can work with code that does it, or doesn't. Doesn't bother me that much.

I will slap any non-rookie developer who regularly embeds type information into variable names though.