Zeit für noch mehr Spielchen?

Xojo genießt bei einigen immer noch den Ruf, sich zwar vortrefflich für Büroanwendungen zu eignen, wenn es aber um Animationen, Bildmanipulationen oder gar Spiele geht, weniger ratsam zu sein.

Und leider ist es gerade in letzterem Bereich so, dass die einzige plattformübergreifende Games-Engine-Portierung für Xojo irgendwie entschlummert zu sein scheint: Von Franklin3D, das die Irrlicht-Engine erschloss, ist keine Spur im Netz mehr zu finden.

Solange sich also niemand erbarmt und, sagen wir mal, eine  Xojo-Schnittstelle für Unity programmiert (aber das ist eigentlich schon eine Games-IDE für sich), ist die plattformübergreifende Spieleentwicklung auf reinen Xojo-Code limitiert. Über Retro-Games mit wenig grafischem Anspruch kommt man damit aber kaum. Oder man steigt, wie Ingo Maurischat in den Kommentaren völlig zurecht schreibt, in die OpenGL-Programmierung ein. Machbar, aber ein völlig anderer Herausforderungslevel.

Mit einer xplattform-Gameengine-Lösung kann ich also zurzeit nicht dienen, wohl aber mit einer Erweiterung für mein Lieblingsbetriebssystem OS X, Verzeihung, macOS. Das führt seit einiger Zeit exzellente Games-Engines mit sich, nämlich SpriteKit für 2D- und SceneKit für 3D-Spiele und Physiksimulationen.

Das erste Framework davon (eine frisch überarbeitete Version der iOSLib-Umsetzung) ist jetzt verfügbar: SpriteKit für macOS. Es existiert noch keine eigenständige Beschreibung, aber das allerallermeiste lässt sich 1:1 von der iOSLib-Version übernehmen. Es ist Bestandteil der grundsätzlich kostenlosen (wenngleich freiwillige Unterstützung, ob finanziell oder codetechnisch, nicht zurückgewiesen wird – versprochen!), im Entstehen begriffenen macOS-Bibliothek für Xojo, die als hübscher Anachronismus OSXLib heißt, weil eine MacOSLib schon seit Ewigkeiten existiert. Diese allerdings rennt zurzeit arg gegen die 64 Bit-Barriere, und das ist mit OSXLib nicht der Fall.

Kleine Animationen wie diese hier lassen sich mit lachhaft  wenig Code erzeugen, und komplette Spiele brauchen nicht viel mehr.

(das Ruckeln ist übrigens nur ein Aufnahmeproblem – in Wirklichkeit läuft alles wirklich rund!)

SpriteKit benötigt – wie die ganze OSXLib – mindestens OSX 10.10. Einige neuere Klassen und Features allerdings wollen 10.11 oder gar macOS 10.12 Sierra – aber das ist alles in den Descriptions dokumentiert, soll heißen, Xojo erklärt Ihnen die Funktionen und Limitierungen im Code-Editor. Und im Gegensatz zu iOS läuft SpriteKit auf dem Mac nur unter 64 Bit. Das Xojo-ObjC-Blocks-PlugIn von Joe Ranieri muss dabei installiert sein.

Schnell mal ausprobieren, ob es bei Ihnen liefe, können Sie mit diesem unsignierten – also über Rechtsklick zu öffnenden – Mac-Programm, das die kleine Demo oben in etwas erweiterter Form beinhaltet (die in OSXLib übrigens recht ausführlich dokumentiert ist). Sie können den Schriftzug durch Anklicken durch die Gegend scheuchen.

Das Dumme ist: Ich habe selten Überblick, wie groß das Bedürfnis an Funktionsbibliotheken ist. Juckt es Sie also, in die Xojo-Spielprogrammierung einzusteigen, wünschen Sie sich aber mehr Starthilfe, dann schreiben Sie mir doch kurz und ich setze mich zwecks besserer Anleitung auf den Hintern.

Sobald ich iOSLib aufgeräumt habe, können Sie dann zumindest für Apple plattformübergreifend Spiele entwickeln: Der Code wird sich, bis auf die nötigen Anpassungen an die Steuerelemente unter iOS und macOS, direkt übernehmen lassen.

Ach so: Und dass das obige Vorurteil auch für Animationen und Bildbearbeitungen nichts weiter als ein Vorurteil ist, sehen Sie, wenn Sie sich einige der anderen Demo-Fenster in OSXLib anschauen …

Update: Das Repository hat einen neuen Platz. Sie finden es jetzt unter Xojo-AppleLib, und nach und nach kommt iOS-Code dazu, da ich endlich angefangen habe, den gemeinsam genutzten Code auch wirklich gemeinsam zu nutzen. Wo immer alles Zusätze folgen, die auf beiden Systemen existieren, werden diese auch gleichzeitig für beide nutzbar sein.

8 Gedanken zu “Zeit für noch mehr Spielchen?

  1. Ich beschäftige mich momentan soweit es die Zeit zu lässt auch mit Spiele Programmierung unter Xojo. Allerdings war mir wichtig, das ein Spiel unter MacOS, Windows und Linux läuft. Ich benutze dafür das OpenGL Surface. Die Ergebnisse sind bis jetzt auch sehr vielversprechend.

    Gefällt mir

    1. Klar, OpenGL ist der kleinste gemeinsame Nenner für schnelle plattformübergreifende Grafiken, allerdings sehr viel komplexer in der Handhabung als Sprite- oder SceneKit und von Überalterung bedroht, da in Form von Vulcan schon der Nachfolger bereitsteht – wobei die Frage ist, wie und ob Apple dieses Framework angesichts der eigenen Gameengines und Metal unterstützen wird.

      Früher gab es einmal RealBasic3DSpace und SpriteSurface, aber die sind vermutlich aus Kompatibilitäsgründen irgendwann ersatzlos gestrichen worden. Es wäre schön, wenn sowas irgendwann wieder dazu käme, um den plattformübergreifenden Ansatz zu unterstreichen. Die Integration modernerer Windows-APIs lässt auf frischere Möglichkeiten in der Zukunft hoffen …

      Ansonsten, glaube ich, gibt es keine deutschsprachige Anleitung zum Einstieg in OpenGL mit Xojo. *zaunpfahlwink*

      Gefällt mir

  2. Ziel wäre ein Spiel wie unser letztes hier
    https://maurix.net/only-7-minutes/
    mit Xojo umzusetzen. Es gibt allerdings Einschränkungen.
    Beispiel: Man entwirft ein Sprite Object zur Nutzung im Canvas, denkt sich kann ich doch genauso mit dem OpenGL Surface machen, nein, das Programm stürzt ab, man kann sich drumherum programmieren mit der Nutzung von Arrays.
    Anderes Beispiel: Das Verhalten unter den unterschiedlichen Plattformen, geht hin bis: wird unter Windows nicht angezeigt.
    Ich habe schon mehrere Tutorials und Handbücher geschrieben, weiss also auch wie zeitaufwendig das ist, momentan geht das nicht.

    Gefällt mir

  3. Hallo, hier meine Abschlussgedanken zum Thema plattformübergreifende Spiele Programmierung mit Xojo.

    Für den Bereich „schnelle Ego Shooter“ mit OpenGL:
    Kann man schlicht weg vergessen: Unter macSierra läuft das alles sehr gut, da gibt es keine Probleme, bei Windows fängt das noch halbwegs gut an, aber letztendlich verbringt man 90 % der Zeit damit herauszufinden warum das unter Windows nicht funktioniert und programmiert Workarounds. Unter Linux Mint funktioniert alles so wie unter macSierra, friert dann aber nach 2 Minuten ein.
    Letztendlich ergeben sich mehr Nachteile als Vorteile, sodass man doch lieber wieder zu C++ greift, denn eine Zeitersparnis hatte ich nicht mal ansatzweise.

    „Normale Spiele“ mit Canvas. Das funktioniert ganz gut, taugt aber eben nicht für schnelle Ego Shooter. Und man darf einige Grundregeln nicht vergessen wie z.B. die Key Events nicht im Canvas Control abfragen, das bremst unglaublich unter Windows.

    Gefällt mir

    1. Wie gesagt: Direkte OpenGL-Programmierung ist in meinen Augen was für Spezialisten. Man muss ja eine komplette Sprache lernen, die weder intuitiv noch einfach ist. Was ich nicht verstehe ist, wieso dann C++ weniger Probleme produziert – es bleibt doch bei openGL. Dass es mit Xojo keine Zeitersparnis gibt, liegt auf der Hand – man programmiert dann ja im Prinzip gar nicht in Xojo, nur die GUI, und der Rest ist eine eben wirklich nicht einfach zu beherrschende Sprache.

      Für komplett plattformübergreifende Spiele-Programmierung gibt es ja Game-Engines wie Unity, die bei guter Optimierung auf die systemeigenen Engines zurückgreifen – Metal bei Apple, DirectX unter Windows …

      Dass Eugene Darin insbesondere für Windows ein Xojo-Buch geschrieben hat, hast du gesehen? Wird in der XDev-Library vertrieben.

      Gefällt mir

  4. Ok, da hatte ich mich missverständlich ausgedrückt. Ich hatte c++ in Verbindung mit Allegro benutzt. Einere bekanntere aber vergleichbare Bibliothek ist SDL.

    Die OpenGL Syntax selbst ist auch nicht das Problem, sondern eher die Umsetzung des OpenDL Surface auf die jeweilige Plattform in Verbindung mit der Unterstützung von OpenGL auf der jeweiligen Zielplattform seitens des Betriebssystem Herstellers, in Verbindung mit ein paar Bugs die hier und da mal in Xojo auftreten.

    Beispiel: Du schreibst eine Sprite Klasse die der die Erstellung von einem neuen Objekt in der folgenden Art ermöglicht.

    dim maxObjects as integer = 5
    dim sphere as sprite

    dim randomNumber as new random

    dim maxRow as integer = (PlayingArea.height / 100) * 90

    for sphereCounter as integer = 1 to maxObjects

    sphere = new sprite (PlayingArea,sphereImage,PlayingArea.width – 100,PlayingArea.height / 4)

    sphere.maxFrameInSprite = 71
    sphere.maxFrameInRow = 16
    sphere.maxFrameRow = 5

    sphere.currentFrameInSprite = 70 ‚randomNumber.InRange (1,sphere.maxFrameInRow)
    sphere.course = sphere.turnRND

    sphere.SetCurrentSpeed(3)

    sphere.AppendTextures()
    spheres.Append (sphere)

    next sphereCounter

    Das funktioniert unter Windows und macOS bei Benutzung des OpenGL Surface oder des Canvas reibungslos.( Ich hatte mit dem Canvas angefangen, das Sprite besteht ja aus 71 Frames und deswegen stieg ich dann auf OpenGL um ) Der ganze OpenGL Kram ist natürlich in der Klasse abstrahiert, weil man sich damit nicht dauernd rumschlagen will. Angenommen, man will nur ein Objekt, dann läßt man die For Schleife natürlich weg. Wenn man hinterher das Objekt ansprechen will, funktioniert das aber nur noch bei dem Canvas. Bei dem OpenGL Surface stürzt das Programm sofort ab. Abhilfe ist hier auch für ein einzelnes Objekt ein Array zu benutzen, dann funktioniert das wieder. Bin ich aber erst nach langem stöbern in den Xojo Foren drauf gekommen. Hängt damit zusammen wie das Surface und der andere Kram von Xojo beim Programmstart initialisiert werden. Dadurch bedingt kann ich auch nicht davon ausgehen das ein Programm welches unter macOS reibungslos funktioniert auch unter Windows noch läuft. Es ist unter macOS problemlos möglich in einem Refresh Timer die Objekte anzusteuern, aber nicht mehr unter Windows. Man kommt gar nicht drum herum ständig alles sofort zeitaufwendig auf allen angepeilten Zielplattformen auszuprobieren. Da ist also das Problem in Xojo zu suchen. Windows unterstützt OpenGL bei weitem nicht so wie macOS, da ist das Problem also der Betriebssystem Hersteller. Noch ein Beispiel: Die hinzugefügten ImageWell Controlls wurden bei der Windows Version nicht angezeigt, bei macOS und Linux schon. Und so kann man sich da schön ein absuchen 🙂
    Wie weit bin ich jetzt ?. Ich kann die Ufos rumfliegen lassen, sie abschiessen, den Hintergrund animieren, die Musik und Sound Effekte nutzen, die Ufos schiessen zurück und mehrere Levels laden, das funktioniert unter macOS problemlos. Unter Windows gibt es Probleme mit dem Laden der neuen Images nach dem ersten Level. Letztendlich habe ich jetzt soviel Zeit investiert, das ich es zu Ende bringen muß 🙂
    PS: Das von Dir angesprochene Buch kenne ich noch nicht, werde es aber kaufen, das wird bestimmt hilfreich sein, Danke für den Tip.

    Gefällt mir

  5. Wer Lust hat kann ja mal den Zwischenstand ausprobieren:

    https://maurix.net/2017/01/22/writing-games-with-xojo/

    Läuft unter Windows 10 und macOS Sierra.

    Ich habe übrigens eben das Buch von Eugene gekauft, der ist genau in das selbe Problem gelaufen, „Programm xy läuft unter Windows, nicht auf dem Mac, Ursache unbekannt“

    Man muss wirklich alle Zielplattformen bei OpenGL auch zur Verfügung habenund permanent testen.

    Apropos Testen: Getestet auf Windows 10 unter Parallels, Imac, Mac mini, mac book air.

    Unter macOS funktioniert auch FullScreen und resizable, unter Windows resizable und maximize.

    Retina haben wir nicht 😦

    Und das ganze ist natürlich Beta.

    Gefällt mir

    1. Ein ganzes Stück voran mit dem Spiel, Ingo!
      Die Kollisionsabfrage scheint mir noch recht grob, und in Level 2 war auf einmal alles voller Schüsse. Aber wie du schriebst: It ja eine Beta.

      Im Forum gibt es gerade einen Thread zu genau diesem Thema: OpenGl vs. Vulkan / Metal, in dem deine Erkenntnisse bestätigt werden: Die Betriebssysteme unterstützen openGL sehr unterschiedlich, sowohl vom Umfang als auch von der allgemeinen Qualität. Weshalb die Idee aufgekommen ist, einen Xojo-Wrapper für beide modernen Engines zu bauen. Wobei so etwas keine kleine Sache werden dürfte, aber das openGLView ist ja auf ähnliche Weise in Xojo gelandet …

      Gefällt mir

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s