Le conversioni possibili: limiti reali Amiga "classic" rispetto alle console a 16-bit

[AlextheLioNet]

Prendendo spunto da una discussione sviluppata in coda alla recensione di Forgotten Worlds per Atari ST...

http://www.retrogaminghistory.com/co...tten-Worlds-ST

... pongo un questito di fantavideoludica che, pur essendo tendenzialmente ozioso, può essere comunque molto interessante.

Gli Amiga "classic" hanno un'architettura piùttosto complessa e, per lo meno a grandi linee, "consolara".

Per dare un'idea di quali sono le specifiche di questa linea di computer, riporto alcuni brani dello speciale ( http://www.retrogaminghistory.com/co...-%28Parte-2%29 ) dedicato agli Atari ST:

COLORI: "Gli Amiga hanno un limite "teorico" di 32 colori on-screen nella 320x200/256, modalità comunemente utilizzata per i giochi e uno di 16 nella 640x200/256. La palette cromatica è particolarmente generosa: 4096 sfumature.
Il limite di 32 colori risulta parzialmente aggirabile tramite l'Extra Half-Brite (EHB) mode, una modalità presente nei modelli posteriori all'A1000 che, analogamente all'interlacciata 640x400/512, permette di avvalersi di 64 tonalità, fermo restando che gli "extra colors" non sono che un "clone" a luminosità dimezzata degli altri.
Per arricchire l'impatto visivo, inoltre, è possibile avvalersi dei raster effects basati sul co-processore Copper. Questo, infatti, è in grado di modificare i registri dei chip custom in sincronia con il movimento del pennello elettronico, feature utilissima che, tra le altre cose, consente di abbellire i background con i cosiddetti "Copper gradients". Opportune combinazioni di EHB e specifici "tricks" basati su tale co-processore permettono poi di quadruplicare il limite di 32 colors on-screen.
L'incredibile flessibilità del sistema progettato dal Jay Miner è peraltro ribadita dall'impressionante HAM (Hold-And-Modify) mode, modalità "estrema", nata sì come sperimentale, ma effettivamente in grado di visualizzare in un'immagine statica, sia pur con significative limitazioni, fino a 4096 colori in contemporanea, ovvero l'intera tavolozza del sistema."

SPRITE E SCROLLING: "Grazie ai co-processori dedicati Blitter e Denise, gli Amiga sono in grado rispettivamente di elaborare in modo efficiente i dati grafici, spostando aree rettangolari mediante la manipolazione di blocchi di memoria e gestire fino a 6 bitplane distinti in opportune combinazioni, 8 sprite hardware con relative collisioni (larghezza massima 16 px -nessun limite sull'altezza-; 3 colori visibili + 1 trasparente) e il rinomato single pixel scrolling.
Interessante notare poi che i chip custom operano indipendentemente dalla CPU in quanto asincroni rispetto ad essa e che un opportuno utilizzo del Copper consente di moltiplicare il numero di elementi grafici hw in movimento grazie alla tecnica denominata multiplexing. Gli sprite hardware gestiti da Denise, poi, possono essere integrati con i "Blitter Object" (BOb o BLOB), sorta di "equivalenti" degli sprite hw manipolati dal Blitter, con vantaggi in ordine a dimensioni e colori e limiti legati alla rilevazione hardware delle collisioni.
L'hw scrolling, infine, può essere implementato in una parallasse singola o multi-strato (mediante "Copper tricks"), grazie alla modalità Dual-Playfield (DP) che, come si evince dal nome, si avvale di due "campi di gioco" distinti che scorrono indipendentemente, suddivisi a loro volta in 3 bitplane ciascuno."

AUDIO: "Le caratteristiche di Paula 8364, chip audio montato sugli Amiga (AGA compresi), sono ancora una volta incredibilmente avanzate per una componentistica risalente al 1985. Si tratta, infatti, di un eccellente 8-bit PCM (Pulse-Code Modulation) stereo soundchip dotato di 4 canali DMA (Direct Memory Access) indipendenti in grado di riprodurre suoni campionati con una frequenza pari a 28 kHz. Da notare poi come si possa aggirare tale limite disabilitando il DMA e, gravando sulla CPU, generare, tramite un noto audio trick, dei sample a 14-bit e 56 kHz.
Grazie alle suddette specifiche e ad un rapporto S/N di 70 dB, Paula permetteva quanto di più vicino al "real sound" si potesse ottenere via tracked music e FX campionati su un sistema consumer, ovvero una resa audio che lascia a tutt'oggi senza parole.
Per ritrovare qualcosa di paragonabile o superiore, infatti, si dovrà attendere l'inizio degli anni '90 e la progressiva diffusione di MIDI Card (ad esempio quelle prodotte da Roland) e schede sonore per PC, come le Sound Blaster realizzate dal 1992 in poi, oltre che l'affermazione del Super Nintendo, con il suo avanzato chip Sony SPC700 e il lancio del Falcon 030 (1992), l'ultimo computer prodotto da Atari, sistema multimediale dotato di un 8 channel 16 bit PCM audio system dalla frequenza di campionamento massima pari a 50 kHz.
In effetti Paula ha un'unica limitazione di un certo rilievo: il numero dei canali. Per quanto totalmente indipendenti riguardo a volume (6-bit: 64 livelli) ed effetti quali loop e concatenazione di samples, difatti, le voci a disposizione sono solo 4. Questa restrizione è comunque aggirabile mediante routine CPU intensive di software mixing quali TFMX 7V e OctaMED, algoritmi che consentono di trasformare i 4 canali "reali" di Paula il 7 o 8 "virtual channels"."

Alla luce di tutto questo e dell'ingegnosità dei c.d. "Sprite Tricks" non di rado utilizzati sugli Amiga "classic" per aggirare i limiti inerenti appunto agli sprite...

http://www.retrogaminghistory.com/sh...ochi-per-Amiga

... sarebbero state teoricamente possibili conversioni fedeli per Amiga di titoli abbastanza "pesanti" sul fronte sprite e scrolling, come Thunder Force IV e Streets of Rage 2 sul lato Mega Drive e come Rendering Ranger R2 e Cybernator sul fronte Super Nintendo?

[AlextheLioNet]

Volendo iniziare a dire la mia sull'argomento, sottolineerei intanto un punto: "I limiti sono fatti per essere superati!" (Iron Man)

Tanto per fare un esempio relativo al Mega Drive e al PC Engine. Queste console possono implementare il "fine-scrolling" hardware su due layer distinti (parallasse) nel caso del MD e su un singolo layer nel caso della PCE. Se un buon numero di sviluppatori non si fossero dati da fare per aggirare tale limite, i giochi per Mega Drive non andrebbero oltre il parallasse standard (2 livelli) e quelli per PCE si limiterebbero ad uno scrolling hardware privo di parallasse. Sappiamo tutti che non è così, visto che tanti titoli per MD sfoggiano la parallasse multistrato (vedi i Sonic... ma l'elenco sarebbe lungo...)... idem come sopra per alcuni sviluppati per PCE (Download, Air Zonk, Coyoon, Air Buster...). Come si aggirava il problema? Mediante horizontal blank interrupts che "affettavano" il/i piano/i "base" in vari sub-layers che scrollavano così a velocità diversa ( http://en.wikipedia.org/wiki/Paralla..._raster_method )... e questo è solo uno degli esempi di aggiramento dei limiti... fra l'altro questo metodo è usato anche su Amiga (vedi Lionheart).

Per quanto riguarda i limiti di sprite che in teoria avrebbero dovuto vincolare gli Amiga classic, se si considera titoli come Z-Out, Disposable Hero e T-Racer, verrebbe da pensare che tali limiti siano stati abbondantemente aggirati. D'altra parte se già si riusciva a "barare" su C64...

[Bert]

Come si aggirava il problema? Mediante horizontal blank interrupts che "affettavano" il/i piano/i "base" in vari sub-layers che scrollavano così a velocità diversa ( http://en.wikipedia.org/wiki/Paralla..._raster_method )... e questo è solo uno degli esempi di aggiramento dei limiti... fra l'altro questo metodo è usato anche su Amiga (vedi Lionheart)..

Non solo, tanto sull'Amiga quanto sul PC-Engine, spesso e volentieri, si usavano anche gli sprite per dare l'illusione della parallasse, ad esempio se su Amiga si disabilitassero gli sprite, gli sfondi di Jim Power e Risky Woods non sarebbero esattamente la stessa cosa, così come anche in Coryoon ed Air Zonk dal lato PCE. In Kaze Kiri, a titolo d’esempio, il paesaggio in scorrimento che si notava dalle finestre, non era altro che un'animazione di sprite.

Codetapper » Amiga » Sprite Tricks » Jim Power

Codetapper » Amiga » Sprite Tricks » Risky Woods

[AmigaMagic]

Senza entrare nel merito di ogni singolo titolo per Megadrive che hai citato, innanzitutto osserviamo quali erano le alternative, su Amiga, per convertire un tipico gioco a scorrimento del Megadrive:

- Modalità a 5 bitplanes e niente parallattico (ma in compenso avrebbe mantenuto tutti o gran parte dei colori dell'originale o potenzialmente di più con delle copper bar). Addams Family, ad esempio, nella sua conversione per Amiga optò per i 32 colori senza parallattico. Purtroppo però, nella fretta della conversione, eliminarono totalmente le tile del secondo strato, sostituite da un semplice colore nero, e non aggiunsero nessun effetto copper. Fortunatamente, il background nero ci stava benissimo in questo platform. Si trattava comunque di una modalità che richiedeva un'accuratissima programmazione per mantenere una buona fluidità.

- Modalità a 4 bitplanes e niente parallattico, al max sostituito da copper bar. Era una modalità in generale molto usata, su Amiga, perché consentiva di ottenere la max fluidità possibile senza dover "castrare" troppo il massimo numero di blitter objects contemporaneamente presenti on-screen. A 4 bitplanes c'era una maggiore bandwidth a disposizione di blitter, copper e cpu, pertanto veniva più facile mantenere i 50fps in ogni situazione, anche con lo schermo riempito di oggetti in movimento. L'esempio tipico che mi viene in mente è Turrican 2: dubito che a 32 colori sarebbe riuscito a muovere tutti quegli sprite con quella fluidità.

- Dual-playfield hardware: due strati indipendenti ad 8+8 colori. Questa era senz'altro la modalità che consentiva di avere uno scrolling parallattico con la maggiore fluidità possibile, ma costringeva il grafico ad optare per uno stile "monocromatico" (vedi primo livello di Lionheart... Se non fosse stato per i trucchi del copper, la grafica del background in primo piano sarebbe apparsa in bianco e nero!) o ad usare dosi massicce di dithering ed accostamenti cromatici poco felici (vedi Dragon Breed), senza contare le orribili limitazioni sulla palette dei bob... Chi si ricorda delle galline gialle nei primi livelli di Mr.Nutz? E no, non era una scelta stilistica...

- 16 colori per il background in primo piano e parallattico "mono-colore", in stile Second Samurai, che optava per un parallasse completamente nero (a parte il solito uso delle copper bar sul colore 0). Da notare che il particolare engine grafico usato in questo gioco non permetteva di andare oltre i 25fps (in compenso consentiva di poter animare tutte le tile del fondale senza rallentamenti).

- 16 colori per il background in primo piano e parallattico "mono-colore" ma arricchito dalle copper bar, in stile Robocod. La particolare tecnica usata richiedeva un aggiornamento continuo del bitplane relativo al secondo strato, mettendo a dura prova il blitter, che non sempre riusciva a mantenere i 50fps, specie quando c'erano dei rapidi scrolling verticali. In compenso, la tecnica consentiva di creare degli effetti di trasparenza assenti nelle conversioni MD e SNES di questo gioco (alle quali mancavano anche le ricchissime sfumature generate dal copper, se non erro).

- 16 colori per il background in primo piano e parallattico a 4 o 16 colori creato mediante tecnica degli sprite clonati, in stile Risky Woods. Molto bello da vedere, ma con il grosso limite di non poter scrollare in entrambe le direzioni e di essere ridotto ad un pattern di 64 o 128 pixel di larghezza, a seconda se venivano usati 4 sprite hw a 16 colori o 8 a 4 colori. Usano questa tecnica anche Jim Power (terzo strato di parallasse in fondo), Turrican 1 (nel livello in stile shoot'em up verticale), Brian The Lion, R-Type 2 (vedi parallasse che compare dopo un po' nel primo livello), Apydia (livello techno con gli ingranaggi animati). Un altro ovvio limite di questa tecnica è che esauriva da subito tutti gli sprite hw a disposizione.

Ognuna delle tecniche sopra menzionate presenta dei limiti, talvolta anche pesanti. Non esiste il generico metodo perfetto per ogni situazione. I migliori giochi dell'Amiga alternavano le modalità di sopra a seconda del livello. Apydia, ad esempio, usava quasi sempre 32 colori, tranne nei livelli con parallattico, dove scendeva a 16 + 4 per il secondo strato emulato dagli 8 sprite clonati. Lionheart usava un dual-playfield nei livelli all'esterno, ma poi usava una modalità standard a 32 colori nelle caverne (che non avevano bisogno di parallasse).

Tutto questo, soltanto per il discorso background e scrolling... Poi ci sarebbe da fare il discorso sugli oggetti animati (per gli amici: sprite). L'Amiga ne aveva pochi, e spesso venivano usati per effetti grafici particolari o elementi in sovraimpressione (numero di vite rimaste, punteggi, ecc.). Per il resto si usavano i BLitter Objects (per gli amici: BOB). Ma per quanto il blitter fosse potente, specie nel 1985 (anno di uscita dell'Amiga 1000), appariva totalmente ridimensionato rispetto a quel che poteva muovere il Megadrive, grazie agli 80 sprite hardware a 16 colori (sebbene con massimo di 20 per scanline... Abbondantemente sufficiente nel 99% dei casi). Inoltre, da quel poco che ho letto relativamente al VDP (il chipset grafico del Megadrive), questo era in grado di fare scrolling hardware sia a livello di schermo che di singole righe di pixel, di tile, o anche colonne di tile. L'Amiga poteva fare qualcosa di simile in hardware, grazie al copper, cambiando l'offset register dello scrolling orizzontale ad ogni horizontal blank (cosa che avveniva ad esempio in Lionheart, nel fondale in parallasse del primo livello, in Shadow of the Beast e altri), ma l'effetto era limitato a movimenti orizzontali. Non poteva agire "a colonne", se non operando totalmente in software (tramite il 68000), con un risultato finale che sarebbe stato sicuramente scarsissimo a livello di performance, a meno che l'area di gioco non venisse notevolmente ridotta (come tipicamente avveniva nei giochi realizzati su Atari ST, che doveva fare tutto tramite la CPU).

In conclusione, la mia ipotesi è che un titolo Megadrive molto massiccio fosse praticamente impossibile da rendere su Amiga mantenendo i 50fps, a meno che non si facesse ricorso a pesanti tagli a livello di quantità e dimensione degli oggetti animati per frame. Inoltre, i grossi limiti cromatici del dual-playfield dell'Amiga, avrebbero costretto il coder ed il grafico a fare tripli e quadrupli salti mortali per cercare, in qualche modo, di "arginare i danni", usando le migliori combinazioni delle tecniche sopra menzionate a seconda del particolare livello di gioco. Non è da escludere, infine, che per alcuni titoli del MD sarebbe stato praticamente impossibile per un Amiga evitare di scendere a 25fps, mantenendo inalterata, rispetto alla versione originale, la quantità di "roba" da renderizzare ad ogni fotogramma. Mi riferisco ad esempio a giochi come Ranger-X, Thunderforce IV (che hai già citato), Gunstar Heroes e Alien Soldier. Questi ultimi due, in particolar modo, facevano massiccio uso di rotazioni di sprite. Brian the Lion ha mostrato che qualcosina si poteva fare anche su Amiga (immagino che le rotazioni avvenissero tramite 68000), ma non certo in maniera così esasperata come in quei due titoli...

Ma le conversioni, si sa, sono sempre dei compromessi (specie quando i due hardware sono molto differenti). Una buona conversione non è necessariamente una conversione "pixel-perfect" dell'originale, ma semplicemente una versione capace di sfruttare al meglio l'hardware su cui viene programmata, cercando di mantenere il più possibile gli elementi fondamentali dell'originale. In quest'ottica, l'Amiga avrebbe potuto avere molte ottime conversioni, non solo di titoli MD e SNES, ma anche e soprattutto di titoli da sala-giochi, che poco o nulla avrebbero fatto rimpiangere dagli originali, specie su alcuni titoli usciti fra il 1985 ed il 1988, come Black Tiger, Tiger Road, Rygar e tanti altri, che erano decisamente alla portata dell'hardware dell'Amiga (magari non sarebberi stati proprio pixel-perfect, ma quasi). Purtroppo, l'Amiga era un computer, non una console, e pertanto non vi era nessun controllo di qualità, da parte di Commodore, sui titoli immessi sul mercato. Questo ha determinato una valanga di giochi realizzati con i piedi da ragazzi poco più che adolescenti, a cui spesso veniva chiesto di convertire nel giro di max 4 mesi un giocone da sala che anche i Factor 5 avrebbero avuto difficoltà a realizzarlo decentemente, senza contare le dozzine di porting diretti da Atari ST che, quindi, non sfruttavano assolutamente nulla di blitter, copper e compagni, risultando in giochi dallo scrolling lento e incerto, framerate claudicante, area di gioco striminzita e tantissimi particolari mancanti rispetto alle versioni originali. Probabilmente, se l'Amiga fosse stato commercializzato come console (quindi privo di tastiera e mouse), come era nei piani originari del suo creatore, avrebbe ricevuto un trattamento decisamente migliore da parte dei developer.

[AlextheLioNet]

In conclusione, la mia ipotesi è che un titolo Megadrive molto massiccio fosse praticamente impossibile da rendere su Amiga mantenendo i 50fps, a meno che non si facesse ricorso a pesanti tagli a livello di quantità e dimensione degli oggetti animati per frame. Inoltre, i grossi limiti cromatici del dual-playfield dell'Amiga, avrebbero costretto il coder ed il grafico a fare tripli e quadrupli salti mortali per cercare, in qualche modo, di "arginare i danni", usando le migliori combinazioni delle tecniche sopra menzionate a seconda del particolare livello di gioco. Non è da escludere, infine, che per alcuni titoli del MD sarebbe stato praticamente impossibile per un Amiga evitare di scendere a 25fps, mantenendo inalterata, rispetto alla versione originale, la quantità di "roba" da renderizzare ad ogni fotogramma. Mi riferisco ad esempio a giochi come Ranger-X, Thunderforce IV (che hai già citato), Gunstar Heroes e Alien Soldier. Questi ultimi due, in particolar modo, facevano massiccio uso di rotazioni di sprite. Brian the Lion ha mostrato che qualcosina si poteva fare anche su Amiga (immagino che le rotazioni avvenissero tramite 68000), ma non certo in maniera così esasperata come in quei due titoli...

Una piccola precisazione sul tuo interessantissimo intervento. Gunstar Heroes e Alien Soldier non fanno "realmente" uso di rotazioni di sprite/fondali "vere e proprie" (tipo Modo 7 del Super Nintendo), solo il primo utilizza per un particolare boss delle routine software di scorrimento scanline/tiles sincronizzati per simulare una doppia oscillazione. In effetti non si tratta di rotazioni complete ma, come sempre su MD, di particolari distorsioni che simulano un effetto appunto di oscillazione. Alien Soldier, invece, utilizza delle animazioni multi-sprite per simulare boss che ruotano... quando invece si tratta di uno scaltro avvicendarsi sincronizzato di sprite più o meno piccoli che costituiscono il boss più grande.

Ugualmente interessante, poi, la citazione di Mr. Nutz, un titolo che, in effetti, sembra tolto di peso dal Mega Drive... quando invece su MD arrivò un altro Mr. Nutz con caratteristiche completamente diverse. In ogni modo il Mr. Nutz di Amiga è stato realizzato anche su MD, ma mai commercializzato... per un confronto: http://www.youtube.com/watch?v=dR8bL9dMuHI

Riguardo sprite su Amiga, ho notato che a volte il refresh non era di 50 Hz... un esempio di questa concessione sul fronte della fluidità si notava in Project X. Questo shoot 'em up, infatti mostrava uno scrolling fluidissimo e degli sprite che, viceversa, risultavano leggermente sfarfallanti. Motivo? Si tratta di BoB? Ad esempio in Z-Out questa leggera differenza di fluidità tra scrolling e sprite non si notava...

Riguardo alle tecniche per realizzare lo scrolling parallattico su Amiga, veniva utilizzato anche il raster method? Ovvero degli horizontal blank interrupts che "affettavano" il/i piano/i "base" in vari sub-layers che scrollavano così a velocità diversa ( http://en.wikipedia.org/wiki/Paralla..._raster_method ). Se il raster method era utilizzato su PC Engine e Mega Drive (credo pure su Master System... vedi Choplifter)... penso proprio che lo fosse anche su Amiga (magari sul 1° e 3° Beast).

[CrisDrago]

-cut-

[CrisDrago]

Non sò se centra col topic ma volevo mostrarvi alcune perle che è ancora possibile fare oggi col C64:

[AmigaMagic]

Una piccola precisazione sul tuo interessantissimo intervento. Gunstar Heroes e Alien Soldier non fanno "realmente" uso di rotazioni di sprite/fondali "vere e proprie" (tipo Modo 7 del Super Nintendo), solo il primo utilizza per un particolare boss delle routine software di scorrimento scanline/tiles sincronizzati per simulare una doppia oscillazione. In effetti non si tratta di rotazioni complete ma, come sempre su MD, di particolari distorsioni che simulano un effetto appunto di oscillazione. Alien Soldier, invece, utilizza delle animazioni multi-sprite per simulare boss che ruotano... quando invece si tratta di uno scaltro avvicendarsi sincronizzato di sprite più o meno piccoli che costituiscono il boss più grande.

Si, guardando i filmati è molto probabile che fosse così. Ad ogni modo, per sfruttare quella tecnica di "simil-rotazioni" era necessario poter scrollare le tile verticalmente, e l'Amiga non ne era in grado (non in hardware, almeno).
Per Alien Soldier, se si tratta di rotazioni pre-calcolate, mi stupisco ancora di più, considerando la scarsa memoria a disposizione del Megadrive. Probabilmente si riusciva a leggere dati dalla cartuccia in maniera sufficientemente rapida da poter fare un refresh "a volo" dei banchi di sprite (altro vantaggio rispetto all'Amiga, limitato ai lentissimi, oltre che poco capienti, floppy).

Ugualmente interessante, poi, la citazione di Mr. Nutz, un titolo che, in effetti, sembra tolto di peso dal Mega Drive... quando invece su MD arrivò un altro Mr. Nutz con caratteristiche completamente diverse. In ogni modo il Mr. Nutz di Amiga è stato realizzato anche su MD, ma mai commercializzato... per un confronto: http://www.youtube.com/watch?v=dR8bL9dMuHI

Per il Mr.Nutz beta di quel filmato, beh, se fosse uscito così, su Megadrive, sarebbe stato molto deludente: stessa palette acida della versione Amiga, con giusto qualche colore in più qua e là. E poi, le galline continuano ad essere gialle, confondendosi con le tile gialle dello sfondo! Su Megadrive era imperdonabile questa cosa...

Riguardo sprite su Amiga, ho notato che a volte il refresh non era di 50 Hz... un esempio di questa concessione sul fronte della fluidità si notava in Project X. Questo shoot 'em up, infatti mostrava uno scrolling fluidissimo e degli sprite che, viceversa, risultavano leggermente sfarfallanti. Motivo? Si tratta di BoB? Ad esempio in Z-Out questa leggera differenza di fluidità tra scrolling e sprite non si notava...

Sei stato molto attento ad aver notato questa cosa. I programmatori più bravi, o più furbi, sull'Amiga ricorrevano alla tecnica del doppio framerate: al 1/50 di sec. per lo scrolling hardware, al 1/25 per tutto il resto. Fare scrolling a 50fps era facile, grazie alla possibilità di poter cambiare l'indirizzo di base dei bitplane (per lo scrolling verticale) e all'offset register (per lo scrolling fino orizzontale). Ma aggiornare tutti i bob a 50Hz, in modalità a 5 bitplanes (32 colori), era molto difficile se non si ricorreva agli sprite hardware. Un gioco come Project-X, che mostra un bel po' di roba sullo schermo, e bella grossa e colorata (quindi gli sprite hw sono da scartare) non ce l'avrebbe mai fatta a 50fps. Gli amighisti non notavano questo trucco, e reputavano Project-X strafluido, ma chi proveniva dal Megadrive (50hz per tutto) si accorgeva della magagna.
Similarmente, Addams Family su Amiga ha uno scrolling super-fluido al 1/50 di sec., ed anche lo sprite principale è animato a 50Hz (cosa che contribuisce a dare l'illusione di fluidità notevole), mentre tutti gli altri elementi (nemici, piattaforme mobili, ecc.) girano al 1/25. Ma chi ha giocato alla versione Megadrive nota la differenza (a parte il parallattico).

Riguardo alle tecniche per realizzare lo scrolling parallattico su Amiga, veniva utilizzato anche il raster method? Ovvero degli horizontal blank interrupts che "affettavano" il/i piano/i "base" in vari sub-layers che scrollavano così a velocità diversa ( http://en.wikipedia.org/wiki/Paralla..._raster_method ). Se il raster method era utilizzato su PC Engine e Mega Drive (credo pure su Master System... vedi Choplifter)... penso proprio che lo fosse anche su Amiga (magari sul 1° e 3° Beast).

No, su Amiga si faceva qualcosa di molto più efficace degli interrupt hardware: si usava il copper per modificare l'offset register (scrolling fino orizzontale) ad ogni horizontal blank. In pratica, col copper potevi modificare qualunque registro hardware dell'Amiga, durante un horizontal blank, un vertical blank o, addirittura, "a volo", dentro una stessa riga (limitatamente però ad una singola modifica di registro ogni 8 pixel renderizzati dal pennello elettronico, se non ricordo male). Non c'era bisogno di interrupt hardware, perché il copper agiva per i fatti suoi con un suo listato, ed era perfettamente sincronizzato col pennello elettronico (aveva un'istruzione di wait che consentiva di "attendere" una certa posizione verticale e orizzontale dello schermo, prima di eseguire la prossima istruzione del suo listato). Non credo che il Megadrive potesse fare una cosa del genere nell'ambito di una stessa linea di pixel (ma potrei sbagliarmi, essendo che non conosco bene i dettagli del suo chip grafico).

Ad ogni modo, alla fin fine, il 90% dei problemi dell'Amiga, come macchina da gioco arcade, erano riconducibili alla scarsezza degli sprite hardware. E la Commodore non fece nulla per arginare il problema, tant'è vero che il chipset AGA continuava ad avere soltanto 8 sprite hardware (sempre a 3 colori + trasparente)!

[AlextheLioNet]

Per Alien Soldier, se si tratta di rotazioni pre-calcolate, mi stupisco ancora di più, considerando la scarsa memoria a disposizione del Megadrive. Probabilmente si riusciva a leggere dati dalla cartuccia in maniera sufficientemente rapida da poter fare un refresh "a volo" dei banchi di sprite (altro vantaggio rispetto all'Amiga, limitato ai lentissimi, oltre che poco capienti, floppy).

No... niente rotazioni precalcolate. Visto che su cart lo spazio è tiranno, sarebbe stato un improponibile spreco di memoria. Le rotazioni di Alien Soldier sono animazioni modulari, ovvero gruppi di sprite aggregati che si muovono in modo sincronizzato per simulare una rotazione. I giochi Treasure fanno un uso degli sprite davvero allucinante... Qualcosa del genere si nota in Granada, sempre per Mega Drive, dove un boss ruota fluidamente su se stesso in stile Modo 7. Come hanno ottenuto la cosa? Divide et impera! Il boss è composto da un piastrellato di sprite quasi "filiformi" che ruotano in sincronia con routine software... della serie: ma quanto si sbattevano i programmatori?! (notare che nel caso di Granada si trattava dello stesso autore che tra anni dopo avrebbe firmato Ranger X)

Sei stato molto attento ad aver notato questa cosa. I programmatori più bravi, o più furbi, sull'Amiga ricorrevano alla tecnica del doppio framerate: al 1/50 di sec. per lo scrolling hardware, al 1/25 per tutto il resto. Fare scrolling a 50fps era facile, grazie alla possibilità di poter cambiare l'indirizzo di base dei bitplane (per lo scrolling verticale) e all'offset register (per lo scrolling fino orizzontale). Ma aggiornare tutti i bob a 50Hz, in modalità a 5 bitplanes (32 colori), era molto difficile se non si ricorreva agli sprite hardware. Un gioco come Project-X, che mostra un bel po' di roba sullo schermo, e bella grossa e colorata (quindi gli sprite hw sono da scartare) non ce l'avrebbe mai fatta a 50fps. Gli amighisti non notavano questo trucco, e reputavano Project-X strafluido, ma chi proveniva dal Megadrive (50hz per tutto) si accorgeva della magagna.
Similarmente, Addams Family su Amiga ha uno scrolling super-fluido al 1/50 di sec., ed anche lo sprite principale è animato a 50Hz (cosa che contribuisce a dare l'illusione di fluidità notevole), mentre tutti gli altri elementi (nemici, piattaforme mobili, ecc.) girano al 1/25. Ma chi ha giocato alla versione Megadrive nota la differenza (a parte il parallattico).

Sì... ci feci caso perchè già quando lo vidi per la prima volta avevo diversi sparatutto su Mega Drive... tra i primi Thunder Force III e Gaiares... e così notai facilmente quello strano sfarfallio che coinvolgeva i soli sprite. Tra parentesi: ho sempre considerato Project X un titolo un po' sopravvalutato... anche per l'eccessiva difficoltà e per la mancanza di musiche in-game. Pur non possedendo un Amiga al tempo, non mancavo di giocare abbastanza spesso a titoli per il 16-bit Commodore da "amighi" (da uno in particolare -era vicino di casa-)... e preferivo Apydia e Z-Out (dove mi pare proprio che la fluidità non cambi di una virgola tra sprite e scrolling) a Project X.

No, su Amiga si faceva qualcosa di molto più efficace degli interrupt hardware: si usava il copper per modificare l'offset register (scrolling fino orizzontale) ad ogni horizontal blank. In pratica, col copper potevi modificare qualunque registro hardware dell'Amiga, durante un horizontal blank, un vertical blank o, addirittura, "a volo", dentro una stessa riga (limitatamente però ad una singola modifica di registro ogni 8 pixel renderizzati dal pennello elettronico, se non ricordo male). Non c'era bisogno di interrupt hardware, perché il copper agiva per i fatti suoi con un suo listato, ed era perfettamente sincronizzato col pennello elettronico (aveva un'istruzione di wait che consentiva di "attendere" una certa posizione verticale e orizzontale dello schermo, prima di eseguire la prossima istruzione del suo listato). Non credo che il Megadrive potesse fare una cosa del genere nell'ambito di una stessa linea di pixel (ma potrei sbagliarmi, essendo che non conosco bene i dettagli del suo chip grafico).

Chiarissimo! Penso che un buon esempio di uso "estremo" del copper per "superaffettare" un layer in tantissimi sub-layer/scanline che scorrono a diversa velocità, fino a creare un effetto prospettico si possa ammirare in T-Racer ( http://www.youtube.com/watch?v=AGfh6NHxURY )... titolo che, fra parentesi, è stato sviluppato da italiani!

[AmigaMagic]

No... niente rotazioni precalcolate. Visto che su cart lo spazio è tiranno, sarebbe stato un improponibile spreco di memoria. Le rotazioni di Alien Soldier sono animazioni modulari, ovvero gruppi di sprite aggregati che si muovono in modo sincronizzato per simulare una rotazione. I giochi Treasure fanno un uso degli sprite davvero allucinante...

Hai ragione, ho rivisto con attenzione un filmato di Alien Soldier... Quel gioco usa delle tecniche di animazione, raggruppamento e movimento sincronizzato degli sprite davvero incredibili! Già il primo boss, il serpentone, è una meraviglia (sembra si contorca su se stesso). C'è da dire, però, che alcuni sprite ruotano davvero (ad esempio, se noti il secondo boss, la formica robot gigante, ha diversi sprite del suo corpo che ruotano (però, furbescamente, lo sprite che ruota è riutilizzato parecchio, così da risparmiare memoria, sempre che si tratti di roba pre-calcolata, come sospetto che sia).
Per un gioco del genere, su Amiga, avresti dovuto rinunciare senz'altro ai 32 colori onscreen, ripiegando quindi su una semplice modalità a 16 colori priva di parallasse (+ al massimo una copperbar, in stile Turrican 2) o un dual-playfield 8+8 (con tutti i problemi cromatici che ne sarebbero derivati). Dopodiché avresti dovuto usare il blitter per simulare quella quantità industriale di sprite della versione Megadrive (essendo che di 4 sprite hw a 16 colori non te ne fai nulla... Al massimo li usi per lo sprite principale o per i colpi della sua arma) e senz'altro saresti dovuto scendere a 25fps (almeno per le animazioni dei bob... Lo scrolling invece poteva rimanere al 1/50 di sec.). Con una modalità a 16 colori, se ti rimaneva un po' di bandwidth, potevi tentare l'approccio degli sprite clonati dal copper per simulare il secondo strato di parallasse. Ma, onestamente, non penso che potevi inserircelo... Jim Power usa questa tecnica, ma per i nemici e altri oggetti animati non mostra mai più di 2 o 3 bob sullo schermo. Lionheart rallenta un bel po' quando ci sono 3 nemici nei livelli dotati di parallasse.

Certo, usare gli sprite hw multiplexati, invece dei bob, avrebbe permesso di ottenere livelli di fluidità ragguardevoli... A patto di accettare che ogni combattimento contro un boss sarebbe stato il festival del flickering, come neanche il peggior gioco del NES avrebbe mostrato!

Qualcosa del genere si nota in Granada, sempre per Mega Drive, dove un boss ruota fluidamente su se stesso in stile Modo 7. Come hanno ottenuto la cosa? Divide et impera! Il boss è composto da un piastrellato di sprite quasi "filiformi" che ruotano in sincronia con routine software... della serie: ma quanto si sbattevano i programmatori?! (notare che nel caso di Granada si trattava dello stesso autore che tra anni dopo avrebbe firmato Ranger X)

Grande gioco, Granada... Mi è sempre piaciuto molto, comprese le musiche, ed ogni tanto mi ci faccio una partitina con l'emulatore. Mi ricordo però che in situazioni particolarmente affollate aveva dei rallentamenti... Questo sta a dimostrare come le ottimizzazioni siano sempre necessarie, anche quando si lavora su hardware particolarmente potenti.

Sì... ci feci caso perchè già quando lo vidi per la prima volta avevo diversi sparatutto su Mega Drive... tra i primi Thunder Force III e Gaiares... e così notai facilmente quello strano sfarfallio che coinvolgeva i soli sprite. Tra parentesi: ho sempre considerato Project X un titolo un po' sopravvalutato... anche per l'eccessiva difficoltà e per la mancanza di musiche in-game. Pur non possedendo un Amiga al tempo, non mancavo di giocare abbastanza spesso a titoli per il 16-bit Commodore da "amighi" (da uno in particolare -era vicino di casa-)... e preferivo Apydia e Z-Out (dove mi pare proprio che la fluidità non cambi di una virgola tra sprite e scrolling) a Project X.

Sfondi una porta aperta. Project-X per me è semplicemente una dimostrazione di capacità di coding sopraffino e di grande pulizia grafica ad opera del mitico Rico Holmes. Ma il gioco in sé è banale nel design, e frustrante oltre ogni limite (quasi quanto Armalyte su Amiga... Buono dal punto di vista grafico e tecnico, ma con difficoltà prossima all'impossibile). Di Z-Out mi ricordo che tecnicamente era un ottimo shoot'em up, ma lo stile grafico aveva un non so ché di strano... Forse era la palette un po' smorta o la grafica poco brillante... Fatto sta che non mi attirava. Il gioco in sé però non era male... Certamente meglio di Project-X. Apydia invece è, a mio avviso, il miglior shoot'em up a scrolling orizzontale dell'Amiga, sia come tecnica di programmazione che come design. Non avrebbe sfigurato su un Megadrive e neanche in sala giochi.

Chiarissimo! Penso che un buon esempio di uso "estremo" del copper per "superaffettare" un layer in tantissimi sub-layer/scanline che scorrono a diversa velocità, fino a creare un effetto prospettico si possa ammirare in T-Racer ( http://www.youtube.com/watch?v=AGfh6NHxURY )... titolo che, fra parentesi, è stato sviluppato da italiani!

Ottima programmazione per T-Racer, ma purtroppo era un'altra di quelle demo tecnologiche senza nessuna vera cura per il level design. Peccato, inoltre, che fosse esageratamente lungo (per finirlo ti ci voleva oltre un'ora e non c'erano salvataggi o password per saltare livelli già superati!) e monotono (ogni "ondata" di nemici veniva replicata fino alla nausea, così da aumentare artificialmente la durata dei livelli). Tecnicamente è migliore di Project-X, ma la grafica usa dei colori troppo acidi e l'astronave principale è proprio un rip-off di quella del noto titolo Team 17!

Comunque, l'uso più estremo del copper lo puoi vedere in Jim Power. Usa praticamente tutti i trucchi di copper possibili e immaginabili, non se ne risparmia manco uno: parallasse con sprite clonati, cambio registri colori in determinati horizontal blank, cambio offset register in svariati punti dello schermo per simulare un movimento prospettico del terreno, cambio di priorità "a volo" dei due playfield, così da simulare un quarto(!) playfield nella parte bassa dello schermo... Il tutto rigorosamente in full-screen e a 50fps granitici per sprite e scrolling. Il problema era che con tutto quel carico di lavoro per il chipset, potevi tirarci fuori soltanto un platform/shooter a scrolling uni-direzionale (vedi anche Risky Woods), bello quanto vuoi, esteticamente, ma come gameplay sempre largamente inferiore ad un Turrican qualsiasi.

[AlextheLioNet]

Per quanto mi riguarda, quella degli 8 sprite hardware con relative collisioni (larghezza massima 16 px -nessun limite sull'altezza-; 3 colori visibili + 1 trasparente) è una "scoperta" recente. Che gli Amiga "classic" potessero gestire degli sprite hardware è cosa arcinota... ma da un buon numero dei titoli migliori dal pdv tecnico non si sarebbe proprio detto che questi ultimi fossero solo 8. I programmatori più ingegnosi, infatti, hanno fatto davvero i salti mortali per minimizzare questa limitazione e di solito sono riusciti a nasconderla abbastanza bene.

Un esempio interessante di programmazione di livello, secondo me, è quella del porting di Toki ( http://www.youtube.com/watch?v=k0Ow5y5kPt8 )... quì un articolo piuttosto interessante che ne tenta un'analisi "tecnica":

http://www.giubileocreations.com/web...-dell-hardware

@AmigaMagic: sono contento che apprezzi Granada . Non è un titolo particolarmente noto... ma secondo me è da apprezzare per l'ottimo gameplay. Tecnicamente non brilla (a parte qualche sporadica soluzione grafica), ma sul fronte del divertimento è e resta piuttisto solido. L'ho recensito su RH circa un anno fa ( http://www.retrogaminghistory.com/co...p/7471-Granada )

[AmigaMagic]

Per quanto mi riguarda, quella degli 8 sprite hardware con relative collisioni (larghezza massima 16 px -nessun limite sull'altezza-; 3 colori visibili + 1 trasparente) è una "scoperta" recente. Che gli Amiga "classic" potessero gestire degli sprite hardware è cosa arcinota... ma da un buon numero dei titoli migliori dal pdv tecnico non si sarebbe proprio detto che questi ultimi fossero solo 8. I programmatori più ingegnosi, infatti, hanno fatto davvero i salti mortali per minimizzare questa limitazione e di solito sono riusciti a nasconderla abbastanza bene.

In realtà, il tipico gioco Amiga riusciva a mostrare molto più di 8 sprite, semplicemente perché erano bob, non sprite hw. 3 colori + 1 trasparente poteva essere accettabile per un C64 o un NES, ma sull'Amiga si pretendeva giustamente di più. Unendo due sprite hw potevi ottenerne uno a 16 colori (15 + trasparente), ma così gli sprite hw si riducevano a 4. Ed il flickering di un eventuale multiplexing non sarebbe stato considerato accettabile, in epoca 16-bit. Perciò, alla fine, il 99% dei developer Amiga rinunciava del tutto agli sprite hw o li usava giusto per il protagonista e, talvolta, l'eventuale sparo della sua arma. Qualcun'altro li ha usati furbescamente per realizzare un layer in parallasse, o altri effetti, grazie alla flessibilità del copper.
Ad esempio, Second Samurai, su Amiga, usa gli sprite hardware esclusivamente per realizzare la luna animata sullo sfondo. Il resto, tutti bob.

Un esempio interessante di programmazione di livello, secondo me, è quella del porting di Toki ( http://www.youtube.com/watch?v=k0Ow5y5kPt8 )... quì un articolo piuttosto interessante che ne tenta un'analisi "tecnica":

http://www.giubileocreations.com/web...-dell-hardware

Mi fa piacere che ti interessi quella discussione, visto che ne sono proprio io l'autore...

Prima o poi la organizzerò in un bell'articolo riassuntivo, ma al momento sono un po' impegnato. Ti svelo un segreto: attualmente sto lavorando ad un platform in stile 16-bit che realizzerò come mio secondo gioco indie, se tutto procederà per il verso giusto. Grafica 320x256 con due layer in parallasse di 16 colori l'uno (come il Megadrive) + sfumature in stile copperbar dell'Amiga sullo sfondo (ma solo quando è utile, non come alcuni giochi dell'Amiga, che l'usavano in maniera un po' indiscriminata, essendo praticamente "a gratis"). Grafica tutta fatta a mano con Grafx2 (un magnifico programma opensource fortemente ispirato al mitico Deluxe Paint dell'Amiga). Per ora ho quasi terminato di realizzare la prima mappa prototipo (che in realtà è una mia reinterpretazione del primo livello di un noto gioco ad 8-bit). Se ti può interessare, non appena ho qualcosa di più concreto potrei postare qualche screenshot.

@AmigaMagic: sono contento che apprezzi Granada . Non è un titolo particolarmente noto... ma secondo me è da apprezzare per l'ottimo gameplay. Tecnicamente non brilla (a parte qualche sporadica soluzione grafica), ma sul fronte del divertimento è e resta piuttisto solido. L'ho recensito su RH circa un anno fa ( http://www.retrogaminghistory.com/co...p/7471-Granada )

Di Granada mi risuona ancora in testa la bella musichetta del primo livello, che faceva molto "sala-giochi".
Quando ho due minuti, mi leggerò senz'altro la tua recensione.

[AlextheLioNet]

Mi fa piacere che ti interessi quella discussione, visto che ne sono proprio io l'autore...

Prima o poi la organizzerò in un bell'articolo riassuntivo, ma al momento sono un po' impegnato. Ti svelo un segreto: attualmente sto lavorando ad un platform in stile 16-bit che realizzerò come mio secondo gioco indie, se tutto procederà per il verso giusto. Grafica 320x256 con due layer in parallasse di 16 colori l'uno (come il Megadrive) + sfumature in stile copperbar dell'Amiga sullo sfondo (ma solo quando è utile, non come alcuni giochi dell'Amiga, che l'usavano in maniera un po' indiscriminata, essendo praticamente "a gratis"). Grafica tutta fatta a mano con Grafx2 (un magnifico programma opensource fortemente ispirato al mitico Deluxe Paint dell'Amiga). Per ora ho quasi terminato di realizzare la prima mappa prototipo (che in realtà è una mia reinterpretazione del primo livello di un noto gioco ad 8-bit). Se ti può interessare, non appena ho qualcosa di più concreto potrei postare qualche screenshot.

Ma guarda... l'articolo mi aveva dato nell'occhio anche perchè già a suo tempo ero stato colpito dalla bontà del porting di Toki (con le dovute proporzioni questa conversione risultava apprezzabile anche su Atari ST)

Per quanto riguarda il tuo interessante progetto, direi che un thread ad hoc in questa sezione ci starebbe... e, quando ci sarà qualcosa da mostrare, pure qualche news in home page...

Relativamente ai BoB, avevo capito che su Amiga gli sprite propriamente detti escono dalla porta e rientrano dalla finestra... anche se sarebbe interessante capire come rientrano. I BoB erano sprite di serie B? Quali erano i limiti dei BoB rispetto agli sprite veri e propri? Avevo letto che i limiti riguardavano le collisioni... ma ero curioso di sapere quali altri compromessi c'erano: dimensioni? colori? numero? frame rate?

[AmigaMagic]

Ma guarda... l'articolo mi aveva dato nell'occhio anche perchè già a suo tempo ero stato colpito dalla bontà del porting di Toki (con le dovute proporzioni questa conversione risultava apprezzabile anche su Atari ST)

Per quanto riguarda il tuo interessante progetto, direi che un thread ad hoc in questa sezione ci starebbe... e, quando ci sarà qualcosa da mostrare, pure qualche news in home page...

Ti ringrazio!

Relativamente ai BoB, avevo capito che su Amiga gli sprite propriamente detti escono dalla porta e rientrano dalla finestra... anche se sarebbe interessante capire come rientrano. I BoB erano sprite di serie B? Quali erano i limiti dei BoB rispetto agli sprite veri e propri? Avevo letto che i limiti riguardavano le collisioni... ma ero curioso di sapere quali altri compromessi c'erano: dimensioni? colori? numero? frame rate?

I bob non hanno limiti né di numero, né di dimensione orizzontale o verticale (se non nella ram disponibile), cosa che li rendeva particolarmente appetibili per i programmatori di videogiochi. Tuttavia:

- condividono la stessa palette del playfield su cui vengono visualizzati. Questo generalmente non dà problemi in modalità single-playfield a 16 o 32 colori, ma costituisce un limite particolarmente fastidioso nei giochi in dual-playfield, poiché i bob erano limitati agli stessi 8 colori del playfield su cui venivano mostrati (ecco perché tutti i giochi dell'Amiga che usavano bob + modalità dual-playfield mostravano degli oggetti animati con delle tonalità uguali a quelle delle tile che componevano il livello e, quindi, quasi si mimetizzavano con lo sfondo o adottavano scelte cromatiche parecchio infelici... Come le famigerate galline gialle di Mr.Nutz!).

- spostare i bob significa dapprima ripristinare l'area sottostante ad essi (cosa che non avviene negli sprite hardware, perché è come se giacessero su un layer a parte). Questo comporta una serie di passaggi in più e, quindi, un maggior carico di lavoro per il blitter.

- i check delle collisioni nei bob avvengono tramite routine software che impiegano banda e risorse. Negli sprite hw, ci sono delle circuiterie apposite che effettuano "a gratis" il controllo di collisioni fra tutti gli sprite e, se necessario, fra uno sprite ed i playfield.

In parole povere:

BoB = massima flessibilità (a parte la scarsezza cromatica in dual-playfield), ma caricano il blitter di tanto lavoro. Difatti, i giochi a 32 colori, spesso ricorrevano al trucco dei 25fps per l'aggiornamento di tutti i bob, e 50fps per lo scrolling (ah, quanto avrebbe guadagnato Ruff'n'Tumble, se avesse usato anche lui questa tecnica!).

SPRITE HW = massima velocità, palette dedicata, ma scarsa flessibilità per via delle limitazioni di numero (4 o 8), colori (16 o 4) e larghezza (16 pixel). Certo, si potevano aumentare artificialmente ricorrendo a dei trucchi del copper, ma poi non avresti potuto sovrapporli (quantomeno non senza flickering), né rilevarne le collisioni in hardware.

[AlextheLioNet]

In parole povere:

BoB = massima flessibilità (a parte la scarsezza cromatica in dual-playfield), ma caricano il blitter di tanto lavoro. Difatti, i giochi a 32 colori, spesso ricorrevano al trucco dei 25fps per l'aggiornamento di tutti i bob, e 50fps per lo scrolling (ah, quanto avrebbe guadagnato Ruff'n'Tumble, se avesse usato anche lui questa tecnica!).

SPRITE HW = massima velocità, palette dedicata, ma scarsa flessibilità per via delle limitazioni di numero (4 o 8), colori (16 o 4) e larghezza (16 pixel). Certo, si potevano aumentare artificialmente ricorrendo a dei trucchi del copper, ma poi non avresti potuto sovrapporli (quantomeno non senza flickering), né rilevarne le collisioni in hardware.

Chiarissimo (e grazie a te per la spiegazione)!

Una cosa va detta: programmare ad alti livelli sugli Amiga era indubbiamente una gran bella scuola. Da possessore di Mega Drive me ne sono accorto quando ho comprato giochi dalle notevoli qualità tecniche, come Sub-Terrania (titolo sviluppato da Zyrinx, team composto dalla fusione di due team della demoscene Amiga: The Crionics e The Silents), Puggsy, Mickey Mania e Toy Story (tutti e tre dei Traveller's Tales, altra etichetta ancora in vita proveniente dal "vivaio" Psygnosis).