------------------------------------------------ Sottosistema grafico ottimizzante in PuzzleBOBS. ------------------------------------------------ Com'è possibile vedere nei file di configurazione (ConfigFiles), PuzzleBOBS permette un ampio ventaglio di scelte per quel che riguarda il disegno della grafica, si può cioè scegliere quale tipo di funzioni abilitare, attualmente tutte basate sull'uso di un chip grafico dedicato o direttamente della Cpu di sistema. Attualmente sono disponibili 5 scelte diverse, per abilitarle è possibile agire direttamente nei ConfigFiles, ponendo il valore numerico scritto a destra dell' "uguale" (=) nell' apposito campo. Tra parentesi quadre è invece indicata l'opzione nel menu di gioco. 1) Funzioni standard di AmigaOS. =0 (default) [Os funcs] -------------------------------- Questa opzione utilizza le funzioni della graphics.library di AmigaOs, BltBitMap(), BltBitMapRastPort(), BltMaskBitMapRastPort(), BltClear() e ClipBlit(). Sfortunatamente la funzione BltMaskBitMapRastPort() sull' hardware standard di Amiga è estremamente lenta ed è molto utilizzata dal gioco. Quest' opzione viene sempre usata quando si utilizza una finestra qualsiasi come contenitore video, e permette di utilizzare programmi di terze parti abili nell'accelerare le procedure grafiche. 2) Funzioni grafiche ottimizzate. =1 [Opt funcs] ---------------------------------- Quest' opzione utilizza dei corrispettivi di BltBitMap(), BltBitMapRastPort() e ClipBlit() sempre utilizzando il blitter però attraverso funzioni a basso livello, scritte in assembler ottimizzato. Le funzioni BltClear() e BltMaskBitMapRastPort() non sono state clonate, e il gioco utilizza quelle della graphics.library. Questo sistema non viene mai considerato quando si utilizza un modo schermo di una scheda grafica e quando si gioca in finestra. L'utilizzo di quest' opzione può dare alcuni problemi alla perfetta visualizzazione grafica dei dati quindi prestategli attenzione, o preferite altre opzioni, considerando che l'aumento di velocità che ne deriva non è così evidente. 3) Funzioni grafiche via Cpu. =2 [cpu slow] ----------------------------- Il chip Blitter, di serie su ogni Amiga, non è spesso all'altezza di compiere un elevato numero di operazioni grafiche considerando inoltre che PuzzleBOBS opera in multitasking. Per questa ragione e se si dispone di un processore veloce è consigliabile abilitare i modi che fanno uso della Cpu come unico operatore grafico, considerando che già un processore 68020 con le caches attive è più veloce del Blitter. A questo fine sono state clonate con successo tutte le funzioni grafiche necessarie, come BltBitMap(), BltBitMapRastPort(), BltMaskBitMapRastPort(), BltClear() e ClipBlit(). Il modo ha dimostrato di lavorare molto bene sugli schermi standard di Amiga, mentre su schede grafiche, in base al sistema RTG adottato, può dare problemi alla visualizzazione dei dati. Poichè accede alla memoria grafica in DMA necessita di processori molto veloci, per questa ragione può essere preferibile utilizzare la prossima opzione che è molto più performante. Questo modo non permette di utilizzare una finestra, nel tal caso il gioco si comporta come nell' opzione 1). 4) Funzioni grafiche via Cpu con dati in Fast Mem. =3 [cpu fast] ------------------------------------------------- Questo metodo utilizza le stesse funzioni di quello precedente ma alloca e dispone tutti i dati grafici in pseudo BitMaps allocate in Fast Mem (memoria pubblica). L'unico blocco di memoria grafica richiesto è quello dello schermo, permettendo risoluzioni dello stesso molto ampie e a molti colori. A questo fine oltre alle funzioni elencate per il modo 3), sono state clonate anche BitMapScale(), AllocBitMap() e FreeBitMap() forzandole a computare dati in Fast Mem. Questo metodo aumenta la velocità delle operazioni grafiche in modo considerevole, a patto che si disponga di memoria pubblica, risparmia la preziosa memoria grafica, e ha dimostrato una elevata compatibilità con il sistema multitasking in cui opera. Come per l'opzione 3) anche in questo caso è possibile utilizzare il modo con schede grafiche ma può creare problemi alla corretta visualizzazione dei dati, sempre in dipendenza del sistema RTG utilizzato. Come il modo 3) anche questo non viene mai considerato quando si gioca in una normale finestra o in una PIP. 5) Sistema cooperativo parallelo tra Cpu e Blitter =4 [Mix] --------------------------------------------------- Con questo metodo ogni operazione grafica viene compiuta utilizzando il blitter e la CPU assieme, attivando prima il blitter e, senza aspettare, in parallelo la Cpu. Quindi se per assurdo la Cpu e il Blitter impiegassero lo stesso tempo t per compiere da soli la stessa operazione grafica, il tempo necessario per terminare la stessa utilizzando questo modo ammonterebbe a t/2. Per ovviare al problema di diverse potenze di elaborazione grafica, date dalla diversa natura dei due chip, è possibile fissare in percentuale la quantità di dati da far processare ad ogniuno. Il valore si trova nel ConfigFile, è di default settato a 50, ovvero 50%, quindi in questo caso i due chip si dividono equamente lì lavoro da compiere. La percentuale indica la quantità di lavoro che deve essere svolta dal Blitter, ed è misurata in base all'altezza della clip grafica sotto esame, quindi per ottenere il miglior risultato bisogna considerare le prestazioni fornite dai due processori, che difficilmente sono le stesse. Se la percentuale è zero il gioco abilita il modo 3) altrimenti se è 100 il modo 2). Il modo non permette di essere usato quando si gioca in finestra e con modi schermi di schede grafiche, per i quali è usato il modo 1). --------------- Note importanti --------------- Quando si seleziona il modo 2) o 3) e si decide di giocare con un modo schermo di una scheda grafica si deve fare attenzione di non utilizzare uno schermo più grande dell'area di gioco definita nel ConfigFile. Per esempio un ConfigFile che necessita di un rettangolo video di 320x240 utilizzato su un modo schermo da 640x480 punti. In questpo caso otterrete sicuramente corruzioni alla visualizzazione dei dati. Questo a causa delle funzioni grafiche clonate che utilizzano la Cpu, che per motivi di velocità non controllano i limiti e i moduli delle RastPorts utilizzate. Quando invece si utilizzano modi video più piccoli, è il caso di un ConfigFile in 640x480 utilizzato in uno chermo da 320x240 punti, non si riscontrano problemi, e lo schermo può essere scrollato con il mouse. Questo effetto collaterale non si avverte in nessun caso quando si usano i modi video nativi di Amiga ma solo su schede grafiche. Ricordate infine che quando si gioca in finestra o in una PIP il gioco utilizza sempre le funzioni grafiche di libreria, quindi il modo 1). ----------- Note finali ----------- BltMaskBitMapRastPort() svolge una funzione grafica molto complessa, la copia di dati grafici sottoponendoli ad una maschera, ed è quindi impensabile scriverne un clone che riesca a compierla in un singolo blit (un blit è una singola operazione del blitter). Infatti AmigaOS, la suddivide in un numero maggiore di operazioni elementari uguale all'altezza in punti del rettangolo. Per questa ragione la funzione BltMaskBitMapRastPort() nel modo 2) non è e stata clonata e si utilizza quella della graphics.library. In tutti i modi che usano la Cpu la stessa è stata invece clonata con successo. Infine è importante considerare che tutte le funzioni che agiscono su RastPorts di schermo sono state redirette su BitMaps, questo perchè le operazioni su RastPorts sono più lente di quelle su BitMaps (richiedono molti più controlli sui layers associati) e sono utili solo quando gli schermi sono popolati da finestre. Per questa ragione una finestra aperta sullo schermo propietario di PuzzleBOBS (tranne quelle dei messaggi di errore e quelle dei requesters Als) può essere alterata nel suo aspetto. Quando si gioca in finestra le funzioni sono invece lasciate lavorare su RastPorts. Inoltre sono state clonate con successo anche BitMapScale(), AllocBitMap() and FreeBitMap() forzandole a maneggiare e allocare dati in Fast Mem. Il corrispettivo di BitMapScale() ha una qualità inferiore rispetto a quella della graphics.library. Redirezione delle funzioni grafiche in tutti i metodi. ------------------------------------------------------ BltBitMap() ---> BltBitMap() BltBitMapRastPort() ---> BltBitMap() ClipBlit() ---> BltBitMap() BltClear() ---> BltClear() BltMaskBitMapRastPort() ---> BltMaskBitMapRastPort() Lista di tutte le funzioni clonate e percentuale di uso in gioco. ----------------------------------------------------------------- Funzione su finestra su schermo BltBitMap() 50% 68% BltBitMapRastPort() 14% 0% ClipBlit() 4% 0% BltClear() 2% 2% BltMaskBitMapRastPort() 30% 30% (Percentuale basata sul rapporto: una_funzione_grafica/somma_di_tutte_le_funzioni_grafiche)*¹ Clonate usando la CPU --------------------- BltBitMap() BltBitMapRastPort() ClipBlit() BltClear() BltMaskBitMapRastPort() Clonate usando il BLITTER ------------------------- BltBitMap() *² BltBitMapRastPort() *² ClipBlit() *² *¹ Una "funzione grafica" è una singola funzione grafica chiamata nel sorgente del gioco. *² Queste funzioni sono poco più veloci di quelle di AmigaOS. Gli unici vantaggi sono: le funzioni sono state scritte in assembler ottimizzato e sono molto veloci nell' inizializzare il chip Blitter, ma sopratutto durante il blit non controllano i limiti delle RastPorts e la ricostruzione dei layer eventualmente danneggiati.