Component Glue is an IoC container and you use it of course to wire up your object graphs for you. Component Glue can also build your object graphs for you automatically if there are no interfaces involved. Take this example:
In After.cs, you can see that Component Glue is able to build the entire object graph for us. This will include all future dependencies as well so long as interfaces don’t come into play. Should an interface be needed, you can just bind that single component.
This is a very powerful thing. If one component needs to take on a dependency, just ask for it in the constructor and Component Glue will handle it for you.
Today I released a project I’ve been playing around with for a year or so on Codeplex. It’s called GLDotNet. From the project description:
C# wrapper for OpenGL. Partially generated from the OpenGL spec and partially written by hand, the aim is to have a flexible and native feeling C# binding.
I have generated functions from the OpenGL spec excluding 1 or 2 but unfortunately of the generated code is untested. There is a demo project included in the source code. The Github repository is located here: https://github.com/smack0007/GLDotNet
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.
I used to have a Github account and later eventually deleted it. I felt Mercurial was a superior source control system and so I wanted to stick with that. At work we switched to using git. And that’s when I discovered gitextensions.
Gitextensions in my opinion makes git usable for me on Windows. My only real complaint with git was that there wasn’t a good gui for it on Windows. Git also has a few features that I can definitely say are superior to Mercurial, fast-forwarding for instance.
I’ve moved most of my open source code over to Github as of now. There are some things that I haven’t moved and probably will never move but will remain on Codeplex.
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.