Everyone’s talking about IP TV and how it’s going to revolutionize things. We’ll be able to get our TV anywhere, any way, but the reality has fallen short of the promise. Your ISP may be beaming Digital channels down to you over IP, but the experience is largely unique to your ISP. Your cable box is not a TV Content browser, no matter how much it tries to be. Heck, you can’t even take your Time Warner Cable box and easily connect it to a Comcast user’s home. The spirit of the IP in IPTV is sorely missing.

That’s why I’m working on a better way–and I need your help.

There are several standards regarding IPTV (and they are used), but while they focus on delivering the content, they do not focus on the programming. If you’re looking at the web to solve your problem, don’t look there either. Every single news or content producer has their own site with their own way of accessing it. You need accounts, you need a pretty hefty browser, and you need to wade through a different interface each and every time.

There is no way to channel surf on the web.

What about RSS?

RSS is great! I love it, but it drastically changes consumption of media, albeit in a very Web way. TiVO’s and DVR’s help bridge this gap on the classic TV side, but what about programming? Sometimes I don’t want to pick what to watch.  Sometimes I just want to flip through channels and see what’s on. RSS does not replace programming. (I’d also like to take this moment to give a big shout-out to Miro, which is an amazing application for automagically downloading and managing video RSS feeds.) We need something more.

A New Way to Surf

What we need is a format for serving up programming that goes beyond a fixed stream.  We need a way of mixing up content, and the web.  We also need a better way of consuming it all.  Without giving it an official name, I’m going to call this protocol LP.  Imagine if you could pull down a link to your favorite channel’s programming and view content live.  It’s not a stream, it’s a url your LP player goes to and it contains all the information you need to find out what’s playing now on your favorite channel.  Heck, why stop with now?  Maybe it’s all pre-recorded and you can skip to what’s playing later?  Maybe, you want to see what was on before?  Who needs a DVR?  The content should stay available and you should be able to consume it.  What I’m talking about is a REST API for navigating video and audio content.

A Trudge Through the Mud

I first started writing this post four months ago and I kept putting it off. Then I wrote some more and put it off a few more months.  I had all these ideas in my head and I wanted to get them all out in one go.  I wanted to have a working prototype of an LP Server and Player, of the “LPXML” format, and have all the whizz-bang features I wanted to put into it.  The fact of the matter is I’m busy and it will take me forever to settle my ideas if I don’t just start and get something out there.  So I’m going to start with just the basics of what I think this “informal” standard should look like.

And I’m definitely looking for feedback.

What I’m proposing is that an LP player take a link to a website (e.g. www.spaceislimited.org/lplayer/) and this will be the root of the lplayer REST interface for my site (the link is hypothetical btw).  The Lplayer application (this could even be Miro if this catches on) would then know the following structure for the REST inteface.

lplayer/now/ – This verb will respond with a page that will contain the URL of the content that is currently now playing.  For example, the Lplayer goes to lplayer/now/ and get this response:

<code>

<a href=”http://spaceislimited.org/videos/awesomevid1.lpxml” />

That’s it.  Nothing else.  Maybe eventually we’ll specify an XML doctype and wrap it in something like:

<?xml version=”1.0″ encoding=”utf-8″?>

<lp version=”0.1″ xmlns:lpxml=”http://www.lpxml.org/lpxml.dtd”>

<program>http://spaceislimited.org/videos/awesomevid1.lpxml</program>

<elapsed>20</elapsed>

</lp>

</code>

The player would then follow that link to get the content and some meta data about the content.  It would also  use the elapsed value to sync up with how far into the program everyone is.  Of course, if it’s a live stream, the elapsed value may not be necessary.  The program link might look something like this:

<code>

<?xml version=”1.0″ encoding=”utf-8″?>

<lp version=”0.1″ xmlns:lpxml=”http://www.lpxml.org/lpxml.dtd”>

<content size=”small” codec=”quicktime” bitrate=”100k”>http://spaceislimited.org/videos/awesomevid1_lowres.mov<content/>

<content size=”medium” codec=”quicktime” bitrate=”200k”>http://spaceislimited.org/videos/awesomevid1_mediumres.mov<content/>

</lp>

</code>

Depending on the player, it can choose one of three files to stream, each with a different bitrate.  For example, if you had an LPlayer on your iPhone, maybe it would choose the 100k stream, while your home computer might opt for the 300k stream.  Also, the rest of the meta-data is standard stuff which could be used within the application.

So what happens when the video is done?  Simple, the player would then go fetch the /lplayer/now/ link again and get what’s playing now!  If it still sees the same entry, it might wait a few seconds and try again (maybe your lp server site is so awesome it’s having trouble responding).  Or the application could try /lplayer/next/ and get what’s playing next.  That way, your iPhone can start buffering what’s next a few seconds before!

A Call to Arms

I’m publishing this as an informal standard and I’d love to see your comments behind this.  More than that, I’d love to see people who are willing to work on this with me on setting up a community around this and implementing a free server and player for the “LP” standard.  For this standard to work, it needs to be open, simple, and platform and codec agnostic.  I haven’t said anything about needing to use the QuickTime codec or having to choose a standard bitrate.  This is about discovery and enabling the player to make the right choice.  Attached is the standard–plain and simple for now.  In the coming weeks I’m going to work on getting a site (lpxml.org), wiki, forum, and mailing list (lpxml [at] googlegroups [dot] com) setup so we as a community can work on this.  I hope you’ll join me.

OpenGL is the Open Graphics Library and it is maintained by the Kronos Group, which is a consortium of top-tier companies that include board members such as ATI nVidia, Apple, IBM, and more. Microsoft used to be on the consortium, but left and decided to make DirectX, a competing closed graphics library that only runs on Windows (at least without some sort of emulation layer or wrapper like Wine or Cedega).

First off, OpenGL is a huge thing to master (and I am nowhere near mastery). I can’t explain everything about it in one post (or even in hundreds), but I strongly encourage you to get the OpenGL “Red Book” to start out. The “Red Book” is the official and definitive guide to OpenGL and is a must have for any graphics programmer. I also recommend the K&R C Programming book and, if you’re interested in the back-end math, the Real-Time Rendering book.

That being said, in our pong clone, we only use a few OpenGL functions. I’m going to list them and tell you what they do, but it may take until the next post to really understand how they work.

First, a word about primitives. OpenGL has only a few key primitives that you can draw with, but that’s okay, because you can use the primitives to draw more complex shapes!

The OpenGL primitives are:

• Points – a simple point in space
• Lines – a 2-dimension line (although it can occupy 3-dimensional space)
• Polygons – a polygon is a simple 2-dimensional shape comprised of 3 or more points. Triangles, or 3-point polygons, deserve special attention, because OpenGL will break up any other polygon into a combination of triangles. For example, a square can be broken up into two triangles along its diagonal. Just about every object you see in OpenGL is comprised of triangles!

So let’s draw a simple quadrilateral! In OpenGL, you draw polygons by calling a function whenever you want to draw a polygon and then creating a bunch of points in space to create that polygon. Once you’re done, you call another function to say you’re done.

Here’s an example for drawing a rectangle (our pong paddle):

glBegin(GL_QUADS);

glVertex2f(-10, -50);

glVertex2f(-10, 50);

glVertex2f(10, 50);

glVertex2f(10, -50);

glEnd();

We start by calling glBegin() and sending it GL_QUADS to indicate we want to draw a quadrilateral. This basically tells OpenGL take every four points I send you and make a quad out of it. We then call glVertex2f() and send it the coordinates of a two-dimensional point. the 2f indicates that this is the glVertex function which takes 2 floating point values as its arguments (or inputs). We then call glVertex2f() once for all four of each of our points and then call glEnd() when we’re done.

We could have optionally set a color before we began to draw that quadrilateral (the default is black on black) by calling this function:

glColor3ub(255, 0, 0); //red

Again we see the OpenGL naming convention of starting off a function with gl and then ending it with letters and numbers that indicate its arguments. In this case the 3ub means 3 unsigned bytes. Each unsigned byte is positive (hence unsigned) and can go from 0 to 255. The order of the bytes indicate the amount of Red, Green, and Blue respectively that will mix to give you your final color. (Color theory is another big subject matter I can post more about in another post, so let me know in the comments!)

Two other functions that are usually called at the beginning of every display function are:

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

glShadeModel(GL_FLAT);

glClear(), quite simply is a function that clears the screen and uses the values specified as its argument for doing so.

glShadeModel() specifies the shading model for how vertexes (points) are shaded or lit. In this case, we’re going for a simple flat colored 2-d look so we use GL_FLAT. This paints everything on screen with whatever colors specified and doesn’t do anything fancy. It’s sort of like painting in mspaint on Windows.

glPushMatrix();

glPopMatrix();

glTranslatef(30.0f, 10.0f, 0.0f);

glPush and Pop Matrix() are important functions. They allow you to draw something as if you are starting from scratch with a new coordinate system. Think about our pong paddle. When you want to draw it some place else, do you really want to respecify the coordinates for how it’s drawn? You could instead push a matrix (a set of points) on the stack, then translate (or move), to a new location and draw the object as you would anywhere else, and then finally pop the matrix which will draw the set of points translated (moved) by the glTranslatef() function. This is a little hard to understand (and explain), so I’ll give an example.

In Part II we talked about drawing a box that moved across the screen. We could draw our box as a point in a 2-dimensional plane. For example, let’s make a square that is 4 across centered at the origin (0,0). So it’s points are, going counter-clockwise, (1,1), (-1,1), (-1,-1), (1,-1). Rather than figuring out how to move it along for every frame. We can do this.

glPushMatrix();

glColor3ub(255, 0, 0); //red

glTranslatef(x, 0.0f, 0.0f);

glBegin(GL_QUADS);

glVertex2f(1,1);

glVertex2f(-1,1);

glVertex2f(-1,-1);

glVertex2f(1,-1);

glEnd();

glPopMatrix();

So we push a matrix (a set of points) on the stack, switch the drawing color to red, then Translate x units in the x-direction (horizontal) and then set the drawing mode to GL_QUADS and push the points of our square as it is centered at the origin, and finally pop the matrix! This has OpenGL do all the work of moving our square x units to the right.

Okay, that’s enough for now. I encourage you to scour the web and read up more before we get to our next post, where I’ll finally post the code and go through it!

For reference, you probably want to start out with Part’s II and I here and here.

Last we left off I said I’d get into some of the basic mechanics of GLUT and OpenGL, so let’s hit the ground running.

GLUT

GLUT, or the Graphics Library Utility Toolkit, is a cross-platform C library for generating windows and handling IO events. Basically, GLUT was written so you can get to learning OpenGL very quickly without having to spend enormous amounts of time learning how to handle mouse or keyboard actions in your current OS, or worse, learn how to setup a simple GUI just so you can see your work. On top of making these tasks simpler, GLUT is, as I mentioned, cross-platform. This means that you can take your code and recompile it on another OS as long as you have the appropriate GLUT library referenced in your IDE. There are currently versions of GLUT created for Linux, OS X, Windows, and probably even more operating systems.

So how do we create a simple window?

Here’s a snippet of code for how to do just that!

int main(int argc, char** argv)
{
glutInit(&argc, argv);

glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowSize(500, 500);

glutCreateWindow(“Tim GL”);

glutDisplayFunc(display);
glutReshapeFunc(reshape);
glutKeyboardFunc(keyboard);
glutKeyboardUpFunc(keyboardup);
glutIdleFunc(idle);

glutMainLoop();
return EXIT_SUCCESS;
}

You start off with your regular main function in C. Then you call the glutInit function and pass it is passed any parameters you may have passed to main. For this tutorial you won’t be needing any, so don’t worry about it. If you need to find out more, check out the GLUT Documentation.

Next, you pass the glutInitDisplayMode() function a “logically OR-ed” value of GLUT_RGBA, GLUT_DOUBLE, and GLUT_DEPTH. If you don’t know what logically OR-ed means, just think of it as smooshing all these flags together to set the display mode with all of these properties. (If you want an in-depth explanation of this, just ask and I’ll put up a post about it!).

After this, we set the pixel dimensions (size) of the window to 500×500 pixels with the line “glutInitWindowSize(500,500);”. We next set the window’s title bar with “glutCreateWindow(”Tim GL”);” You can set either of these last two functions to whatever value you wish!

Next, is the pretty interesting part. And to understand it you need to understand a little bit about Call-Back functions. Call-Back functions are functions that hold a pointer to another function and call it when some event happens. (This is also why Call-Back functions are usually regarded as “Event-Driven Programming”.) To explain this it’s best to show you by example. I’ll start with the glutKeyboardFunc(keyboard). Whenever a key is pressed down, we have set glutKeyboardFunc() to call ANOTHER function called keyboard that WE have defined. The function is not show here, but we will get to that in the next post! Suffice it to say, our keyboard function will handle certain things like “what to do when the up arrow is pressed” in our Pong clone.

It is important to understand that we can’t just write a function that constantly checks the keyboard like this

while(TRUE) {

whatIsTheKeyboardDoing();

}

because we’d be in an infinite loop and never be able to do anything else. The Call-Back function allows us to be “called back” whenever someone presses the keyboard.

Now that we’ve explained that, the rest of the functions are easy to describe:

• glutDisplayFunc() is called most of the time and is the function that paints our screen with whatever we tell it to with OpenGl
• glutReshapeFunc() is what is called whenever the user resizes the window (In case we need to do anything special if the user all of a sudden changes the screen size on us.)
• glutKeyboardFuncUp() is a tricky one, and it’s what is called whenever a key is “depressed”, or let go. This is a subtle point, but it is useful to know when someone presses a key and let’s go of one. Without this, you wouldn’t be able to tell when someone was holding a key.
• glutIdleFunc() this is the function that is called whenever there is nothing to do!

So that’s it! That’s about all you need to know for GLUT for now! Check out the next post for OpenGL.

Before I start with anything, we have to think about simple animation. In fact, animation is just simply a series of static images, with each image slightly displaced from the last.

So what does that mean?

For example, if I’m going to draw animate a ball falling from mid-air, I would first start with an image of the ball in mid-air, precisely as it would look the moment it began to fall. The next frame, or image, would be exactly that, but with the ball a little bit lower down. I would then continue to draw sequential images of the ball, with each image showing it a little bit further than the last. This is how every moving image you see works (well, just about). A series of images is drawn in front of you, quick enough that you can’t tell.

So the next question is, what’s quick enough? It turns out, this isn’t such a simple question. In fact, the answer is different for different animals! But for humans, it turns out, about 30fps, or 30 frames-per-second, is what it takes to fool us. The movies you see in the theatre are (at-the-moment anyways) displayed at 24fps, but most computer screens require 60fps to prevent you from seeing the flicker (some, like myself, need an 85Hz (fps) refresh rate, others up to 120!). The reasons for these differences has a lot to do with the way the image is drawn and the way your eye views things. It’s a pretty involved topic, but if you guys would like me to go into it more, let me know in the comments.

A Simple Animation Loop

Taking what we just learned, let’s think about how to draw a box moving across the screen. Let’s pretend we have a function that draws a box centered at a point we specify on the screen (in 2-D Space). It’s C function prototype would look something like this:

void drawbox(int x, int y);

So if we were going to draw a box that just infinitely moved to the right (or at least until it was off screen). We might decide to create a loop that drew it a little bit further each time. That might look something like this:

#define TRUE 1

int x=0;

while(TRUE) {

drawbox(0+x, 0);

x++;

}

This little snippet of code, runs an infinite loop and draws a box at a point 0+x, 0 and then increments x. Let’s look a little further. First it draws a box at point(0,0) since x is 0 on first count. Then x is incremented and the loop goes on again. Next, it draws a box at (1,0) and increments x. And so on. Congratulations, you just made your first animation loop!

Marching Onward

In the beginning, video games were hand-coded in assembly directly to a particular hardware. This had a lot of benefits, primarily speed, which was very important when hardware was relatively expensive. But as computers progressed and the market expanded, it became necessary to program for a multitude of different hardwares. And this is when a nasty problem reared it’s head. You see, when you decide to have the computer draw something on the screen, it doesn’t just do it instantaneously. The computer has to go and draw each individual pixel on the screen (also a topic for another discussion).

This

takes

time.

Moreover, the time it takes on your brand-spanking new ultra-super processor is not the same time it takes your friend down the street who isn’t as enthusiastic as you are. This is a problem, because if you set up all your animations expecting the processor to draw 30 frames per second on your machine. It’s going to run at less than that on your friends machine. (In fact, there’s some math that shows it will be a fraction/multiple of their refresh rate). Great, so your fast-action shoot-em-up just got stuck in the mud.

What’s a game programmer to do?

There’s a really simple answer to all of this–use our friend (archenemy) time. You see, rather than making your animation speed depend on the animation loop (which depends on your processor speed), have the your animation be a fixed function of time.

Take another look at our first example. The movement speed of the box can really be expressed as 1 unit in the x direction per loop iteration. Really what we want is for the box to move some number of units in the x direction per second (our hour if you like). To do this we need to express our box movement as a function of time and then know how long its been since the computer last drew the box. Essentially, we want our animation loop to look like this.

#define TRUE 1

int speed = 1; //1 unit per second

int x = 0;

startTime = 0;

elapsedTime = 0;

while(TRUE) {

startTime = getTime();

x += speed * elapsedTime;

drawbox(0+x, 0)

elapsedTime = getTime() – startTime;

}

As you can see, this simple example becomes a lot more complicated once we add timing to the mix. First, we defined a universal speed for our box. We still kept the x value, as this represents the boxes point in space, not it’s speed. Then we created variables for keep track when we started our animation loop and how long we were in it. We’re also assuming we have a function that gives us the time, called getTime() here, and that it returns us the current time in seconds.

First we enter our loop and fetch our start time from the getTime() function. Next we set our x position based on how long it’s been since our last loop. We multiply our elapsedTime by the speed of our box and add that distance to our x-position. Then, we draw our box at it’s new position. Finally, we figure out how long it took us to draw that box by setting our elapsed time equal to the current time minus the time we started drawing the box. Now, no matter the computer, our box will move along the screen at the same speed. Note, this does not mean the animation is fluid! If your friend’s computer is really slow (and I mean really if it can’t draw a box) it may only get to draw a box once every 5 seconds. By then, our box may already be off the screen!

So I hope that’s enough for you to digest for a while. Stay tuned for my next post on some of the basic mechanics of GLUT and OpenGL. Until then, it might be useful to brush up on your C programming on the interwebs!

There’s a great article on Beyond3D about the technology of a 3D engine. The article’s split up into parts and part two was just released (after a several month wait!). Part one discusses a lot of the general concepts for a 3D engine design in an easy to read and abstract level, but part two goes into deeper detail. Both make for interesting reads, though part two sort of jumps into an ocean at no discernible point. (It covers scenegraphs I know, but why start there? Why not animation? Look for my own part two of programming a pong clone to animation and early concepts in game programming.)

• Part One
• Part Two

If you ever wanted to program your own video game, this is a good place to start. I remember when I started learning programming it was surprisingly difficult to find out how to make an honest and simple game. In fact, after reading most programming books, the only type of game you could make would be a Zork clone.

You are in a dank cave and you can see nothing, but you hear a walrus in the distance.

What do you do?

1. Look for the walrus.
2. Watch The Big Lebowski
3. Decide that the walrus is Paul.

This is not to knock Zork in any way! Zork is a clever, well written, and extremely well thought out game (even if my pseudo-quote isn’t). But in a world where we’re spoiled by moving objects, you want to know how to move and interact with something on screen. The problem is it takes a lot of different knowledge sets to get the job done. But in this post, you’ll get started learning how to make your very own Pong clone.

A Few Notes..

First, a few notes about setting up. I’m writing this tutorial from the Mac OS X perspective. However, everything we are about to code is, essentially, cross-platform. This is because, it is written using plaing old C, OpenGL, and GLUT. All of these things are themselves cross-platform, and therefore, can be compiled anywhere you have a C compiler (OpenGL and GLUT are just C libraries).

Setting up your environment

Mac OS X

For some reason, this always seems to be the hardest part whenever learning something new in programming. Fortunately, I found a great blog post that makes setting up XCode for compiling an app using OpenGL and GLUT very easy. Read all about setting up your XCode.

Windows

The process in Windows is actually a bit easier (gasp!) than in Mac OS X and there’s plenty of resources available on Google for getting setup. Here’s one in particular.

Linux

Here’s something unusual, you guys get a video.

Congratulations, the hardest part is done! In my next blog post. We’ll start to get knee deep in game programming concepts.

Update!

Part II is Up!