It's getting close to another year since my last blog post, so for anyone still out there I thought I'd put up this little video of a pet project I've been tinkering on. It simulates how Foucault's Pendulum behaves at various latitudes. In case you're wondering what on earth Foucault's Pendulum is -and if you'd actually want to know- you can find more information over here and this here book provides a well-written history on the subject. The short and sweet is that this Pendulum device demonstrates that the earth rotates, which is a pretty neat feat. To get on with the imagery, here's that video:

I'm still tinkering on XNA3.1 so I won't bother you with the hideous source. I'm really not up to speed on the more recent XNA developments, so I have no clue if there's any need out there for another rant on how hard spheres are to texture correctly, or some info on how to paint on your meshes like the pendulum is doing. If there is however, drop me a line and I'll try to put together a tutorial explaining the technique (could be a good reason to finally upgrade to XNA4). And it might be nice to have some fresh content on the site again :)

There seem to be a lot of exciting things happening at the moment. XNA 4.0 has been announced which adds Windows Mobile 7 phones to the list of supported platforms, but you already knew that of course. While Shawn is busy at GDC, I took the liberty of stealing his Fractals code. It doesn't improve anything upon his release in 2006, but I happened upon it and I thought I'd be nice to have this available as a ready-to-run sample. On that page you'll also find my take at handling input (inspired by this discussion) which seems to be all the rage these days.

Other than that, I've started tinkering on a little animation pipeline for XNA together with a 3D artist as a learning experience. I have no idea if this will be anywhere near finished any time soon, or if it'd even be useful for the community since there seem to be a lot of libraries out there already. Like any good software project I settled on an acronym for the name anyway before its anywhere near done, so I lay claim to Uxmal. It's a good fit since the artist is working in Maya and I'm on my third rewrite of the codebase already. Xna Model Animation Library also fits, but my development efforts are currently stumped by trying to come up with what the U should mean. Useful would be ideal, but it might also be Unnecessary or Useless.

Time will tell :)

I came across an excellent discussion of setting up a logarithmic depth buffer in Cameni's Journal. I heard of those before, but I was surprised to find implementing them is as easy as adding only one simple line of code to your vertex shader:

output.Position.z = log(C*output.Position.z + 1) / log(C*Far + 1) * output.Position.w;

The C constant allows you to define the resolution you want at the near plane and Far is the value you use for the far plane. More details can be found in the journal linked above. I happened to be tinkering on a model of our solar system with a bunch of stars surrounding us (from Hipparcos data) to scale. The lightyear distances for the stars and the AU distances within the system were a source of woes with the depth buffer, but using this simple line made my z-fighting stars play nice.

I haven't gotten around to writing interesting samples or uncovering any deep XNA truths lately. Instead I've been tinkering on a little beat-em-up game with stylized stick men to do the fighting. These little actors are entirely procedural, so the game itself generates the geometry and animations rather than using models created by artists. Obviously nothing can replace a good artist and this proved painfully true when it came to the animations.

The animations are generated by a particle-based physics system (described here), which works by applying force to the attacking limb towards the victim, checking collisions and letting the simulation run its course. The base skeleton displayed below is set up easily enough, but without additional contraints the resulting movements are far from natural. As noted in the original article, a lot of tweaking can also be done using the mass of particles to get some control over how easily particles (i.e. joints) can move.

So if the skeleton and animations are that hard to tweak, you might be wondering what good this procedural technique is then. The beauty of this -admittedly simple- physics based rendering setup is that you essentially get inverse kinematics for free. If I want to hit my opponent with a hand, I just apply some force on the hand towards where I want to hit him. With sufficient tweaking, this produces convincing animations for accurately hitting the victim anywhere with any part of the attacking actor. Headbutts, kicks and more exotic attacks are just a matter of picking target and subject particles on either side.

Another nice benefit of this procedural approach is that the geometry is very accessibly to the program and thus can be altered in a variety of ways. With a few minutes of tinkering, style variations like those below are easily implemented.

The project is still a pretty long way off from becoming a playable game, but it's already made its way around the office for passive-aggressive stress relief   I'm afraid I can't put a playable build out anytime soon, but in the meantime here's a little movie (WMV, 7mb) showing some basic pummeling and the style so far. Since a lot of tweaking is involved and much of the style is still up in the air, comments and/or suggestions would be much appreciated.

Foregoing lamenting my own slacking, I want to point everyone who cares to read this to a great online resource I stumbled upon today:

A free online book called "Programming Vertex, Geometry, and Pixel shaders"

It is geared towards D3D10, but it contains an incredible wealth of information about nearly every graphics topic you'd want to implement. The concise and thorough theory certainly holds for XNA and most shaders should give you a good idea how stuff gets implemented, if they don't work out of the box. It's written by these guys, who deserve a truckload of cookies in my opinion!

_{Oh and Jack, if you ever should find your way here, we have to discuss your definition of 'not very active' :)}

On my favorite GameDev forum a lot of threads seem to be popping up from beginners worrying that getting started in game development, even as a hobby, is Hard. Lacking anything really useful to talk about at the moment, I thought I'd write up some points about this.

Get your feet wet

When you're just starting out everything seems hard and no amount of reading is going to do you much good until you sit down and just take a shot at it. Don't worry if you don't create an AAA game on your first try or even when you hit a wall and don't know how to continue (I'll get back on that). The key is, you've at the very least got some basics down and tried out various things that did or did not work. Congratulations, you've now learned something and are no longer a n00b.
 

The best language   

Please stop worrying about what would be the best programming language, please! If you even vaguely know how to code in some language, just stick with that unless you feel you absolutely need to move to another language since it offers something you really can't live without. Programming languages may all have their pros and cons (in no small part due to the libraries they'll allow you to use), but getting bogged down learning hard language X isn't going to help you create your game. Most coding skills you aquire carry over pretty well and should make it a lot easier to learn other languages anyway. And though it may be a fact that language X is the current industry standard,  should you really care about that now?
 

Getting into the industry

Or rather, do you really want to be in the industry right now or in the near future? It's a nice dream to create games for a living and certainly worth hanging on to, but when you're just getting started you really shouldn't be worrying about the industry too much. Just have a go at creating some games or at least coding some fancy things to get a feel for it. Then if coding games really turns out to be the carreer what you want, you will still have plenty of time to brush up on industry standards and how to actually get in there. In the meantime, you'll have a bit of a portfolio layed down which just might show off your experience and passion better than stating you know language X. Here's a little anecdote.

Getting stuck

So you went and started coding your game, but you've hit a wall. That's ok, it means you have something new to learn. Research the problem, ask around on forums and try to get it working. Even if it turns out you've created a monolithic unwieldly behemoth of a program or that something's deeply flawed in your approach, you'll at least know to avoid it in the future and you can start fresh with your newly gained knowledge. But chances are things aren't this bad and you'll have learned how to solve the (perhaps common) issue.
 

Well, that about covers it for now. I'm sure more ramblings will be forthcoming