Sunday, February 24, 2008

Normal Mapping

One of the things that makes modern games look so good is called Normal Mapping. It's a technique that allows the GPU to deform a simple mesh (an object made of relatively few triangles) with a special image made from a much more detailed mesh of the same model. The result is few triangles, which means faster rendering, but lots of detailed thrown in at render time by the GPU, which means better looking models. Read the Wikipedia article in the link to understand it. I plan on using normal maps a lot in Tower Simulator.

This can be applied in very small-scale object, such as a telephone used to communicate to other ATC all the way to a whole planet, which is what this video is all about. It is not rendered in XNA, as I have not learned to do that yet, but in modo. I just wanted to learn a bit more about normal mapping and the quickest way was to use this software, which is what I use to create models.

The video portraits a perfectly smooth sphere model with 288 polygons with to textures applied. One is a color map of the surface of Mars, the other a normal map of the surface of the same planet. The normal map does not show as color, but instead it allows the GPU to deform the smooth surface I created to show elevation of some major features and craters on the surface of the red planet.

This render is made out of 1500 frames playing at 60 frames per second. The blogger upload came out darker than what I wanted, but you can still see some of the major elevations such as the huge volcano that shows on the beginning and end. Notice how it remains partially lit for a little bit once it moves into the shadow area as Mars rotate. That clearly indicates it is higher than the rest of the surface. You can see this in reverse towards the final seconds as a canyon moves into view.

If you are interested, I got the textures from Planet Pixel Emporium.

Here's the video:

video

Sunday, February 17, 2008

Multiplayer and interfacing with other software

I have planned to add multiplayer to Tower Simulator. It will work over system link, which means a bunch of computers connected via Local Area Network (LAN), or over the internet. This would allow more than one person with a copy of Tower Simulator to man different positions, such as Clearance Delivery, Ground, and different Tower positions (in big airports it is common to separate the workload between two or more Tower positions, each with a distinct frequency).

That will be really cool, but another option I plan to implement is interfacing with Microsoft Flight Simulator (MSFS). I have not looked into it yet, but I am pretty sure it can be done without much fuss. Tower Simulator would look at the airplane being flown in MSFS and try to do a best match, based on the aircraft that will be available. Communications will happen over a voice channel.

Another cool interaction could be done with ATCSimulator, which is in version 2 at the moment. This simulator covers the enroute, approach, and departure part of the ATC business, and would be a great complement to Tower Simulator. I have not talked to the author yet, and don't plan to until much later in my own development, but it's definitely a goal.

Friday, February 15, 2008

Tech Article #2: XNA's Content Pipeline

This is pretty cool. Whenever you create a game, one of the hard parts is writing some sort of processor that can, well, process the assets you want in the game. What does that mean?

Let's say I design a kick ass airport in 3DS. I now want to import that into my simulator. How do I do it? My game doesn't just have an "Open file" option, and it sure doesn't understand a .3DS or .MAX extension. So, what are our options?

I could go to Wotsit and take a look at the structure of these file types, meaning their innards, and write some code that can sift through that data and find useful things I need, such as vertices locations, UV map coordinates, etc.

Great, now I can import my cool looking airport and we're in business! Well, not quite. I still need to be able to draw it, and that means I have to write code to run through the vertices and see what textures goes where, load those textures, check everything, then draw.

And what if someone else makes a good airport in another 3D creation tool and I want to add it? What about audio? Can you see how in depth this can get? As a matter of fact, game studios have hordes of people working on just these portions of the code. Lots of work. Boring work, if you ask me.

Enter the Content Pipeline. XNA Game Studio was created by guys who created games for a living, so they know where the pains of the process are. With that in mind, they have created a very cool and streamlined "pipeline" through which we can import all kinds of files. OK, so it's not any kind, they are limited to:

- 3D Files: .X and .FBX
- 2D Files: .DDS, .BMP, .JPG, .PNG, .TGA
- Material files: .FX
- Audio files: .XAP (XACT)

The Content Pipeline takes you all the way from step one, importing, to the last step, loading the asset in memory, ready for use. Check out this graphical description of the pipeline:



How do you use it in code? Very, very simple:

ContentManager myManager = new ContentManager(GameServices);
model = myManager.Load<Model>("ship");

You can now call "ship" in your Draw code and bam!, it's on the screen.

Of course there are shortcomings. The pipeline, as shipped, is pretty limited, but it was meant to be so, since the XNA Team cannot think of all different ways you need to import and convert assets. So they made this a very easy class to inherit and change, adapt, gut, add to, whatever you need, to get exactly what you want out of it. Nice, huh?

Wednesday, February 13, 2008

FAA ATC Documentation

This is pretty cool. I am a pilot by schooling, but have never studied for or been a controller. So I need to learn. Where do you go? FAA.gov, of course. Check this out.

OK, looks like the latest FAA Order for Air TRaffic Control is 7110.65S, which came out February 14. Scrap the previous one.

Tech Article #1: Data structures

Once in a while I will post entries that are more technical in nature. This is the first of them. You should read it anyways, as you'll see the benefit for users at the end.

Last night I was reading about data structures. The folks over at XNA Game Studio have written a four-part article on these, and it made for some excellent reading. Well, I haven't read Part IV yet, but the first three were very cool.

Data structures have to do with storing, retrieving, analysing, and modifying data. In my case, these structures will hold things such as all the aircraft that are in the air, their position, altitude, flightplans (I am considering having overhead traffic at both high and low altitude), etc., as well as anything else that gets bunched up in collections of the same kind.

There are different types of data structures and, like aything else in life, each has its pros and cons. The existing data structures in C# and XNA, and their brief descriptions, are:

- Arrays: A size-defined sequence of data types. Imagine a specific-sized box. Now add, say, 17 of them side by side, glued together. That would be a 17-item array. It is very fast to add and retrieve information, but if you have to change its size by suddenly adding another item in the middle, things get slow. Good for a collection of a static number of items (i.e. number of taxiways in an airport. Those don't change very often).
- Lists: Similar to arrays, except the number of "boxes" is not defined, so they are a little more flexible. Better to hold a collection of items whose total number is unknown or changing over time (i.e. number of arriving flights)
- Collections: Very similar to Lists, except these are good for inheritance (for object-oriented programming, inheriting is making a copy of an object that you can then customize for your own needs)
- Linked Lists: These are very interesting. They are like an array, except instead of being boxes that are glued side-to-side, these are boxes that know where the previous and next are. They could be half a world apart, but if you looked at one box, it would have the address of its predecessor and its successor. The cool thing about this is if you have to add a new itemin the middle of the existing items, you just put it in and change the addresses of predecessors/successors accordingly. The bad part is if you are looking for the last box, your code has to run through every box, starting with the first one, before it can find the last.
- Stacks: Exactly as their name says, these are stacks where you add an object and it goes on top of the stack. When you retrieve an object, they come out in LIFO order. LIFO is Last In First Out. Think of a narrow dead end street being used to park cars. You can only remove the car that was parked first after all the previous ones behind it have been removed. How does this help TowerSIm? Not sure yet, I'm not planning on having vallet parking :).
- Queues: Same as Stacks, but FIFO. You guessed it, First In First Out (i.e. a list of aircraft that have requested clearance).
- Dictionaries: Part IV which I still haven't read.
- Trees: Part IV which I still haven't read.

Pretty cool right? Well, for me it is :). Understanding these will ensure that I use the proper ones for different things, and will give you, the user, the highest possible frame rate.

Monday, February 4, 2008

from DELLicious to HighPerformance

OK, so maybe the title did not turn out to be as clever as I thought it would. What's happening is I am upgrading my development machine. I am switching from a Dell XPS 1710 to an HP dv9700t. The XPS has been wonderful, and has a videocard that absolutely rocks (GeForce Go 7900 GTX), but it is starting to age a bit on the CPU side (mine is one of the first ones, it only has a Core Duo 2GHz).

The new HP has a GeForce Go 8600M GS, which is not the top of the market as far as mobile nVidia chips go, but it's not too bad. It isn't as fast as the one in the Dell, but it does have several advantages:

- Shader model 4.0
- DirectX 10
- HDR
- nVidia PureVideo
- PowerMizer (to save power for using it on the go)

The new laptop also has a 2.5GHz, 6MB L2 cache Intel Core 2 Duo T9300, which should be a nice upgrade for me. Like anything in life, this upgrade is a compromise. I lose some screen resolution (Dell's screen runs at an awe-inspiring 1900x1200), but gain a bit in weight (I do normally take my dev machine with me in my travels), and catch up with times in many different areas.

The best part is I am probably going to be even Steven once it is all done, for I got a great $500 off coupon for the HP. Thanks Slickdeals.

I will shortly post some benchmark comparisons of TowerSim once I put these two machines face-to-face.