Porting To XNA
This is an archived blog entry from 2009 and likely holds little relevance.
I used to have an ill feeling towards XNA. The thing I hate about managed code is primarily the way people come out with “look what I programmed”, not realising that the components they tied together to get the end result was done by someone else. Is this really the effort of this “programmer”, or moreso the “programmer” just selecting a bunch of namespaces and writing a small amount of code to get them to work how he/she wants?
The C++/OpenGL programming over the last year or so – everything was done from scratch. If I wanted a texture, I would have to write the functionality to read a targa image (just one of a few formats). If I wanted models, the same applies. If I wanted the extended functions which Windows does a mean task of not exposing, then I would manually add each required function as necessary. Perhaps this was a lot of work, but I felt like the boss of this particular engine (however good or bad), and that it was my effort that got it there.
With all that said, I am very impressed by XNA. It feels as if it was designed by seasoned game developers, but unfortunately with the advertising of some unrelated office somewhere in Microsoft deciding how to market it. People seem to have the impression that if you have played games for ten years, they know what they are on about, and can make a game. This came up a few times in university too, but the reality is more, that if you do not have a programming background, then don’t expect to jump straight in and produce Half Life.
I am impressed by how easy it has been to get to grips with XNA (note – coming from a background of C++/OpenGL, and NOT starting with perhaps some unrelated PHP usage). In the first couple days, I had a camera class, keyboard class, some of the heightmap class ported over (the fault line algorithm, erosion (smoothing) filter, and obviously the rendering), pixel shader lighting, and later on, the skydome.
The above are not exactly groundbreaking features – they are features a novice should be able to do. The skydome is a little more advanced than the heightmap, but mostly due to the mathematics required to produce the dome. Other than that, the RenderState DepthBufferWriteEnable is disabled, and the skydome is rendered before everything else. This means that anything rendered after the skydome (and after the DepthBufferWriteEnable is enabled again), will be drawn whether they are outside the radius of the skydome or not. The skydome hence appears infinitely far away, and behind the terrain, trees, models, any whatever else is to be in the scene.
Oh, and a final note, the skydome is centered about the Camera. This was just a case of setting the skydome effect’s world matrix to that of the Camera’s position.
One thing I noticed is that the community content for the Xbox 360 does not seem to be doing as well as Microsoft have planned. The plan is to change that, hopefully providing the right balance of nice visuals, but without taking away from gameplay. Hopefully Microsoft will not pull the plug on the community content anytime soon. Hopefully their faith can be restored in making development more available to indie developers. Note, this is not to say that all the content is bad so far. Some people have done very well, and produced some nice content. What is the worst case? This plan fails, and I can just use XNA to ‘pseudo-code’ techniques before writing them fully in C++/D3D or OpenGL.
