home *** CD-ROM | disk | FTP | other *** search
/ Computer Club Elmshorn Atari PD / CCE_PD.iso / mac / 0700 / CCE_0708.ZIP / CCE_0708.PD / GFAHILFE / PRG_TIPS.TXT < prev    next >
Text File  |  1993-01-31  |  10KB  |  205 lines
  1. WIE man 'Auflösungs-Unabhängig' programmiert 
  2. -------------------------------------------- 
  3.    Diese Ratschläge beziehen sich nicht nur auf den OVERSCAN-Modus sondern
  4.    auf ALLE Großbildschirme, Graphikkarten und den ATARI TT. Wenn man sie
  5.    beim Programmieren berherzigt, sollte das eigene Programm auf allen 
  6.    Konfigurationen und unter allen möglichen und zukünftigen  Auflösungen
  7.    laufen.
  8.    Die speziellen Xbios-Funktionen für den Bildschirm (Logbase/Physbase/
  9.    Getrez/Setscreen/Setcolor/Setpallete) sind nur für den ATARI-Monitor
  10.    vorgesehen und nicht für Graphikkarten anderer Hersteller, deswegen muß
  11.    man auf sie verzichten und mit den reichlichen Möglichkeiten arbeiten,
  12.    die das AES und VDI bieten.
  13.  
  14. 1) AES
  15. ------
  16.    Breite/Höhe
  17.    -----------
  18.      Bekommt man durch die Funktion
  19.      'wind_get(0,WORK_XYWH,&x,&y,&breite,&hoehe)' mitgeteilt.
  20.    Form_Dial
  21.    ---------
  22.      Man muß die richtigen BildschirmGrenzen angeben, damit der Desktop
  23.      korrekt restauriert werden kann. Viele Programmierer haben hier leider
  24.      die festen Werte 640/400 ingesetzt, was ein korrektes Laufen des 
  25.      Programms auf dem Großbildschirm verhindert.
  26.    Fenster
  27.    -------
  28.      Nicht nur auf minimale Größe testen, sondern auch auf die maximal
  29.      vorgesehene Größe. Wenn man z.B. ein DEGAS-Bild in einem Fenster
  30.      darstellen will, kann man das Fenster auf einem Großbildschirm oder
  31.      unter OVERSCAN größer machen kann als das eigentliche Bild. 
  32.    Icons
  33.    -----
  34.      In der ResourceDatei werden die Icons im StandartFormat abgelegt,
  35.      das dem Format des MonoChrom-Bildschirms entspricht. Bei anderen
  36.      Auflösungen/Graphikkarten wird aber im geräteabhängigem Format
  37.      gearbeitet. Man muß daher alle IconMasken/IconDatas und BitImages
  38.      mit der Funktion 'trans_gimage' ins geräteabhängige Format überführen.
  39.      Diese Funktion ist der ArtikelSerie ProGEM entnommen. Da das im
  40.      ST-Magazin 10/89 auf Seite 60 abgedruckte Listing doch nicht unter 
  41.      TurboC zu kompilieren war, liefere ich eine richtige Version als
  42.      AES_IMG.C gleich mit.
  43.    Eigener Desktop
  44.    ---------------
  45.      Die Größe des RootObjektes muß an die BildschirmGröße angepaßt
  46.      werden. Außerdem sollte man die Objekte des eigenen Desktops an die
  47.      Ränder des Bildschirms verschieben, da sie sonst mitten auf dem
  48.      Bildschirm liegen (siehe WordPlus 2.xx FunktionsTastenLeiste).
  49.  
  50. 2) VDI
  51. ------
  52.    Breite/Höhe
  53.    -----------
  54.      Bekommt man beim 'v_opnvwk'-Aufruf in WorkOut[0]/WorkOut[1] geliefert.
  55.    Anzahl der Bildebenen
  56.    ---------------------
  57.      Bekommt man beim 'vq_extnd'-Aufruf in WorkOut[4] geliefert.
  58.    Clipping
  59.    --------
  60.       Man sollte seine Ausgaben auf die richtigen BildschirmWerte klippen und
  61.       nicht auf 640/400.
  62.    Verschieben/Kopieren von BildschirmSpeicher
  63.    ------------------------------------------- 
  64.      Dazu gibt es die Funktion 'vro_cpyfm'. GEM benutzt automatisch die
  65.      aktuellen BildschirmWerte, wenn man im MFDB bei der Komponente
  66.      fd_addr einen NullPointer einträgt.
  67.      Man sollte NICHT versuchen die Struktur selber auszufüllen, da z.B.
  68.      unter OVERSCAN die Breite in Bytes nicht gleich der Breite in Pixeln/8
  69.      ist !
  70.    2.BildschirmSpeicher/BildschirmPuffer
  71.    -------------------------------------
  72.      Man errechnet die Größe aus Bildebenen * Höhe * Breite/16 und reserviert
  73.      diesen Speicher mit Malloc. Man trägt nun diese Werte in einen MFDB ein,
  74.      in den MFDB ein und schon kann man mit 'vro_cpyfm' zwischen den
  75.      beiden Bildschirmen kopieren. Es ist also unter OVERSCAN nicht notwendig
  76.      die FüllBytes des rechten Randes mit anzulegen, die unterschiedliche
  77.      Breite in Bytes wird vom VDI korrekt behandelt. 
  78.    Farben
  79.    ------
  80.      Die Anzahl der gleichzeitig verfügbaren Farben bekommt man beim
  81.      'v_opnvwk'-Aufruf in WorkOut[13] mitgeteilt.
  82.      Man darf die Farben NICHT mit den XBios-Funktionen Setcolor/Setpallette
  83.      setzen, sondern mit der Funktion 'vs_color', die von allen GraphikKarten
  84.      unterstützt wird. 
  85.  
  86. 3) XBIOS
  87. --------
  88.      Wie im ersten Absatz schon geschrieben, muß man auf diese Funktionen
  89.      verzichten, wenn man korrekte GEM-Programme schreiben will. Hier noch
  90.      ein paar Erläuterungen, warum dieses so ist.
  91.  
  92.    Logbase/Physbase
  93.    ----------------
  94.      Unter OVERSCAN sind Logbase und Physbase nicht identisch, es existiert ein
  95.      Offset, der zur FeinPositionierung des Bildschirms benutzt wird.
  96.      Auch beim MATRIX-Bildschirm hat Physbase einen falschen Wert, nämlich die
  97.      AnfangsAddresse des ATARI-Bildschirms und nicht des MATRIX-Bildschirms.
  98.      Wenn man in den BildschirmSpeicher schreiben will muß man sich dessen
  99.      AnfangsAddresse mit Logbase holen.
  100.    Setscreen
  101.    ---------
  102.      Das Verlegen der BildschirmAddressen wird von den meisten GraphikKarten/
  103.      Großbildschirmen NICHT unterstützt !
  104.      Sauber geschrieben Programme fragen nach dem Setscreen-Aufruf mit Logbase
  105.      /Physbase ab, ob es geklappt hat.
  106.      Ein 2. BildschirmSpeicher wird wie bei VDI-beschrieben angelegt und dann
  107.      über den OrginalBildschirm kopiert. (Aber nicht mit einer eigenen Routine
  108.      wie bei TurboC 1.1, unter OVERSCAN geht das nämlich schief, sondern mit
  109.      der garnichtmal langsamen 'vro_cpyfm'-Funktion des VDI !)
  110.      Über den Wechsel der Auflösung bei der MAXXON- oder MATRIX-Color- Karte
  111.      ist noch nicht bekannt.
  112.      Unter OVERSCAN existieren unterschiedliche Offsets in den verschiedenen 
  113.      Auflösungen, deswegen ist ein Wechsel der Auflösung, sowie ein Verlegen
  114.      der BildschirmAddressen nicht erlaubt.
  115.      Für ZeichenProgramme, die den OVERSCAN-Modus voll ausnutzen wollen, gibt
  116.      es aber spezielle neue Xbios-Aufrufe, doch dazu später...
  117.    Getrez
  118.    ------ 
  119.      Die zurückgelieferten Werte beschränken sich nicht mehr auf 0-2 ! 
  120.      Es gibt z.B. auf dem TT noch weitere Auflösungen und auch die MATRIX-Color
  121.      Karte liefert eine neue Werte.            
  122.      Ein Programm darf NICHT mehr von diesen Werte abhängen, sondern muß die
  123.      Breite/Höhe/Bildschirmebenen mit den Auskunftsfunktionen des AES oder 
  124.      VDI abfragen.
  125.    Setcolor/Setpallete
  126.    -------------------
  127.      Werden auf den neuen ColorKarten nicht unterstützt. Die BildschirmFarben
  128.      sind mit der VDI-Funktion 'vs_color' zu setzen und abzufragen.
  129.    
  130. 4) ASSEMBLER-ROUTINEN
  131. ---------------------
  132.     Wenn man nicht auf schnellere AssemblerRoutinen verzichten will, muß man
  133.     folgende Ratschläge beachten :
  134.  
  135.     Zuerst sollte man die aktuellen Werte des Bildschirms mit den VDI-
  136.     Funktionen abfragen. Wenn nun eine Anzahl von BildschirmEbenen vorliegt,
  137.     mit der die eigene Routine nicht zurechtkommt, benutzt man eben die
  138.     normalen VDI-Funktionen !
  139.     Am wichtigsten ist es, die AusgabeRoutine so zu schreiben, daß sie mit
  140.     einer unterschiedlichen Anzahl von Bytes zurechtkommt. Man kann sich dabei
  141.     ja auch auf günstige Werte wie, teilbar durch 32,16,8 oder so, beschränken
  142.     und in den Fällen, wo es wieder mal nicht klappt, die orginal VDI-
  143.     Funktionen benutzen.
  144.     Wo bekommt man nun die Anzahl der Bytes pro Zeile her ? Normalerweise ist
  145.     Bytes pro Zeile gleich der Anzahl in Pixel*FarbEbenen/8, leider gilt dieses
  146.     NICHT mehr im OVERSCAN-Modus, wo rechts noch FüllBytes im StrahlenRücklauf
  147.     liegen.
  148.     Man erfährt die Bytes pro Zeile am Besten aus der negativen LineA-Variablen
  149.     BYTES_LIN (Offset -$2). Laut Julian Reschke (ProfiBuch) sollen die LineA-
  150.     Funktionen irgendwann verschwinden. Noch gibt es meines Wissens keine
  151.     GraphikKarte bei der LineA nicht unterstützt wird. 
  152.  
  153. Besonderheiten am OVERSCAN-Modus
  154. --------------------------------
  155.     Es gibt eine Unterschied zwischen Physbase, der Addresse, ab der der
  156.     Shifter den Bildschirmspeicher ausliest, und Logbase, der Addresse der
  157.     linken oberen Ecke des sichtbaren Bildschirms. Unter OVERSCAN beginnt
  158.     der Shifter schon im Bildrücklauf Werte aus dem Speicher zu Lesen, weil das
  159.     Steuersignal modifiziert wurde. Damit der eigentliche Bildaufbau nicht auch
  160.     schon im Rücklauf beginnt wurde dieser Offset eingeführt.
  161.  
  162.     Der Offset und der Vorlauf des VideoSignals sind für jede Auflösung
  163.     unterschiedlich und daher ist die Funktion Setscreen normalerweise
  164.     verboten.
  165.     
  166.     Wenn man aber z.B. ein ZeichenProgramm extra an den OVERSCAN-Modus
  167.     anpassen will, so gibt es einen Ausweg. Es gibt neue XbiosFunktionen 
  168.     mit denen man die Offsets, Bytes pro Zeile und die BildschirmSpeicherLänge
  169.     für jede Auslösung erfahren kann. Außerdem kann man die Funktion Setscreen
  170.     wieder einschalten. Näheres dazu in der HeaderDatei OVERSCAN.H die 
  171.     mit im OVERSC17.ARC entahlten ist.
  172.  
  173. FAZIT
  174. -----
  175.     Um 'AuflösungsUnabhängig' zu programmieren muß man nichts weiter tun, als
  176.     sich an das zu halten, was allen Programmierern mit den ProgrammBeispiel
  177.     DOODLE gezeigt wurde, man muß die AES- und VDI-Funktionen nur richtig
  178.     benutzen und nicht auf den rechnerspezifischen XbiosFunktionen beharren.
  179.     Selbst einer Portierung auf PC-GEM steht dann nichts mehr im Wege (außer
  180.     den FAR-Pointern , ächtz).
  181.  
  182. Ich hoffe diese kleine Abhandlung hat Euch auf die Sprünge geholfen....
  183.  
  184. Mit besten Wünschen und Hoffnung auf bessere Programme
  185.           ___             
  186.        __|___|__
  187.         ! o o !
  188.         \  ^  / __ __ __  .
  189.      kar \ - / /_  / /_  /| /
  190.           \_/ __/ / /__ / |/    Isakovic
  191.          
  192. P.S. Ich bin auf folgender Weise zu erreichen :
  193.  
  194.      Karsten Isakovic
  195.      WilmersdorferStr 82
  196.      1000 Berlin 12
  197.      
  198.      oder in den MailBoxen
  199.      ---------------------
  200.      PARROT Berlin   030/724467
  201.             login visitor visitor
  202.             write mail sten
  203.      MAUS   Münster  0251/80386
  204.             unter meinem Namen
  205.