Razor Code
Rambling about code since quite recently

Topics

User Functions





    Don't have an account yet? Sign up as a New User
    Lost your password?

Events

There are no upcoming events

Older Stories

Sunday 14-Sep

  • ACM ICPC 2008 (0)

  • Monday 11-Aug

  • NZ Programming Comp (0)

  • Sunday 27-Jul

  • Blast from the past (0)

  • Monday 21-Jul

  • Timetable generator again (0)

  • Tuesday 08-Jul

  • Hosting (2)

  • Saturday 05-Apr

  • Sparse Volume (0)

  • Friday 28-Mar

  • Carmack (0)

  • Tuesday 04-Mar

  • Back to Uni (0)
  • Dell Kill Switch Direct (0)

  • Monday 18-Feb

  • Lappy (0)

  •  Platformer02  

    Platformer02

    < Previous    Next >

    Introduction

    In this video, we'll start on OpenGL. I recommend a good book on the subject and a reference, but I'll try to cover the concepts now.

    The state machine

    OpenGL is a state machine. This means that any function you call to change the way OpenGL draws things will affect everything rendered after the call is made. So you have to remember to change things back. For example, you might want to add a red baddie. So you do something like:

    glColor3f(1.0f, 0.0f, 0.0f); // Set colour to red.
    DrawBaddie();
    DrawPlayer(); // Oops, player is now red.

    When what you really wanted was:

    glColor3f(1.0f, 0.0f, 0.0f); // Set colour to red.
    DrawBaddie();
    glColor3f(1.0f, 1.0f, 1.0f); // Set colour back to white.
    DrawPlayer(); // Player is now white.

    Everything from transformation matrices to pointers to vertex data is stored as state in this fashion. You might expect the state to be reset for each new frame, but it is not. Personally, I have a tendency to do things every frame which only need doing once. I'm not suggesting it's the best thing to do, but I'm lazy.

    The matrix stack

    We won't be doing much in the way of transformations just yet, and we certainly won't be doing any 3d, but I think this is an important concept to cover. It's also one of the more difficult things to get your head around, and isn't obvious from code. Might as well do it properly, right now. In 3d, there are several commonly used coordinate spaces. The following is a slight simplification, and other people may have different names for them.

    World space

    World space is not a real coordinate system (if there even is such a thing as a real coordinate system). But it's the one that makes the most sense, so it's used a lot out of convenience. The green thing is the frustum (our view of the world) by the way.

    Model space

    Model space, or object space, is fairly self explanatory. Modifying this coordinate space changes the position, orientation and scale of the model.

    View space

    View space defines the position (etc.) of the camera.

    Screen space

    Screen space, also called clip space, is actually 2d. Well, I think it is, I'm not entirely sure how it's implemented when you get down to it and it might not make sense to make the distinction. But this diagram is intended to show how the transform from view space to screen space can give perspective.

    OpenGL handles all of this with just two matrices. The ModelView matrix transforms straight from model space to view space. If you think about it, all OpenGL needs is the relative positions of the camera and object, their position in the world is irrelevant. Then there is the projection matrix that transforms from view space into screen space. But the heading up there is "The matrix stack". Two matrices are hardly a stack, now are they? Well, those matrices are generated by multiplying a stack of matrices together. This is useful when you have groups of objects all undergoing the same transformation. Picture a train. You push one matrix on the stack for the trains coordinate system. Then you push another matrix for a container on the train, then another for a box in the container, then another for a bar of chocolate inside the box. The ModelView matrix for the bar of chocolate is the combination of all those transformations. But don't worry about that too much, I doubt we'll use it much for a platform game.

    Orthographic projection

    Seeing as we're making a 2d game, I suppose it might be useful to know how to use this stuff in two dimensions. The only real difference is you don't do a perspective projection when going from view space to screen space. That, and we provide all our coordinates with a z value of 0 (or fail to specify).

    I've put them all in one diagram because I thought I could get away with it. As you can see, there is now no perspective, our frustum is just a box. So in this case, all the projection matrix really does is scale. The ModelView matrix is used to position our camera and any objects.

    Errata

    See any mistakes? Let me know.

    < Previous    Next >

    Last Updated Sunday, December 17 2006 @ 07:42 PM NZDT|321 Hits View Printable Version


    Who's Online

    Guest Users: 5

    IM Widget

    Get Firefox

    Get Firefox!