|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Amiga, AmigaOS 4 > Skinersteller(Grafiker) für Sudoku gesucht | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 2 -3- | [ - Beitrag schreiben - ] |
|
16.05.2006, 21:13 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Also 3 Bit? PNG und BMP in 3 Bit? Also zumindest beim BMP gibt es kein 3Bit. Bei BMP bin ich mir nicht sicher. Allerdings wenn man dann auch noch auf die Formate achten sollte, dann bräuchte man ja auch keine Datatypes. Dann wär das Konzept sinnlos. Aber da es ja so nicht ist, kann es vermutlich nur an der bekannten 24Bit-Sache liegen. Zitat: Schau ich mir später mal an. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
16.05.2006, 21:16 Uhr Ralf27 Posts: 2779 Nutzer |
@MaikG: Oder könntest du mir bitte die entsprechenden Bildateien zusenden? Ich würde mir das gerne mal ansehn, weil ich das ganze zur Zeit nur mit >8Bit-Bildformaten rekonstruieren kann. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 11:08 Uhr MaikG Posts: 5172 Nutzer |
>Also 3 Bit? PNG und BMP in 3 Bit? Also zumindest beim BMP gibt es >kein 3Bit. Bei BMP bin ich mir nicht sicher. Bei PNG&BMP gibts 2,4,8,16,32,64,128,256 Farben wie bei ilbm auch. >@MaikG: >Oder könntest du mir bitte die entsprechenden Bildateien zusenden? >Ich würde mir das gerne mal ansehn, weil ich das ganze zur Zeit nur >mit >8Bit-Bildformaten rekonstruieren kann. Muss ich dir heute Nachmittag nochmal umwandeln. Warum hast du kein PPaint oder Picconvert? [ Dieser Beitrag wurde von MaikG am 17.05.2006 um 11:09 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 13:12 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Gerade im Punkt BMP kann ich dir da nicht zustimmen. Gerade mit BMP hab ich mich genauer befast. So gibt es bei BMP nur 1,4,8,16,24,32Bit, wobei 16 und 32 sehr selten anzutreffen sind. Das bedeutet-> 2,16,256, ... Farben. Wenn du jetzt 8Farben hast, dann wird vermutlich ein 4Bit-BMP benutzt. Aber <=8Bit ist ja auch nicht das Problem, sondern das bekannte 16/24-Bit-Problem bei den Datatypes. Jedenfalls hab ich da schon einige hier in Foren gelesen, aber mich selbst nie richtig damit befast. Zitat: Logisch hab ich PPaint, aber ich würde zu gerne wissen was da genau das Problem macht. Z.b. Das Bildformat, die Farbtiefe, vielleicht ein fehlerhaftes Bilformat oder das Datatype. Bzw. wo ich anpacken sollte. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 13:24 Uhr Ralf27 Posts: 2779 Nutzer |
Hab es eben getestet. Also, die Bilder werden richtig geladen, aber die Maske ist da das Problem. Tausche einfach mal die PNG oder BMP-Masken gegen die Originalmasken aus und dann geht es. Mir ist nicht klar wieso die Maske da bei denn anderen Bildformaten Probleme hat, aber z.b mit GIF geht es. Oder moment... da wurde vermutlich Vordergrundfarbe-Hintergrundfarbe verwechselt. Das wird es sein. Das schau ich mir jetzt mal an. An die einfachsten Sachenn denkt man ja erst am Schluss..  EDIT: Ja, genau das ist es. Kein Wunder das es dann so seltsam aussieht. Dann werden die Bildbereiche geblittet die nicht geblittet werden soll und anderstherum. Also kein Problem am Programm, Datatype oder Bildformat, sondern viel mehr am Bild selbst, das Hintergrundfarbe und Vordergrundfarbe vertauscht hat. -- http://www.alternativercomputerclub.de.vu [ Dieser Beitrag wurde von Ralf27 am 17.05.2006 um 13:27 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 13:48 Uhr Ralf27 Posts: 2779 Nutzer |
Noch eine kurze Anmerkung: Das >8Bit-Problem besteht aber noch. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 18:20 Uhr MaikG Posts: 5172 Nutzer |
>Also kein Problem am Programm, Datatype oder Bildformat, sondern viel mehr am Bild selbst, das Hintergrundfarbe und Vordergrundfarbe vertauscht hat. Wenn ich die Farben umtausche gehts dann? Mich wunderts warum Picconvert sowas machen sollte. Mit der Original Mask muss ich erst gucken ob die ChipMem verbraucht :-) [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 20:00 Uhr MaikG Posts: 5172 Nutzer |
Also mit Original Skin gehts, aber mit dem einen Skin frisst sudoku immernoch mehr als 250 kb ChipMem. Trotz PNG, du verwendest da scheinbar doch Routinen mit falschen Parameter etc. So nun wollte ich mal kurz gucken ob es mit umgetauschen Farben geht, also farben ausgetauscht -> geht nicht. [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 20:28 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Einfach Farben wechseln reicht nicht. Eigentlich sind die Farben ja auch egal. Du solltest nur darauf achten das ein gesetztes Pixel geblittet wird und wenn kein pixel gesetzt ist dann eben nicht. Und es geht damit. Und genau das ist bei deinen PNGs und BMPs invertiert. Und was kann ich dafür wenn die Datatypes Chipram fressen? Vielleicht gibt es Parameter das die es nicht machen. Aber die wollen ja die Bitplanes zum blitten ja für die kleinen Maschinen im Chipram haben, was ja auch eigentlich nicht verwunderlich ist. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 20:31 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Hast du Picconvert mitgeteilt das es eine Maske ist?  Ich glaube Picconvert behandelt das Bild nur als Bild. Hört sich jetzt zwar seltsam an, wird aber einfach so sein. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
17.05.2006, 23:38 Uhr MaikG Posts: 5172 Nutzer |
>Und was kann ich dafür wenn die Datatypes Chipram fressen? Ralf, nur der ilbm.datatype frisst von sich aus Chipram. Wenn du Datatypes richtig benutzt dann kommt es bei den anderen nicht dazu. Ich hab dir gesagt wo die Beispiele zu finden sind. >Vielleicht gibt es Parameter das die es nicht machen. >Aber die wollen ja die Bitplanes zum blitten ja für die kleinen >Maschinen im Chipram haben, was ja auch eigentlich nicht >verwunderlich ist. Wenn du 24 Bit, einmal auf 8Bit und einmal auf 16/24 Bit darstellen willst musst du ggf. dein Programm anpassen. Du brauchst für Soduko doch aber max. 8 Bit. >Hast du Picconvert mitgeteilt das es eine Maske ist? >Ich glaube Picconvert behandelt das Bild nur als Bild. >Hört sich jetzt zwar seltsam an, wird aber einfach so sein. Ich hab die Masks noch mit PPaint behandelt/umgewandelt, ich habe auch versucht das Bild selbst zu inventrieren also nicht nur die Farben zu tauschen. Von "Masks" an sich hab ich keinen Schimmer... [ - Antworten - Zitieren - Direktlink - ] |
|
22.05.2006, 16:00 Uhr MaikG Posts: 5172 Nutzer |
By the Way, das Problem mit dem Fehlenden teil des Skins(thetopboarder) bestand ebenfalls unter AGA. Hab ebend meine Schwester getroffen, sie sagt "die 9 ist bei mir auch nicht vollständig zu sehen". Sie hat noch die ältere Version, benutzt DBLPAL 680x512x7. Hat keine Grafikkarte nur einen A1200 mit 030er TK. [ - Antworten - Zitieren - Direktlink - ] |
|
22.05.2006, 16:17 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: also, nochmal von vorne: Sowas wie TheTopBoarder gibt es nicht. Ich hab es früher nie benutzt und wurde stutzig als du es mir mal getippt hast. Und ich benutze es jetzt nicht. Das Problem war viel mehr das ich von Zahlenwerten auf Konstanten aus den Includes umgestiegen bin und da dann einige Werte verwechselt habe. Der Fehler wurde ja in einem anderen Thread behoben. In deinem Fensterbeispiel hast du ja auch gezeigt das du einige Parameter wild durcheinanderwürfelst wie z.b. Innen- und Außenangaben. Deswegen kann es dann auch vorkommen das das Fenster halt nicht so geöffnet wird wie du es möchtest und du dann Zahlen hinzuaddieren mußt. Desweiteren wäre es wohl einfach ein GimmeZeroZero-Fenster zu benutzen, anstatt 0,0 im Fensterrand liegen zu lassen und dann die unnötigen Addieraktionen zu starten. Ich glaube, du machst es dir da wirklich unnötig schwer.  Achja, ich entwickle unter AGA und das von dir beschriebene war das Ergebniss der Umstiegsaktion von Zahlenwerte auf Includes, aber das hat sich schon vor einiger Zeit schon geklärt (wie ich auch schon ein paar Zeilen weiter oben getippt habe). Nochwas zu DBLPAL: Wieso 7 bit und nicht gleich 8? Außerdem ist das wirklich extram lahm mit AGA. Bis 4Bit geht es noch, aber ab 5bit wird es schlagartig langsamer. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
22.05.2006, 18:29 Uhr MaikG Posts: 5172 Nutzer |
>Sowas wie TheTopBoarder gibt es nicht. Bei mir schon aber heisst eigentlich TheTopBorder, ich mach immer ein a zuviel. >Der Fehler wurde ja in einem anderen Thread behoben. Ja, war nur so eine anmerkung, weil du sagtest unter AGA tritt das nicht auf. >In deinem Fensterbeispiel hast du ja auch gezeigt das du einige >Parameter wild durcheinanderwürfelst wie z.b. Innen- und Außenangaben. Ja, woher ich den schwachsinn habe... Hab ich korregiert. >Deswegen kann es dann auch vorkommen das das Fenster halt nicht so >geöffnet wird wie du es möchtest und du dann Zahlen hinzuaddieren >mußt. Desweiteren wäre es wohl einfach ein GimmeZeroZero-Fenster zu >benutzen, anstatt 0,0 im Fensterrand liegen zu lassen und dann die >unnötigen Addieraktionen zu starten. Da du AGA hast bemerkst du keinen unterschied zwischen GZZ und ohne GZZ. Mit dem Addieren von thetopborder ist das Fenster jedoch erheblich schneller. Es ist ja nicht nur die Titelzeile die da von Intuition weggerechnet werden muss sondern alle Rahmen um das Fenster. Gut, bist ja nur AGA gewöhnt. >Nochwas zu DBLPAL: Wieso 7 bit und nicht gleich 8? Damit die 2MB WHDLoad spiele noch laufen, ausserdem ist 7 Bit etwas schneller als 8 Bit. >Außerdem ist das wirklich extram lahm mit AGA. Bis 4Bit geht es >noch, aber ab 5bit wird es schlagartig langsamer. So lahm ist das nicht, jedenfalls nicht mit 030er. Die Fenster+Icons sind da immernoch schneller als unter Windows :-) [ - Antworten - Zitieren - Direktlink - ] |
|
22.05.2006, 20:28 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Ja, am Anfang. Aber als ich den Font größer machte hab ich das auch gemerkt. Das war dann wirklich auf allen Systemen der gleiche Fehler. Jetzt läuft es aber auch bei allen richtig, auch auf dem AOne, und das heißt schon was. Zitat:Du hast mir damals mal getippt das du es aus einem Beispiel her hast (wenn ich das richtig in Erinnerung habe) Zitat:Da läuft schon etwas anderes ab: Zum einen muß ja nur ein Wert bei X und einer bei Y dazuadiert werden. Was denn noch? Außerdem bin ich nicht nur AGA gewöhnt. Jetzt rate mal wieso ich auch einige CybergraphX-Programme für denn eigenen gebraucht programmiert habe? Ich hatte hier wirklich einige Jahre lang ein A1200T mit allem drum und dran denn ich jetzt auch noch habe, aber leider läuft er zur Zeit nicht.Zitat:Ab 4 Bit macht das System merklich runter in die Knie. Da macht der Unterschied zwischen 7 und 8 Bit kaum noch was aus, bzw. drüfte man das eigentlich schon nicht mehr bemerken. Und ich bezweifle äußerst stark das das immer noch schneller ist als Windows. Ok, wenn man vielleicht Win98 auf einem 486er laufen lassen möchte der nur 8MB zur Verfügung hat. Aber selbst da... -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
22.05.2006, 21:13 Uhr DaxB Posts: 1422 Nutzer |
Kann da Ralf zustimmen... bei 4bit ist so die Grenze. Eigentlich schon bei 3bit. Selbst mit FBlit, SystemPatch und Co. PAL ist da etwas schneller. [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 00:14 Uhr MaikG Posts: 5172 Nutzer |
>Du hast mir damals mal getippt das du es aus einem Beispiel her hast >(wenn ich das richtig in Erinnerung habe) Ja, die mischung von width und innerhigh, aber was das mit dem thetopborder in der Windowtaglist war ich wohl selber... >Da läuft schon etwas anderes ab: Zum einen muß ja nur ein Wert bei >X und einer bei Y dazuadiert werden. Was denn noch? Na, du darfst ja nicht bei 0,50 anfangen zu Malen/Schreiben etc. sondern bei 5,50 und du darfst auch bei XFensterende noch schreiben sondern nur bis XFensterende-4(kleinster Rahmen). Also nicht nur was Addieren sondern auch begrenzen. >Außerdem bin ich nicht nur AGA gewöhnt. Schonmal den unterschied selbst ausprobiert? Ich mein wenn du thetopborder noch nie benutzt hast... GMZ gibts sogar bei MBasic Fenster, guck mal im Buch. >Ab 4 Bit macht das System merklich runter in die Knie. Da macht der >Unterschied zwischen 7 und 8 Bit kaum noch was aus, bzw. drüfte man >das eigentlich schon nicht mehr bemerken. Ich merk das, hauptgrund ist aber mangelnder Chip-Speicher. >Und ich bezweifle äußerst stark das das immer noch schneller ist >als Windows. Ok, wenn man vielleicht Win98 auf einem 486er laufen >lassen möchte der nur 8MB zur Verfügung hat. Aber selbst da... Ich meine jetzt, es ist Schneller Work zu öffnen als auf Windows laufwerk C: Die Grafik ist unter 030er etwas schneller als mit 060er und viel schneller als mit BlizzardPPC. Der 030 hat da noch ein paar Bussachen eingebaut, die der 060er nicht hat und die BPPC ist sowieso ein einziger BUG(in dem Falle Chipmem kann nicht gecacht werden). [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 15:00 Uhr Holger Posts: 8116 Nutzer |
Zitat: GZZ-Fenster besitzen für Rahmen und Inhalt getrennte Layer. Vom Resourcenverbrauch ist das also so, als ob Du zwei Fenster geöffnet hättest. Wenn Du dagegen lediglich einen x,y Offset von Hand addierst, bist Du um Welten effizienter. Selbst wenn Du noch manuell auf Einhalten der Breite und Höhe achten mußt, bist Du noch effizienter. Wenn Du eine Reihe von Grafikoperationen durchführen mußt, bei denen vorher nicht klar ist, ob sie den Randbereich überschneiden, kannst Du vor den Operationen auch ein ClipRect im Fenster installieren, um das Übermalen des Rahmens zu verhindern. Auch das ist immer noch deutlich effizienter als ein GZZ-Fenster zu verwenden. Natürlich gilt trotzdem immer noch die Frage, wie wichtig dieser Performance-Unterschied im Vergleich zur vordringlichen Aufgabe, überhaupt erst mal Software zu schaffen, ausfällt. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 16:07 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Wie hoch wäre der denn? Die Struktur des Fensters, vielleicht noch weitere kleine und das dürfte es doch gewesen sein. Als 1-2KB... oder überseh ich da jetzt was? Zitat:Bedenke das ich in Basic programmiere, da dürfte schon mindestens ein/zwei Welten weniger dramatisch sein. Aber selbst im MaxonBasic-Handbuch ist GZZ als schneller beschrieben. Ich kann es ja mal testen ob es denn Mehraufwand wert ist. Das aktuelle Projekt braucht ja nicht gerade eine hohe Geschwindigkeit. Zitat:Das ist es ja. Ich kann GZZ ja mal mit und ohne testen. Hm, das hätte ich auch schon beim Cybershow und BMP-Reader benutzen können... Ich mach später mal Speedtests. -- http://www.alternativercomputerclub.de.vu [ Dieser Beitrag wurde von Ralf27 am 23.05.2006 um 16:08 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 17:42 Uhr Ralf27 Posts: 2779 Nutzer |
War kurz mal im eigenen Code... also ich benutze keine GZZ auf meinem eigenen Screen (Fenster ist da ohne Border) und nur auf der WB mit GZZ. Ich konnte da auf dem ersten Blick keinen großen Unterschied sehn. Aber das Programm braucht ja auch kein HighSpeed. Um mal wieder etwas OnTopic zu kommen ( ):Ich suche als noch Grafiker bzw Pixelwütige und jetzt auch SFXer, bzw. Leute mit einem guten Gehör für Sound -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 19:03 Uhr Holger Posts: 8116 Nutzer |
Zitat: So etwas merkst Du ja auch nicht, wenn Du Dir Dein Programm ansiehst. Wenn sich 50 Fenster auf der Workbench tummeln, dann merkst Du, ob Du 50 normale oder 50 GZZ-Fenster offen hast. Wenn ein Fenster GZZ ist und die anderen 49 keine sind, merkst Du natürlich auch nix. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 19:25 Uhr MaikG Posts: 5172 Nutzer |
Also ich merke den Unterschied. Beim MBasic Proggen sind etwa 4-5 Fenster offen. [ - Antworten - Zitieren - Direktlink - ] |
|
23.05.2006, 19:35 Uhr bubblebobble Posts: 707 Nutzer |
GZZ Fenster sind etwa halb so schnell. Ich kann nur sagen: Finger weg, sofern es sich nicht nur um ein Testprog für den Eigenbedarf handelt. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
25.05.2006, 16:09 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Hm, und das wo ich diese Fenster gerade so lieb gewonnen habe.  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
28.06.2006, 23:02 Uhr Ralf27 Posts: 2779 Nutzer |
Ich suche immer noch User die mir in Sachen Grafik unter die Arme greifen könnten. Da ich jetzt auch noch eine Animationsmöglichkeit eingebaut habe, kann man schon recht viel machen. Ich hab jetzt zwei Abende lang versucht was ansehnliches selbst zu machen, aber leider ohne großen Erfolg, da ich leider in Sachen Pixeln nicht gerade gut bin. Gibt es wirklich keinen mehr da drausen der mir da helfen könnte/möchte? Leuts, ich brauch eure Hilfe!  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
29.06.2006, 14:07 Uhr Holger Posts: 8116 Nutzer |
@Ralf27: Hast Du mal einen Aufruf als News gepostet? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.06.2006, 20:38 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Ja, ich hab das auch schon ins ANF geschrieben. Hm, schade das es halt so aussieht. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
| 1 2 -3- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Amiga, AmigaOS 4 > Skinersteller(Grafiker) für Sudoku gesucht | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|