Autor Thema: Xaaes bugrepoort  (Gelesen 150672 mal)

0 Mitglieder und 3 Gäste betrachten dieses Thema.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #120 am: Fr 15.02.2013, 22:32:36 »
@oneSTone o2o hast Du denn freemint am laufen? Du musst das neueste Paket aus dem daily bild downloaden. Link findest Du im Firebee Thread oben. Da ist auch das neueste XAaes drin, Vorstufe zum nächsten release 1.18. Läuft unter Beta, die 1.19-cur

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #121 am: Fr 15.02.2013, 22:43:18 »
Damit's nicht langweilig wird. Gemclip macht komische Redraw Sachen. Schätze aber, ist selbst dran schuld.


Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #122 am: Fr 15.02.2013, 23:00:22 »
Also leider ist es dann wieder essig, wenn ich auf 32 zurücksetze. Vorher machte TeraDesk den Auswahlbalken in den files blau, jetzt ist er wieder schwarz. Und rsm hat wieder die fvdi.pal im Farbkeil.   >:(

Kann man vielleicht rsm beibringen mit 8 zu starten? So über app_options oder so was? Dann wäre man ja aus dem Schneider, was die Icons betrifft. Und sicher hat das für die andern Widgets und Objekte auch keine negative Auswirkung, oder gibt's dann Probleme mit texture?  ???

Die CICONS.RSC habe ich natürlich gespeichert, das ist ein umständliches aber mögliches Verfahren.

Auf jeden Fall geht es nicht in fvdi.sys die palette einzustellen.  ::)



Die Farbtiefe lässt sich nur in fvdi.sys einstellen, das geht nicht für jedes Programm extra, ist doch wohl klar!

Bei 8 bit-video zeigt rsm die Systempalette an. Man kann die auch nachträglich jederzeit mit Ctrl-Alt-Shift-P laden, und die Farbpalette im Bildeditor ändert sich entsprechend.
Welche Farbtiefe aktiv ist, sieht man im Systemfenster (Ctrl-Alt-B) unter System->Video.

Offline Arthur

  • Benutzer
  • Beiträge: 10.311
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: Xaaes bugrepoort
« Antwort #123 am: Fr 15.02.2013, 23:28:00 »
Was ein Krampf mit den Paletten. Für jede Farbtiefe eine eigene Resourcedatei würde das Problem ja auch nicht ändern, oder?

Offline jens

  • Benutzer
  • Beiträge: 4.637
  • Halleluja, I'm on Highwire...
Re: Xaaes bugrepoort
« Antwort #124 am: Fr 15.02.2013, 23:33:27 »
Nein. Man kann entweder die Resourcen für höhere Auflösungen durch die für niedrige Auflösungen ersetzen, oder man muß basteln, bis es paßt.
Gruß, Jens
 
Falcon 030, TT 030, Mega/STe, ST-Book, 1040 STf, 520 ST+ - Milan 060
Diverse PCs und Macs sowie Amiga 1200 und 3000
 
Classic Computing

jabber: gemini8@atari-jabber.org

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #125 am: Fr 15.02.2013, 23:57:03 »
Zitat
Die Farbtiefe lässt sich nur in fvdi.sys einstellen, das geht nicht für jedes Programm extra, ist doch wohl klar!
Klar!

Zitat
Bei 8 bit-video zeigt rsm die Systempalette an.
Aber warum nur da?

Zitat
Man kann die auch nachträglich jederzeit mit Ctrl-Alt-Shift-P laden, und die Farbpalette im Bildeditor ändert sich entsprechend.
Passiert bei mir garnichts. D.h. im Vorschaufenster von rsm tut sich sehr wohl was (hellroter Rasterhintergrund wird zu weinrotem Raster), aber der farbkeil im Iconeditor bleibt immer auf fvdi.pal, egal ob ich nvdi.pal oder gem.pal nachlade, d.h. rote Kreuze im Icon werden unter 256 Farben grün dargestellt. Und in der Vorschau verändern sich dei Icons geringfügig, rote teile werden z.B. dunkler unter nvdi.pal

Das System gibt aus:
video: 800x608x32, 256 Farben, Format MOT
Zitat
Welche Farbtiefe aktiv ist, sieht man im Systemfenster (Ctrl-Alt-B) unter System->Video.
stimmt genau.
« Letzte Änderung: Mi 27.02.2013, 14:47:52 von Goli »

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #126 am: Sa 16.02.2013, 00:24:25 »
video: 800x608x32, 256 Farben, Format MOT

Das ist 32 bit. Da muss 800x608x8 stehen!

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #127 am: Sa 16.02.2013, 00:33:42 »
Das habe ich doch längst wieder umgestellt, um zu sehen, ob es irgendeine dauerhafte Wirkung hat. Ich kann doch nicht von jetzt ab mit 8 leben. Dass es mit 8 funktioniert habe ich ja schon gesagt. Aber da muss man die Palette auch nicht nachladen, denn rsm stellt gleich die systempalette ein, nur eben nicht unter 32. Und das dürfte ein Bug von rsm sein. Genaugenommen steckt der nicht in rsm sondern nur im Editor.

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #128 am: Sa 16.02.2013, 00:43:46 »
Meine Idee war eben, die icons in in 8bit zu erzeugen mit rsm und der gewünschten Palette, und das Ergebnis mit 32 bit zu nutzen, mit der selben Palette, sonst nichts.

Offline jens

  • Benutzer
  • Beiträge: 4.637
  • Halleluja, I'm on Highwire...
Re: Xaaes bugrepoort
« Antwort #129 am: Sa 16.02.2013, 01:50:59 »
Das ist problematisch:
8 bit ist Palette (die man selbst einstellen kann), True Colour ist nicht Palette und funktioniert anders.
Gruß, Jens
 
Falcon 030, TT 030, Mega/STe, ST-Book, 1040 STf, 520 ST+ - Milan 060
Diverse PCs und Macs sowie Amiga 1200 und 3000
 
Classic Computing

jabber: gemini8@atari-jabber.org

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #130 am: Sa 16.02.2013, 02:29:59 »
Meine Idee war eben, die icons in in 8bit zu erzeugen mit rsm und der gewünschten Palette, und das Ergebnis mit 32 bit zu nutzen, mit der selben Palette, sonst nichts.


Das habe ich auch verstanden und das haben wir ja auch bewiesen, dass das geht. Sobald ich reduziere, aber ehrlich gesagt habe ich immer auf 16 Farben reduziert, um ein brauchbares Ergebnis zu erzielen. Das ist ein Weg, wenn auch ein umständlicher, um Icons zu erzeugen, oder bestehende zu korrigieren.

Aber ich bin langsam von diesem Aranym bedient, denn nichts funktioniert richtig wie es soll. Jetzt habe ich mir eine keyboard.tbl erzeugt, aber die wird garnicht vom Systempfad geladen. Keine ahnung wo das Tastaturlayout herkommt, wird wohl einfach vom Host durchgereicht? Wobei die Atarianordnung erzeugt wird. Nur meine keyboard.tbl wie ich sie mit KeyEdit erzeugt habe, wird nicht geladen. Ich vermute nun auch, dass auch die normale Keyboard.tbl von xaaes garnicht geladen wurde.

Weiß jemand noch einen anderen Pfad oder muss ich da auch wieder in xaaes.cnf irgendwas eintragen? Bei mir liegt sie in c:/mint/1-19-cur/


Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #131 am: Sa 16.02.2013, 09:50:16 »
MiNT lädt keyboard.tbl aus $SYSDIR, was es da macht, müsste im bootlog von MNT stehen.

XaAES erlaubt, die Belegung per hotkey umzuschaten, wie im about-Fenster und in example.cnf angegeben.

Von alleine macht XaAES nichts an der Tastatur.

Das sollte eigentlich alles klar dokumentiert sein.

Ich hab übrigens für aranym die '-Taste mit | belegt, und anderes.

Ich würde in 8 bit die icons erzeugen, und sie dann in einer höheren Farbtiefe benutzen, wenn das geht, was ich ja immer noch nicht sicher weiß.

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #132 am: Sa 16.02.2013, 10:28:18 »
ich werde das noch mehrmals testen. Ich denke, dass es geht, aber sicher kann man nur mit 16 Farbicons sein, wegen der verschiedenen Paletten. Jedoch hatten wir wohl Erfolg damit unter 8-Bit bei richtgier Palette (systempalette) ein Icon zu erzeugen und es dann bei gleicher Palette unter 32 anzuzeigen, ohen Veränderung der Farben.

Das Probelm ist hier nicht xaaes, sondern rsm. Aus welcher Ecke holt sich rsm die fvdi-Palette unter 32-bit, obwohl das system längst eine andere Palette geladen hat?  ???

Die keytable sache werde ich weiter untersuchen, aber wieso lädt xaaes nicht automatisch die vorhandene table? Ich dneke aber auch heir, dass es nicht xaaes ist, aondern aranym das klemmt.

z.B. war mir überhaupt nicht bewusst, dass ich ständig unter 32-Bit gearbeitet habe, wie xaaes ja auch richtig ausgibt, weil im aranym-Dialog, wo die Grundeinstellungen vorgenommen werden, die dann in die config-Datei gespeichert werden, immer 256 Farben angezeigt wird (und manchmal nicht einmal das) und auch so von mir ausgewählt wurde. Wer kümmert sich hier um Aranym, da stecken doch die bugs drin. Muss ich da Peter Stelik oder Vincent verständigen?
« Letzte Änderung: Mi 27.02.2013, 14:49:30 von Goli »

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #133 am: Sa 16.02.2013, 10:42:19 »
Also Moment mal, dokumentiert in xaaes.cnf ist doch nur, wie man die keyboard.tbl switched, was ich aber  gar nicht will und was auch default (aus)kommentiert ist. In dem Fall muss man ja auch die tbl z.B. german.tbl nennen. Was aber ist default?, wird denn da nicht standardmäßig die keyboard.tbl geladen? Wozu muss ich ein shortcut definieren, den ich gar nicht nutzen will? Auch in keyedit steht, dass man die erzeugte table in "keyboard.tbl" umbenennen soll. Hypertext.

Aus dem Hypertext von keyedit:
Zitat
FreeMiNT >= 1.16 will look for a file called keyboard.tbl
   in the current system directory, and load this during boot as the
   default keyboard layout.
« Letzte Änderung: Sa 16.02.2013, 10:57:59 von Goli »

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #134 am: Sa 16.02.2013, 10:50:57 »
Das war doch Sinn der ganzen remap-Geschichte, dass man eben mit jeder Palette alle icons mit jeder anderen Palette laden kann. Müsste mit 8- und 4 bit-icons klappen.

Also ich würde an Deiner Stelle einfach aranym zweimal starten: einmal in 8 bit, einmal in 32 bit, sofern das mit linux möglich ist (24 und 16 würde ich nicht unbedingt nehmen).

Wieso rsm welche Palette benutzt, ist unklar, aber vielleicht findet sich das ja auch irgendwann.

Das mit der keyboard-Tabelle hat nichts mit aranym zu tun. Wenn keyboard.tbl in $SYSDIR ist, wird es auch geladen von MiNT. Falls nicht, poste doch mal die boot.log.

Das VDI versteht eben nur 256 Farben, da bin ich  auch schon drüber gestolpert. Alles darüber sind Erweiterungen (NVDI, fvdi).

Und die aranym-Entwicklung würde ich als klinisch tot bezeichnen, da kommt m.E. nicht mehr viel.

Das Umschalten per XaAES dient in erster Linie den Ausländern, die für Spezialzeichen mehrere layouts brauchen.

Mach doch jetzt erstmal die Sache mit den Icons!

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #135 am: Sa 16.02.2013, 11:06:08 »
Poste doch bitte mal, ob und wie ich $SYSDIR definieren kann. Ins boot.log schau ich noch.
Zitat
Mach doch jetzt erstmal die Sache mit den Icons!

Ja, natürlich, aber versteh bitte auch, dass ich mir so langsam mein System einrichte, damit ich flexibel damit arbeiten kann. Das erleichtert ja auch beim Testen ungemein. Z.B. muss ich mit Tricks bisher immer umschiffen, dass ich nirgends den Backslash auf der Tastatur habe (oder aber irgendwo, wo ich ihn nicht finde). Wenn es irgendwie überall klemmt, dann dreht man sich bald im Kreis.

Aranym zweimal starten, das will ich versuchen, von verschiedenen Konsolen aus, vielleicht geht das ja. aber ich kann's auch so ganz gut vergleichen.

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #136 am: Sa 16.02.2013, 11:18:01 »
Ist alles wie auf der Atari-Tastatur sofern möglich, \ ist also Shift-Alt-ü (sollte zumindest). Stelle gerade fest, dass das default (also ohne keyboard.tbl) nicht klappt.

Also in c:/mint/1-19-cur (das ist $SYSDIR) muss keyboard.tbl stehen (hab meine mal angehängt).

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #137 am: Sa 16.02.2013, 11:29:43 »
In meinem $HOME gibt es eine rsm.inf. Vielleicht kann man damit was anfangen? Man müsste natürlich ne doku haben.

Die keyboard.tbl liegt schon lange in meinem $SYSDIR und jetzt auch noch überall zusätzlich wo nur irgendwie freemint hinschauen könnt.  ;D

Aber, wie Du schon sagst, es klappt nicht. Fragt sich nur wie FreeMint überhaupt die deutsche Tastatur einstellt. lang=de ist natürlich gesetzt.

shift-alt-Ü klappt bei mir im Grundzustand nicht. Da wäre ich doch schon empirisch drauf gekommen. Außerdem sehe ich das nun ja auch in KeyEdit. Nun habe ich mir ne feine notebook.tbl gebastelt, für meine kleine Tatstatur und wollte sie schon veröffentlichen, aber ohne Test - geht gar nicht.
« Letzte Änderung: Mi 27.02.2013, 14:50:32 von Goli »

Goli

  • Gast
Re: Xaaes bugrepoort
« Antwort #138 am: Sa 16.02.2013, 11:36:36 »
Also im boot.log steht

Starting up the update daemon ... done!
Starting up the idle process (pid 0) ... done!
Installing keyboard table `u:/c/mint/1-19-cur/keyboard.tbl' ... AKP 1, ISO 0.


Reading `u:/c/mint/1-19-cur/mint.cnf' ... 5847 bytes done.

Aber erst danach wird xaloader Programm gestartet. Vielleicht wird da die tbl wieder rausgeschmissen?

Hier noch die letzte Session von xaaes (v. 10. Febr., jetzt ist ja wohl das logging abgeschaltet):

size=[800,608], colours=256, bitplanes=32
Also habe ich ja doch 256 Farben bei 32 Bit.
« Letzte Änderung: Sa 16.02.2013, 11:53:36 von Goli »

Offline HelmutK

  • Benutzer
  • Beiträge: 676
Re: Xaaes bugrepoort
« Antwort #139 am: Sa 16.02.2013, 12:02:57 »
Was zeigt keyedit denn, wenn Du $SYSDIR/keyboard.tbl lädst bei Alt+Shift?

Laut boot.log wird sie geladen, und XaAES dreht da nichts dran.

Das mit den 256 Farben hab ich doch eben erklärt!