For Silverlight developers who want to delve into XNA, the hard part is not learning the new set of classes in the library, but the fundamental difference in programming style for some parts of XNA compared to Silverlight. Especially when you have no experience in game programming, you might find some things confusing or even illogical. In the first part of this article, I want to give an overview and explanation of the biggest differences. You will run across all these topics again in the following articles in more detail.
Later on, we finally start with some actual code and analyze the structure of an XNA project. We will learn about the concept of content and how to add it to your project. By the end of the article, we will have built a very simple "Hallo World" game that renders some moving content onto the screen. The source code for the sample project can be found at the end of the article.
Some Theory
Event-driven vs. Polling
In Silverlight, when you are interested in any kind of data or information, the common way to get it is to subscribe to some sort of event (I also count callbacks and similar constructs to that). No matter if it is user actions you want to be notified about, the arrival of data from a returning asynchronous operation, or other situations that require transportation of information: the runtime, third party components, or even objects you have written yourself send you a notification whenever the data you have asked for is available. That also works the other way round. If you want to notify someone else that something interesting has happened, for example signal to a UI component that your data has changed, you raise events. We've all gotten used to interfaces like INotifyPropertyChanged, do we?
This picture is quite different in XNA. A lot of work there is done using polling. For example, instead of being notified by an event that the user has touched the screen, you actively keep asking the screen if something interesting happened since your last call. Like on that long trip in the car, when your kids in the back seat keep asking "are we there yet"; with XNA, you are the kids, and you ask 30 times a second.
Later on, we finally start with some actual code and analyze the structure of an XNA project. We will learn about the concept of content and how to add it to your project. By the end of the article, we will have built a very simple "Hallo World" game that renders some moving content onto the screen. The source code for the sample project can be found at the end of the article.
Some Theory
Event-driven vs. Polling
In Silverlight, when you are interested in any kind of data or information, the common way to get it is to subscribe to some sort of event (I also count callbacks and similar constructs to that). No matter if it is user actions you want to be notified about, the arrival of data from a returning asynchronous operation, or other situations that require transportation of information: the runtime, third party components, or even objects you have written yourself send you a notification whenever the data you have asked for is available. That also works the other way round. If you want to notify someone else that something interesting has happened, for example signal to a UI component that your data has changed, you raise events. We've all gotten used to interfaces like INotifyPropertyChanged, do we?
This picture is quite different in XNA. A lot of work there is done using polling. For example, instead of being notified by an event that the user has touched the screen, you actively keep asking the screen if something interesting happened since your last call. Like on that long trip in the car, when your kids in the back seat keep asking "are we there yet"; with XNA, you are the kids, and you ask 30 times a second.
