So after some discussions about whether finishing the “Rocketman” XNA project was feasible given the deadline for Dream-Build-Play looming, it was decided that we’ll put the game on hold for now. I’ve got something special planned to take its place as my entry for Dream-Build-Play, if I can get it done in time. For now I’ll give you the nitty-gritty on the basis for this project; the Oxide for XNA. Oxide is basically a game engine built on top of the XNA framework to make future Shadowsoft Games (and my own personal projects) a little easier by providing the basis – object systems, audio, input, particles etc. I’ve been meaning to do something like this for a while, but I’ve never gotten around to it.
So how is this going to help me finish my DBP entry in time? It’s not, but I can kill 3 birds with one stone – Oxide is a built on top of the basic “Rocketman” engine, and is nearly entirely backwards compatible. It also provides the basis for my new project, and this will allow me to develop Oxide as a separate sub-entity to the new project… if you’re still following, this means that I can add features to Oxide as I need them with the new project, then when the project is finished I can export the updated Oxide and build “Rocketman” with it, further developing Oxide’s core with new features and bugfixes.
So far I’ve fully split all of the Rocketman-specific stuff out of my new “Oxide” project, created my new SVN repository and began cleaning up code and implementing some needed features. One of the new features I’m particularly interested in is getting in there is physics. The most interesting candidate for a physics engine I’ve seen is Farseer Physics, it’s biggest strengths being that it’s completely free to use, completely open source with a very permissive license (so I can modify it and use it as I like) and 2D-specific. Oxide is going to be a 2D game engine, so this fits nicely. Hopefully it won’t be a pain to use and performance will be adequate; if not though, there are a few alternatives.
Sorry if updates here start getting a bit slow over the summer as I’ve got a lot to do. DBP’s deadline is August 6th, so making an entire game in a month almost from the ground up is going to soak up my time like a sponge in water; not to mention that I have to get working on my dissertation soon…
Over the last week I’ve been doing a lot of work on the XNA project. Since we have 6 weeks until the Dream Build Play submission deadline (which I’m pretty sure we’re going to miss), we’ve decided to get our asses in gear and start working seriously on this project. There’ve been various enhancements to the game both on my part and on Johnny’s – Johnny has learned how the object system works and implemented the friendly “blob” creature (see screenshot below), as well as testing the level editor (and creating a couple of test areas) and giving me a lot of design feedback. I’ve been working hard on getting the game engine up to a fully playable state, and improving the level editor – the main progress being in level and object loading.
A test level showing some friendly blob objects. These are created on a background thread while you are playing and switched in when you enter the area they are contained in. (as always, click for larger image)
With university finished for another few months, I’m going to be shifting my primary focus for a bit to the XNA project. With that said, I thought I’d record an early preview video and stick it up here. Basically it shows some of the current build – basic gameplay mechanics, background tests, and some level editor functionality. If you’re left wondering why the level editor shrinks to the top left, it’s so that interface stuff and infromation can be displayed along the right and bottom without covering any of the action.
You may also notice it’s a Vimeo video, instead of YouTube like a lot of my other videos on this site. I’ve decided that Vimeo gives slightly better video quality (at least for my videos), so I’m going ot be converting my other videos to Vimeo when I have a chance. The main difference is in the smoothness of the framerate – this video was very jerky on YouTube. It’s still not as smooth as the actual game – if and when I get the bandwidth (or someone to host it) I’ll upload the full quality 140mb avi file.
In terms of actual work, I’ve been doing some internals and fixing some bugs. Nothing to get excited about, but just paving the way for the interesting stuff to come. The music in the video is “Unexplored”, and is available to download on my music portfolio page.
I’ve been starting work on the “Rocketman” XNA project again, and while getting into the swing of things I decided to revisit the bloom shader introduced before. Basically, I’ve rewritten it completely using a totally new method, because the old one kind of sucked, and wasn’t real bloom (brighter colours “blurred” the same amount as normal colours). The new bloom effect is much better looking, but unfortunately comes at the cost of performance: it (of course) runs absolutely fine on the PC, and on the Xbox 360 in standard definition (640×480), but problems begin to arise in HD on the 360. At 720p (1280×720), slight slowdown is noticeable in areas with lots of stuff to draw – in itself this is tolerable but I’d really rather it maintained a consistent 60fps. The problems get really bad when the game runs at 1080p (1920×1080); things get really bogged down to the point that it’s running about 20fps. One of the original goals of the project was to have the game run at 60fps in 1080p (as most community games seem to settle for 720p as a maximum) – it’d be nice to be able to fulfill this goal.
The new bloom effect at 720p (running on Windows) – click the image to enlarge.
After working on various tweak’s in the XNA game engine (loading of array data from XML object definitions, animation code improvements, continuing work on the level editor), I thoguht I’d have a go at getting some shaders working. We want to use a few shaders to give the game a more polished feel, and one which we thought would work well and help give the game a “spacey” style is bloom. So over the last two days I’ve been learning how to use HLSL with XNA, and getting a bloom shader up and running. Here’s some screenshots comparing the game with and without bloom (of course, the bloom is only in very initial stages and could do with some tweaking);
Here’s the XNA game without bloom [and with a running sprite!]. Click the image for a larger version.
Here’s the same area with bloom. While it does make the game a bit less focused, the overall effect makes it look more pleasing and easy on the eyes. The intensity of the bloom can be altered too, although very high intensities tend to make it look too blurry to be worthwhile. Comparing the images side-by-side makes the original look like it’s been put through a “sharpen” filter. One might note that this isn’t really bloom; the white doesn’t glow any more than the darker colours…
Recently I’ve been working on generally improving the XNA game’s engine, and looking at ways to get it running nicely on the Xbox 360. One of the biggest problems with speed on the 360, apart from garbage collection issues (which I’m more or less on top of) is batching of draw calls. When drawing layered, tiled backgrounds at high resolutions, a LOT of tiles need to be drawn – the XNA game draws 480 64×64 tiles per layer, with 6 layers and a highlights layer. The Xbox can handle this, if they are well batched; the problem is, with my old tiling system, it was changing textures a lot and, especially in the highlights layer, this ended up causing batching problems. After spending some time trying out a technique using RenderTargets to store big textures for each layer (which ended up using a lot of VRAM and causing difficult-to-debug problems on the 360), I went with the idea of combing all of the tiles into one big texture. This does use a lot more VRAM; 16mb for a 2048×2048 texture, but it comes with a huge speed boost since the engine very rarely has to switch textures while drawing the background.
Originally I started out rendering to a separate render target and resolving that to a texture, as it seemed the most logical and simple option; unfortunately, render targets are somewhat problematic to work with on the 360 and I was getting random crashes without explanation. I switched over to using Texture2D.SetData to copy data from tiles, but again, the 360 wasn’t having any of it. It turns out that the 360 only likes to play nice if you’re replacing a whole texture at a time; it can’t lock regions of the texture for writing. So my final method, and the one that worked, is the oldschool style of getting raw pixel data, copying to a buffer, then copying the whole buffer into a new texture. While this is slow, it’s only ran once at the beginning of the game, and doesn’t introduce any noticeable delay, so there it is. The game now runs a lot more smoothly, so it was worth all the work. Unfortunately, screenshots wouldn’t really help express anything, so this explanation is all I’ve got for now. More to come.
I’ve been doing some interesting (and different) work on the XNA project over the last few days. The bulk of it has had to do with the background tile engine, loading and saving of levels, and the level editor.
One of the features we want in the game is to have highlights and outlines on some of our tiles;
+
=
The highlighting and border effect not only gives a distinctive graphical style, but I think it simply makes the tile look a LOT nicer (as well as saving a huge load of VRAM since we’re using just one base tile here for what looks like lots of tile shapes).
Yesterday Johnny and myself had some fun messing about with what I have of the XNA game’s particle system. After adding some extra stuff that’s needed (fading of particles, gravity effect, improving the attractor and deflector code, etc), we decided that a good way to test it would be to try and create some particle effects. We ended up working on a dramatic explosion effect, and found a few things that need to be added. I got a 720p video of what we came up with, so it’s not all bad, however.
Obviously, this isn’t the full 720p. You can view the YouTube HD version of the video here, or check out the original YouTube page for it here (this is the SD version). Again, this still isn’t actually 720p, but it’s good enough for what it is.
I’ll be making the first post about my Advanced Games Tech project as soon as I can get some screenshots (and videos too, if possible), so stay tuned for that. Uni starts in a week, too, so it’s probably not going to be too long until I start my dissertation project…
So over the last couple of weeks I’ve been having a toy about with the XNA Game Studio stuff for the Xbox 360 – my interest having been sparked by the appearance of “Xbox Live Community Games”. After reading everything about it, it seems to be too good to be true – but so is everything, so what the hell.
My first impressions were as follows, roughly in order;
