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