Display mechanics, frames and scary stuff...
So development is full steam ahead and my a-head wants to explode. Not only I have to do 8-12 hours a day of boring J2EE development work but I now have to pass an exam for .Net development. On top of all this, I am postponing breathing to read about gamehttp://www.blogger.com/img/blank.gif development mechanics for the Android platform. Once you get my brain so stimulated as I just described is hard to catch any sleep hence the reason for this post. I fell in love with Beginning Android Games by Mario Zechner, also author of the libGDX framework.
Four chapters in I have absorbed topics such as the infamous game loop, display mechanics, double buffering, vsync, page flipping and many other weird sounding terms for those than have never touched a Development Environment. I must say that I've been flipping the switches of settings for these aforementioned terms for more than ten years and I have finally come to understand how these things actually work. I'm like a crackhead that just had his first hit and now my brain wants to know even more. Whats fascinating to me is how little the display methods have changed for the past 20 years but the technology has kept advancing. Its hard for me to put in words but it amazes me how much trouble you have to go through to make a moving image display properly on a screen without introducing weird artifacts. To put it oversimplified... video screens paint images at a fixed interval. If you're trying to send a moving image to a screen you basically have to keep sending the same image but with new position coordinates repeatedly. This creates the moving image effect. Here is the tricky part: you have to be careful not to move the image faster than the screen was able to redraw it. So you gotta keep track of when the screen is done drawing so you can send your next image with the new coordinates. This is called VERTICAL SYNCHRONIZATION or VSYNC.
Now, that's all great, you're playing nicely with the monitor or TV. You send the images to the display just right before the display is ready to draw. But what if you take too long to send the image? The display certainly won't wait for you and it will try to draw whatever he has readily available. If this happens you may get a flicker effect. What can you do to prevent this is being able to have ready images for the display to have ready for painting before he is finished painting the previous one. Usually with computer devices this is the case as our game will in fact be able to produce images faster than the monitor is able to draw them. So what you do is create a buffer. Now, your display has already a buffer which is the one it uses to put the image you sent to be drawn. This one is the front buffer. You will create another buffer called the, drum roll* back buffer! Now you have made yourself quite the double buffers. When ever your display is done drawing the image, you tell it to copy the back buffer to the front buffer. This is called BLITTING. This results in always having a smooth transition between the images being painted on the screen.
Copying the buffer is all good but there is always a better way. What the brilliant minds that came before us developed is a way to tell the computer to switch the front buffer with the back buffer. So instead of the monitor always trying to draw things on the screen from its front buffer what you do is point him to use the back buffer instead. This is much faster than copying the image from the back buffer to the front buffer as copying will take more time than just flipping a switch. Appropriately this is called... PAGE FLIPPING! <: 0
Okay okay... this is some good stuff... but I'm gonna tone it down before you OD in a pool full of hookers and blow.
For the most part, this mouth watering technical revelation has robbed me from any sanity as I keep devouring more delicious bits of game design theory and science. I hope to finish quite quickly so I can start implementing and breaking stuff and making a mess. Stay hungry. Never get bored.
Four chapters in I have absorbed topics such as the infamous game loop, display mechanics, double buffering, vsync, page flipping and many other weird sounding terms for those than have never touched a Development Environment. I must say that I've been flipping the switches of settings for these aforementioned terms for more than ten years and I have finally come to understand how these things actually work. I'm like a crackhead that just had his first hit and now my brain wants to know even more. Whats fascinating to me is how little the display methods have changed for the past 20 years but the technology has kept advancing. Its hard for me to put in words but it amazes me how much trouble you have to go through to make a moving image display properly on a screen without introducing weird artifacts. To put it oversimplified... video screens paint images at a fixed interval. If you're trying to send a moving image to a screen you basically have to keep sending the same image but with new position coordinates repeatedly. This creates the moving image effect. Here is the tricky part: you have to be careful not to move the image faster than the screen was able to redraw it. So you gotta keep track of when the screen is done drawing so you can send your next image with the new coordinates. This is called VERTICAL SYNCHRONIZATION or VSYNC.
Now, that's all great, you're playing nicely with the monitor or TV. You send the images to the display just right before the display is ready to draw. But what if you take too long to send the image? The display certainly won't wait for you and it will try to draw whatever he has readily available. If this happens you may get a flicker effect. What can you do to prevent this is being able to have ready images for the display to have ready for painting before he is finished painting the previous one. Usually with computer devices this is the case as our game will in fact be able to produce images faster than the monitor is able to draw them. So what you do is create a buffer. Now, your display has already a buffer which is the one it uses to put the image you sent to be drawn. This one is the front buffer. You will create another buffer called the, drum roll* back buffer! Now you have made yourself quite the double buffers. When ever your display is done drawing the image, you tell it to copy the back buffer to the front buffer. This is called BLITTING. This results in always having a smooth transition between the images being painted on the screen.
Copying the buffer is all good but there is always a better way. What the brilliant minds that came before us developed is a way to tell the computer to switch the front buffer with the back buffer. So instead of the monitor always trying to draw things on the screen from its front buffer what you do is point him to use the back buffer instead. This is much faster than copying the image from the back buffer to the front buffer as copying will take more time than just flipping a switch. Appropriately this is called... PAGE FLIPPING! <: 0
Okay okay... this is some good stuff... but I'm gonna tone it down before you OD in a pool full of hookers and blow.
For the most part, this mouth watering technical revelation has robbed me from any sanity as I keep devouring more delicious bits of game design theory and science. I hope to finish quite quickly so I can start implementing and breaking stuff and making a mess. Stay hungry. Never get bored.
Comments
Post a Comment