Sie sind nicht angemeldet.
Lieber Besucher, herzlich willkommen bei: GEOS-InfoBase-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Donnerstag, 3. Februar 2022, 19:02
1. ReadBitmapFromFile liest auch transparente BMP 's unter Beibehaltung der Transparenz.
2. Es gibt sehr viele Versionen des Icon-Editors. Der Icon-Edito auf meiner (R-BASIC) Webseite sollte stabil laufen. Ich benutze ihn ständig.
3. Mit "In Datei speichern" schreibt der Icon-Editor die Bitmap als HugeArrary in eine VM-Datei, wobei der Kopfblock des HugeArray als Mapblock gesetzt wird. Aus GEOS-Sicht ist das die primitivste aller Varianten. Mit der VMFiles Library könntest du da rankommen, möglicherweise musst du aber Klimmzüge machen, weil, wenn ich mich recht erinnere, der Mapblock aus BASIC-Sicht nicht der aus SDK-Sicht ist. Das steht alles in der Doku.
Donnerstag, 3. Februar 2022, 19:33
). Dieser Quellcode und die ganze Bitpopelei hat es wirklich in sich: Erst heute konnte ich alle Fehler in meiner R-BASIC-Portierung finden und ein regelkonformes GIF87A in 32x32px ausgeben. Das ganze braucht noch ziemlich viel Zeit und unterstützt noch keine Transparenz (erst mit GIF89A möglich) - aber der Anfang ist gemacht.
Donnerstag, 3. Februar 2022, 21:19
Wenn ich das richtig im Blick habe, klappt der GIF-Export beim Screen Dumper gut. Wenn hingegen GeoDraw-Grafik nach .GIF exportiert wird, bzw. ein ScreenShot aus der Zwischenablage in GeoDraw eingefügt und dann nach .GIF exportiert wird, werden horizontal und vertikal jeweils ein oder zwei weiße Pixelzeilen hinzugefügt.Den GIF-Decoder habe ich irgendwo in Netz gefunden und an GEOS angepasst. Einen Encoder habe ich nie versucht, die Algoithmen empfinde ich als ziemlich komplex. Aus heutiger Sicht muss man sehen, dass es in GEOS schon einen GIF Encoder gibt (für die Export-Funktion in GeoDraw). Der ist allerdings nicht perfekt, die Bilder sind z.T. pixelweise verschoben. Man müsste ihn also noch mal durchchecken oder gleich einen neuen schreiben. Und ich hatte damals auch keinen Zugriff darauf und ob und wie das aktuell geht, weiß ich nicht.
Also jein, vom Prinzip her müsstes du wohl einen Encoder schreiben. Unter R-BASIC könnte das aber sehr langsam werden. Vielleicht findet sich ja ein anderer Weg.
..Hier komme ich nun auch langsam voran
Echt beeindruckende R-BASIC-Programmierleistung! Lässt mich irgendwie vor Neid erblassen...Nachdem ich das Thema schon vor einiger Zeit aufgrund der Komplexität ad acta gelegt hatte, habe ich mich nun nochmal tiefer damit beschäftigt: Es gibt im QuickBasic-Bereich zahlreiche antiquierte Code-Schnipsel für allerlei Funktionen und Probleme, welche man mit mehr oder weniger Aufwand nach R-BASIC portieren kann. Allerdings gibt es für die Ausgabe von GIF-Dateien nur einen einzigen sinnvollen Quellcode für QuickBasic. Und zwar den von Rich Geldreich aus dem Jahre 1992 (ja, der Mann hieß wirklich so ). Dieser Quellcode und die ganze Bitpopelei hat es wirklich in sich: Erst heute konnte ich alle Fehler in meiner R-BASIC-Portierung finden und ein regelkonformes GIF87A in 32x32px ausgeben. Das ganze braucht noch ziemlich viel Zeit und unterstützt noch keine Transparenz (erst mit GIF89A möglich) - aber der Anfang ist gemacht.
Wie Rainer schon bemerkte, wird das Speichern dieses Formates mit in R-BASIC geschriebenen Code immer eine Weile dauern - aber ich finde das ist ein vertretbares Übel.
Freitag, 4. Februar 2022, 12:21
Ich bin nach Optimierung des Codes jetzt bei 3 Sekunden für ein 32x32px-Icon. Für die Zwecke des Pixel-Editors mit kleinen Bildabmessungen sollte das für's Erste reichen. Ich würde die resultierende Arbeitsunterbrechung dann auch mit "Hier wird noch jedes Pixel schonend von Hand kaltgepresst" schmücken.Meine Befürchtung ist, dass der Export bei etwas größeren Grafiken doch seeehr langsam sein könnte.
Vielleicht gibt es doch eine Möglichkeit, auf den vorhandenen Exportfilter zuzugreifen? Sollte man mal Falk zu dem Thema kontaktieren?
Freitag, 4. Februar 2022, 20:15
Dennoch, und da gebe ich dir recht, kann es sich dabei nur um eine Quick&Dirty-Lösung für o.g. Zweck handeln - für größere Bilder oder gar Animationen benötigt man dann zwingend eine SDK-Library, welche idealerweise auf einer aktuellen Open-Source Grafik-Library basiert.
Samstag, 5. Februar 2022, 11:30
Ja, stimmt, die Wartezeit ist noch völlig ok. Ein Haupteinsatzzweck wäre ja auch das Zeichnen von Icons. Ich freue mich schon und bin gespannt, wie schnell die App unter DOSBox läuft.Ich bin nach Optimierung des Codes jetzt bei 3 Sekunden für ein 32x32px-Icon. Für die Zwecke des Pixel-Editors mit kleinen Bildabmessungen sollte das für's Erste reichen. Ich würde die resultierende Arbeitsunterbrechung dann auch mit "Hier wird noch jedes Pixel schonend von Hand kaltgepresst" schmücken.Meine Befürchtung ist, dass der Export bei etwas größeren Grafiken doch seeehr langsam sein könnte.
Vielleicht gibt es doch eine Möglichkeit, auf den vorhandenen Exportfilter zuzugreifen? Sollte man mal Falk zu dem Thema kontaktieren?
Donnerstag, 10. Februar 2022, 22:55
Sehr schön!habe es gerade ausprobiert, er hat sogar eine FLI-Datei geladen ...
Das habe ich noch nicht probiert. Aber er prüft alles mit GetImageInfo() und wenn es mindestens 1 Bild hat, wird es geöffnet. Das ist definitiv kein normales Verhalten. Bilder, welche keine Palette haben? Also Truecolor 24-Bit? Hier sollte er sich hilfsweise aus einer 8-Bit-BitmapContent die Palette laden. Wenn dies aber z.B. eine 24-Bit-BMP-Grafik mit einer Maske ist, kann es zu Problemen kommen. Diese Kombination unterstütze ich nämlich noch nicht. Kannst du mir die Datei sonst einmal per Mail schicken?
Zitat
1. Wenn ich ein Bild laden will, das keine Palette hat, beendet sich das Programm. Warum? Ich würde dann die "Standard-Palette" aktivieren. Oder zumindest das Programm weiterlaufen lassen.
Das ist richtig. Ich habe den Fokus derzeit auf Grafiken bis ca. 48x30 gelegt, da auch die Performance bei größeren Grafiken noch verbesserungswürdig ist. Ich schau aber einmal, ob ich eine ausklappbare, größere Ansicht einbauen kann. Die Palette gefällt mir aktuell auch noch nicht - hier wird definitiv noch etwas dran gemacht.2. Für größere Bilder ist der Vorschaubereich definitiv zu klein. Der Palettenbereich ist mir auch zu klein :-)
Freitag, 11. Februar 2022, 13:51
Das ist richtig. Ich habe den Fokus derzeit auf Grafiken bis ca. 48x30 gelegt, da auch die Performance bei größeren Grafiken noch verbesserungswürdig ist. Ich schau aber einmal, ob ich eine ausklappbare, größere Ansicht einbauen kann. Die Palette gefällt mir aktuell auch noch nicht - hier wird definitiv noch etwas dran gemacht.2. Für größere Bilder ist der Vorschaubereich definitiv zu klein. Der Palettenbereich ist mir auch zu klein :-)
Sonntag, 13. Februar 2022, 21:10
Ich teste gerade eine Variante, die Palette unten an der Stelle (jedoch etwas größer) zu belassen und die Vorschaugrafik als extra Dialog auszuführen. Dieser ist mit einer ViewControl verbunden und unterstützt somit auch Zoom usw. Ich mag solche schwebenden Fenster auch nicht. Die Alternative wäre aber sehr viel graue Fensterfläche, wenn man nur kleine Grafiken bearbeitet - das sieht auch nicht schön aus und vergiftet die Kompaktheit der Oberfläche. Vorteil von diesem Dialog ist auch noch, dass man ihn zwischenzeitlich schließen kann, wenn man wirklich gerade keinen Platz hat.Eigentlich mag ich keine Schwebepaletten (nennt man das so?). Vielleicht, weil es die großen GEOS-Programme damit übertreiben und man manchmal das ganze Display mit Dialogen gepflastert hat...
Im Fall deines Grafikprogramms kann ich mir aber sehr gut ein zusätzliches Fenster vorstellen, das die Farbpalette und die Vorschau aufnimmt. Dann hast du mehr Platz und der Nutzer schiebt es hin, wo es nicht stört.
Für 48x30 scheint mir das doch recht lang. Weißt du zum Vergleich aus dem Kopf deinen Wert aus SPEED ? (Ich kann mit den 60000 Cycles nichts anfangen, da ich in keinem Emulator arbeite).Ausserdem habe ich vorhin mal die Zeit gestoppt: Das Speichern der kleinen Testgrafik .BMP als GIF hat auf meinem alten Mac und DOSBox mit 60000 cycles ca. 22 Sek gedauert.
Sonntag, 13. Februar 2022, 21:36
Ich glaube, du findest da eine gute Lösung.Ich teste gerade eine Variante, die Palette unten an der Stelle (jedoch etwas größer) zu belassen und die Vorschaugrafik als extra Dialog auszuführen. Dieser ist mit einer ViewControl verbunden und unterstützt somit auch Zoom usw. Ich mag solche schwebenden Fenster auch nicht. Die Alternative wäre aber sehr viel graue Fensterfläche, wenn man nur kleine Grafiken bearbeitet - das sieht auch nicht schön aus und vergiftet die Kompaktheit der Oberfläche. Vorteil von diesem Dialog ist auch noch, dass man ihn zwischenzeitlich schließen kann, wenn man wirklich gerade keinen Platz hat.Eigentlich mag ich keine Schwebepaletten (nennt man das so?). Vielleicht, weil es die großen GEOS-Programme damit übertreiben und man manchmal das ganze Display mit Dialogen gepflastert hat...
Im Fall deines Grafikprogramms kann ich mir aber sehr gut ein zusätzliches Fenster vorstellen, das die Farbpalette und die Vorschau aufnimmt. Dann hast du mehr Platz und der Nutzer schiebt es hin, wo es nicht stört.
Ausserdem habe ich vorhin mal die Zeit gestoppt: Das Speichern der kleinen Testgrafik .BMP als GIF hat auf meinem alten Mac und DOSBox mit 60000 cycles ca. 22 Sek gedauert.
Speed liegt so um 2437. Auf meinem mac mini M1 siehts schon besser aus: Mit DOSBox und 100000 cycles waren es 13 Sek. Speed liegt dann bei 3980.Für 48x30 scheint mir das doch recht lang. Weißt du zum Vergleich aus dem Kopf deinen Wert aus SPEED ? (Ich kann mit den 60000 Cycles nichts anfangen, da ich in keinem Emulator arbeite).
Mittwoch, 16. Februar 2022, 18:11
Ich teste gerade eine Variante, die Palette unten an der Stelle (jedoch etwas größer) zu belassen und die Vorschaugrafik als extra Dialog auszuführen.
Donnerstag, 31. März 2022, 22:55
Dies wird aktuell nur durch "Transformieren..." in der Statusleiste signalisiert. Ein Markbusy gehört da aber auf alle Fälle noch rein. Gerade bei größeren Bildern mit Transparenz dauert es sicher mitunter sehr lang. Performancetechnisch sind die 4 Funktionen aber auch noch optimierbar.1. Bei längeren Operataionen (z.B. drehen nach rechts) bekommt der Nutzer kein Feedback. -> Mindestens MarkBusy aufrufen, bessere noch einen App-modalen Dialog starrten "Bitte warten .... "
Das ärgert mich jetzt, da dies eines der aufwendigeren Dinge bei den Dreh-Transformationen war und ich meinte dies ausgiebig getestet zu haben.2. Beim Drehen einer nichtquadratischen Bitmap wird entdweder das neue Format nicht angpasst, oder es ist nur ein Problem mit der Vorschau. Jedenfalls wird ein 128x196 Bild nicht zum 196x128 Bild. Beim Zurückdrehen ist es dann aber wieder OK. Irgendwie seltsam.
Die Idee von Bernd fand ich ja mega.Ansonsten...
- gefällt mir das Burger-Menü im Vorschaufenster :-)
- wünsche ich mir eine Voranzeigder Bildgröße im "Öffnen" Dialog
- Ein Problembild schicke dir per Mail
Ich musste das einfach übernehmen. Gerade bei so kompakten Dialogen macht so ein Hamburger-Menü richtig was her.
Freitag, 1. April 2022, 08:59
Dies wird aktuell nur durch "Transformieren..." in der Statusleiste signalisiert.
Das ärgert mich jetzt, da dies eines der aufwendigeren Dinge bei den Dreh-Transformationen war und ich meinte dies ausgiebig getestet zu haben.
Hast du vor dem Transformieren den Bildbereich selektiert oder nicht?
Freitag, 1. April 2022, 21:28
Samstag, 2. April 2022, 21:35
Danke dir. Ich hatte tatsächlich trotz 'customize Toolbars' nichts dergleichen in GeoDraw gefunden.1. Tolle Programmierleistung, Mario.
2. Zumindest für die "Objekt spiegeln"-Icons gäbe es auch Icons in GeoDraw.
3. Für das Icon des Hamburger-Menüs hat sich nach einigem Ausprobieren eine Größe von 24x10 bei mir als praktisch herausgestellt. Das fügt sich unter der Motif- und ISUI-Oberfläche halbwegs harmonisch in die Titelleiste ein.
PC/GEOS »
OS/90- und Beta-Bilder auf Verpackung und Quickstart !!
(21. Mai 2008, 11:05)
PC/GEOS » Letzte Fragen: PC/GEOS,BETA, BSD,SPARCstation 1
(7. Juni 2010, 14:46)
PC/GEOS » $500 für Geoworks BETA! / Weltweite Suche gestartet...
(16. Dezember 2009, 08:08)
Altes Forum » Ist NDO2000 Release 4 die endgültige Version?
(3. Juli 2008, 06:48)
Altes Forum » FTP
(10. Juni 2008, 03:34)
