WIE man 'Aufl”sungs-Unabh„ngig' programmiert -------------------------------------------- Diese Ratschl„ge beziehen sich nicht nur auf den OVERSCAN-Modus sondern auf ALLE Grožbildschirme, Graphikkarten und den ATARI TT. Wenn man sie beim Programmieren berherzigt, sollte das eigene Programm auf allen Konfigurationen und unter allen m”glichen und zuknftigen Aufl”sungen laufen. Die speziellen Xbios-Funktionen fr den Bildschirm (Logbase/Physbase/ Getrez/Setscreen/Setcolor/Setpallete) sind nur fr den ATARI-Monitor vorgesehen und nicht fr Graphikkarten anderer Hersteller, deswegen muž man auf sie verzichten und mit den reichlichen M”glichkeiten arbeiten, die das AES und VDI bieten. 1) AES ------ Breite/H”he ----------- Bekommt man durch die Funktion 'wind_get(0,WORK_XYWH,&x,&y,&breite,&hoehe)' mitgeteilt. Form_Dial --------- Man muž die richtigen BildschirmGrenzen angeben, damit der Desktop korrekt restauriert werden kann. Viele Programmierer haben hier leider die festen Werte 640/400 ingesetzt, was ein korrektes Laufen des Programms auf dem Grožbildschirm verhindert. Fenster ------- Nicht nur auf minimale Gr”že testen, sondern auch auf die maximal vorgesehene Gr”že. Wenn man z.B. ein DEGAS-Bild in einem Fenster darstellen will, kann man das Fenster auf einem Grožbildschirm oder unter OVERSCAN gr”žer machen kann als das eigentliche Bild. Icons ----- In der ResourceDatei werden die Icons im StandartFormat abgelegt, das dem Format des MonoChrom-Bildschirms entspricht. Bei anderen Aufl”sungen/Graphikkarten wird aber im ger„teabh„ngigem Format gearbeitet. Man muž daher alle IconMasken/IconDatas und BitImages mit der Funktion 'trans_gimage' ins ger„teabh„ngige Format berfhren. Diese Funktion ist der ArtikelSerie ProGEM entnommen. Da das im ST-Magazin 10/89 auf Seite 60 abgedruckte Listing doch nicht unter TurboC zu kompilieren war, liefere ich eine richtige Version als AES_IMG.C gleich mit. Eigener Desktop --------------- Die Gr”že des RootObjektes muž an die BildschirmGr”že angepažt werden. Aužerdem sollte man die Objekte des eigenen Desktops an die R„nder des Bildschirms verschieben, da sie sonst mitten auf dem Bildschirm liegen (siehe WordPlus 2.xx FunktionsTastenLeiste). 2) VDI ------ Breite/H”he ----------- Bekommt man beim 'v_opnvwk'-Aufruf in WorkOut[0]/WorkOut[1] geliefert. Anzahl der Bildebenen --------------------- Bekommt man beim 'vq_extnd'-Aufruf in WorkOut[4] geliefert. Clipping -------- Man sollte seine Ausgaben auf die richtigen BildschirmWerte klippen und nicht auf 640/400. Verschieben/Kopieren von BildschirmSpeicher ------------------------------------------- Dazu gibt es die Funktion 'vro_cpyfm'. GEM benutzt automatisch die aktuellen BildschirmWerte, wenn man im MFDB bei der Komponente fd_addr einen NullPointer eintr„gt. Man sollte NICHT versuchen die Struktur selber auszufllen, da z.B. unter OVERSCAN die Breite in Bytes nicht gleich der Breite in Pixeln/8 ist ! 2.BildschirmSpeicher/BildschirmPuffer ------------------------------------- Man errechnet die Gr”že aus Bildebenen * H”he * Breite/16 und reserviert diesen Speicher mit Malloc. Man tr„gt nun diese Werte in einen MFDB ein, in den MFDB ein und schon kann man mit 'vro_cpyfm' zwischen den beiden Bildschirmen kopieren. Es ist also unter OVERSCAN nicht notwendig die FllBytes des rechten Randes mit anzulegen, die unterschiedliche Breite in Bytes wird vom VDI korrekt behandelt. Farben ------ Die Anzahl der gleichzeitig verfgbaren Farben bekommt man beim 'v_opnvwk'-Aufruf in WorkOut[13] mitgeteilt. Man darf die Farben NICHT mit den XBios-Funktionen Setcolor/Setpallette setzen, sondern mit der Funktion 'vs_color', die von allen GraphikKarten untersttzt wird. 3) XBIOS -------- Wie im ersten Absatz schon geschrieben, muž man auf diese Funktionen verzichten, wenn man korrekte GEM-Programme schreiben will. Hier noch ein paar Erl„uterungen, warum dieses so ist. Logbase/Physbase ---------------- Unter OVERSCAN sind Logbase und Physbase nicht identisch, es existiert ein Offset, der zur FeinPositionierung des Bildschirms benutzt wird. Auch beim MATRIX-Bildschirm hat Physbase einen falschen Wert, n„mlich die AnfangsAddresse des ATARI-Bildschirms und nicht des MATRIX-Bildschirms. Wenn man in den BildschirmSpeicher schreiben will muž man sich dessen AnfangsAddresse mit Logbase holen. Setscreen --------- Das Verlegen der BildschirmAddressen wird von den meisten GraphikKarten/ Grožbildschirmen NICHT untersttzt ! Sauber geschrieben Programme fragen nach dem Setscreen-Aufruf mit Logbase /Physbase ab, ob es geklappt hat. Ein 2. BildschirmSpeicher wird wie bei VDI-beschrieben angelegt und dann ber den OrginalBildschirm kopiert. (Aber nicht mit einer eigenen Routine wie bei TurboC 1.1, unter OVERSCAN geht das n„mlich schief, sondern mit der garnichtmal langsamen 'vro_cpyfm'-Funktion des VDI !) šber den Wechsel der Aufl”sung bei der MAXXON- oder MATRIX-Color- Karte ist noch nicht bekannt. Unter OVERSCAN existieren unterschiedliche Offsets in den verschiedenen Aufl”sungen, deswegen ist ein Wechsel der Aufl”sung, sowie ein Verlegen der BildschirmAddressen nicht erlaubt. Fr ZeichenProgramme, die den OVERSCAN-Modus voll ausnutzen wollen, gibt es aber spezielle neue Xbios-Aufrufe, doch dazu sp„ter... Getrez ------ Die zurckgelieferten Werte beschr„nken sich nicht mehr auf 0-2 ! Es gibt z.B. auf dem TT noch weitere Aufl”sungen und auch die MATRIX-Color Karte liefert eine neue Werte. Ein Programm darf NICHT mehr von diesen Werte abh„ngen, sondern muž die Breite/H”he/Bildschirmebenen mit den Auskunftsfunktionen des AES oder VDI abfragen. Setcolor/Setpallete ------------------- Werden auf den neuen ColorKarten nicht untersttzt. Die BildschirmFarben sind mit der VDI-Funktion 'vs_color' zu setzen und abzufragen. 4) ASSEMBLER-ROUTINEN --------------------- Wenn man nicht auf schnellere AssemblerRoutinen verzichten will, muž man folgende Ratschl„ge beachten : Zuerst sollte man die aktuellen Werte des Bildschirms mit den VDI- Funktionen abfragen. Wenn nun eine Anzahl von BildschirmEbenen vorliegt, mit der die eigene Routine nicht zurechtkommt, benutzt man eben die normalen VDI-Funktionen ! Am wichtigsten ist es, die AusgabeRoutine so zu schreiben, daž sie mit einer unterschiedlichen Anzahl von Bytes zurechtkommt. Man kann sich dabei ja auch auf gnstige Werte wie, teilbar durch 32,16,8 oder so, beschr„nken und in den F„llen, wo es wieder mal nicht klappt, die orginal VDI- Funktionen benutzen. Wo bekommt man nun die Anzahl der Bytes pro Zeile her ? Normalerweise ist Bytes pro Zeile gleich der Anzahl in Pixel*FarbEbenen/8, leider gilt dieses NICHT mehr im OVERSCAN-Modus, wo rechts noch FllBytes im StrahlenRcklauf liegen. Man erf„hrt die Bytes pro Zeile am Besten aus der negativen LineA-Variablen BYTES_LIN (Offset -$2). Laut Julian Reschke (ProfiBuch) sollen die LineA- Funktionen irgendwann verschwinden. Noch gibt es meines Wissens keine GraphikKarte bei der LineA nicht untersttzt wird. Besonderheiten am OVERSCAN-Modus -------------------------------- Es gibt eine Unterschied zwischen Physbase, der Addresse, ab der der Shifter den Bildschirmspeicher ausliest, und Logbase, der Addresse der linken oberen Ecke des sichtbaren Bildschirms. Unter OVERSCAN beginnt der Shifter schon im Bildrcklauf Werte aus dem Speicher zu Lesen, weil das Steuersignal modifiziert wurde. Damit der eigentliche Bildaufbau nicht auch schon im Rcklauf beginnt wurde dieser Offset eingefhrt. Der Offset und der Vorlauf des VideoSignals sind fr jede Aufl”sung unterschiedlich und daher ist die Funktion Setscreen normalerweise verboten. Wenn man aber z.B. ein ZeichenProgramm extra an den OVERSCAN-Modus anpassen will, so gibt es einen Ausweg. Es gibt neue XbiosFunktionen mit denen man die Offsets, Bytes pro Zeile und die BildschirmSpeicherL„nge fr jede Ausl”sung erfahren kann. Aužerdem kann man die Funktion Setscreen wieder einschalten. N„heres dazu in der HeaderDatei OVERSCAN.H die mit im OVERSC17.ARC entahlten ist. FAZIT ----- Um 'Aufl”sungsUnabh„ngig' zu programmieren muž man nichts weiter tun, als sich an das zu halten, was allen Programmierern mit den ProgrammBeispiel DOODLE gezeigt wurde, man muž die AES- und VDI-Funktionen nur richtig benutzen und nicht auf den rechnerspezifischen XbiosFunktionen beharren. Selbst einer Portierung auf PC-GEM steht dann nichts mehr im Wege (aužer den FAR-Pointern , „chtz). Ich hoffe diese kleine Abhandlung hat Euch auf die Sprnge geholfen.... Mit besten Wnschen und Hoffnung auf bessere Programme ___ __|___|__ ! o o ! \ ^ / __ __ __ . kar \ - / /_ / /_ /| / \_/ __/ / /__ / |/ Isakovic P.S. Ich bin auf folgender Weise zu erreichen : Karsten Isakovic WilmersdorferStr 82 1000 Berlin 12 oder in den MailBoxen --------------------- PARROT Berlin 030/724467 login visitor visitor write mail sten MAUS Mnster 0251/80386 unter meinem Namen