Il formato PIC

                            traduzione a cura di Stefano Guida

Le informazioni fornite da questo  articolo  sono  a  cura  di
George Gwilt e provengono dai documenti GD2 di Tony Tebby's

Il formato di "Partial Save Area" e' mostrato qui sotto:
+--------+-----------+-------+-------------------------------+
| OFFSET | FUNZIONE  |LUNGH. |    DESCRIZIONE                |
+--------+-----------+-------+-------------------------------+
| 0      | Flag      | Word  | $4AFC - flag identificazione  |
| 2      | X_size    | Word  | Larghezza in pixels           |
| 4      | Y_size    | Word  | Altezza in pixels             |
| 6      | Increment | Word  | Lunghezza di una riga in bytes|
| 8      | Mode      | Byte  | Modo di salvataggio immagine  |
| 9      | Spare     | Byte  | zero                          |
|        |           |       |                               |
| 10     | Image     | incrementa*Y_dimensione bytes         |
+--------+-----------+---------------------------------------+

L'  "image" e' semplicemente l'esatta  copia della parte dello
schermo che e' salvata.
Se  il Mode e' 33  (come per i colori  estesi del Q40/60) ogni
pixel e' grosso un Word.
Per  il Mode 4  ogni Word contiene  8 pixels. Per  Mode 8 ogni
Word contiene  4  pixel  attuali  oppure  l'equivalente  delle
coordinate di  8 pixel nel  caso vengano usati  512 pixel come
sistema   di  coordinate  incrociato.  Si  consiglia  di  dare
un'occhiata  alla sezione  "Concetti" del  manuale del  QL per
ulteriori informazioni.

La parte  "image" e' preceduta da 10 byte di intestazione come
mostrato nella tabella sopra riportata.

L'estensione  _pic e'  spesso usata  dai nomi  dei file  per i
salvataggi parziali.
Infatti se date  un'occhiata  al  manuale  di  Easyptr,  sotto
"WSAIN" i comandi (L_WSA,  S_WSA,  WSASV,  WSARS)  documentano
questo formato  di file  e servono  alle estensioni  BASIC per
usare nella memoria l'area di salvataggio e ripristino (save e
restore) per caricare e salvare da e verso un file.

Per costruire un  buffer  per  memorizzare  un'area  pronta  a
essere   salvata  come  un  file  e'  necessario  definire  la
dimensione dell'area che terrā l'immagine e aggiungere 10 byte
nell'intestazione appena descritta.

Per  il Mode 4 e 8, ogni linea di grafici richiedono il numero
di pixel diviso per 4 e arrotondato per eccesso al valore word
piu' vicino, ma  bisogna  stare  attenti  in  quanto  4  pixel
necessitano 2 bytes! Non uno!

larghezza_salvata=((larghezza_in_pixel+7) DIV 8)*2

Ovviamente questi  files sono facili da  usare se sono salvati
come Word allineati in origine: in altre parole un multiplo di
8  pixel  incrociati,  per  evitare  di  aver  bisogno  di  un
arrotondamento per difetto come  una  locazione  o  ruotare  i
pixel come locazione.


Il miglior avviso e' quello di usare gli operatori forniti nel
sistema  di puntamento per salvare le aree. Questo vorrebbe in
teoria assicurare  che i tuoi programmi  funzionino in tutti i
sistemi: attuali e futuri.

In  pratica questo  non e'  possibile se  si sta  lavorando in
Basic e non si accede alle routines adatte (per esempio).
Io in questo momento sto usando queste routines. Assumiamo che
non ci  siano tipi  durante la  scrittura di  questo articolo.
Queste routines funzionano  secondo la  teoria. Questa  e' una
buona scelta  di  lavoro  in  molti  sistemi,  sempre  se  non
lavorano  su una piattaforma  ben precisa la  teoria e' ancora
giusta  e dovrebbe  fornire una  teoria di  base per  i vostri
lavori.

Per il modo 33 e altri modi dove in un Word c'e' il valore del
colore del pixel, la larghezza sare' 2*larghezza_in_pixel.
Con questa formula e' possibile calcolare l'area necessaria:

10+(((larghezza_in_pixel+7) DIV 8)*2)*altezza_in_pixel

Per   copiare  la  schermata  in  memoria  in  quest'area,  e'
necessario sapere il valore  dell'incremento  di  linea  dello
schermo  sul tuo sistema  (un numero di  toolkits fornisce una
funzione come  per esempio la  funzione display_cde publbicata
su  QL Today e nella directory DISPLAY) esattamente dal blocco
di  definizione del canale dello schermo se si usa l'assembler
o  le estensioni  Basic in  grado di  ricaricare il  blocco di
valori  di definizione del canale e come calcolare l'indirizzo
di origine dell'area salvata dello schermo:

sd_linel nella versione  JS  o  successiva  viene  fornita  la
lunghezza della linea in bytes. 
Nelle versioni  JM, AH o  successive ROM bisogna  fare in modo
che sia 128 bytes.

Io assumero'  in questo caso che  verra' usato DISPLAY_CDE per
salvare la  lunghezza "w" in  pixel e "h"  per quanto riguarda
l'altezza  con l'origine in alto  a sinistra dell'area salvata
nel punto x,y.

LET line_length = BYTES(#0)
LET screen_base = ADDRESS(#0)
LET screen_mode = DMODE(#0)
IF screen_mode = 0  OR screen_mode  = 4  OR screen_mode  = 8
THEN
  LET origin = screen_base+(y*line_length)+((x DIV 8)*2)
  save_width = ((w+7)DIV 8)*2
ELSE
  LET origin = screen_base+(y*line_length)+2*x
  save_width = 2*w
END IF
base = ALCHP(10+save_width*h)
POKE_W base,HEX('4AFC')
POKE_W base+2,w
POKE_W base+4,h
REMark IMPORTANT:  width  contiene  la  lunghezza  dell'area
salvata!Non la lungezza dello schermo!
POKE_W base+6,save_width
POKE base+8,screen_mode
POKE base+9,0
adr_heap = base+10
adr_scrn = origin
FOR a = 0 TO h-1
  MOVEMEM adr_scrn TO adr_heap,save_width
  adr_scrn = adr_scrn + line_length
  adr_heap = adr_heap + save_width
END FOR a
REMark L'area schermo e' copiata e salvata
SBYTES 'filename_pic',base,10+(save_width*h)
REMark rilascia l'area usata
RECHP base

Caricare   un'area  dietro  lo   schermo  coinvolge  l'opposto
allocando  l'area   della  stessa  dimensione   come  un  file
immagine, LBYTES c'e',  viene  calcolata  l'origine  dell'area
dello schermo dove deve essere incollata, settato il puntatore
di origine  e la parte  dell'immagine sul file  (per esempio i
successivi  10 byte dell'intestazione) e un ciclo FOR a = 0 TO
h-1  per copiare ogni riga  dietro allo schermo, incrementando
l'indirizzo  del puntatore dello schermo della lunghezza della
riga  ogni MOVEMEM e l'indirizzo  del puntator della lunghezza
della linea del file salvato.

Per i modi non descritti, il numero di bit per pixel č come il
seguente (da: documenti GD2).
Non ho avuto  tempo  di  testarlo  se  le  mie  teorie  appena
descritte  funzionano per tutti  i modi, non  avendo sistemi a
16,256 e 16 milioni di  colori,  non  conosco  esattamente  il
layout dello  schermo di Aurora a 16  e 256 colori per esempio
per cui ogni informazione e' gradita.

0        monocromatico                 1

4        4 colori                      2
7        4 colori palette mappata      2

8        16 colori                     4
15       16 colori palette mappata     4

16       256 colori                    8
31       256 colori palette mappata    8

32       64K colori 6 bit verde        16
33       64K colori 5 bit verde        16

64       16m colori, 8 bit RGB         24 of 32