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!

Petty

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.