Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Disclaimer: this is a trick-question. It's not about transforms or projections it's about 'gaining perspective'.

Example: I want to create a smoking camp-fire in my game but all the tutorials on particle systems focus on logic. Spawning. Animating. Destroying. But that's easy. I would go even further and say that figuring out how to move the particles around is the FUN part. What I need to know is how to render them. Do I use Point Sprites? Quads? Vertexbuffers? The particle tutorials often nonchalantly do something like this:

    for point in points:

But immediate mode is deprecated! Right?

You're supposed to store stuff in a buffer now! On the GPU! Right?

But how do I animate stuff? Updating buffers is slow! Right?

I'm a beginner and this is my problem: The tutorials and books I found throw around these terms, but don't give you any perspective.

  • How slow is slow?
  • How deprecated is deprecated?
  • What is worse? Many nested code-paths or many OpenGL state changes? And how many?!
  • For how many vertices is it faster to multiply a matrix on the CPU and not in the shader?
  • What's the performance impact of creating, binding, rendering to and applying a new texture?
  • What orders of magnitude are we talking about?

And so forth. How do I go about learning this? Is there a list of thumb-rules anywhere or do I need to code everything multiple different ways and look at the raw FPS?

This isn't just about performance. I don't use thousands of vertices for my crappy little jump'n'run. This is about crippling perfectionism. I want to learn how to do it right.

share|improve this question
That's the thing about best-practices, they come from practice. You can't expect to be perfect without practice. (I would never expect to be perfect ever.) –  UnderscoreZero Apr 19 '13 at 16:57
I don't quite understand how you get the impression that I'm expecting that. Also, I think experience comes from practising. Best-Practice comes from asking people who know better than me :-) –  Jan Apr 19 '13 at 17:04
The line about crippling perfectionism was where I got the impression about being perfect :). My point was that you either learn it yourself through practice, or someone else shows you how to do it (they probably learned through practice). I prefer to do it wrong and then try to improve on the process. But to each their own I suppose. :) Still nothing wrong with asking. –  UnderscoreZero Apr 19 '13 at 17:29
You're asking for an entire education in OpenGL and on multitudes of hardware implementations, this is way out of scope. Plus, you're asking for all this information in the realm of performance programming, which itself is way out of scope. You learn these things one at a time and when you come across them, either from studying a solution to the immediate problem or from experimentation on your target platform. So to answer your question, pick exactly one thing from your list, find recent examples, tutorials or papers, then go on to the next. –  Patrick Hughes Apr 19 '13 at 17:34
How to avoid bad practices in tutorials: find a better tutorial. I'm voting to close because I think your question is answered by the answers to this question. As far as specific numbers, it varies depending on hardware and the details of your particular game. By the way, don't mistake bikeshedding for perfectionism –  Jimmy Apr 19 '13 at 19:17
show 2 more comments

closed as not a real question by Byte56, Patrick Hughes, Anko, Jimmy, Josh Petrie Apr 19 '13 at 22:48

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Browse other questions tagged or ask your own question.