Today I released an incremental update of OnTopReplica (reaching version number 1.3.1). No radical feature changes this time, just some fixes and improvements to how thumbnails are resized, how regions are defined and handled, and so on. Hope you enjoy it. 
As usual, source code and binaries are released on the CodePlex project page.
Giuseppe Maggiore, Microsoft student partner at the faculty of computer science of Venice, is leading a series of lessons about Microsoft XNA. I have been attending these interesting lessons from the start, and last week Giuseppe announced a Microsoft sponsored contest: the objective is to produce a little XNA demo game with spaceships, planets and such. The first prize is an XBox 360 and an XNA premium membership account! 
Obviously, I'll have to try and win that prize!
I'll try to cover my partecipation to the contest in this series of articles, displaying the evolution of the game, step by step, as I'm going to build it.
First of all, I'm firmly decided not to hack together an ugly demo to show off some of the techniques available on XNA. I neither want to develop a full blown XNA game engine, but I'd like to take the time to define a flexible architecture for the game and develop it in a cleanly coded project.
The formal objectives of the contest are the following:
There are several needed components in order to start coding: first of all, Visual Studio!
XNA 2.0 seems to be compatible only with Visual Studio 2005. I originally switched to Visual Studio 2008 since Beta 2 and wouldn't like to switch back just for this contest, but hey... (I'll miss automatic properties in C# and all that nice stuff though 
).
I got a Visual Studio 2005 professional license from the university's MSDN Accademic Alliance and then had to upgrade it with the following additional downloads from Microsoft:
And that's it: after 2 hours or so of installation, I'm ready to go!
After setting up the development framework (Visual Studio 2005 and XNA Game Studio 2.0) and twiddling with the code for the whole day I'm getting something rendered on the back buffer.
I'll start describing the main architecture I built (very roughly).
Remember that I actually just started building the game and I'm not completely sure whether the architecture will work out well or if I'll have to rewrite everything from scratch tomorrow. Anyway, let's get started!
Yesterday I started making use of Giuseppe's XNA lessons about vertex and pixel shaders, texturing and lighting. The models of the game are now nicely rendered using techniques with great names such as Normal mapping, specularity mapping and so on... (more...)
ATi has the good tradition of releasing a new set of video drivers each month, with performance improvements and fixes. Unfortunately owners of Radeon Mobility cards (on laptops) usually cannot benefit of these updates. Here I'll show you a simple workaround.
The monthly catalyst driver release from ATi's website cannot usually be installed on notebooks: because of some stupid vendor / license / OEM limitation, the installation will be blocked before completion and you'll be redirected to your laptop's vendor website in search for some updated drivers. This would be tolerable, if notebook vendors only updated the drivers on their websites once in a while... Usually you'll be stuck with some really old version for years.
But there is hope... < Star Wars title song >
It is possible to actually fool the driver installer and let him think that your mobility card is actually supported by ATi. This requires a minor hack to the installer's .inf file (there used to be some kind of automated program that did the same thing, but it seems to have disappeared).
First of all, unpack the installer files to a directory of your choice. This is simply done by launching the installer you downloaded from ATi's website (the default directory should be C:\ATI\SUPPORT\[version]-[platform]-etc...). Once this is done, the installer will launch. You can abort it rightaway: if you go ahead it will abort as soon as it finds out that your card isn't supported.
In order to patch the .inf file, you must first find out what the unique ID of your graphical card looks like. In order to do this, simply open Windows' Device Manager, seek your card's entry, go into its properties and check the hardware details:
The numeric ID you see in the picture above is my graphical card's unique ID (an ATi Radeon Mobility X1700). Just copy it to the clipboard and close the device manager.
Each graphical card is usually assembled putting a chip (the GPU) together with some memory and interconnecting the two with a bus (an ATi engineer would probably burst in laughter reading this, but...). Both chipset and memory are variable (type, size, frequency) and determine the final name under which your card is assembled and then sold. In order to install the right subset of the Catalyst drivers, you'll have to find out the exact codename of the chipset running your card.
To do this, you'll have to head to the ATi GPU comparison page on Wikipedia or the card's page on ati.com. In my case, my ATi Radeon Mobility X1700 actually features a RV535 chipset.
OK, now navigate back to the folder where you unpacked the driver installer and head to the directory Packages/Drivers/Display/LH_INF. You'll find a couple of files: open the bigger INF file (in the current driver version, the filename is CL_61008.inf) with notepad or a similar program. Ignore the header of the file and head down to the list of hardware identifiers (there's a lot of them). Now, simply try to spot a card similar to yours, mounting the SAME chipset of your card. For instance:
"Radeon X1700 FSC" = ati2mtag_RV535, PCI\VEN_1002&DEV_71C1&SUBSYS_0880174B
This line means that the card named "Radeon X1700 FSC" will load the driver for the "RV535" chipset. Again, in my case I searched for an "X1600" or "X1700" card and then picked the first line with "RV535" in it. Copy the whole line, paste it on a new line just below and replace the hardware ID with the one of your notebook's graphical card and the name of the card. You should have something like this:
...
"Radeon X1650 Series Secondary" = ati2mtag_RV515, PCI\VEN_1002&DEV_71A1&SUBSYS_5921174B
"Radeon X1700 FSC" = ati2mtag_RV535, PCI\VEN_1002&DEV_71C1&SUBSYS_0880174B
"Mobility Radeon X1700" = ati2mtag_RV535, PCI\VEN_1002&DEV_71D5&SUBSYS_12421043
...
Save and close the file.
That should be enough: launch the installer manually (launch Setup.exe in the driver's root folder, where you unpacked the installer, or update your drivers manually through the Windows device manager) and proceed as usual. The installer should recognize your hardware, will assume it is supported and then will install the driver for the chipset you specified. Hope that helps!
DISCLAIMER: as usual when you're doing something not foreseen by the installer, you could potentially destroy your operating system, your hardware, be killed in sleep by your mutated graphical card and so on... Eveything you do after reading this guide is at your own risk!
The XNA framework is a solid foundation for writing a modular and cleanly structured game engine. In this post I'll go through the GameComponent class and how it can be used to provide services to the rest of the engine.
Even though XNA is a simple wrapper around DirectX 9.0, it provides several helper classes and some infrastructure that could / should help developers in building a modular game engine without much effort. One of the most important building blocks XNA provides is the GameComponent class.
Most of this post is inspired by this article on Nuclex.org.
If you played a random game for the last 2 or 3 years, you probably have already seen the incredibly popular (and very beautiful) Bloom post-processing filter in action. In this article, I'll show you how Bloom works and how to implement it as a DrawableGameComponent in XNA.
Oblivion made this effect incredibly popular: all latest games seem to implement it in some way or another.
Oblivion screenshot with Bloom.
A component you'll probably need sooner or later is a "Frame per Second" counter to have a quantifiable performance index of your game. There are many different ways to implement a frame counter. One of the easiest ones, since XNA provides us the exact time elapsed between the current Draw() call and the previous one, is to simply divide 1 second by the amount of time elapsed in seconds.
int fps = (int)Math.Round(1.0, gameTime.ElapsedRealTime.TotalSeconds);
To find out the exact amount of time (in ms) needed to draw the scene, you can further divide 1 second (1000 ms) by the number of frames per second you are rendering currently:
float frameTime = 1000.0f / fps;
If you render these values, you'll notice that your FPS counter will stay blocked on 60 frames per second (or similar). This is because XNA enables VSync by default: the game is rendered at the exact refresh rate of your monitor and presented once at every refresh, preventing graphic artifacts. To disable VSync, you'll have to paste this code in your Initialize() method:
#if DEBUG
IsFixedTimeStep = false;
graphics.SynchronizeWithVerticalRetrace = false;
graphics.ApplyChanges();
#endif
The #if preprocessor stuff will leave VSync enabled when compiling the release version of your game. IsFixedTimeStep will force XNA to call the Draw() method as frequently as possible, instead of idling when no more frames are technically needed. This will also call your Update() methods more frequently than usual.
Ok, now the FPS counter returns the correct measure. Unfortunately the value tends to vary quickly and if your framerate fluctuates you won't be able to read the counter very easily. To fix this you can use a simple counter to accumulate the values from a fixed amount of frames and then update the averaged fps value.
ascending
