WIE man 'Auflsungs-Unabhngig' programmiert 
-------------------------------------------- 
   Diese Ratschlge beziehen sich nicht nur auf den OVERSCAN-Modus sondern
   auf ALLE Grobildschirme, Graphikkarten und den ATARI TT. Wenn man sie
   beim Programmieren berherzigt, sollte das eigene Programm auf allen 
   Konfigurationen und unter allen mglichen und zuknftigen  Auflsungen
   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 Mglichkeiten arbeiten,
   die das AES und VDI bieten.

1) AES
------
   Breite/Hhe
   -----------
     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 Grobildschirm verhindert.
   Fenster
   -------
     Nicht nur auf minimale Gre testen, sondern auch auf die maximal
     vorgesehene Gre. Wenn man z.B. ein DEGAS-Bild in einem Fenster
     darstellen will, kann man das Fenster auf einem Grobildschirm oder
     unter OVERSCAN grer 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
     Auflsungen/Graphikkarten wird aber im gerteabhngigem Format
     gearbeitet. Man mu daher alle IconMasken/IconDatas und BitImages
     mit der Funktion 'trans_gimage' ins gerteabhngige 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 Gre des RootObjektes mu an die BildschirmGre angepat
     werden. Auerdem sollte man die Objekte des eigenen Desktops an die
     Rnder des Bildschirms verschieben, da sie sonst mitten auf dem
     Bildschirm liegen (siehe WordPlus 2.xx FunktionsTastenLeiste).


2) VDI
------
   Breite/Hhe
   -----------
     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 eintrgt.
     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 Gre aus Bildebenen * Hhe * Breite/8 und reserviert
     diesen Speicher mit Malloc. Man trgt 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. 
     Die Lnge des BildschirmSpeichers betrgt nicht immer nur 32K, bei der
     MAXXON sind es sogar 128K. Es ist also notwendig eine Unterscheidung zu
     treffen, wann es aus SpeicherPlatzGrnden nicht mehr sinnvoll ist, einen
     BildschirmPuffer anzulegen. Auch mu der errechnte SpeicherPlatz unter
     Umstnden nicht mehr verfgbar sein, auch darauf mu das Programm
     reagieren und ggf. den Bildschirm auf die alte Art restaurieren lassen.
   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 gesagt, mu man auf diese Funktionen
     verzichten, wenn man korrekte GEM-Programme schreiben will. Hier noch
     ein paar Erluterungen, 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, nmlich 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/
     Grobildschirmen 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 nmlich schief, sondern mit
     der garnichtmal langsamen 'vro_cpyfm'-Funktion des VDI !)
     ber den Wechsel der Auflsung bei der MAXXON- oder MATRIX-Color- Karte
     ist mir noch nichts bekannt.
     Unter OVERSCAN existieren unterschiedliche Offsets in den verschiedenen 
     Auflsungen, deswegen ist ein Wechsel der Auflsung, 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 spter...
   Getrez
   ------ 
     Die zurckgelieferten Werte beschrnken sich nicht mehr auf 0-2 ! 
     Es gibt z.B. auf dem TT noch weitere Auflsungen und auch die MATRIX-Color
     Karte liefert u.U. neue Werte.            
     Ein Programm darf NICHT mehr von diesen Werte abhngen, sondern mu die
     Breite/Hhe/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 Ratschlge 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 !
  Scrollen/Textausgaben
  ---------------------
    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, beschrnken
    und in den Fllen, 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 erfhrt 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. 
  BildschirmPuffer
  ----------------
    Wie oben schon erwhnt, ist die Lnge des BildschirmSpeichers nicht mehr
    nur 32K. Dieses ist auch bei der AssemblerProgrammierung zu beachten.



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 Auflsung
    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 BildschirmSpeicherLnge
    fr jede Auslsung erfahren kann. Auerdem kann man die Funktion Setscreen
    wieder einschalten. Nheres dazu in der HeaderDatei OVERSCAN.H die 
    mit im SOFTWARE.ARC enthalten ist.

FAZIT
-----
    Um 'AuflsungsUnabhngig' 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 (auer
    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

   