... Vorausgesetzt eine Ebene ist als Active oder als Loading gekennzeichnet, dann bekommt die erste Ebene den Zuschlag bezüglich des Eingabefokus. Es sei denn, die CanGetFocus-Eigenschaft des Screens gibt ein false zurück. Head-up Displays, die dem Spieler Auskunft über Lebensenergie und Waffenwahl geben, brauchen meist keine Eingaben verarbeiten. In diesem Fall würde das Screen-Objekt den Eingabefokus verweigern und die darunter liegende Ebene bekommt den Zuschlag. Für die Verarbeitung der Benutzereingaben ist die HandleInput()-Methode vorgesehen (Abschnitt Eingabeverarbeitung).

Ebenen rendern

Im Gegensatz zur Aktualisierung der Logik bedarf es beim Rendern der Ebenen einer umgekehrten Vorgehensweise. Begründet ist dies in der Realisierung von Transparenzeffekten im XNA Framework. Alle Zeichenoperationen münden in einem sequentiellen Speicherbereich (Back Buffer), der den Farbwert eines jeden Pixels speichert. Bei (semi) transparenten Objekten kombiniert das XNA Framework die Farbwerte des aktuellen Objekts mit dem korrespondierenden Pixel im Back Buffer anhand der Gewichtung durch den Alpha-Wert. Wenn die Objekte in falscher Reihenfolge gerendert werden, existiert der Farbwert der unteren Ebene nicht im Back Buffer. Die Konsequenz: Der Transparenzeffekt bleibt aus oder liefert falsche Ergebnisse. Abhilfe schafft die umgekehrte Iteration (von der obersten zur untersten Ebene). Gerendert werden alle Ebenen, indem der Screen Manager deren Draw-Methode aufruft und dabei sowohl ein GameTimeund SpriteBatch-Objekt übergibt. Nicht geeignet sind Ebenen, die den Hidden- Status besitzen.

Listing 3:

1. public override void Update(GameTime oGameTime)
2. {
3. this.Input.Update();
4. if(this.Cursor != null && this.Cursor.Enabled)
5. this.Cursor.Update(oGameTime, this.Input);
6. Screen oRenderScreen;
7. bool bHasFocus = this.Game.IsActive
8. bool bIsHidden = false;
9. m_oScreensCopy.Clear();
10. for (int i = 0; i < m_oScreens.Count; i++)
11. m_oScreensCopy.Add(m_oScreens[i]);
12. while (m_oScreensCopy.Count > 0)
13. {
14. oRenderScreen = m_oScreensCopy[m_oScreensCopy
15. .Count - 1];
16. m_oScreensCopy.RemoveAt(m_oScreensCopy.Count - 1);
17. oRenderScreen.Update(oGameTime, bIsHidden,
18. bHasFocus);
19. if (oRenderScreen.State == ScreenStates.Active ||
20. oRenderScreen.State == ScreenStates.Loading)
21. {
22. if (bHasFocus && oRenderScreen.CanGetFocus)
23. {
24. oRenderScreen.HandleInput(this.Input);
25. bHasFocus = false;
26. }
27. if (oRenderScreen.IsOpaque)
28. bIsHidden = true;
29. }
30. }
31. base.Update(oGameTime);
32. }

Interaktionen dank XINPUT

XINPUT stellt ein statisches Programmiermodell zur Verfügung, über das Benutzereingaben abgefragt werden können. Es bedarf keiner Initialisierung oder einer Sicherstellung, ob ein Gerät angeschlossen ist oder nicht. XINPUT verarbeitet Tastatur- und Mauseingaben sowie die Aktionen des Xbox-360-Controllers. Das Framework feuert keine Ereignisse, wenn eine Aktion registriert wurde. Es obliegt der Anwendung, den Status pro Frame abzufragen. Die Gewohnheiten der Konsolen- und PC-Spieler gehen grundsätzlich auseinander. Zwar unterstützt die Xbox 360 den Anschluss einer USB-Tastatur, dennoch überwiegt die Anzahl derjenigen Konsolenspieler recht deutlich, die keine Tastatur an ihrer Xbox 360 angeschlossen haben. Für beide Plattformen muss das Game Play deshalb auf die Hauptperipheriegeräte abgestimmt und bei der Entwicklung berücksichtigt werden. Drei Klassen dienen als Mensch-Maschine- Schnittstelle:

• GamePad
• Keyboard
• Mouse

Alle diese drei Klassen besitzen eine statische Methode GetState, die eine Game- PadState-, KeyboardState- oder Mouse- State-Struktur zurückgeben. Während die Methode bei Tastatur und Maus keine Argumente erwartet, muss den Varianten des Xbox-360-Controllers eine Konstante der PlayerIndex-Enumeration übergeben werden, die einen von vier möglichen Controllern selektiert.

Instanziierung und Konfiguration des Screen Managers (Listing 4):

1. protected override void Initialize()
2. {
3. m_oScreenManager = new ScreenManager(this);
4. m_oScreenManager.AddScreen(
5. new BackgroundScreen());
6. this.Components.Add(m_oScreenManager);
7. base.Initialize();
8. }

Boolesche Werte oder ButtonState .Pressed bzw. ButtonState.Released teilen den Status digitaler Komponenten eines Peripheriegeräts mit. Als digital gelten alle Tasten, die entweder gedrückt oder nicht gedrückt sein können. Analoge Eingaben erlauben Abstufungen zwischen den zwei Stati. Zu den analogen Komponenten gehört der sog. Thumb Stick des Xbox- 360-Controllers (Abbildung 3) oder das Mausrad. Jene Komponenten repräsentieren die Strukturen entweder als float oder als Vector2.

Abb. 3: Der Xbox-360-Controller

Eingabeverarbeitung mit der Hilfsklasse

In WinForms-Awendungen kümmert sich das Betriebssystem um die Eingabeverarbeitung und stellt z.B. sicher, dass ein Tastendruck nur einmal das Click-Ereignis auslöst. Innerhalb einer XNA-Anwendung passiert es schnell, dass eine Taste über mehrere Frames hinweg gedrückt ist und die Anwendung daher binnen weniger Millisekunden mehrmals die Fire- Methode aufruft. Insbesondere bei der Menüführung führt das zu Problemen. Tätigt der Benutzer die [Escape]-Taste, um zum vorherigen Menü zu wechseln, und hält die Taste über drei Frames hinweg gedrückt, springt die Anwendung drei Bildschirme zurück. Damit das nicht passiert, gibt es eine Hilfsklasse InputManager, von der der Screen Manager jedem HandleInput-Aufruf eine Instanz mitgibt (die Klasse ist nicht Bestandteil des XNA Framework). Sie speichert von jedem Eingabegerät den aktuellen und den vorherigen Status. Diverse Eigenschaften wie MenuSelect geben einen booleschen Wert zurück, der angibt ob einer derartige Aktion ausgeführt wurde. Registriert die Hilfsklasse einen Druck auf die [Escape]- Taste im aktuellen Frame und einen nicht gedrückten Zustand im vorherigen Frame, hat eine Bestätigung stattgefunden. Auch die IsKeyPressed-Methode gehört zur InputManager-Klasse. Die Methode prüft für eine spezifische Taste die beiden Zustände des aktuellen und letzten Frames.

Prüfung, ob eine Menüselektion stattgefunden hat (Listing 5):

1. public bool MenuSelect
2. {
3. get
4. {
5. return (IsKeyPressed(Keys.Enter) || IsKeyPressed(
6. Keys.Space) ||
7. (m_oCurrentGamePadState.Buttons.A ==
8. ButtonState.Pressed &&
9. m_oPreviewGamePadState.Buttons.A ==
10. ButtonState.Released) ||
11. (m_oCurrentGamePadState.Buttons.Start ==
12. ButtonState.Pressed &&
13. m_oPreviewGamePadState.Buttons.Start ==
14. ButtonState.Released));
15. }
16. }

Die Implementierung eines Screens an einem Beispiel

Die Screen-Klasse ist eine abstrakte Basisklasse. Eine Ableitung muss mindestens die Draw-Methode implementieren. Eine Klasse, BackgroundScreen, hat die Aufgabe einen permanenten Hintergrund darzustellen (Abbildung 4):

Abb. 4: Der grafisch überaus gelungene Startbildschirm des Beispielprojekts

Standardmäßig blendet sich ein Screen selbst aus, wenn eine höhere Ebene nicht durchsichtig ist, um Ressourcen zu sparen. Indem die Methode Update überschrieben wird, lässt sich die Logik individualisieren.

Exemplarische Implementierung eines Screens zur Darstellung eines Hintergrundbilds (Listing 6):

1. public class BackgroundScreen : Screen
2. {
3. private Texture2D m_oTexture = null;
4. public override void LoadGraphicsContent(
5. bool bLoadAllContent)
6. {
7. if (bLoadAllContent)
8. m_oTexture = this.Content.Load<Texture2D>(
9. “Content\\Textures\\background“);
10. }
11. public override void Update(GameTime oGameTime,
12. bool IsHidden, bool bHasFocus
13. { }
14. public override void Draw(GameTime oGameTime,
15. SpriteBatch oSprite)
16. {
17. oSprite.Begin();
18. oSprite.Draw(m_oTexture, new Rectangle(0, 0, this
19. .Device.Viewport.Width,
20. this.Device.Viewport.Height), Color.White);
21. oSprite.End();
22. }