Amiga Blast Magazine #5
Con il quinto numero di Amiga Blast, troverete grandi sorprese, a partire dalla grafica e dall’impostazione della rivista, completamente rinnovata!
Contribuite anche voi ad Amiga Blast (Vedere Come Contribuire ad Amiga Blast )
Ora navigate nella rivista.
Il Momento Della Verità
L’Orgoglio Di Essere Tra I Più Grandi (Parte 5)
L’Amiga meglio di un PC o un Mac? Probabilmente. (Parte 5)
Come supportare la Math IEEE library in Blitz.
Basi di OOP e sue implementazioni in AmigaE (Parte 4)
Uniamo la grafica 3D a quella 2D.
Recensioni E Novità
Dave Hayne parla di PIOS e dei loro progetti futuri su Amiga!
ClassX Annuncia la nuova versione di X-DVE.
NOTA BENE
Tutto il materiale in quesa rivista e’ di Pubblico Dominio, potrete quindi scaricarvi: grafica, sorgenti e usarli per i vostri giochi o i vostri programmi!!!
Gli articoli rimarranno però (C)Copyright di Amiga Blast!
L’Opinione dell’Editore
IL MOMENTO DELLA VERITA’
Il tempo dei bei propositi e delle idee interessanti sta per finire. Nei prossimi mesi cominceremo a vedere i risultati delle ricerche di VIScorp, PIOS e Phase5.
VIScorp, come potrete leggere dalla sezione delle news, ha presentato il primo Amiga portatile, basato su di un processore 68040 o 68060.
PIOS è presente al CeBIT, dove speriamo di poter andare anche noi per poter esaminare dal vivo questa nuova macchina, o almeno per vedere fino a che punto il team di sviluppo di PIOS è riuscito a giungere.
Phase5 è la nota più dolente di questa rapida carrellata. Dopo aver fatto incredibili promesse, si è come eclissata, non ha mai risposto a nessuna delle nostre e-mail, anche se, personalmente, mi sono anche iscritto al programma per sviluppatori nella categoria copper. Speriamo che questa casa, così promettente, non si alieni o rallenti il suo sviluppo, perchè sarebbe veramente una grossa perdita.
Comunque sia, ormai siamo giunti al momento della verità: le innumerevoli nuove opportunità che si erano aperte nei mesi scorsi devono ormai concretizzarsi in proposte effettive.
Qui ad Amiga Blast, crediamo che, coloro che riusciranno per primi ad offrire una macchina RISC con determinate caratteristiche e con una buona compatibilità, anche a livello binario, coi programmi Amiga esistenti, potranno diventare velocemente leader del mercato Amiga e non solo.
Amiga è una macchina con incredibili potenzialità e con del software professionale ormai di altissimo livello. Una nuova macchina RISC in grado di far funzionare questo software, si ritroverà con un parco programmi immenso e pronto all’uso.
E noi, utenti Amiga da sempre, un nuovo computer con il quale continuare la nostra strada.
L’Orgoglio Di Essere Tra I Più Grandi (Parte 5)
Grazie Wintel!
Un Po’ Di Storia
In principio era MS-DOS, un sistema single-task, single-user, che richiedeva poca memoria per funzionare. Poi i programmi cominciarono a diventare più “esosi”, a chiedere una maggiore quantità di memoria… e allora nacquero la memoria estesa e la memoria espansa… e insieme a loro i primi problemi: i programmi richiedevano sempre una certa quantità di memoria “DOS”, e quella memoria non c’era mai. Intanto, gli utenti MS-DOS cominciarono a guardarsi attorno, credendo comunque di essere molto fortunati, credendosi una “razza migliore”, fino a quando non videro che su altre piattaforme, Mac e Amiga, gli utenti non solo ignoravano cosa fossero la memoria “DOS”, quella “espansa” e quella “estesa”, ma avevano anche un ambiente di lavoro grafico piacevole a guardarsi e comodo ad usarsi. Gli utenti MS-DOS si accorsero che le loro controparti Amiga e Mac, spesso non conoscevano neppure i classici comandi come “dir” o “copy”, nè tantomeno fatomatici “chkdsk” e simili, e che, anzi, avevano i nomi dei files più lunghi di otto caratteri e non avevano bisogno di inventare abbreviazioni forzose ai loro files per ricordarsi cosa fossero: cominciarono a piangere, a sentirsi sfortunati. E chiamarono la mamma.
Mamma Microsoft venne loro incontro regalando “Windows”, che crebbe velocemente fino alla versione 3.11, nella quale simulava una interfaccia grafica. ma richiedeva per funzionare almeno 4Mb di memoria, più altrettanti mega di memoria virtuale sull’hard disk. Come se non bastasse, i programmi che funzionavano sotto “Windows” richiedevano macchine veloci e potenti, e gli utenti MS-DOS piansero di nuovo, fino a quando papà Intel non regalò loro la più grande fregatura del secolo: i processori della famiglia 80×86 che, una volta sul mercato, diventano “obsoleti” dopo sei mesi, perchè delle versioni più recenti e costose ne prendono il posto. Con questi processori, Intel sta continuando la famiglia di CISC, quando tutto il resto del mondo sta ormai passando ai processori RISC…
Fu in questa situazione che entrò in scena la zia IBM, con un suo sistema operativo a 32-Bit multitasking: OS/2. Ma mamma Microsoft disse ai suoi figli di non seguire la zia cattiva, perchè il suo sistema operativo avrebbe richiesto ben 8Mb di memoria e che non era poi quel granchè. I figli boccaloni ci cascarono un’altra volta e continuarono a castrarsi da soli sulle loro bellissime macchine a 16Bit, con Windows 3.11. Ma le proteste aumentavano anche tra loro, figli completamente incompetenti in informatica. Vedevano gli utenti Mac e Amiga giocare con programmi multimediali bellissimi e interessantissimi, mentre loro non riuscivano ad andare più in là di “Word” e di “Excel”. Volevano qualcosa di più e cominciarono a chiederla.
Oggi
Microsoft ha “esteso” Windows, creando Win95, un prodotto che, come abbiamo già avuto modo di spiegare in queste stesse pagine, non ha apportato grosse novità, anzi.
Però, la nascita di Win95 e dei Pentium hanno portato qualcosa di buono, incredibilmente: Win95 richiede “almeno” 16Mb per funzionare umanamente e hard disks molto capienti: solo l’installazione di Win95 richiede più di 100Mb di spazio sull’Hard Disk!
Dal momento che ormai tutti gli utenti MS-DOS vogliono passare o sono già passati a Win95, hanno acquistato nuove macchine o nuove parti alle loro macchine precedenti: e tra queste parti ci sono in primo luogo le RAM e gli HD. Risultato: una drastica diminuzione di prezzo sulle SIMM e sugli HD, che sono parti del computer che possiamo utilizzare anche su Amiga senza alcun tipo di problema.
Grazie utenti Microsoft e Intel, per essere così incompententi e per scegliere macchine così esose! Grazie Microsoft perchè prendi così bene in giro milioni di persone in tutto il mondo: adesso il nostro Amiga può avere più RAM e Hard Disks più capienti anche con pochi soldi.
Grazie.
Blitz Course
IEEE Doppia precisione in Blitz2
Stavo scrivendo un programma di calcoli astronomici (probabilmente lo pubblicherò uno dei prossimi mesi) quando mi sono accorto che l’accuratezza matematica di Blitz2 è terribilmente scarsa: il tipo float può contenere solo numeri bassi e le routine di conversione (ad es.: Val) hanno qualche baco. Quindi ho deciso di implementare i potenti algoritmi della doppia precisione Ieee in ambiente Blitz2. Il mio lavoro è stato ispirato dal modulo “longreal” scritto in AmigaE da EA van Breemen.
Per usare il mio codice non dovete far altro che XINCLUDErlo all’inizio del vostro programma, ed assicurarvi di avere le due librerie “mathieeedoubbas.library” e “mathieeedoubtrans.library” sul vostro disco di sistema.
Il nome del tipo in doppia precisione è “longreal”: esso è costituito da due longword. Potete usarlo solo per mezzo dei puntatori: vale a dire, per creare una variabile longreal dovete definirla (DEFTYPE) come un puntatore a longreal e poi inizializzarla utilizzando la funzione dNew{}. Ecco un esempio:
DEFTYPE.longreal *pippo
*pippo=dNew{}
e poi potete usare pippo con le routine a doppia precisione (attenzione a non dimenticare l’asterisco ()!). Se dimenticate di inizializzare una variabile prima di usarla, la vostra macchina gurerà. Ovviamente potete maneggiare una variabile longreal solo per mezzo delle routine a doppia precisione poiché il tipo longreal non è un tipo primitivo di Blitz2 (è una specie di trucco). Prima di uscire dal programma dovete liberare tutte le variabili longreal che avete precedentemente inizializzato: per far ciò scrivete semplicemente
dFree{*pippo}
Se dimenticate di liberare una variabile, la memoria allocata per essa verrà persa.
Ora descriverò le routine di conversione. Per inserire un numero a doppia precisione dovete scriverlo in una stringa e poi convertirlo in un longreal utilizzando la funzione a2d{}:
a2d{stringa$, *longreal}
La variabile *longreal conterrà il vostro numero. La funzione a2d{} accetta anche la notazione scientifica: 12e3 o 12E3. Per riconvertire il numero in stringa vi sono due funzioni: dFormat{} e dLFormat{}. La prima è utilizzata per numeri piccoli e non negativi, mentre la seconda accetta ogni tipo di numero (e permette anche l’output in notazione scientifica). La sintassi è:
stringa$=dFormat{*longreal, cifre}
stringa$=dLFormat{*longreal, cifre, potenza_max}
dove: *longreal è il numero da convertire; cifre è il numero di caratteri ascii utilizzati per rappresentare il numero convertito; potenza_max è una specie di soglia: se il numero è maggiore di 10^potenza_max allora la routine userà la notazione scientifica.
Le altre routine costituiscono tutte le operazioni che potete effettuare sul tipo a doppia precisione: in generale, esse accettano uno o due longreal come argomenti e pongono il risultato dell’operazione nel primo argomento, quindi ricordatevi di copiarlo se non volete perderlo. Per copiare un longreal usate
dCopy{*longreal1, *longreal2}
dove, come dice la regola generale, la variabile destinazione è la prima. Routine insolite, per quanto riguarda la loro sintassi, sono
long=dFix{*longreal}
converte un longreal in intero;
dFloat{long, *longreal}
converte un intero in longreal;
risultato=dTst{*longreal}
confronta *longreal con il valore 0.0: resituisce -1 se *longreal<0, 0 se *longreal=0 e 1 se *longreal>0;
risultato=dCompare{*longreal1, *longreal2}
confronta i due longreal e restituisce: -1 se longreal1<longreal2, 0 se longreal1=longreal2 e 1 se longreal1>longreal2;
dDouble{IeeeSingle, *longreal}
converte un valore Ieee singola precisione in un valore a doppia precisione;
IeeeSingle=dSingle{*longreal}
converte un valore a doppia precisione in un valore a singola precisione;
dPi{*longreal}
mette il valore di Pi (3.141592…) in *longreal. Esempi di operazioni standard sono
dAdd{*longreal1, *longreal2}
somma i due numeri e restituisce il risultato in *longreal1;
dRad{*longreal}
converte i gradi in radianti per essere usati con le funzioni angolari;
dSqrt{*longreal}
calcola la radice quadrata di *longreal e la pone in *longreal. A proposito: non vi è controllo per errori come passare un argomento negativo a dSqrt{}, dovete farlo voi; e se passate un valore negativo a dSqrt{} la vostra macchina si pianterà senza nemmeno avvisarvi.
Non riporterò tutte le funzioni numeriche implementate: il sorgente è ampiamente commentato e quindi vi invito a dargli un’occhiata.
Per essere sincero devo dire che se convertite, per esempio, il numero “1.23” (con a2d{“1.23”,longreal}) e poi lo riconvertite in stringa (con s$=dFormat{longreal,10}) vi ritroverete con “1.229999999”: probabilmente le routine di conversione possono essere migliorate, ma finora non so se questo è completamente dovuto a me; probabilmente questo è dovuto anche agli errori di arrotondamento del formato Ieee od alla funzione IeeeDPFloor (e/o IeeeDPCeil), inclusa nelle librerie Ieee, che uso durante la conversione.
Per il sorgente in LHA, premere qui.
Corso Di OOP In AmigaE (Parte 4)
Object Inheritance in AmigaE V3.x
Uno dei piccoli trucchi che si imparano pian piano programmando in OOP in AmigaE, è quello di non ereditare direttamente un oggetto per crearne un altro, ma di incapsulare il vecchio oggetto all’interno del nuovo, in modo da nasconderlo completamente dalla vista dell’utilizzatore.
Questo metodo di programmazione ha alcuni vantaggi: in primo luogo, il nuovo oggetto non disporrà di tutti i metodi dell’oggetto originario, e questo, anche se a prima vista può apparire più un limite che una caratteristica interessante, assicura che la lista dei metodi non cresca a dismisura man mano che ereditiamo un oggetto sopra ad un altro. Come secondo vantaggio, possiamo ridefinire dei metodi con un numero di parametri differenti dai metodi origirari, senza incorrere in alcuna segnalazione da parte del compilatore. Terzo, senza utilizzare il comando SUPER il nostro codice appare più chiaro e pulito.
Questo accorgimento di programmazione, infine, permette di ottenere degli oggetti più piccoli, a livello di occupazione di memoria del modulo, e più funzionali: i metodi presenti sono quelli che, effettivamente, servono all’oggetto e non uno strascico derivato dall’aver ereditato in maniera canonica un oggetto.
Inheritance Sì, Inheritance No
A questo punto bisogna effettivamente valutare quanto sia utile ereditare realmente un oggetto, piuttosto che inglobarlo all’interno di uno nuovo. I vantaggi, ma anche gli svantaggi, derivanti dalla scelta errata del metodo di implementazione. Se, per esempio, intendiamo scrivere un oggetto che sia realmente una estensione del precedente, è meglio considerare veramente la possibilità di utilizzare le capacità di “inheritance”. Il nuovo oggetto erediterà tutti i metodi del precedente, partendo già, quindi, con un bagaglio di informazioni considerevoli. E’ molto probabile, quindi, che ci troveremo ad utilizzare un nuovo oggetto che ha troppi metodi. Sicuramente molti di più di quanti ne desiderassimo, a meno che il nostro nuovo oggetto non intenda semplicemente ridefinire o ampliare l’oggetto precedente.
Una seconda possibilità, viene quindi dallo scrivere un nuovo oggetto che contiene al suo interno l’oggetto precedente. In questo modo, i metodi dell’oggetto originale non entreranno a far parte dei metodi dell’oggetto che stiamo creando, a meno che non vengano definiti nuovamente. Questo approccio, abbastanza singolare, alla programmazione a oggetti ha anche degli svantaggi: se nel nuovo oggetto alcuni metodi eseguono esattamente le stesse cose dei metodi dell’oggetto precedente, dovremo, comunque, scrivere del codice e riscrivere dei metodi, facendo crescere il codice finale del nostro oggetto.
Comunque, credo che ci si possa avvicinare alla OOP anche tramite questo particolare metodo di programmazione, inglobando un oggetto in un altro: a volte i vantaggi sono superiori agli svantaggi.
Unifichiamo la grafica 2D e 3D (Parte 3)
In questo numero tratteremo i seguenti punti:
x Conoscenze delle basi dei comandi del Layout
x Modellazione di un altro Livello di Gioco: Un mondo di Ghiaccio
x Schizzi preparatori per la modellazione del Personaggio Principale
Iniziamo con i comandi del Layout:
Visto che creeremo un mondo Ghiacciato, è utile sapere le proprietà delle Texture.
Surfaces Color: Serve a dare il colore alla Surfaces
Diffuse Level: Determina la quantità di luce che l’ oggetto rifletterà
Specular Level: Determina il Materiale, se Plastica, Metallo ecc..
Glossiness Level: Utilizzato soprattutto per le Surfaces: Plastica, Silver, determina l’ ampiezza del punto di luce sull’ oggetto.
Reflecty: Determina la riflessione di Immagini, Luci ecc.
Transparency: Determina la Trasparenza dell’ oggetto.
Dopo questa piccola parentesi sulle varie proprietà delle Textures, possiamo passare alla modellazione del Mondo di Ghiaccio.
Nel Modeller selezioniamo BOX e Numeric, aumentiamo il numero di segmenti a quattro. A questo punto andiamo in Poligon e Subdiv e clicchiamo su Metaform, rientriamoci e clicchiamo su Fractal, con valore 3. Assegnamo una Surfaces all’ oggetto e copiamolo un paio di volte. Nel Layout, carichiamo l’ oggetto, andiamo in Surfaces e settiamo i seguenti valori:
Color: 0,0,0
Specular LVL: 90%
Diffuse Level: 100.0%
Transparency: 100%
Refractive Index: 1.5
Selezioniamo anche SMOOTH E DOUBLE SIDED. Usciamo e Posizioniamo la telecamera e la Luce. A questo punto mandiamo in Rendering.
Con lo stesso procedimento del numero scorso creaimo vari blocchi e disegnamo il nostro mondo. Uno sfondo, quale montagne innevate, sono ben accette per abbellire il nostro schermo.
Ricordiamo di Settare nella camera i seguenti valori:
Trace Refraction
Trace Shadow.
Per lo schizzo del protagonista conviene procurarsi uno Scanner, o seguire questi pochi passaggi direttamente su computer:
Prima di tutto disegnamo un cerchio e tracciamo i Diametri Ortogonali.
Disegnamo Gli Occhi e il Naso.
Abbozziamo le Gote e la Bocca
Disegnamo bene il Naso, Gli Occhi, le Gote e abbozziamo le orecchie
Coloriamo come vogliamo il nostro personaggio.
Ecco un’immagine dimostrativa.
E questo è tutto per questo mese. A risentirci !!!
Intervista alla PIOS
Amiga Blast ha parlato con Dave Haynie di PIOS, delle loro macchine e del futuro dei Power Amiga. Leggete tutto adesso!
AB – Ciao, e grazie per averci regalato un po’ del tuo tempo prezioso.
Prego. Ho sempre trovato che un po più di vicinanza verso l’utente finale rispetto a quanto succede su “altre” piattaforme sia estremamente utile. Questo è qualcosa in cui Fred Bowen, io, e alcuni altri abbiamo sempre cercato di fare al meglio sin dai tempi del Commodore 128, e abbiamo cercato di mantenere durante la vita di Amiga alla Commodore. A volte è duro, quando ci sono due o tre lavori a tempo pieno da finire ogni giorno, ma io ci provo 🙂
AB – Per favore, si presenti spiegando anche i suoi compiti nella sua ditta.
Sono Dave Haynie. Ho lavorato in Commodore 11.5 anni, prima su alcuni sistemi a 8-Bit della Commodore come il C128, poi su Amiga. Sono stato su A500 per circa un mese, poi sono passato all’ A2000. Ho lavorato su entrambi i modelli A2500 (le schede accelleratrici), ho disegnato i bus Zorro III e alcune parti dell’ A3000, ho creato i primi prototipi dei sistemi AA e AAA, ecc… e così via.
Dopo Commodore, ho lavorato per giorni a Scala, che si potrebbe definire la “Ex-Commodore Orientale”, dal momento che quasi l’ 80% dell’ufficio di Engineering è di ex-Commodore, con i rimanenti associati comunque in qualche modo ad Amiga (sviluppo indipendente della GVP) (Per conoscenza: la compagnia 3DO è “Ex-Commodore Occidentale”). Ho tenuto anche molte consulenze su progetti hardware, molti condannati a morire (sciocco io, che ho provato a fare soldi sul bussiness di Amiga mentre questa appassiva).
Lo scorso novembre, Amiga Technologies mi ha assunto come consulente per il progetto Power Amiga. Ho scritto un’offerta, loro l’hanno accettata, e noi abbiamo iniziato a provare a fare qualche cosa. Col passare del tempo, divenne chiaro che ESCOM non aveva le tasche tanto profonde come ce le aspettavamo, e il progetto venne chiuso ancora prima che partisse realmente. Poco tempo dopo, la maggior parte di Amiga Technologies venne chiusa. Da quelle ceneri nacque PIOS. La nostra missione: avere successo come venditori di hardware PowerPC, e fare quello che possiamo per continuare a mantenere la promessa delle idee di un PowerAmiga che avevamo sviluppato.
AB – Cosa state sviluppando esattamente tu e la vostra compagnia?
Il nostro scopo è di sviluppare macchine PowerPC “tipo-Amiga”. In questo preciso momento, c’è poco senso a re-inventare i sistemi PowerPC partendo dall’utenza professionale. La maggior parte delle macchine sono basate su idee solide e buone, alcune prese dal mercato dei cloni PC, e come in questo mercato, è estremamente difficile migliorare su ciò che è stato già fatto e rimanere ancora competitivi. Quindi, a questo livello, PIOS è un integratore di sistema, che usaciò che è disponibile per far crescere l’idea di un range di macchine PowerPC, multimediali e facili da usare.
Comunque, sin dal declino di Amiga, l’industria sembra essersi dimenticata completamente del mercato low-end. Il mercato dei cloni PC serve la piccola utenza principalmente dendendo macchine “obsolete” a un prezzo da discount (tutto sotto a US$1000). Noi crediamo sia possibile distribuire un sistema PowerPC, basato sulle tecnologie attuali, che possa essere venduto in questo range di prezzo, giungendo là dove l’A500 e l’A1200 hanno finito. Questo non vuole affatto dire che noi stiamo creando qualcosa che somigli FISICAMENTE ad un A1200 per esempio. Ma io penso che il nostro sistema PIOS ONE, ora in sviluppo, avrà qualcosa dello spirito di questa idea. Ho sempre amato l’idea dell’home computer, e penso che dovrebbero essere abbordabili ai bambini, alle scuole e, in generale, a tutte le persone normali che non vogliono spendere per forza US$1500-US$3000 per un sistema.
AB – Quando vedremo i primi risultati?
Mostreremo un sistema al CeBit in primavera. Molto probabilmente anche prima di quello.
AB – Quanto è compatibile la vostra macchina con Amiga?
Beh, essendo una macchina PowerPC, non lo è, così fuori dal cappello. Abbiamo studiato le tecnologie di emulazione di Amiga, e crediamo che una versione commerciabilizzabile sia sicuramente una possibilità. Tuttavia, il livello definitivo di “compatibilità Amiga” può essere raggiunto solamente attraverso il porting di AmigaOS al PowerPC. Ad Amiga Technologies, Andy Finkel ha mostrato un piano per raggiungere questo scopo, includendo un progetto per definire un Livello Astratto dell’Hardware (HAL) per il PowerAmigaOS. Questo significa che una singolva release binaria dell’OS può funzionare su ogni possibile macchina PowerPC, inclusi i nuovi sistemi, i compatibili Mac e gli Amiga aggiornati. Un PowerAmigaOS potrebbe anche, per definizione, includere una efficente emulazione dei binari per 68K e del sistema, più o meno quello che MacOS fa tutt’oggi.
AB – E cosa ci dici riguardo alla “compatibilità binaria”, possiamo aspettarci di essere in grado di far girare il nostro software sulle nuove macchine?
Non ancora. PIOS è principalmente una compagnia di hardware, e per questo, non stiamo sviluppando un sistema operativo. Ci siamo offerti di aiutare VIScorp, o un qualsiasi altro proprietario di AmigaOS, nel porting su PowerPC, ma per ora, questo progetto non è partito. Assumendo che VIScorp prenda Amiga Technologies (oggi è la data definitiva), queste cose potranno cambiare. Fin quando ci sarà un PowerAmigaOS, avrete delle buone possibilità di emulare Amiga su macchine PIOS, ma per ora è una cosa molto lenta.
I piani di PIOS per una migliore emulazione è veramente di grande importanza sul progetto PowerAmigaOS. Noi lo vediamo come ponte verso il nuovo OS, non una cosa fine a se stessa. Sarebbe sbagliato chiamarci “Amiga compatibili” se non c’è nessun AmigaOS vero, nativo, che verrà in futuro. Dopo tutto, potete, per esempio, usare UAE sui sistemi MacOS già oggi (PIOS distribuisce MacOS sui primi sistemi PPC), ma pochi direbbero che questo vi offre un Amiga su cui poter lavorare.
Noi ci aspettiamo di essere in grado di far girare una grande quantità di sistemi operativi sullo stesso hardware, così che gli utenti possano scegliere. Il MacOS è popolare, ma non lo vediamo come un valido rimpiazzo ad AmigaOS.
AB – Puoi dirci alcune specifiche hardware della vostra nuova macchina?
Stiamo usando PowerPC, naturalmente. I primi sistemi, OEM, sono basati su PPC604 e PPC604e. Ci aspettiamo di avere alcuni sistemi PPC603ev più avanti, anch’essi OEM. Il PIOS ONE userà anch’esso la famiglia PPC603, o almeno questo è il piano — come con Amiga, ci aspettiamo di avere un sistema abbastanza semplice per cambiare la CPU. Includiamo anche bus PCI come principali bus di espansione in questi sistemi. Non è ancora molto chiaro se PIOS ONE userà tecnologie PCI o no, ma come un sistema di piccole dimensioni, gli slot PCI sono più un’opzione di espansione. Come già detto, alcuni dettagli non sono ancora stati definiti.
[LA DOMANDA CHE SEGUE E’ SOLO SE STATE UTILIZZANDO MOTOROLA RISC]
AB – La vostra macchina è anche compatibile PPC?
I primi sistemi PIOS lo sono. Non è detto che i nostri sistemi low-end saranno in grado di eseguire MacOS così come sono, anche se è possibile che questo venga definito come un upgrade, possibilmente con un sistema tipo-ShapeShifter.
AB – E cosa ci dici del supporto agli sviluppatori? Possiamo scrivere software per la vostra nuova macchina già da ora?
Come ho già detto, non stiamo attualmente creando un OS, e guardiamo verso lo sviluppo di un OS principalmente come strategia di supporto del nostro hardware. Quindi, al momento, potete sviluppare sull’ OS PPC che preferite, e lo eseguite sul vostro hardware. Dal momento che il nostro sistema low-end non sarà un “clone” di di qualche standard, avremo sicuramente più dettagli su questo col passare del tempo. Di particolare interesse sono i porting degli OS.
AB – Esiste qualche cross-compiler da Amiga a RISC disponibile al mometo? Avete intenzione di realizzarne uno?
No. E non stiamo pensando attualmente di creare dei nostri compilatori.
AB – Dove finiscono i concetti di “Copper” e di “Planar” nella vostra nuova architettura?
I sistemi attuali usano grafica standard SVGA, che supporta display planari da 1-4 bits di profondità. Comunque, per la maggior parte, non c’è molta ragione ad eseguire grafica planare. Persino la maggior parte delle schede grafiche su Amiga 68K usano chunky pixels per display 8-bit e oltre.
AB – La vostra macchina avrà una porta MIDI di default?
Non tutte le macchine, anche se le prime macchine avranno la porta seriale ad alta velocità di Mac, che apre la porta a una grandissima varietà di interfacce MIDI. Alcuni dei nostri sistemi molto probabilmente avranno MIDI di serie, abbiamo un bel po’ di interesse musicale qui alla PIOS.
AB – E qual’è il vostro target di mercato? E il vostro utente ideale?
Noi stiamo pensando a un mercato generale, per così dire, ma io credo che maggior importanza verrà data ai sistemi multimediali, per uso professionale nell’ high end e per utenti normali nel low-end. In altre parole, le forze tradizionali di Amiga — noi capiamo questi mercati.
AB – E’ la vostra macchina facilemente espandibile/aggiornabile?
Le macchine OEM hanno normali slot PCI, come ti aspetteresti da un qualsiasi sistema desktop di questi tempi. Il PIOS ONE avrà una qualche forma di espansione, ne stiamo ancora discutendo. Sarà almeno tanto espandibile come l’A1200, speriamo anche di più. AB – La vostra macchina avrà di default supporto internet/intranet/net?
Sì, abbiamo pianificato supporto internet già dall’inizio, incluso software in bundle, Java e altro.
AB – Cosa ci puoi dire dell’OS della vostra macchina?
Attualmente è MacOS, perchè è lì. Stiamo studiando delle alternative, e speriamo ancora che PowerAmigaOS arrivi sul mercato il più in fretta possibile.
AB – Quanto costerà la vostra macchina?
I sistemi attuali sono high-end, tra i US$3000-US$5000 circa, dipende da cosa c’è dentro. Sicuramente, avremo sistemi completi per meno di US$1000.
AB – Potremo avere mainboard multiprocessore sulla vostra macchina?
Al momento, non abbiamo alcun processore su mainboard. Forse ne avremo, ma noi siamo fans sfegatati del concetto della piastra CPU modulare di Amiga, che ci ha aiutati a scalare le vette dell’A2000. Il design che creeremo supporterà sicuramente i moduli multiprocessore, supponendo che l’OS sia in grado di gestirli correttamente, è una gran cosa.
AB – C’è qualche coprocessore?
Tutti i sistemi avranno sicuramente dei blitter di qualche tipo. Stiamo guardando verso vari tipi di processori alternativi, ma è vero di certo che, nella maggior parte dei casi, una seconda CPU vi darà molto di più di un qualsiasi processore ausiliare a basso costo o molto specializzato. Quindi il supporto multiprocessore è molto alto nella lista delle priorità. Crediamo che questo è persino possibile sotto AmigaOS, almeno quando verrà portato su PowerPC.
AB – C’è niente che vuoi dire ai lettori di Amiga Blast?
Stiamo cercando di fare quello che possiamo per conservare Amiga, e l’ideale che esso rappresenta, vivi. Questa non è una cosa facile, soprattutto per compagnie come PIOS, che hanno iniziato lo scorso maggio basandosi su piccoli investimenti. Non abbiamo altra scelta se non di distribuire dei sistemi completi subito, o di uscire dal mercato, e sfortunatamente, il MacOS è il solo gioco disponibile in città. Alcuni utenti Amiga ci hanno accusati di “esserci venduti”, o di “promuovere il nemico”, ma questo semplicemente non è vero. Prima di tutto, il MacOS non è il nemico (sapete chi è), e secondo, stiamo semplicemente facendo quello che possiamo per rimanere negli affari, e speriamo di crescere. Avremo altri OS, incluso AmigaOS se sarà possibile, quando potremo permetterci di credere in questo.
Dave Haynie
V.P. Hardware Engineering
PIOS Computer
haynie@pios.de
“…no RISC, no fun”
ClassX announcia la il X-DVE V2.50
Versione 1.00 Caratteristiche tecniche
Ambiente integrato con Interfaccia semplice ed intuitiva, totalmente pilotata da mouse.
Supporto di oggetti di tipo testo, immagine, animazione, sequenza di immagini (non c’e bisogno di un paint esterno).
Pre elaborazione degli oggetti con generazione automatica di ombra, rilievo, bordo, bordo 3d, rimozione degli spigoli, ricalcolo dei colori, trasparenze, ecc.
Gestione di animazioni con un massimo di 100 oggetti contemporanei in 10000 fotogrammi con effetti totalmente personalizzabili.
Effetti “3D” per rotazioni, prospettive, zoom e movimenti 3D. Decine di Effetti “Wind” per la generazione di esplosioni, spruzzi, vortici. 34 Effetti “Slide” con voltapagina, scioglimenti, compressioni. 40 Effetti “Warp” con sequenze 3D gia’ programmate (stile centralina DVE).
Gestione di una sorgente di luce per rendere ancora piu’ fantastici gli effetti a disposizione.
Preview dell’animazione fotogramma per fotogramma tramite pannello di controllo.
Movimenti totalmente indipendenti degli oggetti con temporizzazioni impostabili tramite timeline.
risoluzioni supportate da 320×200 a 1472×592 in super-hires 256 colori da 16 Milioni.
Supporto di DataTypes per il caricamento di immagini in qualsiasi formato grafico (solo con OS 3.x).
Generazione delle animazioni in formato XFA ultra-veloce.
Possibilita’ di tracciare e salvare un singolo fotogramma o l’animazione completa.
Codice Ottimizzato per processori e coprocessori matematici.
Dotazione programmi esterni con interfaccia ARexx per l’esecuzione e la conversione delle animazioni.
Dotazione di immagini, fonts ed animazioni pronte per l’uso.
X-DVE 2.50
A parte le piccole differenze estetiche tra la versione 2.00 e la attuale 2.50, il programma é stato ampliato sotto diversi aspetti in modo da aumentarne la produttività generale.
Grazie alla notevole espandibilità di X-DVE, abbiamo implementato un nuovo tipo di oggetto per la generazione di campi stellati (StarField) ed abbiamo reso più elastica le gestione di oggetti come AnimBrush e MultiBrush.
Grazie ad una programmazione più efficace, abbiamo cercato di ridurre i tempi di rendering e di aumentarne la qualità.
Abbiamo aumentato il numero di effetti disponibili, migliorando ed espandendo quelli già presenti.
Abbiamo introdotto il supporto completo per punti di pausa in prospettiva (siamo gli unici al mondo) sorpassando definitivamente le centraline 3D più blasonate ed ovviamente tutti i software per DVE esistenti oggi.
Abbiamo dato ascolto ai suggermenti dei nostri utenti, implementando funzioni particolari che erano sfuggite al nostro occhio attento.
Abbiamo eliminato qualche malfunzionamento del programma (ce ne siamo accorti solo noi ?), rendendo X-DVE se possibile più affidabile.
Abbiamo realizzato tutto questo senza alterare la filosofia di utilizzo e l’interfaccia con l’utente che rendono così semplice il lavoro con X-DVE.
Ricordiamo che molte delle nuove funzionalità di X-DVE2.50 sono già note agli abbonati di “ClassX Collection” che godono, tra l’altro, di un servizio di aggiornamento costante del programma.
Modifiche rispetto alla versione 2.00
Aggiunte
Aggiunto il metodo “Floyd-Steinberg” per il remap degli oggetti.
Aggiunto un nuovo tipo di oggetto “StarField” per la generazione di campi stellati.
Posizionamento degli oggetti con visualizzazione della sagoma.
Supporto risoluzioni NTSC con refresh a 60Hz (per gli americani).
Supporto di posizione di pausa in prospettiva (ruotato e translato).
Supporto rotazioni in gradi per Effetti 3D.
Supporto rotazioni in gradi per effetti Wind.
Calcolo effetti 3D con supporto del punto di pausa in prospettiva.
Calcolo effetti Wind con supporto del punto di pausa in prospettiva.
Calcolo effetti Slide con supporto del punto di pausa in prospettiva.
Calcolo effetti Warp con supporto del punto di pausa in prospettiva.
18 nuovi effetti Slide (rimbalzo armonico, serpente, doppio serpente, ecc.).
Funzione di replicazione oggetti con supporto di rotazioni e profondità.
Modalità di esecuzione “Lento” per raddoppiare il tempo di play delle animazioni.
Supporto di memoria virtuale per la generazione di animazioni.
Ottimizzazioni
Ottimizzazione del rendering di oggetti AnimBrush/MultiBrush se non remappati.
Migliore AntiAliasing.
Velocizzazione di calcolo di alcuni effetti Slide.
Velocizzazione di preview per effetti ed animazione.
Velocizzazione del calcolo di effetti in prospettiva.
Maggiore naturalezza e precisione degli effetti (calcoli in virgola mobile).
Miglioramenti
Nuovo palette requester ridimensionabile.
Supporto di fonts fino a 256 colori per oggetti Testo (utile per i fonts generati con FontMachine).
Modalità ciclica escludibile per AnimBrush e MultiBrush.
Schermo Editor ridirezionabile su qualsiasi tipo di monitor.
Effetti “TurnX” e “TurnY” con rotazioni reali.
Supporto Croma Key anche durante il posizionamento degli oggetti.
Posizionamento oggetti anche con tasti cursore.
Bugs corretti
Sono stati eliminati alcuni bugs, dovuti soprattutto alle parti del programma che dipendono direttamente dalla versione del sistema operativo ospite.
Tra i bugs funzionali eliminati, annoveriamo
Ricalcolo colori per immagini non trasparenti.
Riconoscimento chip grafici installati.
Riconoscimento processore 68060.
Gestione del CheckBox relativo alla selezione della sorgente di luce.
Overscan durante il play delle animazioni XFA.
Cancellazione dei fotogrammi renderizzati in modalità “DISK”.