Dieses mal geht es im Ataquarium weniger um Programmcode als um Perspektiven. Dies sind nicht etwa Anzeichen dafür, das dem Artikel-Autor der Vorrat an Tiefkühl-Pizza und Cola-Flaschen ausgehen würde, sondern zwei andere Projekte, die dazwischen gekommen sind. Als erstes wäre da ein Update der SDK-CD [1] zu nennen, denn in den letzten sechs Monaten hat sich so einiges angesammelt. Zweitens erhielt ich auf dem xtos-Treffen in Dresden eine CD-ROM. Nichts spektakuläres an sich, aber der Inhalt ist für Entwickler sehr interessant: viele Entwickler-Artikel aus dem ST-Magazin, ATARImagazin, PD-Journal, ST-Praxis und TOS. Auch aus heutiger Sicht sind einige dieser Artikel noch interessant und werden nach und nach im stc-Archiv veröffentlicht.
Ein Thema, das immer wieder mal hier im Ataquarium aufgegriffen wurde, ist HighWire [2]. Auch wenn es nicht sicher ist, ob aus der Anwendung jemals der erhoffte CAB-Killer oder Adamas-Liquidator wird, bietet ein Open Source-Browser, der speziell für die Atari-Plattform geschrieben wurde, doch neue Möglichkeiten in der Programmierung von Anwendungen.
Ein kurzer Blick in die PC-Welt sei hier gestattet und sicherlich jedem wird Mozilla ein Begriff sein. Üblicherweise als WWW-Browser bezeichnet, ist Mozilla doch viel mehr: eine Grundlage zur Entwicklung von Anwendungen. Diese Anwendungen nutzen die Resourcen von Mozilla und sind damit nicht nur voll Internet-fähig, sondern auch plattformunabhängig. Neben den üblichen Anwendungen wie Kalender und Taschenrechner gibt es bereits IRC und einige Spiele. Das ganze wird möglich, durch die Unterstützung der neuesten Web-Standards.
Zurück zum Atari: es wäre sicherlich etwas vermessen zu glauben, in dem nächsten Jahr käme Mozilla für den Atari auf den Markt. Selbst wenn, ist Mozilla doch eine ziemlich große Grundlage für Anwendungen und wer möchte schon für einen Kalender eine Megabyte-große Software starten? Ein weiterer Nachteil der Browser aus der Unix-Welt ist, das sie entweder GnuC zum kompilieren brauchen oder der X11-Server benötigen.
In der derzeitigen Form wird HW immer darauf angepaßt, mit GnuC, PureC und Lattice C kompilierbar zu sein. Es ist geplant, aus dem "reinen" HighWire, also der Version ohne Menüleiste, eine Library zu machen. Eine genaue Konzeption steht allerdings noch aus, so das zum gegenwärtigen Zeitpunkt noch nicht sicher ist, ob man HW auch von anderen Sprachen als C nutzen wird.
Als kleines Eigentor erwies sich die im Ataquarium 01/2002 gegebene Einführung in den Quelltext. Mittlerweile rühren schon mindestens fünf Köche am Source von Highwire herum, so das Prozeduren gestrichen, verschoben oder ersetzt wurden. Glücklicherweise ist alles noch relativ kompakt geblieben.
Eine der größten (sichtbaren) Neuerungen der nächsten Versionen dürfte die Grafik-Unterstützung sein. Zwar ist dies an sich nichts aufregendes - CAB und Adamas können dies schon seit Jahren - aber für den ST-Programmierer ergibt sich daraus die interessante Möglichkeit, seine Programme mit GIF-, PNG- und JPEG-Unterstützung auszunutzen. Entsprechende Freeware-Libraries gibt es zwar schon seit längerem, aber irgendwie war den Programmierern im Freeware-Atari-Bereich wohl der Aufwand zu groß, diese an den ST anzupassen. Neben den "geliebten" Oldie-Formaten wie Degas hat daher einzig das (X)IMG-Format breite Unterstützung widerfahren. Im Sourcecode vom grafikfähigen Highwire könnten sich nun Programmierer bedienen. Da die drei Grafikformate höher komprimiert sind als XIMG, werden auch höhere Anforderungen an die Hardware gestellt. Dafür entfällt die Konvertierung, wenn z.B. schnell einmal ein Effekt mit Photoshop hinzugefügt werden muß.
Ein Screenshot von einer HW-Testversion sehen sie in Bild 1. Deutlich zu sehen ist auch, das sich die Darstellung von Tabellen stark verbessert hat.
Mozilla kennt eine ganze Reihe von Web-Sprachen, die das Programmieren von Anwendungen ermöglichen. JavaScript ist davon sicherlich die bekannteste. Da Highwire (noch) keine dieser Sprachen beherrscht, müssen die gewünschten Funktionen direkt in C programmiert werden.
Um das ganze plastischer zu gestalten, sollen hier zwei Beispiele vorgestellt werden: ein Kalender und ein Quiz-Spiel.
Für die Darstellung eines Kalenders wird eine oder mehrere Tabellen benötigt, die dynamisch je nach Monat erzeugt werden müssen. Da Highwire kein JavaScript beherrscht, muß die Berechnung des Kalenders sowie die interne Generierung einer HTML-Seite in C erfolgen. Als kleiner Gag könnten noch Kalendermotive eingebaut werden.
Um weiter zu blättern können normale HTML-Links verwendet werden. Das Kalenderprogramm müßte nun in der Routine eingreifen, die für das Auswerten von Links verantwortlich ist. Je nach dem wie das Verweisziel lautet, wird ein anderer Monat intern generiert und im Browserfenster dargestellt.
Ein Kalender kann natürlich auch von einer Internet-Anbindung profitieren: wird z.B. im Kalender ein Termin eingetragen, könnte dieser auf die dazu passende Webseite verweisen.
Ebenfalls mit simplen Links könnte ein Quiz-Spiel gestaltet werden. Auf dem Atari gibt es zwar eine Menge Quiz-Spiele, aber die meisten von ihnen laufen nur in der hohen ST-Auflösung. Spiele für ST-Low sind schon seltener und alles was bunt und hoch auflösend ist, stellt schon fast eine Kuriosität dar. Als einziges Beispiel fällt dem Verfasser dieser Zeilen nur das "Dr. Who Quiz" ein, das auch ein gutes Beispiel ist, zu welch verzweifelten Maßnahmen ein Programmierer greift, weil keine vernünftigen Farbgrafikroutinen verfügbar sind: alle Bilder sind in der Resource gelagert und blähen diese so auf stolze 510 KB auf. Die Windows-Version benutzt hingegen JPEGs, die nachgeladen werden - dank der JPEG-Library für Delphi.
Die Aufgaben des Quiz-Spiels sind im Prinzip genau die gleichen wie die des Kalenders:
Der Clou ist, das durch die Verwendung von GIFs (JPEG- und PNG-Unterstützung waren bei Drucklegung noch nicht eingebaut) schönere Quiz-Spiele möglich sind. Da Highwire das Dithering übernimmt, muß das Bild vorher noch nicht einmal heruntergerechnet werden.
Ein Quiz-Spiel mit Internet-Anbindung könnte hohe Punktzahlen an eine Web-Seite übermitteln. Damit könnten Highscore-Tabellen erstellt werden. Komplizierter, aber möglich, wäre ein Netzwerk-Spiel.
Natürlich gibt es bei anderen Projekten eine Reihe von Hindernissen. So ist Bewegung im Browser-Fenster nur schwer möglich, aber selbst ein relativ einfaches Spiel wie "Sokoban" würde einigen Programmieraufwand erfordern. Bis zu einer Version, die dynamische Positionierung ermöglicht, wird wohl noch etwas Zeit vergehen.
Einige Spiele könnten auch andere Tag-Attribute oder sogar Spezial-Tags benötigen. Dies ist aber kein allzu großes Problem.
Zu der früheren Meldung über die Portierung der Multimedia-Library SDL gibt es eine kleine Korrektur. So funktioniert die Sound-Ausgabe nicht korrekt. Die Abhilfe ist, alle Sound-Befehle vorerst auszukommentieren.
Erste Portierungsversuche abseits der bekannten Ego-Shooter gibt es ebenfalls zu vermelden: Guillaume Deflache arbeitet an Scumm [3]. Scumm bringt alte Lucasfilm-Adventures auf den ST. Der Clou dabei: nicht nur Klassiker wie Maniac Mansion oder Zak McKracken sind spielbar, auch Sam & Max, Day of the Tentacle, Indy 4 und Simon The Sorcerer sind spielbar - also Adventures, die nie für den ST veröffentlicht wurden.
Das Nachprogrammieren von Game-Engines scheint in letzter Zeit Groß in Mode zu kommen - kein Wunder, merken doch selbst Windows98-Besitzer, das ihr DOS-Spiel in dem eingebauten DOS kein vollwertiges MS-DOS sieht und verzweifelt nach skurrilen Memory-Managern schreit. Für alte Ultima-Fans interessant ist Exult, ein Remake der Ultima 7-Engine in SDL.
[1] http://www.mypenguin.de/shop/
[2] http://highwire.atari-users.net/
[3] http://scummvm.sourceforge.net/
[4] http://exult.sourceforge.net/