Diamo all'MSX quello che è dell'MSX

[musehead]

Ragazzi, abbiamo deciso di sospendere questa discussione visti i toni non appropriati, le difficoltà comunicative e l'argomento pressappoco esaurito del topic.

[musehead]

Riapro il thread, mi raccomando al buon senso della community. Evitare flame e toni accesi in generale. Thanks!

[gekido_ken]

Riapro il thread, mi raccomando al buon senso della community. Evitare flame e toni accesi in generale. Thanks!

Lo spero anch'io!

In ogni caso ero interessato a riallacciare l'argomento sulle prestazioni MSX1 con un qualcosa che mi ha lasciato perplesso e che dimostri quanto faccia la differenza il programmatore, in particolare nello scrolling, postando in principio tre video:

Questo è Gall Force, un gioco per MSX1 pubblicato nel 1986 dalla Sony e sviluppato dalla SMA, distribuito su cartuccia sfruttando lo standard Mega Rom della Konami, infatti la cartuccia è di 128K. La struttura di gioco è ben fatta come molti shooter verticali sviluppati su questa macchina ma purtroppo lo scrolling, nonostante l'ottimo uso dei colori e il dettaglio grafico, è stato ancora una volta realizzato in modo char by char, lasciando sempre quel po' di amaro in bocca data l'elevata giocabilità e una buona gestione degli sprite, in questo caso anche multicolor.

Poi girando tra le rom per MSX1 scopro due titoli che (purtroppo lo ammetto) mi erao sfuggiti, due shooter verticali di nome Exoide Z ed Exoide Z area 5, quest'ultimo seguito del primo.
La cosa che salta subito all'occhio, oltre ad una buona giocabilità e ad un discreto uso degli sprite, è finalmente uno scrolling fluido e con buoni dettagli grafici

Posto i due video:
Exoide Z

Exoide Z - Area 5

Entrambi i giochi sono pubblicati dalla Casio ( conosciuta da noi solo per calcolatrici scientifiche ed orologi ) e che inizialmente penavo fossero delle "brutture" realizzate su MSX2 dato quello scrolling fluido. Poi ho visto mediante l'emulazione che le ROM erano rispettivamente di 16k e 32k (quindi non sono neanche Mega Rom ma semplici cartucce che funzionerebbero anche su MSX1 a 16K) e che funzionavano perfettamente su MSX1. Per una maggiore chiarezza e quindi non basandomi solo sull'emulazione, ho preso la mia Mega Flash Rom e "dumpatoci" su entrambi i giochi. Con mia sorpresa questi funzionavano non solo sul mio NMS8280 ma anche sul mio più semplice VG8020!!!
I fondali sono abbastanza complessi e ben realizzati da indurre un qualsiasi programmatore ad usare un sistema scrolling char by char. Invece qui è stato sfruttato a pieno un "non limite" nell'utilizzo dei colori su MSX1 e la velocità dello Z80.
Un limite noto (si spera) del TMS9918 è quello di poter usare un max di due colori per ogni fila orizzontale di 8x, ma non vi sono limiti in verticale; quindi ogni carattere di 8x8 pixel puo' visualizzare tutti i 16 colori ( 2 colori in orizzontale x 8 in verticale fanno 16 ). Questo "non limite" in verticale ha permesso la realizzazione di uno scrolling fluido totalmente software, in quanto i caratteri che compongono le Tiles e a loro volta lo schermo, vengono internamente animate come nell'esempio che ho fatto nel post dedicato a Malaika, ma questa volta in verticale e quindi senza limiti di colore e imbattendosi in alcuni "colour clash" tipici del processore video Texas Ins.
Animare tutti quei caratteri prima di aggiornare la pagina schermo e quindi dare la sensazione di uno scrolling fluido è un lavoro non indifferente sia per il programmatore che per la macchina. Ma questa volta il programmatore ha fatto la differenza comprimendo il tutto addirittura in 16k per il primo e 32k per il seguito...vi è anche uno scrolling parallattico delle stelle; inoltre anche se gli sprite sono discretamente realizzati (in Exoide Z Area 5 con due colori per ciascuno di essi), il programmatore è riuscito a dare a questi due titoli un'ottima giocabilità e risposta ai comandi.
In Exoide Z è stato pero' penalizzato il suono composto da effetti sonori discreti e un motivetto su un solo canale che si ripete in modo quasi irritante (16k cosa pretendete?), mentre in Exoide Z Area 5, i 32k usati comprendono anche una discreta musichetta che da una certa atmosfera al gioco in particolare nelle fasi critiche.
Qualche sfarfallio degli sprite ogni tanto si nota nei momenti affollati ma non durano che qualche istante e per nulla compromettendo la giocabilità dei due titoli.

Bene ragazzi a voi un giudizio su questi due esempi di quanto faccia la differenza il programmatore.

[gORE70hp]

il primo è piuttosto famoso e lo conoscevo, non conoscevo il suo seguito però.
gli sprite sono abbastanza pacchiani xò
lo scrolling fantastico. ed anche la scelta dei colori ed il design dei fondali nono è niente male
cmq se il gioco occupa 16 k è ovvio che ti giri sull'8020 che ne ha 64
ti che ti stupisci!

[gekido_ken]

il primo è piuttosto famoso e lo conoscevo, non conoscevo il suo seguito però.
gli sprite sono abbastanza pacchiani xò
lo scrolling fantastico. ed anche la scelta dei colori ed il design dei fondali nono è niente male
cmq se il gioco occupa 16 k è ovvio che ti giri sull'8020 che ne ha 64
ti che ti stupisci!

Vi sono alcuni titoli scarsi che sfruttano il V9938, ma che non occupano molta memoria...addirittura 48k
Mi stupisco il come è possibile animare internamente decine e decine di caratteri ridefiniti differentemente tra essi in così poco spazio.
Probabilmente sono del parere che questi titoli sono di quei pochi che sfruttano la mappa di memoria video riservata e che lasciano spazio a quella di sistema per la programmazione.

Si gli sprite del primo sono monocromatici...ma credo sia anche questo il motivo della poca memoria occupata.
In ogni caso questi due titoli ti inducono a dire "You Can Do It"!!!

[AlextheLioNet]

Un limite noto (si spera) del TMS9918 è quello di poter usare un max di due colori per ogni fila orizzontale di 8x, ma non vi sono limiti in verticale; quindi ogni carattere di 8x8 pixel puo' visualizzare tutti i 16 colori ( 2 colori in orizzontale x 8 in verticale fanno 16 ). Questo "non limite" in verticale ha permesso la realizzazione di uno scrolling fluido totalmente software, in quanto i caratteri che compongono le Tiles e a loro volta lo schermo, vengono internamente animate come nell'esempio che ho fatto nel post dedicato a Malaika, ma questa volta in verticale e quindi senza limiti di colore e imbattendosi in alcuni "colour clash" tipici del processore video Texas Ins.
Animare tutti quei caratteri prima di aggiornare la pagina schermo e quindi dare la sensazione di uno scrolling fluido è un lavoro non indifferente sia per il programmatore che per la macchina.

Bene ragazzi a voi un giudizio su questi due esempi di quanto faccia la differenza il programmatore.

Quando i coder sono validi si riesce ad ottenere dall'hardware delle prestazioni quasi impensabili... quando non incredibili.

Ho notato che negli home computer privi di hardware dedicato per lo scrolling si tende a preferire i titoli a scorrimento verticale... è vero?

Pare che (se non ho capito male...) in generale lo scorrimento verticale fosse meno "oneroso" sulla CPU di quello orizzontale... prima di scrivere l'articolo relativo agli Atari a 8 bit ho letto che anche gli hardware Atari (A400 / A800, serie XE / XL, Atari 5200 -la console-) avevano sì un co-processore dedicato per sprite e scrolling (l'ANTIC), ma quest'ultimo era più "facile" a livello di programmazione quando era verticale in quanto, per qualche motivo, "pesava meno" sul DMA -sempre a carico dell'ANTIC- in termini di kB utilizzati... (se non ho capito male NON essendo un programmatore...).

Su MSX i titoli impreziositi da uno scrolling fluido che hai mostrato in video sono vertical shooter caratterizzati da fondali composti da motivi tendenzialmente geometrici dove prevalgono le linee rette e gli elementi sono ripetuti nel giro di pochi pixel... probabile che questo snellisca le complesse operazioni su cui si basa lo scorrimento "software".


Sulla differenza che potevano fare i "coder McGyver" credo che sia molto eloquente il video che segue... si tratta di Enchanted Land della Thalion su Atari ST ( http://thalion.exotica.org.uk/games/...d_land/el.html )... title screen stile Shadow of the Beast con 10 livelli di parallasse... velocissima e perfettamente fluida (50 Hz)... della serie "GUARDA MAMMA... SENZA BLITTER NE' CO-PROCESSORI DEDICATI E TUTTO CON IL SOLO MOTOROLA 68000 !!!"... questo è il più incredibile sync-scrolling SOFTWARE visibile su Atari ST (STFM standard con 1 MB di RAM -NON STE-)... fuori da una demo (da notare che la Thalion e i CareBears -non a caso demo coders- hanno sbriciolato il limite della low-res ST di 16 colori a video... in questa title screen sono visualizzate circa 50 tonalità on-screen...):

[gekido_ken]

Ho notato che negli home computer privi di hardware dedicato per lo scrolling si tende a preferire i titoli a scorrimento verticale... è vero?

Pare che (se non ho capito male...) in generale lo scorrimento verticale fosse meno "oneroso" sulla CPU di quello orizzontale... prima di scrivere l'articolo relativo agli Atari a 8 bit ho letto che anche gli hardware Atari (A400 / A800, serie XE / XL, Atari 5200 -la console-) avevano sì un co-processore dedicato per sprite e scrolling (l'ANTIC), ma quest'ultimo era più "facile" a livello di programmazione quando era verticale in quanto, per qualche motivo, "pesava meno" sul DMA -sempre a carico dell'ANTIC- in termini di kB utilizzati... (se non ho capito male NON essendo un programmatore...).

Su MSX i titoli impreziositi da uno scrolling fluido che hai mostrato in video sono vertical shooter caratterizzati da fondali composti da motivi tendenzialmente geometrici dove prevalgono le linee rette... probabile che questo snellisca le complesse operazioni su cui si basa lo scorrimento "software".

Le limitazioni nell'uso dei colori per i vecchi 8 bit sono quasi sempre in orizzontale. In questo caso del TMS9918 il limite è quello esposto e cioé max due colori per ogni fila di 8 pixel. Il fatto di usare figure particolarmente geometriche è relativo, perché se tu animi con 8 frames un carattere a questo punto è indipendente la sua complessità restano comunque e sempre 16 bit variati indipendentemente dai disegni che compongono ogni carattere. Credo che la scelta del design "povero" va attribuito alla poca memoria utilizzata quindi al basso numero di caratteri ridefiniti...inoltre da notare che in 16k vi sono 8 livelli e senza multiload.
Nei 16 bit il discorso è un po' differente...non vi erano "limiti orizzontali" ma solo nell'uso complessivo su schermo (tipo Amstrad CPC)ù, di conseguenza se una certa risoluzione prevedeva 16 colori, quei 16 li potevi scegliere dalla palette e indirizzarli singolarmente per ogni pixel su schermo.

In effetti le prestazioni ed i risultati di questi due titoli non sono impossibili ma semplicemente hanno impegnato di piu il programmatore nel fare routine piu lunghe e noiose.

[musehead]

Ho notato che negli home computer privi di hardware dedicato per lo scrolling si tende a preferire i titoli a scorrimento verticale... è vero?

Penso che in questo modo tu puoi sfruttare il raster, in orizzontale decisamente no. In questo Exoide il trick è davvero ingegnoso e sicuramente non alla portata di tutti gli sviluppatori, nè tantomeno a quella di tutti i generi. A occhio, mi sembra che alla base di questi Exoide ci sia una funzione procedurale, la quale giustificherebbe le modeste dimensioni del programma. Tutto lo scenario è specchiato, è uno script che genera da pochissime informazioni l'area di gioco, ma ovviamente è limitante: il processore ha il suo da fare e credo che l'azione lenta sia voluta per non affaticare ulteriormente la macchina. Anche gli FX del primo Exoide, come sottolinea anche Gekido, sono essenziali, probabilmente per lo stesso motivo, poi nel secondo hanno fatto ulteriori passi avanti.

Una funzione procedurale venne usata anche per River Raid addirittura su VCS, infatti in QUATTRO Kb ci misero uno shooter lungo e con uno scenario relativamente dettagliato. Sono straordinari esempi di programmazione, ma impongono severi limiti.

[gekido_ken]

Penso che in questo modo tu puoi sfruttare il raster, in orizzontale decisamente no. In questo Exoide il trick è davvero ingegnoso e sicuramente non alla portata di tutti gli sviluppatori, nè tantomeno a quella di tutti i generi. A occhio, mi sembra che alla base di questi Exoide ci sia una funzione procedurale, la quale giustificherebbe le modeste dimensioni del programma. Tutto lo scenario è specchiato, è uno script che genera da pochissime informazioni l'area di gioco, ma ovviamente è limitante: il processore ha il suo da fare e credo che l'azione lenta sia voluta per non affaticare ulteriormente la macchina. Anche gli FX del primo Exoide, come sottolinea anche Gekido, sono essenziali, probabilmente per lo stesso motivo, poi nel secondo hanno fatto ulteriori passi avanti.

Si effettivamente lo schermo per metà speculato ( ma non sempre...almeno in Exoide Z) sarà servito per risparmiare cicli del processore. Il sistema usato negli Exoide è stato usato anche negli scrolling parallattici sul C64, in particolare nei titoli Katakis ed i due Enforcer, solo che nel caso di Exoide, si è potuto usare liberamente il multicolor non avendo limiti nella colorazione verticale. La velocità dello schermo è adeguata al gioco ma credo che una velocità maggiore avrebbe compromesso tutto con risultati sballati...prima animi i caratteri con 8 frames e poi li sposti....un bel lavoraccio direi. Mi immagino solo un sistema del genere con un gioco che occupa più memoria. Comunque questo tipo di scrolling è stato usato anche in Malaika ma fateci caso ad un dettaglio....c'è molta più colorazione in verticale che in orizzontale. Questo per permettere di rimanere sempre nei limiti dei due colori per ogni fila orizzontale di 8 pixel. Chi lo sa...magari per l MSXDev '10 potrebbero presentare qualcosa con scrolling verticale fluido.

Una funzione procedurale venne usata anche per River Raid addirittura su VCS, infatti in QUATTRO Kb ci misero uno shooter lungo e con uno scenario relativamente dettagliato. Sono straordinari esempi di programmazione, ma impongono severi limiti.

Anche la versione di River Raid per Colecovision, che tu hai "video recensito" e di conseguenza per MSX (che è identico), sfrutta lo stesso sistema dell'Atari 2600 per ottenere uno scrolling fluido...anche se povero di dettagli. Poi curiosità: la cartuccia Coleco di River Raid è di 16k mentre quella per MSX1 di 32k...spreco di risorse?

[Gedeone de Infortunis]

Bene bene...il thread è stato riaperto. Dunque, vedo che si parla di agevolazioni quando c'è da implementare uno scrolling sw in verticale.
Dunque.....qua lo scrolling è orizzontale, fluido, veloce e paralalttico....i fonadali sembrano ispirati a Ziynaps, indimenticato sparatutto Hewson uscito sui principali formati 8 bit e Atari ST. Il sonoro è realizzato in maniera competente, come dimostra la musica dell'intro. Richiede 64KB...

[Gedeone de Infortunis]

dimenticavo di precisare che il video non rende giustizia all'effettiva fluidità.....da provare su un emulatore

[AlextheLioNet]

Bene bene...il thread è stato riaperto. Dunque, vedo che si parla di agevolazioni quando c'è da implementare uno scrolling sw in verticale.
Dunque.....qua lo scrolling è orizzontale, fluido, veloce e paralalttico....

Notevole! A livello di valorizzazione dell'hardware se la gioca con Starray su Atari ST... a dimostrare che i coder Mc-Gyver riescono ad lanciare il codice oltre l'ostacolo...

[Gedeone de Infortunis]

Già, peccato che Starray sia uscito nell'88......

[gekido_ken]

C'è poco da meravigliarsi di una grafica del genere visto che lo scrolling ha lo stesso "motore" ( se cosi' possiamo chiamaro) di Malaika, la cui spiegazione dello scrolling l'ho gia menzionata!
Il meravigliarsi è il come mettere in memoria le animazioni di tanti caratteri sullo schermo prima di spostarli da una "locate" all'altra al fine di rendere uno scrolling fluido.

[Gedeone de Infortunis]

Malaika non ha uno scroll multistrato (c'è la striscia superiore dello schermo che è fissa), cosi' veloce e per giunta multidirezionale...che la generosa memoria a disposizione aiuti?