home *** CD-ROM | disk | FTP | other *** search
/ ST-Computer Leser 2002 January / STC_CD_01_2002.iso / UTILS / LIBERTY / DEVELOP / IBMR.H next >
C/C++ Source or Header  |  1997-12-20  |  6KB  |  151 lines
  1. /* Hauptverarbeitungsbildtypen *
  2.  *******************************
  3.  
  4.  * RASTERGRAFIKEN *
  5.  
  6.  * Da sich Plane-orinetierte Bitmap-Grafiken ganz schlecht
  7.  * und nur langsam weiterverabeiten lassen wurde ein eigenes
  8.  * Format für die Verarbeitungen gewählt. Aber keine Angst,
  9.  * entsprechende Konvertierungsfunktionen sind integriert.
  10.  * Dieses Format hat auch den gro₧en Vorteil das es oft
  11.  * schon dem geräteabhängigem Format von Grafikkarten ent-
  12.  * spricht. 
  13.  * Man hat höchste Geschwindigkeit, da man sich eine Umwandlung
  14.  * via VDI-Transform ersparen kann !
  15.  * Die Umsetzung dieses Formates in das geräteabhängige Format
  16.  * wird durch eigene, hochoptimierte Algorithmen übernommen und
  17.  * eine entsprechende Funktion zur Verfügung gestellt.
  18.  */
  19.  
  20. #include <portab.h>
  21.  
  22. #ifndef _GEN_IBMR_
  23. #define _GEN_IBMR_
  24.  
  25. #ifndef BOOLEAN
  26.  typedef enum
  27.  {
  28.     FAIL=-1,
  29.     FALSE,
  30.     TRUE
  31.  } boolean;
  32. #define BOOLEAN    boolean
  33. #endif
  34.  
  35. typedef struct
  36. {
  37.    WORD  red;        /* Rot-Intensität in Promille (0-1000) */
  38.    WORD  green;      /* Grün-Intensität in Promille (0-1000) */
  39.    WORD  blue;       /* Blau-Intensität in Promille (0-1000) */
  40. } RGB1000;             /* Farben VDI kompatibel */
  41.  
  42. #define RGB255    BYTE /* Genau: Eine Folge von 3 Bytes:
  43.                            BYTE  red;      Rotintensität von 0-255
  44.                            BYTE  green;  Grünintensität von 0-255
  45.                            BYTE  blue;      Blauintensität von 0-255
  46.                         
  47.                         Leider ist das Beschreiben einer Struktur
  48.                         hier nicht möglich, da PureC automatisch
  49.                         diese auf 16 Bit 'alignen' würde, welches
  50.                         zu Verarbeitungsmängeln im 68000 Code führt.. 
  51.                         */
  52.  
  53. typedef struct {
  54.                         /* Viele (ableitbare) Informationen... */
  55.                         /* spart aber Zeit und wir wollen doch */
  56.                         /* Speeeeeed...... */
  57.     WORD    xsize;        /* Bildbreite */
  58.     WORD    ysize;        /* Bildhöhe   */
  59.     WORD    wdwidth;    /* Breite/16 (aligned) */
  60.     BYTE    bpp;        /* Bytes pro Pixel (monochrome = -8) */
  61.     WORD    bpl;        /* Bytes pro Zeile */
  62.     WORD    dumb;        /* Anzahl der für align. unbenutzten Bytes */
  63.     LONG    bpb;        /* Speicherbedarf der Bilddaten in Bytes */
  64.     BYTE    cdepth;        /* Farbtiefe (2^n Farben). */
  65.     WORD    colors;        /* Wenn Farbtiefe <= 8: genaue Farbanzahl */
  66.                         /* sonst -1 für keine Palette. */
  67.     RGB255    *cmap;        /* Zeiger auf eine Farbtabelle */
  68.     BYTE    *bitmap;    /* Die Bilddaten.
  69.                          * Folgender Aufbau:
  70.                          *
  71.                          * Wenn cdepth=1 ist (monochrome),
  72.                          * sind 16 pixel wordäquivalent (und aligned).
  73.                          * Das höchste Bit steht an linker Position.
  74.                          * Die Farbzuordnung ist: Bit leer = Index 0
  75.                          * Bit gesetzt = Farbindex 1 der akt. cmap.
  76.                          * Bilddaten sind WORD aligned.
  77.                          *
  78.                          * Wenn cdepth=2-8 ist, sind die
  79.                          * Bilddaten pixelgepakt farb-indiziert
  80.                          * bezgl. der Farbtabelle.
  81.                          * 1 Pixel = 1 Byte. 
  82.                          * 
  83.                          * Wenn cdepth=16 ist, liegt 16 Bit High-
  84.                          * Color vor. 2 Byte pro Pixel Motorola-Format:
  85.                          *   even  |  odd
  86.                          * rrrrrggg gggbbbbb
  87.                          *
  88.                          * Wenn cdepth=24 ist, liegt 24 Bit True-
  89.                          * Color vor. 3 Byte pro Pixel, Intel-Format:
  90.                          *  first  | second | third
  91.                          * bbbbbbbb gggggggg rrrrrrrr
  92.                          *
  93.                          * Die 'eigentuemiliche' Zahlenformat-
  94.                          * kombination ist ein Zugeständnis an
  95.                          * die Hardware des Falcon030 !
  96.                          * Da es aber von ATARI keine 24bit Grafik
  97.                          * gibt und Grafikkarten 'normalerweise' ;-)
  98.                          * das Intelzahlenformat benutzen, wurde
  99.                          * dieses aus Geschwindigkeitsgründen bei
  100.                          * True-Color gewählt.
  101.                          *
  102.                          * WICHTIG !!!
  103.                          * Alle Zeilen sind 16 Pixel-Aligned! Auch
  104.                          * wenn dieses ab 8 Bildebenen unsinnig
  105.                          * klingen mag, es ist von Vorteil, da so
  106.                          * oft 'automatisch' das geräteabhängige
  107.                          * Format von  Grafikkarten vorliegt.
  108.                          * Das spart bei der Konvertierung viel
  109.                          * Zeit. (Auch wenn es etwas zu Lasten
  110.                          * des Verarbeitungskomforts und Speicher-
  111.                          * bedarfs geht..)
  112.                          */
  113. } IBMR;                    /* Internal BitMap Representation */
  114.  
  115.  
  116.  
  117. /* VEKTORGRAFIK *
  118.  *
  119.  * GEM-Metafiles haben drei Nachteile bei der Ausgabe via VDI die
  120.  * mit dem 'Compact-VDI'-Format beseitigt werden:
  121.  * - alle Werte liegen im Intel-Zahlenformat vor
  122.  * - Funktionsnummer treten auf, die nicht vom Bildschirmtreiber
  123.  *   verstanden werden (Sub-Objekte etc.)
  124.  * - Punkte müssen ziemlich umständlich durch Befehlsinterpretation
  125.  *   auf ihre Zieldimension umgerechnet werden.
  126.  *
  127.  * Das CVDI-Dateiformat hat folgenden Aufbau (alle Zahlen im
  128.  * Motorola-Format!!!):
  129.  */
  130.  
  131. typedef struct _cvdi_
  132. {
  133.   LONG    identifier;            /* 'CVDI' */
  134.   WORD    headlen;            /* Headerlänge / Versionserkennung (1.0 = 60 Bytes) */
  135.   BYTE    name[14];            /* Name der Grafik (nullterminierter String) */
  136.   struct _cvdi_    *next;        /* Nächste Grafik oder NULL */
  137.   WORD    xsize;                /* Breite der Grafik */
  138.   WORD    ysize;                /* Höhe der Grafik */
  139.   LONG    spcoffset;            /* Byte-Offset zu den Weiten/Höheninformationen... */
  140.   LONG    spccount;            /* Anzahl der Special-!WORDS! */
  141.   LONG    ptscount;            /* Anzahl der Punkte (x,y = 2!!) */
  142.   WORD    *userlistcolor;        /* Programmspezifische Zeiger zu spez. Infos... */
  143.   WORD    *userlistpattern;
  144.   WORD    *userlistfonttype;
  145.   WORD    *userlistfontsize;
  146.   WORD    *userlistfree;
  147. /*WORD  graphic[...]           Vektorgrafikdaten */
  148. } CVDI;                        /* Compact-Vector-DescriptIon (oder Chriskers-VDI ;-) ) */
  149.  
  150. #endif
  151.