Snowy (December 2013)
One of my modules for MProf is called "Programming games" although it basically boils down to graphics programming with DirectX 11. Our coursework was to create an application that displayed various basic graphics capabilities. I decided to go for particle effects because it was something that I hadn't done before.
While living up in Scotland has put a foul taste in my mouth regarding snowy weather, I decided to go for a snowy scene because I think that is more interesting than a rainy one (which is the typical go to particle effect outside of compute shader demos). While I had the whole semester to work on this project, having done a DirectX 11 application for my honours project, I wasn't too worried about picking it up again and instead concentrated on making sure my other modules were up to scratch, specifically the semester 1 game which took up nearly all of my time.
When I did finally get around to making a start, I realised that I'd perhaps underestimated the work involved. I started building the core part of the framework: setting up a wrapper for the Windows API and another for the DirectX API. From there I created an input class. In all my previous self created projects, I've never had decent input. I wanted a class that informed me of whether a key had just been pressed and similarly if it had just been released. While I can know through the Windows messaging system whether a key has been pressed or released, I wanted a more robust method that allowed me to check the state of the key. To do this (as well as avoid branching for every key) I used an enumerated type to represent the different key states: up, pressed, down and released and twiddled with the bits so that if a key's state is either pressed or released, then it will fall to down or up respectively. I was pleased with the results and the next step was mouse input. Similar to failing to have key states (which resulted in horrible hacks such as time delays to stop multiple key presses), I hadn't had a properly controlled camera. The best attempts I have simply use the arrow keys to control the rotation of the camera. I've had attempts in the past at a mouse controlled camera, but usually the drag just isn't calculated correctly (as simple as it should be). As such, I made a conscious effort this time. It's still not perfect, because it is updated through the messaging system, it doesn't update every frame and thus is a little jagged. I wanted to avoid as much branching as possible which is why I went through the messaging system as that drastically reduces the branches in the program however, while it is sufficient for the keyboard presses, I probably want to try a different method that queries the mouse pointer every frame for higher fidelity.
This initial work was done with about a month before the deadline, which was still more than enough time to complete the project. As I mentioned in my blog post, it was great to go back to lower level coding after scripting for so long. I'm still sure that gameplay programming is where I want to be, I love being able to control how things interact in a game, but it's definitely a hobby of mine to core parts of programs, it goes back to my love of knowing how things work. While I had the core part of my framework down to get a start on creating an application, I was actually delayed as my other modules required urgent attention. It wasn't until my Xmas break that I properly got a start on the coursework which left three weeks to create the application (as well as write a supplementary report).
I describe the process in more detail in my blog post, but the bottom line is I'm quite pleased with what I managed to accomplish in what was essentially 72 hours work. It was fun doing the particle effects, my work on the tessellation stages certainly helped speed up learning how to use the geometry shader. I was also really pleased with my particle emitter solution, while it's no doubt been used countless times in many variations, it was something I designed and created myself which is why I'm proud of it. I was happy enough with the snow popping in but the fact I have it blend in and thus making it seamlessly fly in was awesome. Similarly, I was happy enough with a static fog but given it required no extra computation to make it move based on the intensity of the storm I had to add it in.
I would obviously have preferred to have proper assets in the application, the framework would have been able to support such. However I think the programmer art for the guy you have to save is actually pretty amusing, similarly I crack up at my attempts at wind and helicopter noises.
While I'd struggle to honestly label it a "game", the application is something I'm happy with as I think it does a good job to show how much I can do, and learn, in a short space of time. I enjoyed creating particle effects, in semester 2 is the second stage of this module which is to use more advanced features. I could use tessellation, but given it wouldn't be anything new, I will look elsewhere. I've also done post processing previously however I don't think I'm as strong on that process as I could be, additionally I've still yet to use HDR lighting which is something I really want to do. I may also look at compute shaders. As a space geek, I obviously love seeing n-body demos and if I was able to create my own I'd be over the moon.
To see a run through of the application, head over to my Vimeo.
While living up in Scotland has put a foul taste in my mouth regarding snowy weather, I decided to go for a snowy scene because I think that is more interesting than a rainy one (which is the typical go to particle effect outside of compute shader demos). While I had the whole semester to work on this project, having done a DirectX 11 application for my honours project, I wasn't too worried about picking it up again and instead concentrated on making sure my other modules were up to scratch, specifically the semester 1 game which took up nearly all of my time.
When I did finally get around to making a start, I realised that I'd perhaps underestimated the work involved. I started building the core part of the framework: setting up a wrapper for the Windows API and another for the DirectX API. From there I created an input class. In all my previous self created projects, I've never had decent input. I wanted a class that informed me of whether a key had just been pressed and similarly if it had just been released. While I can know through the Windows messaging system whether a key has been pressed or released, I wanted a more robust method that allowed me to check the state of the key. To do this (as well as avoid branching for every key) I used an enumerated type to represent the different key states: up, pressed, down and released and twiddled with the bits so that if a key's state is either pressed or released, then it will fall to down or up respectively. I was pleased with the results and the next step was mouse input. Similar to failing to have key states (which resulted in horrible hacks such as time delays to stop multiple key presses), I hadn't had a properly controlled camera. The best attempts I have simply use the arrow keys to control the rotation of the camera. I've had attempts in the past at a mouse controlled camera, but usually the drag just isn't calculated correctly (as simple as it should be). As such, I made a conscious effort this time. It's still not perfect, because it is updated through the messaging system, it doesn't update every frame and thus is a little jagged. I wanted to avoid as much branching as possible which is why I went through the messaging system as that drastically reduces the branches in the program however, while it is sufficient for the keyboard presses, I probably want to try a different method that queries the mouse pointer every frame for higher fidelity.
This initial work was done with about a month before the deadline, which was still more than enough time to complete the project. As I mentioned in my blog post, it was great to go back to lower level coding after scripting for so long. I'm still sure that gameplay programming is where I want to be, I love being able to control how things interact in a game, but it's definitely a hobby of mine to core parts of programs, it goes back to my love of knowing how things work. While I had the core part of my framework down to get a start on creating an application, I was actually delayed as my other modules required urgent attention. It wasn't until my Xmas break that I properly got a start on the coursework which left three weeks to create the application (as well as write a supplementary report).
I describe the process in more detail in my blog post, but the bottom line is I'm quite pleased with what I managed to accomplish in what was essentially 72 hours work. It was fun doing the particle effects, my work on the tessellation stages certainly helped speed up learning how to use the geometry shader. I was also really pleased with my particle emitter solution, while it's no doubt been used countless times in many variations, it was something I designed and created myself which is why I'm proud of it. I was happy enough with the snow popping in but the fact I have it blend in and thus making it seamlessly fly in was awesome. Similarly, I was happy enough with a static fog but given it required no extra computation to make it move based on the intensity of the storm I had to add it in.
I would obviously have preferred to have proper assets in the application, the framework would have been able to support such. However I think the programmer art for the guy you have to save is actually pretty amusing, similarly I crack up at my attempts at wind and helicopter noises.
While I'd struggle to honestly label it a "game", the application is something I'm happy with as I think it does a good job to show how much I can do, and learn, in a short space of time. I enjoyed creating particle effects, in semester 2 is the second stage of this module which is to use more advanced features. I could use tessellation, but given it wouldn't be anything new, I will look elsewhere. I've also done post processing previously however I don't think I'm as strong on that process as I could be, additionally I've still yet to use HDR lighting which is something I really want to do. I may also look at compute shaders. As a space geek, I obviously love seeing n-body demos and if I was able to create my own I'd be over the moon.
To see a run through of the application, head over to my Vimeo.
What did I actually do?
Over the course of 3 weeks I created a 3D DirectX 11 application where you control a helicopter and fly over terrain to try to find a stranded mountaineer. The application features particle effects, dynamic fog, various shading models and audio. The majority of the framework and application was created from the ground up by myself. I did use online tutorials however to help me put together the font engine and model loading at a quicker pace than I would have managed writing them from scratch.