Sito interessante sui retroscena sugli "Sprite Tricks" usati nei giochi per Amiga...

[AlextheLioNet]

... e su molto altro.

http://www.codetapper.com/ è uno dei siti che ho usato per documentarmi in vista dello speciale sugli Home Computer Atari a 16-bit, ovviamente per la parte dove li confronto con gli Amiga "classic":

http://www.codetapper.com/amiga/sprite-tricks/


Shadow of the Beast:

http://www.codetapper.com/amiga/spri...-of-the-beast/


Agony:

http://www.codetapper.com/amiga/sprite-tricks/agony/


Jim Power:

http://www.codetapper.com/amiga/spri...cks/jim-power/


Risky Woods

http://www.codetapper.com/amiga/spri...s/risky-woods/


Brian the Lion

http://www.codetapper.com/amiga/spri...rian-the-lion/


... molto interessante, poi, la parte riservata alle interviste rilasciate dai programmatori... davvero ricca di curiosità e chicche tecniche:

http://www.codetapper.com/amiga/interviews/

[Gedeone de Infortunis]

già, conosco bene...interessante notare come l'hw amiga, per quanto ricco doveva sapientemente essere "raggirato" per ottenere risultati simili a quanto si vedeva su Megadrive, PC Engine e Snes (curioso il ruolo degli sprites che finivano per simulare scorrimenti parallattici come in Risky Woods )...è vero che Amiga disponeva di copper e half brite, ma ciò non significava usare i colori in più ovunque si volesse sullo schermo, riporto un commento rilasciato sulla english amiga board in una discussione riguardante un confronto con il Megadrive:

Genesis sprites are bigger. Apidya etc. had sprites as small as pinheads, dunno what you are talking about. And in most caes, what you see as a huge boss sprite is just a bunch of sprites held together, every machine worked like this.
= Genesis can shove more sprites onscreen than the Amiga without slowdown or flickering (more hardware prites)
= Genesis can display 64 UNIQUE colors onscreen without much of a slowdown. Halfbrite is but a joke, and using copperlists to change the palette is not the same as having that same ammount of UNIQUE colours useable ANYWHRE on screen (all it can do decently is shading). This said before you claim garbage about Lionheart etc.
= Both had almost the same resolution games-wise, the fact that the Amiga can display 320x512 or 640x512 doesn't mean that resolution is USEABLE by any game.
= Last but not least the Genesis works in a tile-based manner, which is eons faster than the shitty Amiga bitmap mode.

peraltro, i BOB se non erro si muovevano a 25hz ed erano vincolati cmq alla palette dello sfondo (lapidatemi se sbaglio)

inoltre:

"In contrast to hardware sprites Bobs were not limited in size and number. Bobs required more processing power than sprites, because they required at least one DMA memory copy operation to draw them on the screen. Sometimes three distinct memory copy operations were needed: one to save the screen area where the Bob would be drawn, one to actually draw the Bob, and one later to restore the screen background when the Bob moved away"

[Gedeone de Infortunis]

Per altro, Alex, si parla se non erro anche di Silkworm su ST...

http://www.codetapper.com/amiga/interviews/john-croudy/

e come nel caso dell'intervista al team ICE, curioso che nessuno si sogni di dire "beh, in effetti il gioco in questione è venuto fuori uno schifo"

[Gedeone de Infortunis]

Sia ben chiaro che quando ci si mette l'amiga, non c'è Md, Snes e PC Engine che tengano (Es. Lionheart, Elfmania, Stardust)

[Gedeone de Infortunis]

cioè, della serie.. qualcuno si ricorda di questo? gira su 500 liscio ed è un gioco ITALIANO

[AlextheLioNet]

Davvero interessante il discorso Dual Playfield & dintorni, con tutti i vari escamotage per valorizzare al massimo questa modalità minimizzandone i limiti. Quando era nelle mani di sviluppatori di prim'ordine, l'Amiga "classic" era in grado di rivaleggiare senza problemi, se non superare anche significativamente sul fronte audiovisivo, le console a 8/16-bit come PC Engine / PCE CD-ROM e 16-bit (Mega Drive e Super Nintendo).

@Gedeone: sui BOB ho anche letto che uno degli inconvenienti era la gestione delle collisioni. Se non ho capito male, infatti, con i BOB questa doveva essere implementata via software, cosa che non era necessaria con gli sprite hardware veri e propri.
Su Silkworm per ST non posso dire granché, visto che ho avuto di provarlo solo in emulazione. Bel tentativo, ma io avrei rinunciato alla parallasse, puntando a un po' di fluidità in più... secondo me si sarebbe trattato di un compromesso più intelligente. Idem come sopra per il porting per ST di Wrath of the Demon, a mio avviso fin troppo ambizioso (parallasse multistrato e più di 32 colori su schermo) per le possibilità del computer Atari.

[Bert]

sui BOB ho anche letto che uno degli inconvenienti era la gestione delle collisioni. Se non ho capito male, infatti, con i BOB questa doveva essere implementata via software, cosa che non era necessaria con gli sprite hardware veri e propri.

Per quanto riguarda i bob, visto che me li sto ristudiando in questi ultimi giorni per il mio gioco, posso confermare che il blitter è in grado di rilevare solo quando due porzioni di grafica copiate dentro lo schermo collidono, cioè si sovrappongono, ma non è in grado di distinguerle ad esempio tra personaggio, nemico o piattaforma, quindi entrano in gioco altre verifiche del caso come ad esempio testare la natura della tile sotto la posizione degli oggetti (sfondo od ostacolo) o comunque verificare prima la posizione degli oggetti sullo schermo tramite il bounding box, ossia le coordinate e rispettive dimensioni. Fermo restando che il bob più piccolo che si può fare è analogo per dimensioni ad uno sprite OCS/ECS, cioè massimo 16 pixel orizzontali per quante linee se ne vuole verticali, il blitter infatti opera solo a livello di word, 16 bit, infatti ad esempio per blittare dei font 8x8 si deve usare il 68000. Ma poi sfatiamo il mito che gli sprite siano comodissimi, a parte il poterli riutilizzare più volte in righe diverse dello schermo, su Amiga occorrono due sprite sovrapposti per farne uno a 16 colori, 4 bitplane, il che ridurrebbe il numero a quattro disponibili, inoltre possiedono una limitazione per le collisioni che consiste nel poter essere rivelate solamente a coppie. Nel senso che lo sprite 0 può essere rivelato quando collide col 2,4,6, mentre lo sprite 1, col 3,5,7 per capirci, appunto perché hanno questa modalità di sovrapposizione, stesso discorso anche per l'assegnazione della priorità sullo sfondo e anche per i playfield. Ad esempio, il registro di scrolling ha un nibble, 4 bit, per scrollare i bitplane pari indipendentemente da quelli dispari, cioè ogni coppia di bitplane ha un pezzetto di registro! Amiga era si potente, ma la programmazione dell'Hardware non era così intuitiva e bisognava sbattersi di brutto! Tornando al sito, si lo conoscevo e rimango basito dall'inventiva di questi programmatori, benché ci siano cose sorprendenti un po' su tutti i sistemi pseudo ludici, che so anche per l'Oric Atmos di tangerine con Space 1999 e Stormlord! E ‘sto computer non era mica fatto per giocare.

[AlextheLioNet]

Per quanto riguarda i bob, visto che me li sto ristudiando in questi ultimi giorni per il mio gioco, posso confermare che il blitter è in grado di rilevare solo quando due porzioni di grafica copiate dentro lo schermo collidono, cioè si sovrappongono, ma non è in grado di distinguerle ad esempio tra personaggio, nemico o piattaforma, quindi entrano in gioco altre verifiche del caso come ad esempio testare la natura della tile sotto la posizione degli oggetti (sfondo od ostacolo) o comunque verificare prima la posizione degli oggetti sullo schermo tramite il bounding box, ossia le coordinate e rispettive dimensioni.

Questo sembrerebbe confermare, per lo meno a grandi linee, quello che ho scritto nello speciale sui computer Atari a 16-bit:

"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 all'assenza di rilevazione hardware delle collisioni."

Magari, visto che "il blitter è in grado di rilevare solo quando due porzioni di grafica copiate dentro lo schermo collidono, cioè si sovrappongono" potrei correggere con la meno impegnativa:

"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."