GEOS-InfoBase-Forum

Nach einer Pause, bedingt durch viel Arbeit und etwas Corona, kann ich heute endlich mal wieder einen Fortschrittsbericht einstellen.
Sukzessive habe ich in den letzten Wochen das Format MegaPaint umgesetzt. Und sogar so komplett wie noch kein anderes.

MegaPaint war eine Graphik-Software, die um 1990 zuerst auf dem Atari und dann auch auf DOS lief. Sie beherrschte nur Schwarz-Weiß-Bilder, hat aber als Besonderheit in der hohen Drucker- und nicht nur in der kleinen Bildschirmauflösung gearbeitet. Sie brachte auch ihre eigene Benutzeroberfläche mit, die mir auch heute noch wegen ihrer Klarheit gefällt. Zudem wurde das Programm in Deutschland erstellt und auch die Formatendung .BLD erinnert daran. Wenn andere Bildformate .PIC und .IMG heißen, dann sollte dies nur recht sein.

Wie weit geht die Unterstützung nun?

• Die Bildinformationen werden angezeigt.
  
• Das Bild selber wird angezeigt.
  
• Bilder können in diesem Format gespeichert werden.
  Und genau hier finden sich einige Erweiterungen:
  
  • Das Einfachste wäre, nur 1-Bit-Bilder zum Speichern im Schwarz-Weiß-Format MegaPaint zuzulassen. Aber das wäre ja was für Anfänger, und wir haben natürlich höhere Ansprüche. Für das Programm und Geos ist das Beste gerade gut genug! Also lassen sich auch Index- und RGB-Bilder speichern! Sofern sie bereits Schwarz-Weiß-Bilder sind,werden sie kommentarlos gesichert. Findet sich jedoch nur ein buntes Pixel, so wird darauf hingewiesen und eine vorherige Schwarz-Weiß-Konvertierung nahegelegt. Alternativ – um dem Nutzer alle Möglichkeiten zu geben – wird das Bild gleich mittels der einfachen, aber schnellen Schwellwertkonvertierung umgewandelt. Und das sei verraten: Da ist schon mehr in Arbeit!
    
  • Dieses Speichern von Index- und RGB-Bildern in einem Schwarz-Weiß-Format war ja schon für MacPaint geplant. Nun habe ich dies endlich umgesetzt und den zugehörigen Code in eigene Funktionen ausgelagert. Daneben habe ich noch weiteren, beim Speichern öfters benötigten Code generalisiert und auch in Funktionen gepackt. So ist die eigentliche Speichern-Funktion nun viel kompakter. Diese neuen Funktionen werde ich dann bei MacPaint und XBM integrieren, so daß sie von den Neuerungen profitieren.
    
  • Die Optionen zum Speichern werden nun in einer aufrufbaren Hilfe erklärt! Ein weiterer wichtiger Schritt in Richtung Professionalisierung.
    
  
  

Wünsche viel Freude beim Betrachten der Beispiele!

Zitat von »geobart«

Für Geos64/Geos128 gab es ja auch reichlich Grafiken - wobei es durchaus schwierig ist, die vom Commodore oder Apple II auf den PC zu bringen. Was waren das für Formate?

Auf Commodore-Grafiken (auch abseits von Geos) bin ich auch schon gestoßen. Von denen habe ich aber Abstand genommen, da ich a) mit dem Rechengerät nie zu tun hatte und b) es auch ohne schon erschlagend viele Formate gibt.

Falls jemand aber noch gerne Formate aus dieser Ära dabei hätte, kann er sie gerne anmelden. Muß nur noch schnell das Antragsformular A37 entwerfen ...

Zitat von »Achim«

Ich fände es toll, wenn das Programm auch .PNGs könnte....

Ja, das fände ich auch supertoll , ist aber leider nicht so realistisch .

Das Problem mit PNG ist, daß es drei Rechenverfahren benötigt:

• CRC32 und Adler32 für Prüfsummenberechnung
  
• zlib für Datenkompression
  

Die drei haben in Geos so einen Schrödinger-Status: liegen vor und gleichzeitig auch nicht:

• Gut: Alle drei liegen in Geos als C-Bibliotheken vor.
  
• Semigut: Sind alle nicht aus R-Basic ansprechbar und sind zudem wahrscheinlich alte Versionen (insb. die zlib-Bibliothkek erfährt regelmäßig Updates).
  
• In R-Basic habe ich schon mal CRC8, CRC16 und CRC32 implementiert. Dazu hatte ich C-Code nach Basic übertragen und dabei nicht ganz verstanden, was der macht. Aber die berechneten Prüfsummen waren richtig !
  
• Auf meiner Liste steht schon die Idee, auch noch Adler32 zu implementieren und damit das Speichern unkomprimierter (!) PNGs zu ermöglichen. Die wären zwar ungewöhnlich und praktisch gesehen sowas wie BMPs, aber wäre vom Standard abgedeckt.
  
• An eine zlib-Implementierung wage ich mich derzeit nicht heran – obwohl das ein ordentlicher Programmierer wohl schaffen sollte . Das Grundprinzip ist einfach, aber im Detail sieht's total komplex aus.
  
• Eine andere Möglichkeit wäre, jemand baut Bibliotheken, um die drei C-Bibliotheken in R-Basic ansprechen zu können. Freiwillige vor !
  
• Vielleicht wäre es eine Idee für das Novembertreffen, wenn jemand Kundiges, z.B. Rainer oder Uli, einen kleinen Workshop gibt, wie man solche C-Basic-Brücken überhaupt erstellt. Aber dann wäre davor wahrscheinlich noch eine Einführung in die Handhabung des SDKs notwendig ...
  

Hoffnung stirbt zwar zuletzt, aber leider schwacher Puls.

Abschlußarbeiten: Die neuesten Code-Errungenschaften aus der MegaPaint-Speichern-Funktion habe ich nun auf die MacPaint-Speichern-Funktion übertragen und bin deren gesamten Code noch einmal durchgegangen. Beim ausgiebigen Testen konnte ich sogar noch einen Fehler ausmerzen. Nun ist die Funktion topaktuell und sollte endlich, wieder viel später als angedacht, fertig sein.
Dieser wichtige Bildformaturahn wird nun vollständig unterstützt .

Das Spezielle am nun fertiggestellten MacPaint-Format ist ja, daß es eine fixe Größe besitzt. Weist das zu speichernde Bild eine andere Größe auf, muß es im MacPaint-Rahmen positioniert werden. Ist es größer, werden Teile des Bildes abgeschnitten, ist es kleiner, werden freie Bereiche mit der Hintergrundfarbe gefüllt. Diese Funktionalität wollte ich noch gerne an anderer Stelle testen, da eine Mehrfachverwendung oftmals versteckte Implementierungsfehler aufdeckt. Also suchte ich – und fand NEOchrome!

Bei NEOchrome handelt es sich (natürlich!) um ein Atari-Format. Das gleichnamige Malprogramm war ein sehr wichtiges und verbreitetes während der Atari-ST-Zeit. Das Format kommt in drei festen Größen daher. Mich interessierte jetzt nur die Schwarz-Weiß-Variante. Mit 640 x 400 Pixeln ist es im Gegensatz zu MacPaint ein Querformat. Also klonte ich die Speichern-Funktion und paßte sie an das neue Format an. Das ging so problemlos wie erhofft, nur die zu schreibende Atari-Farbpalette verursachte mehr Aufwand.

Und nun lassen sich Schwarz-Weiß-Bilder auch im NEOchrome-Format speichern. Damit hat mein aktuelles Steckenpferd Schwarz-Weiß-Graphik eine weitere Weide gefunden: XBM auf der Unix-Wiese, MacPaint in der Mac-Aue und eben NEOchrome auf der Atari-Alm.

Einfach phantastisch! Die essentielle Marke von 21.000 Zugriffen wurde geknackt ! Ich danke Euch !

Entgegen allen enthusiastischen Enthusiasmus war dieses Format natürlich noch nicht abgeschlossen . Die Hilfe fehlte noch! Aber nun ist sie verfaßt und steht zur Unterstützung bereit.

Hier spielt die Kapelle nochmal dasselbe Lied: Des armen Nutzers Hilferufe verhallten echolos in der leeren Ebene – nun werden sie erhört und Mr. Wolf kommt sofort!

Auch auf dieses Schwarz-Weiß-Format übertrug ich die aktuellesten, bei MacPaint erprobten Errungenschaften:

• Schwarz-Weiß-Bilder mit 8 oder 24 Bit Farbtiefe lassen sich nun direkt als XBM speichern.
  
• Grau- und Farbbilder mit 8 oder 24 Bit Farbtiefe lassen sich, falls man es denn unbedingt möchte, auch als XBM speichern. Dabei werden sie mit dem einfachen Schwellwertverfahren nach Schwarz-Weiß gewandelt. Da dadurch das Bild meist verfremdet wird, wird dem geneigten Nutzer nahegelegt, das schöne Bild doch lieber vorher gezielt selber zu wandeln.
  
• Auch hier steht man jetzt bei Zweifeln nicht mehr auf verlorenem Posten, die HIlfe wartet nur einen Klick entfernt!
  

So liebe Freunde des formidablen Formatwaldes, was mich spontan zu diesem Format zog, weiß ich auch nicht. Vielleicht die verruchte Aura? Lust auf ein Abenteuer? Das hat geklappt, denn ich sah Welten, die noch nie lange keiner mehr gesehen hat!
CrackArt ist – natürlich – wieder ein Atari-Bildformat, und es stammt auch wieder aus deutschen Landen. Das Programm kommt in der Aufmachung allerdings deutlich avantgardistischer daher als das nüchtern-präzise MegaPaint.
Was gibt es über dieses Format zu berichten?

• Umgesetzt wurden die Anzeige der Bildinfos, der Farbpalette und des Bildes selber.
  
• Auch hier gibt es die drei üblichen Atari-ST-Auflösungen mit zwei, vier und 16 Farben. Während die anderen Bildformate stoisch immer 16 Farben speichern, achtet CrackArt auf jedes WORD und sichert wirklich nur null, vier oder 16 Farben.
  
• Auch hier wird das eigene Format, wie bei Degas oder MegaPaint, in zwei Geschmacksrichtungen angeboten: Unkomprimiert und komprimiert.
  Da diese Wahl häufig vorkommt, muß sie damals wohl relevante Bedürfnisse adressiert haben. Diese lagen wohl in den Rechenknechtkapazitätsbegrenzungen, denn ein Handbuch beschrieb die Vorzüge dieser Varianten so: Das eine ist schnell zu erstellen, verbraucht aber viel Speicherplatz, während das zweite Platz spart, aber mehr Zeit zum Speichern und Einlesen benötigt.
  
• Das unkomprimierte Format war blitzschnell abgehandelt, diese Aufgabe übernahm achselzuckend meine Atari-Standardfunktion. Aber sein komprimierter Zwilling hatte es in sich – teuflische Avantgarde!
  
• Der komprimierende RLE-Code verarbeitet nicht einfach, wie jeder andere anständige Code, die direkt aufeinanderfolgenden Bytes, sondern er springt wild in den 32.000 Byte Bilddaten umher und sucht sich dort die zu kodierenden Bytes zusammen. Mir scheint es eine originelle Variante zu sein, mit den Atari-typischen Farbebenen umzugehen.
  Jedenfalls hat dies zur Folge, daß die Sichtbarmachung des Bildes in zwei Schritten erfolgt. Zuerst werden die komprimierten Bilddaten dekodiert. Auf dem Atari konnte man die wohl gleich ins Video-RAM schreiben, aber in R-Basic muß ich die dann durch Auflösen der verschachtelten Farbebenen nacheinander in Bildzeilen umwandeln und diese in die Anzeige-Bitmap kopieren. Zum Glück sind die Bilder immer 32.000 Byte groß und passen damit ins R-Basic-VRAM.
  
• Und die fremden Welten? Die betrat ich als Jäger des verlorenen Komprimierungsalgorithmus! Ich las zwar zwei Beschreibungen in Pseudo-Code, aber diese waren unvollständig und nicht ganz richtig. Und da fand ich in einer verlassenen Kellerecke die Originalroutinen. In Assembler. Für Motorola 68k! Und wie weiland das Griechisch den Stein von Rosetta zu entziffern half, unterstützte mich auch der Pseudo-Code und ich konnte dann das urtümliche, quasi in Silizium gemeißelte Programm lesen! Darauf war ich wirklich ein paar Tage lang stolz .
  

Nach dem unendlichen Herumgerastere wollte ich mich einfach mal in ganz anderen Welten rumtreiben. In der Ebene der Vektoren!
Um allen Enttäuschungen vorzubeugen gleich hier zu Anfang, was nicht geht:

• Kein Import! Dazu ist der SVG-Standard zu umfangreich, zu komplex. Zudem entstehen die Bilder heute nicht mehr in Handarbeit, sondern in Vektorprogrammen, wie Inkscape oder Illustrator, wo sie dann nach SVG exportiert werden, wodurch oft komplizierte Code-Konstruktionen entstehen.
  
• Kein Export von Geos-Graphiken! Das würde ich gerne tun, aber wenn z.B. eine GeoDraw-Graphik kopiert wird, kann man mittels R-Basic diese zwar einfügen, aber nicht mehr auf die Einzelelemente zugreifen. Diese Infos, wie „roter Kreis mit gelbem Rand und Durchmesser 3,14“, wären aber notwendig.
  

Was bleibt dann? werdet ihr zu Recht fragen. Nun, ich fand eine kreative Nische. Das Programm Bildinfos vermag nun, normale Rastergraphiken als Vektorgraphiken zu exportieren, indem es jeden Pixel als Vektorelement zeichnet und diese Elemente dann neben- und untereinanderreiht . Diese Elemente tragen die Pixel-Farbe. Je größer sie sind, um so pixeliger wirkt dann auch das Bild. Um mit kreativem Spieltrieb noch etwas (mehr) Sinn in das Vorhaben zu bringen, sind verschiedene Pixel-Formen möglich:

• Quadrat – der Pixel-Klassiker natürlich.
  
• Rechteck: ob hochgeschossen oder breit, der beliebig formbare Cousin ist auch dabei. Damit lassen sich dann auch Bilder angemessen wiedergeben, deren Pixel nicht quadratischer Natur sind.
  
• Kreis: die perfekte Schwester darf nicht fehlen!
  
• Ellipse: ein Rechteck ohne Ecken!
  
• So war dann der Export fix und fertig, zum Abschluß schrieb ich noch die Hilfe. Und dabei pflanzte mir eine der Pixel-Formen, ich weiß leider nicht welche, sonst könnte ich sie verbannen, den bösen, hartnäckigen Gedankenflüsterer ein: Reichen diese paar Formen wirklich? Warum auf 2D beschränken? Du mußt dir angewöhnen, dreidimensional zu denken! Und ohne großen Widerstand, zum zombiehaften Werkzeug mutiert, implementierte ich die Pixel-Form der Kugel! Da SVG nur 2D-Graphiken kennt, simulierte ich die Kugel durch ein weißes Glanzlicht, einen Farbverlauf von Weiß zur Pixel-Farbe. Das wirkt gar nicht so unüberzeugend, nur je weißer die Farbe wird, um so mehr verschwindet die Kugel einfach. Ich hab's mit einem schwarzen Rand versucht, aber dann wirkt es wie ein weißer Kreis inmitten von Kugeln. Auch noch suboptimal. Falls da jemand eine Idee hat ...
  

Da die runden Formen naturgemäß nicht lückenlos aneinanderreihbar sind, kann man eine Hintergrundfarbe mitgeben. Diese wird als Rechteck umgesetzt, das seine Ecken natürlich and die Rundung an die Pixel anpaßt!

So, nun schauet die Beispiele und staunet!

Hier gibt's noch einen Einblick in die SVG-Eingeweide.

Da SVG ja ein Textformat und XML-Dialekt ist, entstehen ziemlich schnell viel Code und große Dateien.
Um dem etwas entgegenzuwirken, habe ich versucht, Redundanzen zu minimieren. Deshalb habe ich nicht einfach aus jedem Pixel eine SVG-Zeile gebildet, wo dann Form, Farbe und Position stehen. Sondern ich erstelle zu Anfang die Pixel-Form als Symbol, das dann bei jedem Pixel wiederverwendet wird. Mit den Farben versuche ich es genauso, klappt aber nicht bei allen Kombinationen.

Das waren jetzt ganz schön zahlreiche Neuigkeiten auf einmal. Das liegt daran, daß ich an diesen so ungefähr parallel gearbeitet hatte und sie mit Unterstützung des Osterhäschens endlich abschließen konnte.

Ja, wie geht es nun weiter? Ein paar Mal habe ich es schon behauptet, aber nun stehe ich wirklich vor einer Wand. R-Basic kompiliert das Programm nur noch sporadisch, meist stürzt das gesamte Geos in den tiefen, dunklen Orkus. So habe ich jetzt schon einige Mal über die Aufteilung auf Bibliotheken nachgedacht. Die Funktionen zum Anzeigen und Speichern von Bildern sollten (hoffentlich!!!!!) recht problemlos auslagerbar sein. Aber bei den Funktionen zum Ermitteln der Bildinfos, sind Info-Ermittlung und UI-Code noch sehr vermischt. Da muß ich wohl eine extra Funktionsschicht zur Trennung einziehen. Zudem wäre ein Datentyp, der alle Bildinfos enthält, zu entwerfen. Was aber bei der Vielfalt der Bildmöglichkeiten nicht einfach wird. Das habe ich bislang immer hinausgeschoben. Zudem gibt es auch Formate, die mehrere Bilder enthalten, die auch noch unterschiedliche Größen usw. besitzen können. Wie die unterbringen, ohne unendlich Speicher vorab zu reservieren? Seufz ...

Wahrscheinlich werde ich dann mit einer zweiten Programmversion beginnen und peu à peu Code-Teile übertragen. Bin gespannt, wie gut das geht und wie lange das dauert. Hoffe, Ihr seid auch gespannt und bleibt dran !

Zitat von »Rainer«

Oh man, du führst mein armes Program echt an die physischen und psychischen Grenzen!

Tut mir leid , aber du kannst stolz auf dein Baby sein ! Allein schon, welche Textmengen es verarbeitet! Habe mal die Zeilen in den Code-Fenstern gezählt:

1.611
2.843
12.460
46.219
36
--------
60.169



Der Extremtest ist jetzt übrigens abgeschlossen, dein Programm kann sich verdient erholen!
Heute habe ich begonnen, die zweite Version meines Programms zu erstellen. Hier wird alles in Librarys ausgelagert.
Habe jetzt zu Beginn erstmal den UI-Code kopiert und zum Kompilieren gebracht.
Bevor ich mit den Bildern anfange, werde ich erstmal die UI in eine aktualiserte Form bringen. Kann sein, daß ich dabei deine neue Tab-UI-Funktion ausprobiere!