Episode 5 - Buffer Strategy

Key Takeaways

hey what is up guys My Name Is AO welcome to episode 5 of game programming okay so today we're going to actually do something really cool um well actually we're sort of not like we're going to explain some really cool stuff but we're not actually going to be able to get anything onto our screen really cool just yet just because I want to make sure that you guys um understand everything so what what we're going to do today is actually talk about buffer strategies or particularly you know graphical um buffering data buffering so at the moment we've got this window that we created last uh time and all it is at the moment is just if I run it you'll see um it it's just a just a window with uh you know running being printed over and over again in the console so we'll just delete this line of code because that was just for testing purposes um basically what's going to happen is while the game's running it's going to serve two two sort of parts of um of code is going to be repeated over and over again and essentially you you can divide games into into two parts right one one is like the logic of the game so in other words um you know stuff like calculations onto where you move um ex acceptance of like keyboard input events or Mouse events um I don't know processing uh where you shoot towards you know handling stuff like um multiplayer stuff for example like sockets and um networking anyway list goes on there's that part and then there's also the part of actually rendering Imes to the screen so in other words putting putting you know drawing the player onto the screen and the environment onto the screen so there's like a graphical part and then there's like a logic part now the reason that there's two different parts and we don't dump everything into say the rendering part like why can't we just say you know something like um huh something like I don't know do game for example why can't we why why can't we make a method called do game and that'll handle the rendering and like the logic stuff Allin one now the reason we actually cannot do that is because of timing issues everyone has a different computer right now and if I make a game for you guys and give it to you and tell you you know open up fraps and tell me what FPS you get tell me what frames per second you get on that game like tell me how you how your computer handles that game how that game performs on your computer you will all give me different numbers guaranteed every single one of you will give me a different minimum average and high on the on on an FPS Benchmark now the reason for that is all of you guys have different configurations one of you might have a supercomputer which runs this game at 1,000 frames per second and someone else might have a laptop or a netbook which is running at a 20 frames per second now the problem with that is like literally that is how games work if you see the number 1,000 frames per second what it's doing is it's actually you know completing all the code in the game 1,000 times every second it's calculating everything 1,000 times a second so in other words if we tell it okay let's move the player at a rate of 1 pixel per frame then we're going to be moving one pixel per frame but not per second because remember one pixel per frame frame that frame the amount of frames that your computer fits into one seconds into 1 second depends on the speed of your computer on the performance of your computer on this game so in other words to simplify this down to people who might might not understand what I'm saying is people with faster computers will essentially Run the game faster meaning that their character will move faster people with slower computers their character will move slower obviously that is unacceptable and we need to normalize this so so that we actually move at so that the player moves at the same rate no matter what he's playing on no matter if he's having 100 frames per second or or 1,000 frames per second the player obviously should still move at the same speed so to handle this we actually need a timer now we're not going to go over this now but essentially we need one part of the code which actually handles things like play of movement like logic like key and mouse input events control input events all of that stuff The Logical stuff the stuff that gets calculated and actually works out how much you know animation for example how much something moves that's just one example of it as well there's tons of stuff um related to that and then we need one part of the game which actually is unrest which can run at 1,000 frames per second and that handles the rendering so in other words we split this up into two different methods one is called update and this update method sometimes is referred to as tick okay tick an update it depends on how you want to call it a lot of game programmers not just Notch call um call their uh methods tick instead of update that's quite a convention um I prefer to call it update personally I've sort of mediated over the years um I called it tick for a while just because tick was shorter and sort of you know you you could say tick and stuff like that and it would work more than um updated but um I've sort of gone mainstream and going to update now and then there's the render method so these are two methods that we're about to create called update and render now the update method is going to handle all the logic it's basically going to update our game and the render is going to actually display images to our screen now update we will restrict to running 60 times per second uh in the future and render will be unlimited so in other words as we'll be rendering as fast as we can but updating not as fast as we can we'll be updating at a specific speed to uh to ensure consistency through out um computers um all right so we'll create these two methods now simply by typing public void they'll both be they'll both be void public void update that'll be the update method which we're not going to talk about today or do anything too you can see that the uh error goes away because we've actually created that method um and then we'll make public void render and that's where we're going to spend most of our time at today so the random method is as you can imagine handle rendering now we're going to dive into buffering today and we're going to take this slow like it's probably going to take us two 3 days so that means two to three episodes maybe even four episodes to actually finish this random method and actually get a black box onto the screen or a colored box whatever um because I really want you guys to to know the process behind why this works and how this works not just um what what code you need to write so to start off I'm just going to create a buffer strategy essentially that's all I'm doing here I'm creating creting a buffer strategy now what is a buffer first of all and again I know there's like I don't know a lot of you sitting there being like Oh are are you kidding me this guy's going to explain what a buffer is Chill okay I know that some of you are very very smart and you you already know all this stuff and some of you do not okay there's half of you literally saying you know skip over the boring stuff I already know it and then there's the other half of of you going do this this is great I'm I'm learning so much so just chill all right seriously there's like this huge war going on on Reddit um as to the speed that I have to explain things so in other words it's better to explain everything and satisfy everyone than to explain half the stuff and only satisfy half of you so just chill all right so what is a buffer a buffer you can think of a buffer pretty simply it's basically like a temporary storage place all right so when we CC calate something we don't necessarily need to actually apply that data straight away we can just we've calculated it great let's put it onto like the ready list and then you know when we actually need that data we can we can grabb it so in other words what we're saying is we've rendered an image right now it's already it's already done the image is completely rendered we're ready to put it onto the screen but we don't need to yet because we've rendered it but like we're still on the previous frame we need we need to actually store that that that frame somewhere now the best way to explain this um is probably just to show you guys now incomes paint.net um and those of you who have been long long-term subscribers of mine uh probably um you know see me use this all the time in my 3D game programming series cuz paint. net is it's really good for explaining things um think of it this way right this is our screen this is the computer monitor um and this is uh this is embarrassing that's just made it even worse doesn't matter um this is our this is our computer screen right so when we're rendering things we can't actually render it live what you might think is happening and again this is happening very very fast remember because most games to be actually really smooth and playable um need to run need to run it at at least 30 frames per second if not 60 frames per second for more like twitch Shooters like first person shooters and stuff like that this is happening like a lot of times this is happening like 30 to 60 times a second minimum so it's happening very fast you can't really see um the rendering going on but we can't actually render it on onto the screen because what happens is when your computer renders things it it goes It goes It goes like one by one by the pixels it fills up every pixel with the appropriate color um and thus you know that makes up an image now the problem the problem is that if we're doing this live what you'll actually see is a black screen and then you know every pixel being updated live now that's a problem because that results in as you can imagine graphical issues we're seeing an image being updated one by one because the computer's going going ahead and being like all right this color used to be blue now it's red let's change that oh it's red now um and the problem with that is that that you know that's happening live in front of our eyes and we don't want that to happen we sort of want to H want want that to happen behind the scenes we want to be able to calculate the color of every pixel on our screen store it somewhere you know as a buffer and then you know when we're when we actually advance to the next frame we pop that image in and wow look at that we've already got an array of pixel colors worked out for us we just need to actually display them and that's what the graphics card does so in other words what we're saying is that rendering right okay first of all I know half of you probably screaming right now um we're not going to be using the the graphics card to render all right this is going to be pure Java we're not going to use openg we're not going to use anything I will create a series in the future using opl just not right now it takes a long time to explain I don't have time right now and I find that especially for people who are new to game programming openg is a horrible way to go you want to learn how to do it from scratch you want to know how how computer Graphics work first and then you can dive into opengl for Hardware acceleration and to actually get the graphics card to process and render pixels not not in this series so um we're only using the the graphics card to actually display the final image onto the screen not to actually compute process calculate render the actual images so just no no we're not doing that um yeah these episodes are getting longer and longer so uh I need to get back to work um quickly though um all right so essentially we don't want to have um it rendering live we want like I guess we want like a here we go this might help um essentially what we want is like we want a temporary storage place where we can work all this out and then suddenly we'll be like all right this frame's up it's we've already worked everything out let's pop it into our screen now it's ready it's computed it's calculated everything's fine now the thing is we actually need to create a place for this to be in our computer's memory right in our Ram we want to create an area called a buffer strategy really um to actually store this thing we need to create a buffer because essentially what a buffer is again is it's it's a temporary place for storage right a data buffer is it's it's a region of physical memory um which can temporarily hold data while it's being you know moved from one place to the other so this will only be here for like maybe 160th of a second but it needs somewhere to be um and we need to create that that area so we can do that simply by first of all uh drawing on Java's buffer strategy objects so buffer strategy we we'll just call it BS right short for buffer strategy um and then we'll set that equal to Simply get buffer strategy now remember where um and then let's import buffer strategy obviously okay now remember we're actually extending canvas here so what canvas comes is with its own pretty much buffer strategy so all we need to do is just simply retrieve the buffer strategy of our canvas object which is our game class now cuz it's a subass of canvas we need to retrieve that that um that data and simply apply you know the current buffer strategy that we already have because we're extending canvas we just need to actually be able to manipulate that now so we um create an object called BS so that we can actually access um the buffer strategy so we've we've got the buffer strategy now um like the buffer strategy object I guess of the canvas class now we need to actually create it so we've we've got it we're able to manipulate it we have to create it now so the reason the the thing is right this is being this is being called remember it's in a wild running Loop this is being called this method uh like 60 times a second oh sorry more than 60 times a second as many times per second as we possibly can cuz it's in the render method we don't want to create buffer strategies every time we actually render that's no literally we only need we only need to do that once so what we can type is is a simple if statement right really simple if buffer strategy if BS if this if this object is equal to null then create Buffet strategy and then we'll put three in the uh in the parameters and I'll explain all this in a second and then we need to return so what this is doing is it's saying that if if the buffer strategy kind doesn't exist right because buffer get buffer strategy is returning null for some reason which means it is returning nothing because get buffer strategy is equal to null it hasn't been created yet um andang on a minute yeah so you can see that what that does is Returns the buff strategy used by this component and this component being the uh the canvas class so if if the canvas class is returning null for the buffer strategy because it hasn't been created yet then we execute this code which is we create a buffer strategy with triple buffering and then we return so in other words we get out of this method Now quickly create buffer strategy creates a buffer strategy yeah pretty pretty self-explanatory now the three now the three the number inside here it seems to be um very important in off a debate you pretty much always want to have it at three there are very few if any circumstances where I would recommend you leave it at two for example for just standard double buffering three is the number to go now I'll explain my reasoning for this first of all what what we want to do what we need to do is multiple buffering right because with with two right if we put two here essentially we're saying right so there's this there's this area and then there's the screen so we calculate here and then we and then we we put it right to the to the screen now if we put three here what we're saying is that oh hang on a minute we've got another area we've got triple buffering now what we've got is is like another another like a midpoint almost so in other words what what can happen is if our computer actually manages to render a few images at once for example uh I don't know if we have multiple um CPU Cordes all of that stuff if we actually have time to start rendering a third image we can actually store two images in memory right because what happens is we can actually you know if if we were using double buffering we would actually our program would actually have to wait until this this image is displayed to the screen before we can start rendering the next one now with with triple buffering that's not the case because what happens is there's two back buffers and they can immediately you know start drawing the next one um which basically gives us a speed Improvement because we can actually work we can actually start work on calculating the next frame before our our backup frame is displayed so I'm not going to get too too much into this but I guess another way actually real quick um let's go 800 by 600 um another way real quick to say this is let's just say we've got um oops we'll go black and there's no black in the default presets that's weird Okay um we've got this is the screen I should probably show the screen in like green this is the screen all right and then this is our back buffer so what happens is this is the image this is the image that's displayed on the screen and this is our back our back buffer it's like our um you know our place to calculate the um the the next frame now if we've got another one what can happen is this is the image currently being displayed and we've already got two waiting in the background so essentially instead of just waiting we can instead of just having our computer wait to display the next image um it can actually start work on the second one so instead of just the the process are going completely idle for a few milliseconds or even nanc and we'll keep it at milliseconds um instead of the the processor not doing anything for nanc or milliseconds it can actually start work on a third one meaning that um that will be ready and you'll actually be able to um have two things ready so in other words what we're doing by creating a triple buffering strategy and I'll just get out of that is again it's just going to be a speed Improvement it's going to be as simple as that it's just going to let us let us have three buffers which um yeah which is just going to help us out now in case you guys are wondering well if three buffers are so good why don't we just go up to 10 or four or something there's there's pretty much no advantage in doing that I'm just going to tell you straight away that's not going to actually um give you any real world results in which you have a much faster thing so keep it at 3 that's honestly going to be as simple as that hope you guys um are just still something out of that um and tomorrow we'll uh we'll continue on with this so I'm going to go back to studying right now cuz uh that was a lot of time I just wasted well I wouldn't say wasted but um a lot of time I just spent so yeah anyway I'll um I'll see you guys later I'll see you guys tomorrow [Music] bye [Music]