Grafische Oberflächen für die Konsole von Microsoft

Widgets für die Xbox 360
Kommentare

Microsoft predigt seit Jahren, dass Silverlight die Zukunft ist. Denn wer sein GUI mit Silverlight programmiert, kann es angeblich auf allen Microsoft-Plattformen verwenden. Doch stimmt das auch?

dot.NET Magazin

Der Artikel „Widgets für die Xbox 360“ von Tam Hanna ist erstmalig erschienen im dot.NET Magazin 1.2012.

Leider zeigt ein Blick auf die XBox 360, dass hier wie übrigens auch bei Nokia mit Qt der Wunsch der Vater des Gedankens war. Mit Silverlight erstellte Interfaces laufen im Browser, auf dem PC und dem Windows Phone. Auf der XBox 360 heißt es nach wie vor: Silverlight, nein danke! Obwohl man theoretisch sein eigenes GUI-Framework entwickeln kann, ergibt das finanziell keinen Sinn. Es gibt nämlich bereits zahlreiche Frameworks, die nur darauf warten, lizenziert und/oder heruntergeladen zu werden.

Von Open Source …

Aus der Sicht eines Open Source Heads gibt es kaum ein attraktiveres Produkt als einen GUI-Stack: Ist er unter einer viralen Lizenz lizenziert, entsteht immer mehr offener Code. Und selbst wenn man keine virale Lizenz verwendet, profitiert man nach wie vor vom Linusschen Gesetz. Leider zeigt das im Open-Source-Bereich weit verbreitete Problem der Fragmentierung im Bereich der GUI Stacks seine Fratze auf besonders hässliche Art: Es gibt mittlerweile rund zehn verschiedene Projekte, die jeweils nur zu einem Viertel fertige Stack anbieten. Ruminate XNA 4.0 GUI ist dabei das aktuellste Produkt des Pulks. Es wurde zuletzt am 6. September dieses Jahres aktualisiert. Das XNA 4.0 UI System for Xbox 360 and Windows ist das zweitjüngste Projekt. Dabei handelt es sich aber weniger um einen GUI Stack als um ein Menüsystem für Spiele. Kandidat Nummer drei, besser bekannt als Nuclex Framework, wurde zuletzt im März dieses Jahres aktualisiert. Es ist ein extrem komplexes Framework, das eher in Richtung Spiele-Engine als GUI Stack geht. Zuletzt wollen wir noch xWinForms erwähnen, seit seinem letzten Update ist über ein Jahr verstrichen.

… und kommerziellem Projekt(versuch)

Auch die kommerziellen Anbieter sind nicht faul. Einige Consulting-Häuser haben aus PR-Gründen angefangen, ein GUI-Framework zu programmieren. Ob es in Anbetracht des kleinen Marktes je fertig gestellt wird, steht auf einem anderen Blatt. In diese Rubrik gehören sowohl DigitalRune GameUI als auch XPF von RedBadger: Bei beiden sucht man Updates seit Ewigkeiten vergeblich und kommerzielle Lizenzen gibt es auch keine. Das Unternehmen theSpoofNet stellt dabei die Ausnahme dar (mehr dazu im nächsten Kapitel).

Warum orbUI?

Als paranoide Kreatur ist es dem Autor sehr wichtig, im Falle des Falls jemanden belangen zu können. orbUI ist derzeit das einzige kommerziell lizenzierbare Framework. Daher ist es auch als einziges in der Lage, diese Bedingung zu erfüllen. Wer bei theSpoofNet 119 US-Dollar pro Lizenz bezahlt, erhält zwei Jahre kostenlose Updates und hat im Ernstfall einen Ansprechpartner. Wer orbUI nur testen will, findet natürlich auch eine kostenlose Testversion. Sie darf allerdings unter keinen Umständen für kommerzielle Projekte verwendet werden.

Erste Schritte mit der Kugel

Für unsere ersten Schritte genügt die Testversion der Plattform, die unter [1] heruntergeladen werden kann. Das Archiv OrbUI_Release.zip wird in einen Ordner entpackt. Danach wird das Beispielprojekt /XNA 4.0/OrbUI_Demo/OrbUI_Demo.sln geöffnet. Nun wird das Unterprojekt OrbUI_Demo for Xbox rechts angeklickt und mittels Set as StartUp project zur Ausführung freigegeben. Nach einem Klick auf den Käfer sollte das Testprogramm auf die XBox geladen und dort ausgeführt werden, erst danach kann man eigene Programme ausführen. Warum das erforderlich ist, fragt sich der Autor bis heute – es ist eben so.

Im nächsten Schritt wird ein neues XBox360-Spieleprojekt erstellt. Unser Beispiel hat den Namen DotnetOrbUI. Nach der Erstellung des Projektskeletts wird der Ordner References rechts angeklickt, worauf der Referenzmanagementdialog erscheint. Dort klickt man auf BROWSE und selektiert die Datei OrbUI.dll, die im Ordner OrbUI_ReleaseXNA 4.0BinXbox 360Release zu finden ist. Wenn die DLL als Referenz angezeigt wird, ist OrbUI Teil des Projekts geworden.

OrbUI besteht intern aus einer Gruppe statischer Klassen, die wie ein Zustandsautomat auf eingehende Events reagieren. Leider fallen diese Events nicht vom Himmel, weshalb wir einige Routinen des Programmbeispiels anpassen müssen (Listing 1). Der Code der Methode Draw ist vergleichsweise simpel: Der SpriteBatch wird aktiviert, die Formulare werden in ihn hineingeschrieben. Danach wird der SpriteBatch zum Auf-den-Bildschirm-Zeichnen freigegeben. Auch die Methode Update enthält nichts wirklich Geheimnisvolles. Nach der vom vorigen Artikel bekannten Überprüfung des Back-Buttons auf dem Controller werden einige Frameworkklassen darüber informiert, wie viel Zeit verstrichen ist. Zuletzt wird wie auch in der Methode Draw() die Basisklasse über die „Vorfälle“ informiert.

Listing 1
protected override void Draw(GameTime gameTime)
{
    GraphicsDevice.Clear(Color.CornflowerBlue);
    spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.AlphaBlend);
    OrbFormCollection.Draw(GraphicsDevice, spriteBatch);
    spriteBatch.End();
    base.Draw(gameTime);
}

protected override void Update(GameTime gameTime)
{
    if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
      this.Exit();

    CursorState.Update(gameTime);
    OrbFormCollection.Update(gameTime);
    OrbListManager.Update(gameTime);

    base.Update(gameTime);
}
  
Listing 2
protected override void Initialize()
{
    // TODO: Add your initialization logic here
    graphics.PreferredBackBufferWidth = 800;
    graphics.PreferredBackBufferHeight = 600;
    graphics.SynchronizeWithVerticalRetrace = true;
    graphics.ApplyChanges();

    //initialize OrbUI's skin
    InitializeResources();

    //initialize OrbUI
    OrbMaster.Initialize(this, this.GraphicsDevice, this.graphics);

    //for optimizing speed while debugging, allow StencilHelper to collect stenciled Controls
    StencilHelper.CollectStenciledControls = true;

    IsMouseVisible = true;
    base.Initialize();
}
  

Nachdem Update– und Draw-Events an die relevanten Klassen weitergereicht werden, müssen wir uns nur mehr um die Initialisierung kümmern. Der dafür notwendige Code wird eins zu eins aus dem vom Hersteller übergebenen Beispielprogramm kopiert (Listing 2). Im ersten Schritt wird das als globales Member des Skeletts definierte Graphics-Objekt verwendet, um die gewünschte Bildschirmauflösung festzulegen. Im nächsten Schritt wird die Funktion InitializeResources aufgerufen, die diverse Eigenschaften der Steuerelemente festlegt. Ihr Korpus wird, wie schon weiter oben erwähnt, eins zu eins aus dem Beispiel übernommen. Danach werden einige Eigenschaften des Frameworks festgelegt und die Sichtbarkeit des Mauszeigers durch Setzen der globalen Variable IsMouseVisible aktiviert. Auch die im dortigen Content-Projekt befindlichen Ressourcen werden in unser Programmskelett kopiert, wir wollen orbUI in diesem Beispiel ja nur testen und nicht skinnen. Wer orbUI hingegen genauer anpassen will, müsste nur die Routine und die Grafiken entsprechend modifizieren. Zuletzt muss UnloadContent angepasst werden, sodass keine Speicherlecks auftreten:

protected override void UnloadContent()
{
// TODO: Unload any non ContentManager content here
OrbMaster.Dispose();
}

Führt man die Anwendung nun aus, müsste ein Mauszeiger auf dem Bildschirm erscheinen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -