Xaaes bugrepoort

[rastr]

Wenn die Icons dann nicht richtig dargestellt werden, müssen die mit er richtigen palette eben neu gezeichnet werden. ende.

[Goli]

Der Knackpunkt ist aber, dass fvdi und XAaes die gleich Palette haben müssen, denn sonst funktioniert der Icon-Editor nicht. Und genau das haben wir herausgefunden. Über den langen Weg, na gut...

Ich denke auch, dass die meisten Icons die NVDI-Pallette wollen, aber einige eben nicht und dafür wurde wohl das remapping erfunden. Man kann natürlich auch die Icons entweder nicht verwenden oder einfach neu zeichnen. 

[rastr]

das AES hat mit der Palette eigentlich NULL zu tun

[HelmutK]

Das remapping ist von mir gewünscht, weil ich in XaAES die gem-Palette bevorzuge, die meisten icons aber für nvdi-Palette gemacht sind. Manche können auch auf irgendeiner beliebigen Palette basieren. Außerdem verlangt das die AES-Spezifikation, wo eine Palette im rsc-file enthalten sein kann, so dass der der die Icons gemacht hat, bestimmen kann, mit welcher Palette sie dargestellt werden. Ich glaub es ist sogar möglich, für jedes Icon eine separate Paltte zu definieren, das wird von XaAES allerdings nicht unterstützt.

Ich will in jedem Fall davon weg, dass man immer nur die eine Palette benutzen kann, das ist Schrott!

Man kann die fvdi-Palette ganz einfach in eine XaAES-Palette umwandelen, indem man

cat pa01 <fvdi-Palette> >XaAES-Palette

in einer shell eingibt

Die Datei pa01 enthält dann PA01 ohne newline..

[rastr]

ich als enduser mag mit dieser ummapperei nichts zu tun haben, eigentlch. denn mit der jetztigen methode wird man quasi dazu gezwungen sich damit zu beschäftigen. und das finde ich persönlich scheisse!
vorher ging es doch auch. wieso jetzt nicht mehr? wo ist das prob?
wenn es mehrere anwendungen gibt in einer palettenauflösung und jede anwendung einer eigene palette durchsetzt (auch nur beim fokus auf sie selbst) gibt es eine bunte hin und her blinkerei. ein kunterbunterhaufen an farben die der user dann sehen darf. und das empfinde ich als störend, schrottig und blöde.
in einer mehr als 8bittigen also 16 bittigen umgebung ist ein umappen eigentlich nicht mehr sinnvoll, da es kein palette im eigentlchen sinn mehr gibt. sie ist eher störend. warum also dort dem vdi in die methoden einmischen? wenn ds aes dann schon so weit geht, warum dann nicht gleich das gesamte vdi entfernen und ersetzen? das würde doch viel einfacher sein, oder?
aber sorry, seit einigen jahren empfinde ich die entwicklung hier eher als persönliche belange noch als allgemeinen fortschritt. aber das mag auch nur mich betreffen, denn sonst hat ja niemand den mum die schnauze aufzumachen.
sorry, hab schlechte laune!!

[HelmutK]

Du hast das ganze Konzept nicht verstanden. Lass einfach in xaaes.cnf alles mit pal* weg und Du bist glücklich.

[rastr]

das konzept ist scheisse, das ist ds prob. aber ich lass euch jetzt in ruhe weiter fummeln

[Arthur]

Für jeden Besitzer einer Grafikkarte ist das wohl ein interessantes Thema und es wäre schön wenn die Farben auch in höheren Farbtiefen nicht falsch rüber kommen.

[HelmutK]

das konzept ist scheisse, das ist ds prob. aber ich lass euch jetzt in ruhe weiter fummeln

Denkst Du - Du hast es ja auch nicht verstanden.

[rastr]

versteht doch bitte das vdi ist für die palette zuständig, nicht das aes
mit dem remapping wird alles verkompliziert.

[rastr]

erklärt mir das konzept hinter dem remapping. aus sicht des endanwenders. danke.

bitte ohne aes und vdi zu vermischen, danke

[HelmutK]

Lies alles nochmal von vorne, vielleicht wird's dann klar, keinen Bock alles nochmal zu wiederholen.

[rastr]

das sind die antworten, weshalb atari.anwender heute noch so zahlreich sind.
ich hatte 2005 oder so aufgegeben. anfang des jahres hatte ich mal wieder was versucht. ich hätte es nicht tun sollen. sorry.
sorry das ich fragen stelle die vielleicht nicht so genehm sind . sorry, ganz grosses
wird nicht wieder vorkommen.

[Goli]

So geht es mir auch oft. Ich möchte immer alles hinschmeissen und frage mich welcher Affe mich gebissen hat. Aber ernsthaft löse ich meine Probleme  schon lange nicht mehr mit dem Atari.  Für Entwickler ist das jedoch ein reizvolles System nach wie vor und es macht mir dann halt wieder Spaß damit zu experimentieren. Gerade das Aranym-System auf meinem kleinen Notebook ausschließlich unter Host-Medien ist jetzt, nachdem ich es erstmal eingerichtet habe, dermaßen flexibel, für Experimente und Tests ideal. Da ich jede Operation auch im Host machen kann und ständig hin und her springen kann. Es macht jetzt keinen Unterschied mehr, ob ich tar oder gzip auf der Hostconsole oder in toswin2 benutze. Wäre das nicht so, hätte die ganze Arie hier doppelt so lange gedauert. Natürlich habe ich vor Augen, dass die Entwicklungen letztlich für den Firebee- oder Atari-user gedacht sind. Nur mit einem Rechner unterhalb der Firebee, würde ich heute nicht mehr ernsthaft arbeiten. Andere wollen spielen. Das ist mein Spiel.

Ich finde das auch etwas kompliziert mit dem remapping, aber den Ansatz verstehe ich jetzt und ich denke man kann es so weiterentwickeln, dass jeder damit klar kommt und man davon profitiert.

Einstweilen habe ich mal eine saubere fvdi.pal erzeugt (für XAaes). Das Format mit den 4 zusätzlichen Bytes gibts doch eigentlich schon lange. Und man fragt sich, warum fvdi damit nicht zurecht kommt. Das Testicon mit der CD ist das mit der falschen Palette. Ich habe für meinen Desktop das mal gegen das richtige CD-Icon ausgetauscht, dass auch bei mir gut aussieht. Also nicht wundern, wenn die falsch aussehende Scheibe bei mir plötzlich richtig aussieht. Dieses auswählen der richtigen Icons, insbesondere gerade das CD-Rom-Icon habe ich auch früher so gemacht, daran erinnere ich mich noch sehr genau. Ich bin sogar der Meinung, dass ich damals mit ähnlichen Problemen kämpfte und schon das Matrix-Tool benutzt hatte, um mit der Palette zu spielen. Wenn ich dereinst wieder an meine Atari-festplatten rankomme, werde ich all die Software wiederfinden.

[Goli]

Das Format mit den 4 zusätzlichen Bytes gibts doch eigentlich schon lange. Und man fragt sich, warum fvdi damit nicht zurecht kommt

.
Ich weiß ja nicht, was das TOS-VDI und das NVDI machen, aber das fvdi-Format wird vom Matrix-Tool nicht geladen. Das deutet doch daraufhin, dass fvdi was falsch macht und das ist zumindest unbefriedigend.

[HelmutK]

Hast Du das probiert:

Man kann die fvdi-Palette ganz einfach in eine XaAES-Palette umwandelen, indem man

cat pa01 <fvdi-Palette> >XaAES-Palette

in einer shell eingibt

Die Datei pa01 enthält dann PA01 ohne newline..

[Goli]

Aber gebraucht wird gerade das umgedrehte. Denn die nvdi.pal und die gem.pal sind ja Referenz. Die würde ich nicht anzweifeln.

Im Falle des fvdi.pal, habe ich einfach fvdi die fvdii.pal laden lassen beim booten. Jetzt hat das Matrix genau diese Palette, wie wir ja längst wissen und dann habe ich aus Matrix die Palette exportiert. Das ergibt eine xaaes-fähige fvdi.pal.  Welche oben anhängt. Ein direktes Laden über das file-system der fvdii.pal in Matrix funktioniert nicht. Was wiederum ein Beweis ist, dass die Palette über das VDI geladen wird und nicht irgendwie über das Filesystem innerhalb von Matrix und gewiss auch vom IconEditor. Über das Filesystem lassen sich offenbar nur die langen PALs laden, was wiederum der IconEditor garnicht beherrscht.

Ich erwähne das nicht, weil ich damit nicht klar komme, sondern weil ich der Meinung bin, da sollte was geändert werden = Einheitliches Palettenformat

[HelmutK]

Sicher sollte da was geändert werden: Alle sollte nur das Matrix-Format verwenden (mit PA01 am Anfang). Aber das kann man wohl vergessen.

Etwas dumm ist zugegebenermaßen, dass XaAES .pal als Endung verwendet, so wie fvdi, und MyAES, die alle das einfache 1536-byte lange Format verstehen.

Deine Erklärung ist mir leider nicht so ganz klar geworden.

Also:
fvdi->XaAES: PA01 am Anfang einfügen
XaAES->fvdi: PA01 entfernen.

Wenn das nicht geht, stimmt noch was anderes nicht.
Das Matrix-tool streikt gelegentlich mit fvdi, da muss man schonmal Komplett-redraw machen, manchmal geht's garnicht.,  hab ich ja schon gesagt.

Man kann die Palette ja über XaAES laden (Ctrl-Alt-Shift-P), dann wirkt es nur auf die AES-Palette, oder in dem Programm selbst mit dem Disk-Icon, dann wirkt es auf die Palette in CXX-Setup. Die ist ja nicht dieselbe bei TC. Sollte zumindest so sein ..

[Goli]

Also:
fvdi->XaAES: PA01 am Anfang einfügen
XaAES->fvdi: PA01 entfernen.

Genau, das meinte ich. Ich habs nicht ausprobiert und weiß auch nicht, wie man die zweite Zeile durchführt (außer natürlich im Hexedit)

Ich habe es gemacht, wie oben beschrieben und wie wir empirisch herausfanden. Nämlich beim booten lädt das cx-Programm eine der beiden Paletten nvdi5.pal oder fvdii.pal. Durch speichern erzeuge ich dann die xaaes-taugliche Palette. Umgekehrt kann man über das Disk-Icon ja nur letztere Formate laden, und da fehlte mir halt das fvdi.pal. Da Deines ja nicht sauber war. Es ging mir eben gerade darum das kurze in das lange zu verwandeln und nicht umgekehrt. XAaes kann ja auch beides, die Palette beim booten laden, oder per shortcut über den FS. Das Matrix-Tool kann das auch, mit der Einschränkung des richtigen Formates, nur der IconEditor kann ausschließlich ersteres.

[HelmutK]

Das kurze in das lange verwandeln ist doch einfach: hab ich doch schon zweimal erklärt: mit cat.

Und außerdem sind  meine Paletten immer sauber!

Geht auch mit einem Einzeiler:

Code: [Auswählen]

echo -n PA01 >neu.pal && cat nvdi5.p >>neu.pal
nvdi5.p ist jetzt die Palette, die bei mir von fvdi geladen wird.