Diamo all'MSX quello che è dell'MSX

[Dexther]

di xenon l'unica cosa che mi è mai piaciuta e la song

[gekido_ken]

Gekido: riguardo a Meteorite Kiss...continuo a chiedermi il perchè di una simile scelta cromatica senza trovarlo...sarebbe stato meglio a 'sto punto farlo direttamente su Msx1, certo...ma considera che già il 2 quasi esplode in certi punti in cui il programmatore ha azzardato troppo con il numero di sprites (leggasi: flickerii e rallentamenti a livelli di guardia).

Dexther: su MSX peraltro Xenon era anche più lento della vers. Speccy (colpa del porting, credo), ma la musica e gli effetti suonano meglio (imho la migliore da questo punto di vista, persino di quella c64!). C'è da dire che fra la versioni a 8 bit quella Amstrad Cpc, visto che odi il feeling monocromatico, è di ben altra pasta (coloratissima e moolto simile a quelle a 16bit)..

Meteorite Kiss non è il primo caso in cui viene usata la grafica MSX1 in codice MSX2.
Ne è un esempio Barunba della Namcot, pubblicato nel 1990 su floppy.

Come si vede dal video la grafica è MSX1 e neanche delle migliori, tiro fuori di meglio la Konami dai sistemi MSX1 con la serie gradius, anche se in formato MegaRom.
Probabilmente questa scelta è dovuta al fatto di non voler "sporcarsi" troppo le mani con una programmazione più performante ma anche più complessa e, per l'epoca, nuova sul V9938 della Yamaha e "rifugiarsi" nel codice del TMS9918.

Personalmente questa è una scelta triste e indegna su di un MSX2


Riguardo al fatto che Xenon su MSX giri leggermente più lento dello Spectrum a causa di una reinterpretazione da parte del TMS9918 del codice usato sulla ULA dello Spectrum.
Questo non uccede quando invece il gioco viene completamente riscritto anche se poi l'aspetto grafico è simile ma non uguale.
Ne è un esempio il recentissimo Invasion of the Zombie Monster della Relevo, presentato in esclusiva per la prima volta ufficialmente in Italia proprio da noi di RH, in versione Spectrum ed MSX.

Questa è la versione ZX Spectrum

E questa è la versione MSX

Notare la velocità maggiore della versione MSX,nonché molto più colorata, che sfrutta bene il TMS9918 con addirittura tre scrolling parallattici e la totale assenza di sprite, ma tutto generato con caratteri!

[Gedeone de Infortunis]

Barumba è veramente indegno....non hanno usato NESSUNA (apparentemente) delle agevolazioni della macchina su cui è stato sviluppato
Parlammo di questo Invasion of the Zombie proprio su questo stesso thread (lo postai io stesso), ma non m'ero (allora) accorto delle differenze con la versione Spectrum...una piacevole sorpresa

[Gedeone de Infortunis]

di xenon l'unica cosa che mi è mai piaciuta e la song

'azz, mi spiace. Per me Witthaker anche qua è un mito!

[Gedeone de Infortunis]

per la serie "NON gira su MSX ma con grafica/sonoro sulla falsariga" segnalo questa chicca:

[Mr.8088]

Gradius e' un capolavoro sul C64, per quello che il C64 poteva fare.
Come al solito dipende dalle peculiarità del gioco stesso.
Questa tipologia di gioco "viene" meglio su un msx piuttosto che su un C64. Perchè?
Semplicemente, se uno non vuole semplificare troppo il gioco e il gameplay e vuole rimanere fedele all'originale, si trova di fronte al problema degli sprites. Questo gioco ne ha una infinità su schermo.

Ora qui si vedono i due approcci adottati sulle due macchine:

C64: se voglio avere + di 8 sprites/screen devo multiplexare. Il che mi pone di fronte alla limitazione di 8 sprites/scanline (che nel c64 sono anche quelli sullo schermo in condizioni normali). Per averne di piu', scanline - interrupts e rescrittura dei registri del VIC II. Nel C64 le istruzioni piu' rapide durano 2us, e una scanline 64us. In una scanline posso scrivere (caso migliore) fino a 32 bytes, sperando di non beccare una badline. I programmatori erano forzati a pensare di suddividere in bande orizzontali lo schermo ed adottare il multiplexing. Ma questo "condizionava" la riproducibilità dell'originale. Fateci caso: durante lo svolgimento del gioco non ci sono mai un sacco di sprites "sparpagliati" a differenti posizioni Y sullo schermo. Il multiplexing sw pesa, soprattutto sulle spalle del povero 6510.
(In realtà raramente fai multiplex su tutti gli 8 sprites del C64, ne riservi alcuni per essere non multiplexati, come il personaggio principale. Questo riduce il n. di sprites multiplexabili liberi su tutto lo schermo, ma allevia il carico CPU)

MSX: Il supporto Hw degli msx e' cosi limitato che praticamente gli sprites sfarfallano SEMPRE, i programmatori non si pongono neanche il problema. "ruotano" le priorità degli sprites come in una circular linked list e lasciano che il VDP tagli cio' che non puo' visualizzare. Mischiano caratteri grafici che hanno svantaggi sulla fluidità di movimenti e vantaggi sulla "colorabilità"

Paradossalmente, questo approccio, finisce per conservare la giocabilità originale del gioco, pur pagando prezzi sotto il profilo del flickering e della fluidità del movimento.


La realtà e' che molto, moltissimo dipende dal gioco. Si possono fare esempi nei quali il C64 surclassa tranquillamente un MSX2+ per via della sua notevole flessibilità sulla gestione sprites.
Ma in questo genere di giochi, (che non sono alla portata di un 8 bit se realizzati decentemente), tra c64/zx/msx quello che fa meno peggio globalmente e' a mio avviso l'msx.

Aggiungo anche una questione sulle limitazioni del colore. La versione C64 e' un po' monotona.
La grafica multicolor consente una minore "sofferenza" in termini di limitazioni su aree piccole di schermo, ma ogni carattere puo' avere al max 4 colori.
gli msx consentono un carattere con 16 colori differenti, pur imponendo una maggiore limitazione a livello del singolo carattere.

Giochi come salamander e gradius sono sostanzialmente svantaggiati su C64. (Anche se a livello di fondo si poteva fare decisamente di meglio sul C64)

[Mr.8088]

....

[Mr.8088]

Ho rigiocato a Salamander per C64 e una cosa mi era passata di mente: vi sono vistosi rallentamenti di tutto nel momento in cui fuoriescono due tentacoli contemporaneamente, vi sono pochi sprite e pochissime situazioni "affollate" ed è una cosa che con l'avanzare dei livelli peggiora ora che mi ricordo...in particolare il terzo livello con il drago finale....li è bestiale il rallentamento....per non parlare poi del quarto e ultimo livello ...giochi praticamente al rallentatore dove è inascoltabile anche la colonna sonora....me la chiami conversione migliore? Li mi sembra che il C64 fa a fatica!!!

Ciao, Per una trattazione di cio che sostieni vai a pag. 24 del blog.
Li mi sono permesso di disquisire tecnicamente ( ho programmato C64/ZX/MSX negli anni 85-90 ) queste questioni. La mia conclusione e' chiara per giochi come Gradius

[Mr.8088]

Boh, stavo riguardando i video su youtube... Salamander su C64 mi sembra nettamente migliore tecnicamente. Poi sulla giocabilità mi riservo di commentare in futuro...

La giocabilità intesa come fedeltà all'originale e' sacrificata, paradossalmente proprio a causa della diversa impostazione della gestione degli sprites hw, che mentre in alcuni casi e' una scelta vincente per il VIC II, in questo caso compromette il risultato della conversione, semplificandolo troppo rispetto all'originale. (sul C64)
Come ho gia' scritto, questo e' un gioco non alla portata di un 8 bit, se si vuole un livello decente di tutte le caratteristiche dell'originale arcade, (gfx, snd, giocabilità, mantenimento dettagli etc). Non e' solo una questione di scrolling fluido.

[Mr.8088]

nonostante il notevole vataggio di un nome del calibro di Konami che vi ha sviluppato in prima persona[/I].

il cui peso e' ovviamente relativo... la differenza e' nel conoscere e sfruttare l'hw o meno.

Riguardo al fatto che le conversioni c64 non fossero realizzate da team all'altezza, non sono affatto d'accordo.
Il C64 e' il computer che IN ASSOLUTO ha avuto il max livello di hacking negli anni della sua vita "attiva".
Ci sono cose che sono state fatte sul C64 (come il blending di frames per avere piu' colori) che, sebbene possibili anche su altre piattaforme non sono neanche state copiate su queste ultime.

Se c'e' una cosa che non si puo' dire e' che il C64 non sia stato spremuto a dovere dai vari sviluppatori.

[Mr.8088]

Stai parlando di schede audio aggiuntive, da pagare separatamente, eppure nessuna di queste tue soluzioni ha mai raggiunto in popolarità il SID. Il chip di serie dell'MSX non era un gioiellino.

Il psg e' un chip "standard" senza infamia e senza lode. Una roba da piena sufficienza per l'epoca (tanto e vero che era impiegato negli arcade).
Il Sid presenta notevoli features rispetto al psg (ring modulation, ADSR control (che in realtà non e' cosi fondamentale) ) 4 differenti (e queste fanno la differenza a livello di cio' che sentiamo con le nostre orecchie ) forme d'onda.

tuttavia, rimaniamo negli hanni ottanta. cosa facevano questi videogames, un po' di rumore, effetti sonori e una musichetta di sottofondo. Niente a livello di musica professionale.

Solo se confronti il SID e il PSG in termini "musicofili" si vede la differenza.
tuttavia, se uno pensa a questo orientamento, tra gli 8 bit, meglio non mettersi contro la pletora di chip audio disponibili sugli msx. Non c'e' praticamente 8 bit che regga il confronto con chip che sono i "nonni" di quelli utilizzati sulla prima soundblaster.

Ma questo e' ovviamente un'altro discorso. Se il videogame che sto giocando non supporta il chip e io non ce l'ho, mi tocca accontentarmi del psg.

A mio avviso, per il gaming sarebbe stato meglio disporre di piu' canali (cosa peraltro "tentata" dal progettista del SID che aveva pensato originariamente a 6 canali)

[Mr.8088]

Ti rispondo io:
Si fa la rotazione delle priorità. Una tecnica concettualmente simile di multiplexing ma non a livello di schermo (come nel C64) ma a livello di scanline.
Gli sprites li vedi, ma flickerano.

Ci sono situazioni limite dove il mux del c64 effettuato a livello schermo mostra un po' di sfarfallio.

E ora ti rivelo un segreto: Per stessa ammissione del progettista del VIC II l'implementazione degli sprites sul C64 e' un'idea copiata dal chip del msx ( conosciuto come VDP ). Solo che gli ingenieri commodore "did it substantially better" (come dico io)

Esiste un limite dovuto al carico delle vRAM che e' imposto per la gestione degli sprites. Questo limite e' influenzato dal n. di oggetti x scanline. Ora tu mi dirai: 'ma il c64 non ha limiti su scanline'. Risposta: certo. Non li ha perche' i progettisti commodore sanno che il chip non puo' superare 8 sprites/scanline. Hanno semplicemente posto questo limite uguale al n. di oggetti sullo schermo. Tutto li.

Per fare un paragone, e' come se il chip dell'msx potesse avere 4 sprites su tutto lo schermo. Nessuno parlerebbe di limite su scanline.

La scelta operata dal team del c64 e' stata coraggiosa (perche' per certi versi limitante), ma ha consentito, pensa, di fare una migliore grafica sprites con MENO accessi un memoria rispetto al VDP degli msx ;-)

[AlextheLioNet]

Se c'e' una cosa che non si puo' dire e' che il C64 non sia stato spremuto a dovere dai vari sviluppatori.

Mai detto il contrario. Sottolineavo solo il caso delle conversioni da coin-op che, nel caso dell'MSX, avevano per lo meno il vantaggio di essere sviluppate da team interni che non di rado facevano capo alla stessa casa madre dell'arcade originale. Nel caso del C64, se non vado errato, non era così.

Poi è chiaro che nemmeno Konami poteva fare miracoli avendo a disposizione un hardware con rilevanti limitazioni... in ogni modo aveva comunque il vantaggio del "filo diretto" con il coin-op.

Ricordo che determinate conversioni su C64 sono state effettuate senza supporto... o per lo meno con un supporto limitatissimo da parte dello sviluppatore del coin-op... con il povero programmatore (penso al mitico Chris Butler per Power Drift e -se non sbaglio- Thunder Blade) che doveva andare a giocare con il coin-op per poi "andare ad orecchio" nella conversione. Da notare che, nel caso di Power Drift, anche ZZKJ su Amiga e Atari ST dovette ripiegare sul "fai-da-te".

[Mr.8088]

La vivacità delle attuali community dedite a ZX e MSX deriva essenzialmente dal fatto che tali hardware, per i loro limiti intrinseci, si prestano molto per le sfide che i coders lanciano alla loro stessa abilità, nonchè a tutta la community di McGyver informatici che gravita intorno a questi home computer...

Questo e' un ragionamento valido per qualsiasi sistema vetusto, 8 /16 bit che sia. Quindi anche per il C64.
Ed e' lo spirito della gente che giochicchia con queste piattaforme.
La differenza sono le debolezze della macchina.
Sugli msx spingi per avere lo scrolling fluido
Sul C64 che non ha questo genere di debolezza spingi per superare le limitazioni del 6510 in termini di potenza pura (come quando implementi demo 3d).
Sullo ZX ti inventi un modo per pilotare decentemente il buzzer audio mentre giochi (e' arduo se vuoi ottenere risultati decenti)

[Mr.8088]

Mai detto il contrario. Sottolineavo solo il caso delle conversioni da coin-op che, nel caso dell'MSX, avevano per lo meno il vantaggio di essere sviluppate da team interni che non di rado facevano capo alla stessa casa madre dell'arcade originale. Nel caso del C64, se non vado errato, non era così.

Poi è chiaro che nemmeno Konami poteva fare miracoli avendo a disposizione un hardware con rilevanti limitazioni... in ogni modo aveva comunque il vantaggio del "filo diretto" con il coin-op.

Appunto. Con le "rilevanti" prestazioni del C64 ci si sarebbe dovuto aspettare chissache'. Ma come ho detto, soprattutto trattandosi di c64 il risultato non e' dei migliori. Konami era famosa per conoscere a mena dito l'hw su cui sviluppava. Il suo livello qualitativo era il max spremibile (ragionevolmente) per ogni piattaforma su cui ha sviluppato.