Reportage dal MIPS-A
(Meeting Italiano Programmatori e Sviluppatori AMIGA)
Sapete che ho un debole per le convention Amiga... Avrei
mai potuto trascura la fatica dell'instancabile (SIC!) Fabio
Rotondo? Ovviamente no, e grazie ad OgniX (si, quello del: Itts
deee intelll auuuzaaiid, de sisteem ai laiiik... =), potere ora
godervi un Succusu (ariaje!) speciale.
Mi dicono dalla regia che è un po' in ritardo... Beh, sapete che
lo speciale di Ipisa ha richiesto ben due mesi e l'Omino Ruoccoso
(Thank you!, Piso) forse avrebbe potuto offendersi se avessi
pubblicato la fatica di OgniX dopo qualche giorno... Ok. lasciamo
perderele le scuse insensate (sperando che Mr. Ruocco non mi
denunci per abuso indebito e plurimo della sua figura!) e diamo
la linea a OgniX!
Paolo Pettinato.
Introduzione
Sabato 7 Marzo 1998, a Novara, cittadina non troppo distante da
Milano, si è svolta una conferenza amighista.
Il nome scelto per questo avvenimento è stato
MIPS-A
(acronimo di Meeting Italiano Programmatori e Sviluppatori
Amiga), ed è stato il suo debutto.
La conferenza è stata ideata ed organizzata da Fabio Rotondo, un Amiga user
del luogo, conosciuto bene anche dal resto della comunità Amiga
italiana per alcuni suoi progetti software.
La conferenza si è svolta nella Sala Congressi del Centro
Sociale "Oasi Verde": sebbene molte persone ritengano
un centro sociale un luogo un po' malandato, malconcio e
maltenuto (in molti casi è vero), quello di Novara è grande,
piuttosto confortevole e dispone di tutti i servizi di cui una
persona ha bisogno (ci sono anche il campo da tennis e la
piscina).
In ogni caso non sono qui per raccontarvi quanto carino è 'sto
posto, ma per parlare degli avvenimenti "amighisti".
L'inizio della conferenza era stato preventivato per le 10:00,
ma, come sempre accade, c'è stato un po' di ritardo: i lavori
sono iniziati alle 10:45 (ancora con alcuni problemi tecnici:
niente sincronizzazione video sul proiettore in alcuni screen
modes e cattiva qualità visiva).
Bene, ora segue una completa descrizione di ogni intervento, in
ordine cronologico (purtroppo il programmato intervento di Gabriele Santilli su NewPrefs è saltato a causa
dell'influenza che ha colpito l'autore).
Messaggio da ICOA - Rudi Chiarito
La conferenza è iniziata con questo argomento, nella persona di
Rudi Chiarito, rappresentante di
ICOA in Italia.
Egli ha presentato ICOA
(Industry Council Open Amiga), la sua struttura, come è
nata, i suoi obiettivi, le speranze...
Come probabilmente si sa, ICOA
è un'associazione localizzata in USA, ora legalmente
riconosciuta, nata da una discussione su una mailing list
promossa dalla Jay Miner Society.
L'obiettivo principale di questa associazione è quello di
aiutare la comunità Amiga ed i proprietari della tecnologia (
Amiga Inc. and
International) a definire gli
standard futuri per la piattaforma, sia hardware che software.
Ogni tipo di sviluppatore puo' sottoscriversi, pubblico dominio,
shareware, commerciale, anche i semplici utenti lo possono fare:
ogni categoria sarà informata delle notizie relative al campo
d'interesse.
Il consiglio direttivo che è responsabile delle azioni è eletto
democraticamente dai membri di
ICOA (almeno da quelli
che sono degli sviluppatori certificati) ed è composto da alcuni
degli stessi membri (sempre programmatori e progettisti
hardware).
Un altro obiettivo di ICOA
è quello di promuovere iniziative pubbliche per divulgare
l'immagine di Amiga e per accrescere la conoscenza di questa
favolosa tecnologia il più possibile (
MIPS-A ne è
un esempio).>
Ogni decisione presa dal consiglio di
ICOA deve passare una
votazione e, solo dopo di ciò, è resa pubblica via WWW, mailing
list e CD per sviluppatori.
Ovviamente ICOA è
legata strettamente ad Amiga Inc., che è l'unica entità in
grado di dire l'ultima parola sui progetti e decisioni,
specialmente su quelli concernenti l'hardware.
Ok, tutte queste cose suonano bene, ma quali sono i fatti, almeno
per ora?
Bene, qualcosa è già stato realizzato sicuramente, ma molte
cose rimagono oscure ed indefinite (come Sergio Ruocco ed uno
sviluppatore della ClassX
hanno sottolineato durante l'intervento). Prima di tutto la
programmazione su PowerPC, per esempio: cosa deve essere usato
per realizzare i programmi su PPC? La PowerPC.library della
Phase 5 oppure WarpOS della
Haage & Partner?
Attualmente non c'è un compilatore standard per Amiga: il SAS/C
è probabilmente il più usato, ma è legato strettamente
all'impegno ed alla voglia di andare avanti di alcuni suoi
sviluppatori originali, che piazzano di tanto in tanto un'update
gratuita su Aminet. Per
quanto tempo ciò succederà?
Lo Storm C sembra essere un buon prodotto (non l'ho provato
personalmente), ma penso che sia un po' troppo per l'attuale
mercato Amiga, che si sorregge principalmente su programmatori
non commerciali (un mio amico mi ha detto che con il package
scontato per studenti non ti è permesso rilasciare programmi
neanche freeware).
Come ultima cosa, ma non meno importante, gli orizzonti hardware
dell'Amiga: al momento non vedo nulla, solo nebbia, che non so
cosa possa nascondere.
Un nuovo Amiga con un hardware pseudo-CHRP, slot Zorro III e PCI?
Porting dell'Amiga OS su varie famiglie di microprocessori (PPC,
Alpha e... ARGHHH!!! \8^O X86)? Chi farà questo lavoro? Quanto
tempo impiegherà/anno? Bah! Solo nei nostri sogni per ora... :^(
Alla fine Rudi non ci ha detto gradi novità circa i piani di
Amiga Inc. per il futuro; l'unica speranza era lo show di St.
Louis Amiga '98: per quanto ne so niente anche 'sta volta
(pazienza, pazienza, ed ancora pazienza...). \:^( Le
"sfere" cominciano a girare. (La mia famiglia ha
risolto ormai da tempo i problemi di ventilazione... ndPetty=B^)
In ogni caso per ulteriori commenti si guardi il paragrafo finale.
RALF - Rudi Chiarito
RALF è un file system per reti locali (LAN) basato sul
protocollo SANA 2. Per il momento supporta solo lo scambio di
file, ma se sarà apprezzato in futuro potrà supportare la
stampa in rete, un collegamento con più macchine e non solo
peer-to-peer, e varie opzioni per la multi- utenza (es. vari
livelli di accesso agli hard disk/partizioni remoti/e).
E' totalmente Amiga-based, è indipendente dall'interfaccia
hardware (si puo' usare sia via ethernet che via seriale), ha
dimensioni contenute (max 10kB) è puo' condividere l'interfaccia
sulla quale lavora con altri protocolli (infatti non usa il
protocollo TCP/IP). Supporta, o supporterà, ogni pacchetto
dell'Amiga OS 2.0 e 3.0 eccetto ExamineAll.
L'autore l'ha realizzato perché aveva bisogno di un file system
robusto ed affidabile: prima di questo progetto usava NetFS che,
stando a Rudi, non è così stabile.
Si potrà dire che le varie implementazioni di ParNet sono
sufficientemente buone per la maggior parte degli usi (es.
ParNFS): si, ciò è vero, ma se si ha bisogno di un file system
che possa funzionare su quasi tutte le interfacce di rete, non si
puo' usare il ParNet.device perché esso è limitato
all'uso con il suo speciale cavo.
RALF non è compatibile con il famoso stack TCP/IP di Holger
Kruse, Miami, perché quest'ultimo non riconosce i pacchetti di
RALF.
Rudi non ci ha potuto mostrare il programma funzionante a causa
di un guasto al suo controller
SCSI, che non gli ha permesso di accedere ai dati sull'hard
disk.
L'autore è in cerca di beta tester.
Amiga Foundation Classes - Andrea Galimberti
Questa
associazione fornisce un set di classi per
controllare/implementare varie funzioni, in vari campi, per
facilitare l'utilizzo delle risorse del sistema operativo.
Naturalmente per usare questo prodotto software si deve conoscere
la programmazione orientata agli oggetti (almeno le bbbasi
;) (Ma sesesei Balbububuzientetete? =º^] ndPetty), ma siccome
questo tipo di approccio allo sviluppo di programmi sembra essere
quello del futuro, sarebbe meglio istruirsi al riguardo (un
consiglio valido anche per me :) (L'importanza del paradigma ad
Oggetti per il futuro è rimarcata in un documento pubblicato
negli atti di Ipisa '95. Trovate tutto sul sito di
Cloanto. ndPetty)
Anche se ogni classe specifica è realizzata per semplificare
l'accesso alle comuni funzioni/risorse dell'OS, non è stata
fatta per essere usata anche dai più ignoranti in programmazione
per evitare di ridurne la flessibilità.
I principali vantaggi che derivano dall'uso delle seguenti classi
sono questi: come già accennato prima non è necessario andarsi
a studiare degli aspetti complessi e a basso livello del sistema
operativo; un altro punto a favore è la portabilità: se si
scrive un programma usando queste classi, si potrà ricompilare
lo stesso programma su un altro OS che ha a disposizione le
stesse classi (in ogni caso ciò dipende dalla disponibilità
delle stesse su sistemi operativi diversi): all'inizio le classi
sono sviluppate in Amiga E, poi vengono tradotte in C++.
Naturalmente gli autori lavorano sodo per fare in modo che ogni
classe sia stabile e sicura. Un altra simpatica caratteristica è
il riconoscimento automatico dell'OS, così in relazione alla
versione dello stesso (es.2.0 o 3.0), la classe userà le
corrette routine in dipendenza delle funzioni di sistema
disponibili.
Ovviamente ad ogni classe è allegata un completa documentazione
in formato standard (tipo autodocs), con numerosi esempi.
Queste sono solo alcune delle classi completate: Bitmapper per la
trattazione delle bitmap, Super_Picture per il caricamento delle
immagini, Database è una classe pe questo tipo di applicazione,
NodeMaster per le liste dinamiche, Rexxer per implementare porte
ARexx, ReqTooler per accedere alla libreria ReqTools, Displayer
controlla le CopperLists e le ViewPorts, IFFParser per leggere e
scriver file di questo tipo, Tasker permette di lanciare task
asincroni (multithreading), e Palette controlla una specifica
palette di colori.
Ora ci si potrà chiedere quanto bisogna pagare per tutto questo.
Niente (come spesso succede in ambiente Amiga).
La distribuzione è completamente gratuita via
WWW e tramite
il CD italiano periodico Amy
Resource; c'è anche una mailing list.
Per il futuro l'intenzione è quella di fornire ancora più
classi, completare il porting in C++, per supportare anche altri
OS (più avanti), e sfruttare le nuove caratteristiche delle
successive versioni dell'Amiga OS (?).
Un nuovo assembly ad alto livello,
indipendente dalla CPU - Piero De Nicola
Piero ha iniziato a parlare delle sue esperienze passate di
programmazione con il C-64, Amiga ed anche Piccì, in Basic,
Pascal, C e C++. Ci ha detto che le cose più sorprendenti le ha
scoperte con il linguaggio assembly: il C, la programmazione ad
oggetti sono cose notevoli, ha detto, ma niente è cambiato
drasticamente dai principi della programmazione.
Alcuni anni fa ha avuto un'idea per un nuovo linguaggio, mixando
vari aspetti delle sue esperienze di programmazione.
Ha fatto solo un abbozzo della sua idea: lui pensa che ci siano
delle istruzioni/funzioni comuni per ogni tipo di
microprocessore. Studiando i vari ambienti Piero ha trovato
alcune strutture fondamentali: ogni altra operazione è solo
un'adeguata combinazione di quelle di base. In questo modo ognuno
può costruire la propria struttura FOR preferita, la struttura
WHILE, quella REPEAT, e così via.
E'così possibile realizzare il proprio set di funzioni base per
poi usarle in futuri programmi; se si trova un metodo migliore
per realizzare un specifica struttura, basta cambiare la sua
definizione.
Alla fine, una volta scritto il programma principale, si deve passarlo
all'assemblatore/compilatore, il quale pre-processerà l'intero
listato tante volte quante sono le strutture non standard
utilizzate (sostituisce la label di una struttura custom con il
suo codice sorgente; queste funzioni possono essere anche
annidate), e poi alla fine traduce il tutto in linguaggio
macchina.
Si puo' notare delle somiglianze con il C, E e così via: bisogna
avere un differente compilatore per ogni processore si desideri
supportare.
Questo è vero, ma ci sono almeno due differenze: la prima è che
si è più liberi di definire anche le strutture più semplici
(quelle della programmazione strutturata per esempio). La seconda
differenza è che creare un assemblatore/compilatore di questo
tipo è più facile che realizzare uno per il linguaggio E, per
esempio; ogni microprocessore ha un istruzione carica un
numero ad uno specifico indirizzo, varie funzioni di somma,
ecc.
Tutto ciò potrà sembrare un po' inutile oggigiorno con
l'imperante C, C++ e Java. Beh, non sono qui per dare un
giudizio: pensaci tu.
POSBB, Portable OS Based Benchmark
- Pietro Altomani
Come il nome stesso dice, il progetto presentato cerca di essere
un sistema universale di benchmark che dovrebbe permettere di
testare ogni tipo di computer su veri parametri, non solo sulla
mera potenza di calcolo, accesso alla memoria, ecc.
Al momento ci sono due versioni di POSBB: una solo per Amiga e
l'altra atta ad essere compilata sotto ogni piattaforma. I
sorgenti sono disponibili.
POSBB attualmente testa i seguenti parametri: CopyMem (velocità
di copia dati in RAM), Printf (velocità di stampa a video sulla
console), IMath (velocità di calcolo con numeri interi), FMath
(velocità di calcolo in modalità virgola mobile), TMath
(velocità di calcolo delle funzioni trascendentali), Read e
Write (velocità di lettura/scrittura su disco) e, solo per la
versione Amiga, WritePixel, DrawEllipse, Draw (velocità di
disegno...).
Per le versioni future l'autore pensa di aggiungere altri
parametri: velocità di disegno della GUI, velocità di
coding/decoding di file JPEG, velocità di coding/decoding file
MPEG, velocità di compressione/decompressione, trattamento della
grafica 3D ed alcuni parametri per verificare il multitasking.
Una cosa carina da implementare puo' essere la comparazione tra
potenza della CPU e capacità di multitasking: in questo modo
l'incredibile efficienza dell'Amiga sarebbe indubbiamente
provata.
Successivamente Pietro ha mostrato alcuni risultati di vari test
tra il suo Amiga 1200 (030/40MHz) ed un PC con un Pentium 120:
naturalmente il PC ha superato l'Amiga di Pietro, ma non tanto
quanto la differenza di potenza di calcolo puo' far supporre ai
soliti imbecilli PC user (i risultati peggiori dal lato Amiga
sono stati ottenuti nei test matematici, ma in questo caso la
ragione è da imputarsi alla mancaza di una FPU nel 1200).
Purtroppo Pietro non ha potuto realizzare il test su un Amiga
equipaggiato con PowerPC.
POSBB non ha una GUI per il momento (per la portabilità) e
l'autore sta cercando collaboratori, specialmente per il porting
su altri OS.
Michele Battilana della
Cloanto ha offerto alcuni utili gadgets e prodotti poco prima del
pranzo...
Proprio come ad IPISA, l'altra convention Amiga italiana, Michele
Battilana della Cloanto (i
creatori di Personal Paint) ha regalato ad ogni partecipante
alcuni doni: una copia di Personal Paint V7.0 su Mini-CD ed un
coupon per ricevere gratis Amiga Forever V2.0.
Così ogni Amiga user tranquillamente si è mosso verso il
tavolo centrale per ricevere questi gingilli oltre agli atti
della conferenza (su CD-ROM); dopo di ciò tutti sono andati
nella grande sala da pranzo per cibarsi... ;)
Studio dell'Amiga OS: meriti, punti
deboli e tecniche di programmazione - Enrico Altavilla
In questi ultimi tempi Enrico
si è divertito a studiare approfonditamente varie parti del
sistema operativo dell'Amiga, specialmente Exec e la
graphics.library.
Ha iniziato questo lavoro perché voleva (e, per quanto ne so,
vuole :) conoscere come funziona l'OS ad un livello molto basso
per implementare, o almeno per suggerire, modi per migliorare le
funzioni attualmente disponibili e per aggiungerne di nuove
(protezione della memoria, resource tracking, ecc.).
Prima di tutto Enrico ha puntualizzato che l'Amiga OS è stato
realizzato per funzionare il più velocemente possibile su un
68000 base, che oggigiorno è mooolto lento; questo significa che
gli autori hanno accettato alcuni compromessi tra una
programmazione pulita e la velocità.
All'inizio questi compromessi hanno dimostrato di essere stati
un'ottima scelta; oggi, anno, dopo anno, sono diventati un
ostacolo per l'espandibilità del sistema.
Un esempio di questi trucchetti è il codice in-line: invece di
saltare ad una subroutine, cosa che consuma un certo tempo su un
68000 normale, il codice di questa è stato replicato proprio
dopo la chiamata, così da non sprecare tempo in un istruzione di
salto. Naturalmente questa operazione non è stata usata molto
perché la quantità di ROM disponibile non era eccessiva.
Un altro problema che i programmatori dell'Amiga OS dovranno
affrontare è la gestione non proprio pulita dei semafori da
parte dell'OS durante l'accesso ad alcune risorse pubbliche:
talvolta, in alcune routine del sistema operativo, il
multitasking è "spento manualmente"; scrivendo su un
registro custom, si lascia al sistema operativo tutta la libertà
che vuole, e più tardi, alla fine dell'operazione, il
multitasking viene riattivato sempre manualmente. In questo modo,
come si puo' capire, il sistema operativo agisce in maniera molto
sporca.
Una cosa simile è il salto diretto ad una parte interna di una
subroutine: quella principale non usa il corretto offset per la
chiamata, ma salta direttamente all'interno della subroutine,
alla linea che è importante per l'operazione attuale. In questo
modo si possono guadagnare alcuni cicli di clock, ma oggi è
totalmente inutile.
Questo è un comportamento molto pericoloso in un sistema che dovrebbe
essere modulare ed aggiornabile.
Enrico ha studiato un
modo per risolvere molti di questi problemi, senza riscrivere
molto codice dell'OS, prevedendo una buona performance.
Egli ha presentato una documentazione di questi sui studi e
risultati ad Amiga Inc., ma uno dei "capoccia"
dell'azienda gli ha risposto che non erano interessati al suo
lavoro (questo è quello che ha
detto Enrico).
Sebbene questa cosa piuttosto triste Enrico continuerà il suo
studio e pensa di aprire un mailing list per dei collaboratori
esterni e, in prossimità della fine del progetto, ripresentare
lo stesso ad Amiga Inc.: se anche questa volta la risposta sarà
negativa, probabilmente penserà se chiedere una licenza Amiga OS
(tanto costa 10.000 lire :) .
Nota carina a margine.
Enrico Altavilla è l'autore di un programma che
"patcha" alcune funzioni della graphics.library: si
chiama AmyWarp. E' davvero utile per velocizzare il
redrawing su schermi Amiga con elevata profondità (es. Hi-Res
Interlace 256 colori), cioè per ogni sistema senza una scheda
grafica.
Giusto per rendere ogni partecipante a MIPS-A più felice, ha
deciso di regalare tale programma a tutte le persone presenti
(visto che il programma è shareware).
Avrebbe dovuto spedirlo via e-mail pochi giorni dopo
l'avvenimento di Novara, ma per problemi legal-commerciali (?)
non è ancora arrivato.
AmyWarp non è ancora su Aminet,
per quanto ne so, ma sarà uploadato quando la versione 1.2 sarà
completa.
DOOPSI 2: Revolution - Fabio Rotondo
DOOPSI,
acronimo di Dynamic Object Oriented Programming System Interface
(Interfaccia di Sistema Orientata agli Oggetti e pure Dinamica :)
, è un sistema autore per creare delle avventure grafiche tipo
quelle della Lucas Arts (Zak McKraken, The Secret Of Monkey
Island, The Day Of The Tentacle, ecc.).
La prima versione di questo programma è stata presentata ad
IPISA nel 1996.
A MIPS-A
è stata presentata una nuova versione completamente riscritta.
Caratteristiche: 100% orientata agli oggetti, editor
multi-finestra, drag and drop (trascina e lascia... triste
traduzione italiana :) , le azioni possono esser definite
dall'utente (Premi, Tira, Leggi, Usa, Guarda, ecc.), nodi di
percorso programmabili (es. azione quando il personaggio sta su
un ben determinato punto), percorsi intelligenti (cerca il
percorso più breve), gestione intelligente degli elementi
grafici (lo stesso oggetto usato in due scene diverse non viene
caricato due volte in memoria), salvataggio del gioco integrato
(auto-salva la posizione durante il gioco).
Supporta: CyberGraphX, librerie di compressione XPK, datatypes,
AHI e le NewIcons per i pulsanti all'interno dell'editor.
Fabio ha lanciato il
programma, attivato l'editor, caricato alcuni oggetti, scene,
immagini e poi ha fatto partire tutta 'sta roba: è apparso un
nuovo screen e dopo circa 0.5 secondi... tah dah! GURU
MEDITATION, intercettata da MCP. Si, è ancora una beta, anche se
in uno stadio avanzato. Ha detto che la versione sul CD-ROM di
MIPS-A è
più stabile visto che non è stata compilata proprio la notte
prima della conferenza. ;)
Ad ogni modo il programma è davvero notevole, comparato
anche con la sua prima versione: ogni personaggio che abbia in
mente di realizzare un adventure come quelli della Lucas Arts
dovrebbe prendere in seria considerazione l'idea di usarlo.
Ma non è finita qui.
Fabio ha presentato anche
un "piccolo" programma, fatto solo due giorni prima: si
chiama InstallerFX.
Come si potrà evincere è un programma di installazione
che vorrebbe sostituire il ben conosciuto figlio di Mamma
Commodore.
Presenta le seguenti caratteristiche: è incredibilmente facile
da programmare se confrontato con quello Commodore (gli script
sono leggibili); si possono caricare delle immagini all'interno
della finestra di installazione (per bellezza, ma anche per dare
alcuni consigli); è strutturato a pagine: l'utente puo' scorre,
su e giù, e selezionare cosa vuole; non si interrompe se non
trova un file o se c'è un qualsiasi errore (appare un bel
requester).
Per ciò che riguarda il futuro di questo programma si puo' dire
che supporterà un controllo delle risorse (che palle 'sto nome
da Win user) della macchina (se c'è uno 060, se c'è
CyberGraphX, ecc.), oltre alla deinstallazione (anche se a me
ciò non piace ;) .
Sarà disponibile (forse lo è già) su
Aminet in forma freeware.
BOOPSI e VisualPrefs - Massimo Tantignone
Massimo ha iniziato a
parlare di programmazione BOOPSI in Amiga OS.
BOOPSI (Basic Object Oriented Programming System Interface, che
significa Interfaccia Elementare di Sistema per la Programmazione
Orientata agli Oggetti) è un ambiente, incluso in Intuition, che
permette di sviluppare alcune parti dei propri programmi (GUI, ma
non solo) in una modalità ad oggetti.
Ecco un esempio. Se si ha bisogno di disegnare una cornice dentro
ad una finestra, si puo' agire in due modi: disegnarla a
"mano", pixel per pixel (questo è l'unico modo sotto
OS 1.X), oppure usare uno specifica routine dell'OS, chiamata classe,
in questo caso FrameIClass. Perché si dovrebbe usare l'ultima?
Immaginiamo che ci sia bisogno di questa cornice per contornare
un gadget: si vuole che il tutto appaia nello stile grafico
attuale dell'OS, si vuole che la cornice sia legata all'oggetto
in questione (il gadget); quest'ultima cosa è particolarmente
utile perché se si cambiano le dimensioni del gadget in futuro,
non ci si dovrà preoccupare di riscrivere una differente routine
per un corretta cornice. Inoltre se in una nuova versione del
sistema operativo (?) lo stile grafico cambia, tutti i programmi
scritti in questo modo vi si adatteranno automaticamente.
Tutte queste cose, e molte altre, sono realizzate da una classe
specifica.
Massimo ha poi mostrato un
puo' di codice sorgente come esempio di una corretta
programmazione: tutte le spiegazioni sono state chiare e precise,
anche per me, che sono un novellino di programmazione in C, non
abituato alla OOP.
Naturalmente egli ha parlato del suo famoso programma VisualPrefs
(su Aminet util/wb/VisualPrefs.lha),
che permette di configurare vari aspetti della GUI di Amiga OS;
è una cosa tipo SysIHack, ma davvero molto più avanzata.
Ha detto che realizzare un programma che funzioni correttamente
con VisualPrefs non è difficile e non comporta regole
specifiche, basta solo usare in modo corretto tutte le risorse
dell'OS.
Infine voglio sottolineare che ho veramente apprezzato questo
intervento da parte di Massimo Tantignone per la precisione e la
chiarezza.
Modellazione 3D di una faccia umana
partendo da una immagine digitalizzata - Andrea Rotondo
Questo intervento ha trattato alcuni consigli per creare un viso
umano sotto forma di oggetto tridimensionale, partendo da due
immagini digitalizzate di un volto reale: la vista frontale, per
i dettagli della faccia, e la vista laterale, per la profondità
della testa.
Andrea ha usato Lightwave come programma 3D; in ogni caso tutta
la discussione è portabile su qualsiasi altro software di
modellazione tridimensionale.
Per spiegare le varie fasi di questo tipo di lavoro egli ha usato
alcune immagini provenienti da ogni livello di una sua precedente
esperienza; una cosa simpatica: nell'esempio ha usato il viso di
suo padre. :)
Ha iniziato la modellazione con un cubo, immediatamente tagliato
per approssimarlo ad una testa. In seguito ha caricato l'immagine
della faccia di suo padre come background e ha continuato la
modellazione riferendosi a quella immagine; ha usato l'opzione smuss
di Lightwave per rendere il tutto meno spigoloso e, alla fine, ha
avvolto il viso di suo padre attorno all'oggetto creato.
Il risultato si è rivelato piuttusto notevole.
Dopo di ciò Andrea ha presentato un CD-ROM da lui stesso
realizzato, chiamato Humanoids, con molti oggetti 3D
rappresentanti personaggi umani (un clone di Lara Croft, un body
builder, una donna nuda 8^p , un cyborg, ecc.) in varie posizioni
e stili di animazione, tutti con le loro texture.
E' davvero utile per i programmatori di video game e per i
grafici che non vogliono perdere tempo a modellare questo tipo di
oggetti molto complessi.
Uso corretto della graphics.library
su macchine AGA e per assicurare la compatibilità con le schede
grafiche - Gabriele
Greco
Oggi l'unico modo per mantenere una completa compatibilità con
il dispositivo di uscita video, sia esso il chipset Amiga oppure
una scheda grafica, è quello di usare la graphics.library
correttamente. Infatti il vecchio modo di pokare direttamente ai
registri hardware è il sistema più errato per gestire l'uscita
video.
Perché ciò? Perché, come Gabriele
ha detto, ci sono troppi modi per trattare le bitmap, così ogni
volta che si cambia il device di uscita, si dovrebbe scrivere una
specifica routine (probabilmente anche in schede grafiche
differenti si ha un ordine di byte colore diverso).
I vantaggi di usare la graphics.library?
Compatibilità con i cloni Amiga senza chipset (DraCo, UAE),
l'utente puo' selezionare il suo screen mode preferito, supporto
per le attuali e le future schede grafiche, si puo' lanciare i
propri programmi sullo schermo del Workbench e, non ultimo, solo
un codice invece di diversi tipi quanti sono i metodi di
memorizzazione delle bitmap.
Gabriele ha parlato anche di
alcune particolarità degli standard CyberGraphX e Picasso96,
tecniche di double buffering, condivisione della palette sul
Workbench e trattamento degli schermi interleaved.
Spendo solo alcune parole circa questi argomenti un po'
complessi.
Come probabilmente si saprà CyberGraphX e Picasso96 sono due
standard de facto per l'RTG su Amiga (Re-Targettable
Graphics - Grafica Re-Indirizzabile). Entrambi sono delle pesanti
patch che cambiano molte funzioni dell'OS: infatti le schede
grafiche sono utili per schermi più profondi con elevate
risoluzioni (e più alta frequenza di refresh). Il problema è
che l'Amiga OS non sa cosa sia uno schermo a 24 o a 16 bit: esso
puo' aprire uno schermo con al massimo 256 colori (su macchine
AGA). Questo ha portato a vari problemi su vari aspetti, talvolta
risolti in modi differenti dai due standard (un esempio è il bug
nel picture.datatype V39/40, riguardo alla natura planare delle
bitmap su Amiga.)
Per l'altro argomento, il double buffering, Gabriele ha riferito che dall'OS
3.0 è system friendly e che è supportato correttamente dalle
schede grafiche. Egli ha mostrato un po' di codice come esempio
d'uso delle funzioni relative. Per chi non lo sapesse, il double
buffering è una tecnica per permette di ottenere delle
animazioni più fluide.
Un altro importante argomento della programmazione attuale su
Amiga è la condivisione della palette, implementata dall'OS 3.0,
la quale permette di remappare i colori per un altro programma
funzionante sullo schermo Workbench. Gabriele ha detto che
generalmente questa cosa appare difficoltosa all'inizio, ma
prende non più di tre linee di codice, ed è system friendly.
Per convincere l'audience ha mostrato un clone di Kick Off,
chiamato Eat The Whistle, realizzato da egli stesso,
funzionare fluidamente in una finestra su uno schermo
CyberGraphX.
Alla fine Gabriele ha spiegato
i vantaggi e gli svantaggi del modo interleaved, che permette di
muovere un oggetto (normalmente un rettangolo) su questo tipo di
schermo usando il blitter invece di perder tempo CPU, ma in
alcuni casi questo metodo succhia la preziosa Chip RAM.
Anche questo intervento, sebbene profondamente tecnico, è stato
presentato in modo davvero chiaro.
Pregi e difetti del ray tracer
Persistence Of Vision - Paolo
Redaelli
Persistence Of Vision (POV) è un programma di grafica ray
tracing di pubblico dominio disponibile quasi su ogni
piattaforma.
E' distribuito con i suoi sorgenti ed è scritto in ANSI C.
Naturalmente questo significa che il programma principale non ha
una GUI: infatti la scena è descritta con uno script ASCII (il
linguaggio è simile al C).
Per questo motivo si sono create un vasto numero di primitive
(oggetti di base) per rendere l'editing più semplice.
Se si vuole utilizzare un oggetto realizzato con il modeller di
un altro pacchetto per grafica tridimensionale, si potrà usare
un programma chiamato Win3D (come si puo' facilmente indovinare
dal nome è solo per W*nd*s, per ora) in futuro, il quale
permette la conversione da quasi ogni tipo di formato.
POV supporta anche le splines, ma la modellazione con
questo tipo di tool usando solo un text editor è veramente dura;
al momento l'unico modo per creare oggetti con splines è quello
di usare un programma per Mac in emulazione (ShapeShifter oppure
Fusion).
Un'altra grande caratteristica di POV è la vasta scelta di
texture; infatti molti grafici, od artisti se si preferisce,
usano POV solo per creare alcune texture da usare poi in altri
programmi di grafica 3D.
Anche i blobs (o metaballs) sono supportati; utili
per i fluidi come l'acqua.
Si puo' pensare che usare POV si abbastanza difficoltoso perché
si usa un linguaggio script per creare le scene. Beh, è vero,
non è facile come Lightwave, o Imagine, oppure come un altro
pacchetto con interfaccia grafica, ma il linguaggio script
permette di creare alcune scene molto complesse con solo poche
righe di codice: si definiscono gli oggetti, la legge matematica
che descrive le variazioni, ed ecco fatto. E' incredibilmente
flessibile!
Secondo me le immagini generate da POV sono molto impressionanti,
ma a causa della sua natura, ho trovato il programma
tendenzialmente utile per arte astratta, non così idoneo alla
riproduzione del mondo reale (in modo semplice).
Il problema principale di POV su Amiga è la mancanza di
programmi di supporto per la modellazione, per le funzioni di
rendering e così via. Paolo sta facendo di tutto per spingere
gli autori di varie utility per POV a portare i loro programmi
sulla nostra amata piattaforma. (A proposito di supporto, vorrei
ricordare che Paolo Redaelli sta creando una sezione su AmiWorld
interamente dedicata alle meraviglie di POV! Non cambiate canale!
=)
Amiga e
dintorni - Sergio
Ruocco
Perché Sergio? Perché lui ha organizzato, insieme ad altri
amighisti, IPISA, la più "anziana" conferenza Amiga in
Italia; Perché ha lavorato attivamente nella redazione di Amiga
Magazine.
Il discorso di Sergio è iniziato parlando della chiusura di
Amiga Magazine. Per quelli che non lo sanno, Amiga Magazine era
indubbiamente la più completa ed autorevole rivista Amiga in
Italia (ma non solo). La sua pubblicazione è stata bloccata nel
Dicembre 1997 a causa della mancanza di vendite e di
inserzionisti.
Naturalmente da quando questa decisione è stata resa pubblica,
tutto lo staff editoriale ha dichiaratamente espresso la volontà
di cercare un nuovo modo per continuare la "missione
Amighista" (o meglio il modo per continuare a diffondere il vero
verbo della cultura informatica).
Ha parlato di due modi per riprendere le pubblicazioni: uno è
quello di stampare una fanzine Amiga-only per i circa 5000 utenti
Amiga italiani. L'altro è di iniziare un progetto più complesso
per una rivista nelle edicole, aperta anche ad altre piattaforme
alternative come Linux, Java e il Be
OS.
Il primo progetto è legato a piani certi di sviluppo per il
futuro dell'Amiga da parte di Amiga Inc./
Gateway 2000, quindi possiamo già
scartarlo visto che niente è stato rivelato (se
c'è qualcosa da rivelare); in quel periodo si stava aspettando
buone nuove della fiera Amiga '98 in St. Louis.
L'altra opzione sembra essere la più realizzabile, visto che non
ci sono molti nuovi prodotti per Amiga da recensire e Perché ci
potrebbe essere un supporto monetario da parte di
Sun Microsytems e
Be Inc.. Inoltre grazie alla base di
utenti Linux sufficientemente ampia, affamata di consigli,
trucchi e notizie, ci potrebbe essere un'audience più grande. In
ogni caso ciò non significa abbandonare l'Amiga; è solo un modo
per sopravvivere.
Solo un'altra piccola cosa triste riguardo alla chiusura di Amiga
Magazine, la quale ha contribuito ad un grossa caduta del mercato
Amiga in Italia: non c'è stato alcun supporto sia dalla casa
madre (Amiga Technologies/International), sia da qualsiasi altra
grossa azienda amighista come la Phase 5. Come sicuramente si sa
un rivista vive con la pubblicità.
Sergio ha anche parlato del bassissimo profilo del mercato delle
riviste di informatica in Italia: false recensioni (comprate dai
produttori) e così via. Importano solo i soldi.
Egli ha parlato anche delle necessità per l'Amiga:
sostanzialmente una...soldi.
Denaro per ingaggiare 50 ingegneri hardware e software per la
ricerca e lo sviluppo: ogni nuova persona mette qualcosa di suo
ed unico dentro il progetto Amiga (es. i datatype).
Denaro per la pubblicità sui vari media: senza campagne
promozionali non c'è mercato oggigiorno, anche se si possiede il
migliore prodotto. I tempi in cui l'Amiga si vendeva da solo
sono finiti.
Tristemente sembra che Amiga Inc. ed Amiga International non
abbiano fondi né per 50 ingegneri, né per un minimo di
pubblicità...
Dobbiamo pregare ed avere fede... finchè questa non finisce.
Sergio ha parlato anche del progetto PIOS One della
PIOS GmbH (David Haynie sta
lavorando alla PIOS) e, come detto prima, del
Be OS.
Note finali
Purtroppo la conferenza non è stata molto pubblicizzata, così
non si sono presentate molte persone: infatti io ho contato non
più di 30-35 "anime" nella Sala Congressi.
Alla conferenza c'erano anche dei vip della scena Amiga :) : il
già menzionato Michele Console Battilana della
Cloanto, lo staff della
ClassX, Luca Danelon
della Interactive con la sua collezione di CD-ROM
Amy Resource.
L'atmosfera globale non era molto felice a causa della attuale
debolezza della situazione Amiga (in special modo in Italia):
come sarà il futuro, o meglio, ci sarà un futuro per l'Amiga?
Al momento non possiamo rispondere a queste domande. Solo i
detentori della tecnologia Amiga possono farlo (se solo fossero
gli utenti a possedere l'Amiga... un po' difficile da gestire ed
organizzare ma... carino ;) .
Io spero che il prossimo anno le cose vadano meglio per la nostra
amata, specialmente nel Bel Paese :) .
Hey, personaggi! \8^O Non voglio dire di comprare un Piccì con
W*nd*ws9X/NT, ok? E neanche scegliere Linux oppure il
Be OS. Solamente non dobbiamo essere
sciocchi e dobbiamo mantenere gli occhi bene aperti.
Bonus
Sempre grazie al solito :) Michele Battilana della
Cloanto,
qui si potrà trovare
delle belle foto dell'evento scattare con la macchina fotografica
digitale Sony di Michele.
Questo documento è stato scritto
da Luca
"OgniX" Ognibene.
Molte grazie a Roberto Braidotti che mi ha
permesso di unirmi
a lui per raggiungere Novara in auto, e per avermi prestato tutto
il video della conferenza.
Mi scuso per la lunga attesa per la realizzazione del presente
reportage.