Hardware > Emulatoren

AtariX => MagicOnLinux

<< < (107/107)

AndreasKromke:
Das Grafiktreiberdrama nimmt kein Ende: Nur (!) im True-Colour-Modus führt das Zeichnen von Polygonen mit nutzerdefiniertem Farb-Füllmuster bei Ellipsen zu einer leeren Ellipse, bei Dreiecken zum totalen Systemabsturz. Man braucht nur das uralte Testprogramm VDITEST\POLYGON\OPLYGON.PRG auszuführen, und dann -- Bumms.

Da liegt ja anscheinend noch einiges im argen...

AndreasKromke:
Also wenn das kein kapitaler Fehler ist, was dann?

Hier fehlte eine Registerzuweisung, wodurch bei der Ausgabe von Polygonen, Ellipsen etc. mit nutzerdefiniertem, farbigem Füllmuster in die Pampa geschrieben wurde, mit der Folge eines totalen Systemabsturzes. Da hat offenbar die QS völlig versagt, wenn sie denn überhaupt existiert hätte. Ich nehme an, daß so ein Fall in der Praxis äußerst selten vorkommt. Meist zeichnet man eh Rechtecke, und ein farbiges Füllmuster müßte man auch immer auf die Farbtiefe des Bildschirms abstimmen. Macht vermutlich niemand.

Fun fact: Ich habe mal einen Blick in fvdi geworfen. Hier habe ich keinen Code gefunden, der die Bit-Tiefe des nutzerdefinierten Füllmusters abfragt. Das sieht für mich so aus, als ob fvdi überhaupt nur monochrome Füllmuster kann. Ich habe aber nicht nachgeschaut, was fvdi macht, wenn ein Programm versucht, ein farbiges Füllmuster zu setzen. Im besten Fall gäbe es einen Fehlercode zurück, im mittelguten Fall würde fvdi nur 32 Bytes des Musters kopieren und es als "monochrom" fehlinterpretieren, und im schlechten Fall geht irgendetwas fundamental schief.

AndreasKromke:
Es gibt jetzt einen True-Colour-Bildschirmtreiber OFF16M_H.OSD, der bis auf das Lesen und Setzen einzelner Pixel alle Grafikausgaben an den Host delegiert. Der Treiber ist standardmäßig deaktiviert und heißt ".OSX". Um ihn zu aktivieren, muß man den 68k-Treiber OFF16MOV.OSD umbenennen, z.B. in .OSX, und dann den o.g. Treiber von .OSX in .OSD.

Ich teste das noch ein wenig, und dann werde ich die beiden Dateien vertauschen.

Geschwindigkeitsmäßig bringt es nicht fürchterlich viel, es ist eher eine Machbarkeits-Studie. Der 68k-Code ist halt extremst optimiert, betreibt heftiges loop unroll und verwendet für jeden Farb- oder Schreibmodus eine eigene Schleife, um jegliche bedingten Sprünge in den innersten Schleifen zu vermeiden. Die Mühe habe ich mir nicht gemacht, der C-Code ist hoffentlich deshalb etwas besser leserlich und auf jeden Fall sehr viel kürzer.

Die meisten Geschwindigkeitsmeßprogramme versagen wegen irgendwelcher Überläufe, aber in den Fällen, in denen Kronos mal lief, sehe ich ungefähr Faktor drei. Das ist nicht aufregend und vielleicht nur auf langsameren Rechnern interessant.

Auf jeden Fall habe ich viel über die Behne-Treiber-Paradigmen gelernt.  :)

Navigation

[0] Themen-Index

[*] Vorherige Sete