So as I mentioned in my Lacadia blog post, I've gotten a little side tracked and started a new project with particle systems in Monogame/XNA. The whole point of this project is to see how many particles I could have on the screen without falling below 30 fps. It was an interesting challenge, and it has definitely taken me places I did not expect to go. And by that I mean shaders. From my understanding, a shader is code that is run on your GPU with input from your CPU. So the big thing is take all of the computation and stuff you're doing on your CPU and does it on the GPU; it's much faster.
So in order to do this I had to learn about HLSL or high level shader language. It was pretty interesting to learn about actually! I hit a couple bumps in the road, but now I've gotten my shader working quite nicely. It can now do lighting, color fades, and color changes! Pretty cool stuff.
So let me take you through the events so far. I first start my project, using the same strategies I used in Lacadia for particles... I end up only being able to render ~2200 particles before I get down to 30 fps. Not cool! I don't quite remember how I found out about using shaders, but I investigated thoroughly, and after quite a lot of fiddling and learning, I was then able to get ~4000 particles rendering before 30 fps. You'd probably expect more, but I was actually making a really dumb error. So the way I was passing all the particles information to the GPU before was looping through each particle, and sending its information to the GPU, drawing it, then moving on to the next one... Well I ended up compiling all the vertices of the particles into a list of vertices, and sending them all at once to the GPU... HUGE increase in the number of particles.... I went from ~4000 to ~24,000 particles with 30 fps. 6 times as many! It was an awesome discovery! That puts me where I am today, and honestly i'm not quite sure what else I can do as of now to increase that number even more.
So what I've been doing lately, is investigating light sources with shaders, because I think I want my next game to have some sort of dynamic lighting, its pretty cool looking! So I've implemented a point light, that can have different colors of lights. I'll put the video down below as it's much more clear!
Hope you enjoy!
Sunday, January 19, 2014
General code readability, some class updates, and Render targets
I kind of got side-tracked since my last update for Lacadia. After I started fooling around with particles, I wanted to create a separate project for fooling around with particle systems and see how efficient I could make it. It's been really interesting and I'm going to start another blog about that... (I'm not exactly sure if you're supposed to have more than one blog but I guess I'll figure it out!) But I just got back to making some changes for Lacadia...
One of the biggest things I changed was the way the code was organized. Previously I had all my data for the current level, items, characters, enemies, etc. just sitting in my main Game class. Well I decided that wasn't very clear, and it was pretty ugly too, so I made a GameLevel class, and basically moved all the character, enemies, items, rooms, hallways, and other things into that, and in my main game class, I just call GameLevel.Update and GameLevel.Draw. I think it makes it a little more understandable. Another thing it allows me to do is have a reference to the current GameLevel without having access to the Game itself. So following that change I created a GameObject interface. A GameObject is anything that is going to be on the screen. So characters, items, chests, enemies are all GameObjects. A GameObject has a position, whether its removed or not (for instance if an enemy dies it sets this to true), a reference to the GameLevel it is on, and some other things. This allowed me to make A LOT of my code waaaaay more readable, and clearer as well. Now I'm not sure if this is a good thing to do, I don't really understand the whole use of private and public variables, but I'm guessing having your character be able to access all the enemies and item lists is probably a bad thing... I'll have to investigate some time.
Another thing I did was update some class mechanics. I'll put a video of these with this post, but basically I changed the whole Warrior attacking mechanic. Previously the warriors sword would follow the mouse, so you could "swing" it by moving your mouse in a direction. All I did was put collision detection on the sword and that was that. This caused problems and wasn't very fun though. You could just hold your sword still and enemies that were on top of it would die, which wasn't very fun. Also swinging it around with your mouse was kind of hard. So I got rid of it. I changed it so when you click, you swing your sword around you in a circle, and it damages all enemies it touches. It's still not quite satisfying when you attack with the sword because you can't really control which direction it goes in, but I think I have an idea to fix that.
The last thing I want to talk about is render targets. So along with fooling around with particle systems, I started investigating my memory usage and frame rate. I discovered that drawing the stats of your character and stuff on the screen was escalating my memory usage a lot and it was because I was creating these strings and then throwing them away, multiple times per second. So I wanted to find a way to only draw stats if they were updated. In come render targets. Render targets are basically like another drawing layer. You can draw on them, an then draw them on top of the main graphics. So I draw all the UI on this other render target, and then if it needs to be updated, I update the render target. It helped memory usage a lot, although I still should change those strings to string builders.
So that's it for today's blog post! Hope you enjoyed!
One of the biggest things I changed was the way the code was organized. Previously I had all my data for the current level, items, characters, enemies, etc. just sitting in my main Game class. Well I decided that wasn't very clear, and it was pretty ugly too, so I made a GameLevel class, and basically moved all the character, enemies, items, rooms, hallways, and other things into that, and in my main game class, I just call GameLevel.Update and GameLevel.Draw. I think it makes it a little more understandable. Another thing it allows me to do is have a reference to the current GameLevel without having access to the Game itself. So following that change I created a GameObject interface. A GameObject is anything that is going to be on the screen. So characters, items, chests, enemies are all GameObjects. A GameObject has a position, whether its removed or not (for instance if an enemy dies it sets this to true), a reference to the GameLevel it is on, and some other things. This allowed me to make A LOT of my code waaaaay more readable, and clearer as well. Now I'm not sure if this is a good thing to do, I don't really understand the whole use of private and public variables, but I'm guessing having your character be able to access all the enemies and item lists is probably a bad thing... I'll have to investigate some time.
Another thing I did was update some class mechanics. I'll put a video of these with this post, but basically I changed the whole Warrior attacking mechanic. Previously the warriors sword would follow the mouse, so you could "swing" it by moving your mouse in a direction. All I did was put collision detection on the sword and that was that. This caused problems and wasn't very fun though. You could just hold your sword still and enemies that were on top of it would die, which wasn't very fun. Also swinging it around with your mouse was kind of hard. So I got rid of it. I changed it so when you click, you swing your sword around you in a circle, and it damages all enemies it touches. It's still not quite satisfying when you attack with the sword because you can't really control which direction it goes in, but I think I have an idea to fix that.
The last thing I want to talk about is render targets. So along with fooling around with particle systems, I started investigating my memory usage and frame rate. I discovered that drawing the stats of your character and stuff on the screen was escalating my memory usage a lot and it was because I was creating these strings and then throwing them away, multiple times per second. So I wanted to find a way to only draw stats if they were updated. In come render targets. Render targets are basically like another drawing layer. You can draw on them, an then draw them on top of the main graphics. So I draw all the UI on this other render target, and then if it needs to be updated, I update the render target. It helped memory usage a lot, although I still should change those strings to string builders.
So that's it for today's blog post! Hope you enjoyed!
First post on blogger
So, I decided my little website just wasn't doing it for posts about my games anymore, I wanted to keep a devlog for my games, but didn't really feel like figuring out how to make a nice readable website by myself. So I've decided to move my updates and such here. If you want to check out my previous posts, you can go to my website and read about them (link will be posted at the bottom.) My website also has links to some videos I've posted demonstrating some of my updates to my game if you want to check them out too... From now on though I'll be posting later videos on the blog post itself. I may end up just moving the stuff i've already done onto here, but I'll decide that later.
devlog: http://clowman.net76.net/thoughts.html
videos: http://clowman.net76.net/videos.html
devlog: http://clowman.net76.net/thoughts.html
videos: http://clowman.net76.net/videos.html
Subscribe to:
Posts (Atom)