The version of Snowball currently on GitHub under the “develop” branch has been split into multiple projects. There is now an assembly for each major piece of Snowball, such as Graphics, Input, Sound. Although this means having to reference more assemblies, the amount of code your project depends on is now smaller. This also makes code maintenance a bit easier as it’s more clear now what parts of the library depend on other parts of the library.
The parts of the library which really make up a Game Framework has also been split out into their own library. This allows for using Snowball as a just a simple set of libraries or a full blown game framework, depending on what your situation calls for.
I fixed a bug yesterday in Snowball related to a lost graphics device. I noticed that when I would use CTRL + ALT + DELETE, my apps were crashing. Turned out it was due to not recovering properly from a lost device.
The root of the problem was that I needed to call the ID3DXEffect::OnLostDevice() method when the device was being lost. This allows the effect to recover from the lost device. I’ve made the Effect class in Snowball now do this automatically.
I’ve now merged the “Shaders” branch back into the “master” branch. All rendering is now based on shaders and no longer on the fixed function pipeline.
The function of the Renderer class was essentially been reduced to pushing data to the GPU and therefore I decided to rename the class to GraphicsBatch. The Begin() overload which would allow you to specify RendererSettings has been removed and been replaced with an overload which allows you to specify an Effect file to use. Also, the DrawLine() method has been removed, although vertical and horizontal lines can still be drawn using the DrawFilledRectangle() method. Better line drawing should be possible through shaders and I hope to eventually make a sample which provides an example.
I’ve added a sample (pictured above) which demonstrates using a custom shader. By default, GraphicsBatch uses a BasicEffect class which is basically the old way of rendering implemented in a shader.
In order for shaders to work properly when using GraphicsBatch, the GraphicsBatch class must pass a few parameters to the shader. At the moment, this only includes a transform matrix but may include more parameters in the future. The GraphicsBatchEffectWrapper can be used to wrap custom effects which you write in order to work with GraphicsBatch correctly. GraphicsBatchEffectWrapper will pass the parameters to your shader by following a standard naming convention. For example, the transform matrix is passed to your shader through a parameter named “TransformMatrix”. You can also write you own class which implements IGraphicsBatchEffect. See the sample for an example of using the wrapper class.
It’s been a long couple of months. I’m in the middle of switching jobs, been on vacation a bit, and have been playing around with OpenGL a bit to get a feel for how that API works compared to Direct3D. As of yesterday I started working on implementing shaders in Snowball.
In order to implement shaders or Effect(s), there may have to be a few changes to the API / interface of the Renderer class. Nothing significant I don’t think but mainly changes to the Begin() method overloads. Today I pushed the branch which contains my initial implementation.
For a little while, I was thinking about giving up on Snowball. When you’re one guy working on a project that gets to a certain size, it can start to feel a little daunting. You find a bug, and you feel like you need to fix it asap. I don’t know if anyone reading this has actually tried Snowball, but if you have, please comment to let me know. It would encourage me.
I decided to switch Snowball over to SharpDX. It’s not that I was unhappy with SlimDX, it just seems like there is a lot more innovation happening on the SharpDX side. I also like the fact that I can include the DLLs in the repository so end users don’t have to download another dependency in order to compile it. The Win8 stuff is also quite interesting, although the SlimDX guys say they are working on that.
I plan to set a road map soon for what I want to include the first release of Snowball. Music and Pixel Shaders are high the list. I’ve experimented with implementing a UI library but I think I want to push that back for a later release.
My game framework Snowball is far enough along that small games can be developed with it by now. The basic overall design is now laid out and not too much is likely to change as I’m now developing my own small games with it.
In order to create some kind of documentation on how to use Snowball, I created a Samples folder in the source. In the Samples folder is a WalkingWizard sample. I’m posting this source code here but it can also be viewed on GitHub here.
I originally got the idea for Snowball after working with the Xna Framework. The Xna Framework is a good piece of software for what it is but there are some things about which I just do not agree with:
- The content pipeline only works with content in the serialized .xnb format.
- There are certain content types which can only be loaded via the content pipeline.
- Certain features don’t exist on the PC because they don’t exist on the XBox or Windows Phone 7.
Xna was designed as an abstraction layer for all the 3 platforms mentioned in the last point, so that one is somewhat understandable. I don’t want to write games for my XBox right now though, so why should things like drawing lines not be available to me?
With these points in mind I started working on Snowball. It’s designed to be an Xna like framework for making 2D games. It uses SlimDX on the backend, but that is completely abstracted away from consumers of the framework. What I want to do is design the API so that the backend can be swapped out somewhat painlessly.
I still have a ways to go before I will consider it a version 1.0 release. As of this writing, I’m transitioning to more of a ContentLoader class style for loading your game’s content. Any resource type from within the framework can be loaded by hand if you want, the ContentLoader class will just make it easier. After that I have a few other features like GamePad and Music which I would like to implement before saying I have a Beta type release.
The future after that is up in the air. I would love to try and have different implementations of the API for Xna and/or OpenTK.
I recommend for anyone who is interested as to why an API designer choose to implement the API in the way they did to try it for themselves. I have learned many things from this project including why certain design decisions were made by the Xna Framework team.
The Codeplex Snowball repository is finally working again. It had to be wiped out but I had the repository locally again. Codeplex will remain as the main site where I host Snowball but Bitbucket will continue to be updated.
I’ve been unable to sync my code to GitHub with any success as of late. With that said I decided to delete my GitHub account and give up on trying to keep Snowball updated there.
The Codeplex site is still busted but I won’t be deleting that anytime soon. That means the only place that really has my latest updates is the Bitbucket repository.
Sometime at the beginning of this week my Codeplex repository for Snowball busted. I wrote them and hoped they would fix it asap. As of this writing it is still not fixed and I have not had any response from them.
So I then decided to try and pump my source code up to github. Although I was successful with the help of hg-git, eventually my local repository became corrupt. All the code in the working directory was ok of course, but I was unable to make any commits to the repo. I pulled the latest backup I had locally of the repository and decided just to fork off from there.
I then decided to give Bitbucket a try. I figure the more options the better. I still really like the way Codeplex is set up. I like the social aspect of github but codeplex seems more structured to me.
Going forward I’ll try to keep the code updated in all 3 places. Pushing to github is not a huge priority to me as it can be a little tricky pushing from mercurial to git, but I will try my best.
I’ve added a Samples folder to the repo now which I hope will help provide some kind of how to get started. The Walking Wizard sample shows the basics of getting a sprite of the screen and making it move with the keyboard.