Pygrr - rendering and framerate (part 1)
This is part one of the "rendering and framerate" section of Pygrr. In the first section, I will describe what rendering and framerate is, and in the second, I will apply it to Pygrr.
Rendering - the act of drawing pixels on a screen. First of all, what's a pixel, and what's a screen? A pixel is a small light, in the shape of a 2D square. These are tiled along two axes, creating a screen. The screen is just a cluster of pixels, typically (like, seriously, who doesn't do this) in a rectangular shape. 1920 x 1080 is a typical 16:9 ratio, where the screen is landscape. That means there are 1920 pixels along the horizontal (x) axis, and 1080 along the vertical (y). That's a whole 2,073,600 pixels!
The white light goes through each segment, and only the light that's the same colour as the segment penetrates. These 3 channels of light then mix together. This is known as the RGB spectrum! (note that each pixel, and thus, the subpixel segments, are really tiny) By mixing different amounts of each colour, you can get a different colour output. Colours within the RGB spectrum are represented with 'Hex Codes'. These are small 6-digit bits of information written in hexadecimal (base 16), starting with a #. For example, the code #FF00FF is equal to magenta. The first 2 digits are red (FF), then green (00), then blue (FF).
Rendering - the act of drawing pixels on a screen. First of all, what's a pixel, and what's a screen? A pixel is a small light, in the shape of a 2D square. These are tiled along two axes, creating a screen. The screen is just a cluster of pixels, typically (like, seriously, who doesn't do this) in a rectangular shape. 1920 x 1080 is a typical 16:9 ratio, where the screen is landscape. That means there are 1920 pixels along the horizontal (x) axis, and 1080 along the vertical (y). That's a whole 2,073,600 pixels!
Let's go back a step, and look at how these pixels display a different colour. The monitor is 'back-lit', meaning that there are normal, white lights behind the pixels. Each pixel is a small square, split into 3 segments: red, green, and blue. They look like this (I made this on MS Paint, the best drawing software!):
The white light goes through each segment, and only the light that's the same colour as the segment penetrates. These 3 channels of light then mix together. This is known as the RGB spectrum! (note that each pixel, and thus, the subpixel segments, are really tiny) By mixing different amounts of each colour, you can get a different colour output. Colours within the RGB spectrum are represented with 'Hex Codes'. These are small 6-digit bits of information written in hexadecimal (base 16), starting with a #. For example, the code #FF00FF is equal to magenta. The first 2 digits are red (FF), then green (00), then blue (FF).
Why the letters and stuff? The hexadecimal system supports 16 characters - 0123456789ABCDEF. F is equal to 16, and 0 is equal to 0. If you have two hex-digits next to each other, you get a total of 256 different outcomes (16 times 16). This number is important as it's a binary number, meaning it fits into 8 ones and zeros! Computers like these numbers, because they're easy to store and read, 1 being an 'on' signal, and 0 being 'off'.
256 different outcomes for each colour. This means that the maximum you can get of each colour in this spectrum is 255, as one of the outputs is 0, meaning that the colour is completely blocked off. These 256 different colours mean that they equal only 2 bits in hexadecimal, with the whole colour (all three channels) equating to 6 bits, a very easy string for humans to read and remember!
FF is 255, and 00 is 0. I could explain how to convert hexadecimal to denary (our number system!), but that warrants it's own post, about binary and data... I might do that sometime, what do you guys think?
So, anyway, the string #FF00FF means 255 (max) red, 0 (no) green, and 255 (max) blue. Mixing blue and red together gets magenta, this colour:
256 different outcomes for each colour. This means that the maximum you can get of each colour in this spectrum is 255, as one of the outputs is 0, meaning that the colour is completely blocked off. These 256 different colours mean that they equal only 2 bits in hexadecimal, with the whole colour (all three channels) equating to 6 bits, a very easy string for humans to read and remember!
FF is 255, and 00 is 0. I could explain how to convert hexadecimal to denary (our number system!), but that warrants it's own post, about binary and data... I might do that sometime, what do you guys think?
So, anyway, the string #FF00FF means 255 (max) red, 0 (no) green, and 255 (max) blue. Mixing blue and red together gets magenta, this colour:
If you were to represent that in binary, in case you're interested, that is "111111110000000011111111". Not so easy to remember! If you want to mess around with different colours and seeing the hex output, click here (Google's built in colour picker). Pretty cool stuff! Now we understand how a still image can be rendered on a screen, by the computer choosing each pixel's channel occlusion (how much to block each colour)! However, what fun would a computer be if we could only see a still image forever?
This is where 'frames' and 'framerate' comes into play! Every frame, the computer refreshes the screen, recalculating all of the pixels. Normal monitors render at 60 frames per second, meaning that every second, the pixels are recalculated 60 times! With a monitor that's 1920x1080, and each pixel having three channels, that's a whopping 373,248,000 channel changes a second - or one every 0.0000000027 seconds... Wow - that's... A lot! This isn't even close to how fast normal computers run - you'd need to multiply this by almost 10 times (with a clock speed of 3.5GHz).
By doing this, the computer can display many images a second, giving the illusion of movement! Quite simple, although more complicated rendering than the programmer telling the screen what colours to make each pixel, will calculate each pixel that, let's say, a square model is on top of, and colour those according to the square's colour. Even more complicated will do things like calculating the percentage that the square covers each pixel by, and blending the colours accordingly. This creates what you normally see, if you look really closely at your screen (preferably not for too long, please!), you can see the edges of objects being blurred. This creates the illusion of perfect lines and angles!
Anyways, this about concludes part 1 of the rendering entry, until next time:
Isaac, over and out...
This is where 'frames' and 'framerate' comes into play! Every frame, the computer refreshes the screen, recalculating all of the pixels. Normal monitors render at 60 frames per second, meaning that every second, the pixels are recalculated 60 times! With a monitor that's 1920x1080, and each pixel having three channels, that's a whopping 373,248,000 channel changes a second - or one every 0.0000000027 seconds... Wow - that's... A lot! This isn't even close to how fast normal computers run - you'd need to multiply this by almost 10 times (with a clock speed of 3.5GHz).
By doing this, the computer can display many images a second, giving the illusion of movement! Quite simple, although more complicated rendering than the programmer telling the screen what colours to make each pixel, will calculate each pixel that, let's say, a square model is on top of, and colour those according to the square's colour. Even more complicated will do things like calculating the percentage that the square covers each pixel by, and blending the colours accordingly. This creates what you normally see, if you look really closely at your screen (preferably not for too long, please!), you can see the edges of objects being blurred. This creates the illusion of perfect lines and angles!
Anyways, this about concludes part 1 of the rendering entry, until next time:
Isaac, over and out...