olc::PixelGameEngine 2.0

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

This post appears to be a direct link to a video.

As a reminder, please note that posting footage of a game in a standalone thread to request feedback or show off your work is against the rules of /r/gamedev. That content would be more appropriate as a comment in the next Screenshot Saturday (or a more fitting weekly thread), where you'll have the opportunity to share 2-way feedback with others.

/r/gamedev puts an emphasis on knowledge sharing. If you want to make a standalone post about your game, make sure it's informative and geared specifically towards other developers.

Please check out the following resources for more information:

Weekly Threads 101: Making Good Use of /r/gamedev

Posting about your projects on /r/gamedev (Guide)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

👍︎︎ 1 👤︎︎ u/AutoModerator 📅︎︎ Apr 15 2020 🗫︎ replies
Captions
hello in this video I'd like to introduce the one loan coder pixel game engine - and I'm going to structure the video in the following way I'm going to talk about the new features I'm going to talk about why there's been a bit of a shift in design philosophy and then I'm going to show some examples but I do want to make it very clear from the beginning that pixel game engine 2.0 is fully backward compatible with pixel game engine any other version so I know many of you have got projects and have started to use the pixel game engine don't worry you can just drop this header in as a direct replacement and start to take advantage of the new features I first created the pixel game engine about eighteen months to two years ago it was an upgrade of the one line code at console game engine and it was developed purely as a tool for me to visualize algorithms to help me make videos during that time it's both been really pleasing and quite humbling to see quite a number of people have now adopted the pixel game engine as their preferred platform of choice for creating their own demonstrations and applications and whilst on the whole the response has been very positive there have been a few criticisms about its speed when it comes to drawing sprites particularly high resolution sprites which some users have felt has impeded them from really realizing the full potential of what they wanted to create so I hope this update goes some way to addressing that problem the pixel game engine has always strived for simplicity and it's a single header file include into your project to get working and if we have a look at its major features the first thing it will do is create a window it then provides rudimentary drawing algorithms for drawing pixels on the screen and there are quite a few different functions for this you can draw circles rectangles lines and triangles you can also load images as sprites and there are functions for loading sprite assets drawing them to the screen and scaling and manipulating them in various ways there's also a basic functionality to draw text and drawing all of these things is all well and good but if you can't interact with it you don't have much of an application so it can also handle basic keyboard and mouse input critically it can do all of these things cross-platform and it'll do all of these things without requiring the user to install any additional frameworks its standalone from an end-user perspective there are really only two things the user needs to do and that is provide an implementation of a function called on user create which is called once at the start of your program and then on user update which is called every single frame and the pixel game engine will run as fast as it possibly can trying to draw as many frames to the screen as possible and I believe this is a formula that works people do seem to be using it and people seem to be using it successfully and I think when people do use it they're often surprised that it really is no slouch with frame rates in the hundreds if not thousands of frames per second typically achievable after surveying a lot of user feedback it would seem there are typically two common complaints the first involves sprites the pixel game engine handles sprites very well but if you've got alpha blending or you want to scale or rotate or in some way distort the sprite that can become very computationally intensive and whilst I applaud the efforts of those that have gone to great lengths to micro optimize their sprite rendering algorithms to get every single last cycle of performance out of it that's not an option that's available to everybody the second highlighted area is a candidate for improvement is the cross-platform nature now I've always ensured the pixel game engine will run on Windows and Linux with a basic development install but it seems people want to port it to other platforms and in its current form the pixel game engine one point whatever is not that easy to modify to adapt it to new platforms one of the reasons sprites are a little slow is that the pixel game engine is pretty much entirely CPU bound yes it does use OpenGL in the background but all of these drawing functions and sprite drawing functions are fundamentally CPU operations where the CPU copies memory from one surface to another if the sprites are pixel and axis aligned and have no additional computation other than a then that's quite fast too but that's quite restrictive in terms of game development and so for pixel game engine 2 we're going to leverage the graphics capabilities of your computer a little more by introducing a new fundamental primitive the decal which I want us to consider as a non persistent sprite and fundamentally decals live on the GPU so what exactly does non persistent sprite means normally when we draw a sprite it's drawn into a memory surface which represents the screen the pixels of the sprites are copied directly into that memory so if you draw it it's it's persistent into the frame after and it will stay there until you explicitly remove it or raise it or overwrite it a non persistent sprite is slightly different it exists only for the duration of that frame because it is never directly written into the frame it is layered on top of it from a technical point of view this has quite a number of advantages it means I can let the graphics card completely handle the rendering of that sprite object one of the downsides is you can't interrogate the memory afterwards to see whether one of those spike pixels was set but in my use case so far and I've not really observed any of the community doing it not many people actually assess the pixels they've drawn on the screen I think the only use case for that would be for doing some sort of pixel perfect collision detection and there are invariably better ways than just testing points on the screen to do that so let's have a quick look at creating a decal and drawing it to the screen and I'm going to go through the code pretty quickly in this video I'm starting by using the now-familiar standard basic pixel game engine application where you override the pixel game engine base class and you provide the two functions on user create a non-user update in my main I'm creating an instance of this derived class and I'm telling it to construct a pixel game engine with a 640 by 480 resolution where each pixel game engine pixel is two by two screen pixels and then I start the engine you can click the little link above for a video of how to install the pixel game engine in Visual Studio environments but it's very simple I'll start by creating a pointer to a sprite and we need the sprite because that contains the image information and in on user create I'm going to load that sprite a decal is the new type of object and OLC decal and again I'm creating a pointer to it decals need to be given as sprite as a source of the image information so when I create my decal in on user create in this instance I'm passing in the pointer to the sprite behind the scenes this has the effect of downloading the sprite directly to the graphics card if for some reason I changed the sprite and don't forget with pixel game engine sprites you can actually draw to them and manipulate them then I'll need to re-upload the sprite to the graphics card and I can do that via the decal update function in on user update I'm going to do some rendering first thing I'm going to do is clear the screen and I'm going to clear it to very dark blue and just to make this demonstration a little bit interactive I'm going to grab the mouse position on the screen if I wanted to draw the sprite at the mouse location I would call the draw sprite function pass in the position pass in the sprite and we're done we can run this there we go it's a very large sprite this tree relative to our screen we can see the frame rates about 100 frames per second however the sprite should have a transparent background normally if we've got transparency in the sprites we would change the pixel mode accordingly and I always advise if you do change pixel modes always set it back to normal when you're finished because doing this alpha blending calculation per pixel is quite costly so let's have a look now so now the sprite is rendering accurately but we've dropped down to about 45 frames per second and that's because it's a very large sprite I can't scale down a sprite in the pixel game engine because then I would have to choose a particular sampling algorithm and there are several and they all have their different advantages and disadvantages instead of drawing the sprite I'm now going to draw the decal equivalent and to do this we use the draw decal command again I'm going to pass in the position and I'm going to pass in the pointer to the decal I don't need to specify a pixel mode when I'm drawing decals if the sprite has alpha in it it will be used regardless so let's take a look while here we've got the same end result but the frame rate is now 3500 frames per second so hopefully it's obvious that by moving to decals we can really improve the performance of our applications the draw decal function has some additional arguments we know the sprite was very large so let's scale it to about a fifth of the size I can do that by passing in a Noel CBF 2d which is what's this results to that's better we can see the whole sprite now and rather ironically our performance has gone up we're now 3700 frames per second the final argument when drawing a decal and both scaling and this argument of optional is we can also supply a tint by default it's tinted to white but let's say I wanted to tint the sprite red we've not sacrificed anything in terms of performance but we've now changed the nature of the sprite and in fact we can tint it to any particular color by just passing through an OLC pixel so if I wanted it to be all red and all green but no blue so we're technically tinting it yellow and I can also specify the amount of transparency as well so a little bit tricky to see but it's a little more yellow than the original sprite let's just play with that transparency value so I'm going to set that to be quite low and of course it blends with the dark blue background but it's more transparent and it yet again we have not sacrificed any performance in doing this so decals are really a fast way of rendering sprites in a flexible manner I've also provided a function that allows you to draw a decal rotated so here I'm going to add a variable to just keep track of an angle that will change over time and I'm going to call the draw rotated decal function and again we need to pass in a position I'm going to put it where the mouse cursor is I'm going to pass in the decal itself then I need to specify the angle each frame I'm going to increase my angle by F elapsed time just so it changes and so we can see the sprite is well it's large again and it's certainly rotating even though it's large and it's rotating we've not yet taken a performance hit but it would be more useful if it rotated in a place that we understood right now it's chosen the top left of the image I'd rather it rotate around the center of the sprite so the next argument in draw rotated decal allows me to specify precisely that center position and here I'm specifying it as a vector and I'm using the source sprite to get its dimensions to tell me where the center point of that sprite is all of these vectors and positions are in pixel space were not working with normalized coordinates here and as before with the standard draw decal function I can also provide scaling and tinting options so I'm going to scale it back down again so there we've got the sprite now rotating around wherever the mouse cursor is if you're familiar with sprite sheets or atlases sometimes you want to just draw from a particular source rectangle in that sheet and you've always been able to do that in the pixel game engine with the draw partial sprite function in exactly the same way I've also provided a draw partial decal function but I'm not going to demonstrate that here there is one final decal drawing function which I think people will use in abuse to great effect and to demonstrate it I need to throw in a little bit more code so I'm going to add in a standard array of 2d vector types and that's going to hold four of those 2d vector types it's called points and I'm also going to add in a raw pointer to a particular vector and it's going to be one of those locations in that array in my own user create function I'm going to populate those points with some dimensions now I did promise I will rattle through the code quite quickly but I'll upload it to the github so you can explore it on your own later I'm going to check to see if my current mouse location when clicked exists in the vicinity of one of those points on the screen effectively this allows me to select that particular point and move it around the screen with the mouse and to help the user know where those points are I'm just going to iterate through the array and draw them as filled in circles with a radius of four and this allows me to demonstrate the final decal drawing routine which is draw Warped decal and here we pass in the decal that we want to draw and we pass in our array of four points and you can pass that array in in various ways so let's take a look so here we can see this sprite and in the corners of the sprites are four circles and I can use my mouse to click and drag one of these four circles around and the warping drawing technique allows you to add artificial perspective to your sprites and again you'll see there is minimum performance loss in doing this the four points that we pass in are the four screen positions the way you want the sprite to appear and you can even do some funky things when you start passing in invalid point sets I'm sure some people might find a use for that but I'm not so sure yet I can see this feature being used for animating sprite slightly so if we wanted the tree to slightly blow in the wind we could just manipulate these top two points we can also change what the sprite looks like so if I wanted it to be slightly more cartoony I can specify the points that's so now whenever I've created a new bit of Technology and made a video about it invariably I find a way to destroy the YouTube video encoding algorithm and so this code does exactly that I wanted to see how many sprites we could really throw at the rendering system so here we've got the pixel game engine - logo pulsating in the background it's just being drawn with an alpha that changes we see the framerate at about 700 about 800 frames per second so I click the mouse we're going to throw a random assortment of sprites into the screen we're going to tint the color and we're going to scale them as they bounce around and I'm going to keep doing this now most people's accepted standard a frame rate is about 60 frames per second and I think if you get to a point where you can render several thousand fully transformed tinted scale and alpha blended sprites that you're probably doing okay you can see around the edge here I've got them alpha blended depending on the x coordinate so that's why we get this softer fuzzy edge here so none of these sprites are being deleted yet they're still just bouncing around even though they're being drawn on top of each other and that's an important point to make that decals are drawn on the screen in the order that you draw them in code so if they automatically apply the painters algorithm they're not sorted in any way now in the Edit I'll speed up and slow down bits of this video and clicking awhile to get to a large number but it's fun to watch so now we've reached a situation where occasionally we're dipping to about 60 frames per second and as you can see it's drawing about 22,000 sprites these are fully transformed and illuminated sprites I think that's probably going to be enough for most people but of course your mileage will vary depending on how you use the application in this case my physics is very simple it's just bouncing off the edge of the screen as you add more complexity to the game cause your sprite budget will diminish so hopefully I've demonstrated that by using sprites directly on the graphics card in the form of decals we can achieve significant performance upgrades I'd like to talk about the next feature of the pixel game engine which is the concept of layers and these are entirely optional but some people might find them useful to organize their rendering the pixel game engine has always assumed that the screen is the primary drawing target its top left is 0 0 and down here we've got screen width and screen height in pixel dimension - this is now considered layer 0 and layer 0 always exists however sometimes it's useful to have additional layers and so now you can do just that and layer 0 will always be at the front so if we added another layer we would have layer 1 which is the same size as layer 0 but exists behind it and we can actually have many layers layers can be used for conceptually grouping various stages of your rendering so for example you could have in layer 2 here right at the back a mountain scene layer 1 could be where all your game is happening and layer 0 could now be some debug overlay or a heads-up display all layers except for layer 0 can be toggled on or off they can also be tinted in their own right so if you wanted to change the overall tint of everything that's drawn in that layer you can specify that explicitly you can also offset a layer so it's not necessarily drawn at the 0 0 location relative to layer 0 the top of the screen one of the advantages of a lair is there a little bit intelligent once you've drawn to a lair it costs nothing more to render that lair so let's say your game has a static background of a mountain scene you could draw that into the lair in on user create and then it's done you don't have to worry about it again this means you could save those valuable cycles of having to redraw the whole screen every single frame I will point out that there is nothing that layers bring that is new that can't be also achieved with decals so they are more of a conceptual organizing tool in the fact that you have things grouped together and you choose different layers using the set draw target method so you can now you set draw target to target sprites or layers let's have a quick look at adding a couple of layers to our demonstration application to demonstrate the layer I'm going to draw the pixel game engine to logo in the background so I'm going to load the logo as a sprite you know I'm usually create explicitly load that sprite I'm not going to create a decal of the logo but I could and choose to render that first instead I'm going to draw that logo into a layer of its own layers are identified as integers and I will ask the pixel game engine to create a layer for me it returns the ID so they need to be created in the order that you expect them to be rendered remember layer 0 always exists and that's always at the top of the layer stack I will explicitly target drawing to that layer only with the set draw target function and now we just treat it like a standard pixel game engine rendering process will clear all of that background to white and then going to set the pixel mode draw my logo sprite in the middle of the layer and then I'm going to enable the layers this will tell the pixel game engine that yes I do want you to draw this layer when it's appropriate and then I'll specify set draw target null pointer you can also specify zero here now what's quite important is we've just drawn into the layer here the logo but that was layer 1 but layer 0 which is our default the first thing we're doing is clearing everything to very dark blue so that means we won't see anything in the layer behind this layer zero so instead of clearing everything to very dark blue I'm going to clear it to blank because we want the transparency of this layer to allow us to see the layer that's underneath it other than that it's going to carry on allowing us to warp the tree sprite let's take a look no we can see the logo in the background just move the tree out of the way and yet in our own user update function we never explicitly draw that logo it is now cemented there as part of the layer in the background and we can of course tint that layer also whether you use layers or decals it's entirely up to you I think in the future I might add in some additional functions to handle automatic blending between layers in interesting ways such as perhaps additive transformations that kind of thing anyway that's it with the new graphical features one of the things I want to talk about now is what's really changed behind the scenes in the pixel game engine to make it far easier to port to other platforms and systems in the original pixel game engine you were presented with an interface and throughout that interface scattered all over it were lots of little hash if deaths and that was to handle compatibility between different platforms and what we would see is in this part of the code you'd have something for Windows and then in this part you'd have something for Linux and then maybe a bit of Windows here and then a bit of Windows here and then a bit of Linux here and some Linux here and some windows here and even possibly some code blocks specific things here so there were all these little fixes and patches just to make it work on different systems as the pixel game engine has developed in sophistication this has become quite tricky to maintain and makes the code somewhat unreadable so the pixel game engine too has been pretty much a complete rewrite to abstract away this complexity and so there's a bit of a philosophical difference now between what the pixel game engine actually is the PGE core itself is now a genuine application programming interface it's what defines all of the drawing functions and how they are used for the end-user and it sits on two additional module the first one handles the platform and the second handles a renderer the platform and the renderer can communicate with each other so this means there is absolutely no platform specific or render a specific code in the pixel game engine to API for the platform you can provide different implementations and so far I've got one for Windows and I've got one for Linux some of the guys on the discord server are also looking at building one frame scripting which is effectively WebGL so it'll allow you to run it in the browser and of course I would really like there to be one for Apple I don't have access to a Mac computer so it's very difficult for me to develop that one in much the same way the renderer module abstracts away whatever rendering technology your system is using so by default the pixel game engine and some of you will giggle at this if you didn't already know use the OpenGL one if you wanted to play around with pixel shaders or use the pixel game engine as a general-purpose opengl interface we are currently working on an OpenGL 3.3 implementation and in the pipeline we're hoping to have an OpenGL es2 implementation we should make migration to Android devices and potentially the inscription platform a little easier but there's nothing stopping anybody coming up with the DirectX implementation and indeed I know that somebody did that for the pixel game engine one and sure why not for the hell of it somebody I'm sure will come up with a Vulcan implementation because they're masochistic now it may be the case that a particular platform requires a minimum style of renderer and so those small details need to be worked out but the idea is that through encapsulation we've now really simplified the process of porting the pixel game engine to different platforms the API never needs to change in order to accommodate the different platforms underneath so that's it for the major technical descriptions of the changes between pixel game engine 2 and its predecessors I hope you'll find something useful in that now I wanted to also produce some sort of demonstration to try out all these new features for myself and I started off with this I wanted a simple scene that demonstrated some parallax scrolling and lots of rendering so all of these blades of grass that are blowing in the breeze here are rendered separately and I can actually change the time of day slowly although we can see it changing at the top that changes the tinting required so here comes the Sun the Sun is a regular fill circle and I changed the tint on two layers of cloud sprites so I can change the underside and the top side of the sprites differently and I also changed the tinting on the landscape at the front so all of the blades of grass that are rendered as decals are tinted accordingly and then as it goes into nighttime we change the gradient in the sky in the background and we start to reveal some stars and of course night passes and the Sun starts to rise again this time going through a different color sequence to sort of emulate dawn but then I thought I'm not thinking big enough and so I thought I'd try a little bit harder why not take advantage of the tinting to handle lighting conditions properly why not take advantage of the fact we can draw many thousands of sprites to draw every single blade of grass why not take advantage of decal warping to handle perspective [Music] it's not a perfect demonstration by any means but we can see that the graphical user interface hood in the front is a layer on its own we've got a background layer handling the mountains in the distance and the color of the sky and we've got a main game layer we can see objects that come too close the camera can become transparent so we don't lose sight of the player we can also render very large worlds too so I move my camera upwards I can pan around the whole world and it's a very populated world of learning this little forest and we can see in the background the world kind of popped into view anyway I hope you enjoy the updates to the pixel game engine in the form of PG e 2.0 like with any new software I'm sure there are going to be bugs that will find and hopefully will get them changed very quickly [Music] I look forward to seeing all of your wonderful and crazy projects over the next few months like with all new software they are probably going to be bugs and things that we'll need to fix and find and I'm hoping that the community might get involved in sourcing someone throws out anyway if you have any trouble come and have a chat on the discord server if you've enjoyed this video a big thumbs up please to keep me going and I'll see you next time take care [Music]
Info
Channel: javidx9
Views: 143,290
Rating: 4.9820929 out of 5
Keywords: one lone coder, onelonecoder, learning, programming, tutorial, c++, beginner, olcconsolegameengine, command prompt, ascii, game, game engine, pixelgameengine, olc::pixelgameengine
Id: 8OfgGUGP4Vc
Channel Id: undefined
Length: 29min 15sec (1755 seconds)
Published: Sun Apr 12 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.