Diamo all'MSX quello che è dell'MSX

[Mr.8088]

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

E questa dove l'hai letta? Quando una casa acquisiva la licenza per la conversione, aveva a disposizione mappa del gioco e peculiarita' del coin op. Sempre. Non pretenderai mica che con i tempi di sviluppo relativamente brevi che avevano quei poveracci ( era dura a quei tempi in assembler, i piu' fortunati potevano contare su ICB o HW debuggers), si mettessero anche a giocarci per capire cosa c'era al tal livello? ( Masochismo puro )

[Mr.8088]

Molto carino Caverns of Titan, peraltro è evidente come nel secondo livello il limite max dei 4 sprites per linea venga dribblato...considerato che per ottenere un effetto multicolore su uno sprite devo sovrapporne almeno 2...ho visto in una situazione che, considerando che ogni personaggino ha 3 colori (almeno, il ragno ne ha di più) ce n'erano, di sprites, secondo questa regola almeno 8. A questo punto credo che il limite sia dato dalla loro diversa posizione sullo schermo (seppur sulla stessa linea)....che dici?

sono su scanline. se li disponi in posizioni y sfalsate non c'e' il problema. E' vero tre sprites fisici per logico, ma ricorda:
il rendering e' per scanline. Al VDP non interessa quanti sprites hai "agglomerato" in un'area. Gli interessa quante "fette" di sprites deve "fetchare dalla Vram " x scanline. Sono semplicemente disposti in modo che non interferiscono.
Prova a affettarli per scanline, vedrai che non capita mai che ce ne siano piu' di 4 !

Queste limitazioni si applicano anche ad altri sistemi BOB based, come il NES SNES SMS e chi piu' ne ha piu' ne metta... non sono aggirabili. Questo e' il motivo per cui gli sprites hw sono stati messi nel dimenticatoio con hw piu' performanti in favore di blitter grafici. Questi ultimi sono piu' flessibili.

[AlextheLioNet]

E questa dove l'hai letta? Quando una casa acquisiva la licenza per la conversione, aveva a disposizione mappa del gioco e peculiarita' del coin op. Sempre.

E' una voce che gira a proposito di Chris Butler e delle conversioni da coin-op Sega. Ricordo Power Drift... e anche un problema analogo con le versioni Amiga e ST, sviluppate dal programmatore ZZKJ. Pare che il problema fosse dovuto a qualche mancanza di US Gold.

[Gedeone de Infortunis]

un esempio di sfruttamento egregio degli sprites su msx dovrebbe essere questo...andate al min 2:00 e attendete qualche secondo per vederne allineati in orizzontale (seppur per un brevissimo istante) ben più di quattro (considerato l'uso di sprites sovrapposti per avere un effetto multicromatico)

P.S.:felice che questo thread sia ripartito!

[Aladar]

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.

Magari! Avremmo visto cose da fantascienza!
Le istruzioni da due cicli non prevedono scritture in memoria, nel caso migliore per scritture nei registri del VIC-II ci vogliono 6 cicli: 2 cicli per caricare il valore da scrivere nell'accumulatore(LDA imm), più 4 cicli per scriverlo nel registro(STA abs).
Inoltre per la chiamata della routine di interrupt vanno aggiunti 7 cicli più quelli necessari al completamento dell'istruzione corrente.
Non basta, se sono previste scritture in linee consecutive vanno conteggiati anche i cicli per il ritorno dall'interrupt e la variazione dei dati da scrivere...
Quindi, senza scritture in linee consecutive, abbiamo: (63-(7+6))/6 = 8 scritture per linea.
Comunque, l'altezza anomala degli sprite del C64(21 linee) permette, lasciando delle linee "vuote" agli estremi, di poter effettuare un multiplex con tempi più rilassati.

[Mr.8088]

Magari! Avremmo visto cose da fantascienza!
Le istruzioni da due cicli non prevedono scritture in memoria, nel caso migliore per scritture nei registri del VIC-II ci vogliono 6 cicli: 2 cicli per caricare il valore da scrivere nell'accumulatore(LDA imm), più 4 cicli per scriverlo nel registro(STA abs).
Inoltre per la chiamata della routine di interrupt vanno aggiunti 7 cicli più quelli necessari al completamento dell'istruzione corrente.
Non basta, se sono previste scritture in linee consecutive vanno conteggiati anche i cicli per il ritorno dall'interrupt e la variazione dei dati da scrivere...
Quindi, senza scritture in linee consecutive, abbiamo: (63-(7+6))/6 = 8 scritture per linea.
Comunque, l'altezza anomala degli sprite del C64(21 linee) permette, lasciando delle linee "vuote" agli estremi, di poter effettuare un multiplex con tempi più rilassati.

Si lo so, era il classico conto della "serva", che non tiene conto di fattori. Ho scelto appositamente tempi per istruzioni come STX che non interagiscono con la memoria. In realtà ci sono un'infinità di altri fattori da considerare come anche il wraparound degli indirizzi, eventuali "stop" imposti dal vic-II per la gestione degli sprites e chi piu' ne ha piu ne metta.

tutti questi fattori, insieme alle bad line incidono sconvolgendo le carte in tavola. Ho solo fatto un'esempio teorico per dire che anche con l'instruzione piu' veloce o anche solo una NOP c'e' veramente troppo poco tempo in una scanline.....
poi e' chiaro anche se implementi un piccolo loop paghi altri costi, per incrementare valori, testare condizioni etc.
Quindi proprio non ce la si fa in 1 sola scanline a fare un numero significativo di cose.
(Come del resto e' presumibile che sia vista la tipologia di queste anziane bestie a 8 bit)

[Mr.8088]

un esempio di non gestione, vorrai dire! al minuto 2:52 si vede chiaramente quando i minidischi si allineano con la nave di buck roger (che conta 3 sprites) che il vdp droppa la parte azzurra interna del minidisco. Sarebbe stato meglio scegliere di sacrificare i contorni o gestire il flickering.

[Gedeone de Infortunis]

un esempio di non gestione, vorrai dire! al minuto 2:52 si vede chiaramente quando i minidischi si allineano con la nave di buck roger (che conta 3 sprites) che il vdp droppa la parte azzurra interna del minidisco. Sarebbe stato meglio scegliere di sacrificare i contorni o gestire il flickering.

è vero, nelle sequenze nello spazio si nota come una banda nera che attraversa i dischi avversari (curioso che tale effetto non si noti nelle sezioni a terra al minuto indicato da me...colpa dell'infima qualità del video?). fra le due ipotesi da te contemplate per ovviare avrei preferito sacrificare uno degli sprites, piuttosto che il flickering

[Mr.8088]

è vero, nelle sequenze nello spazio si nota come una banda nera che attraversa i dischi avversari (curioso che tale effetto non si noti nelle sezioni a terra al minuto indicato da me...colpa dell'infima qualità del video?). fra le due ipotesi da te contemplate per ovviare avrei preferito sacrificare uno degli sprites, piuttosto che il flickering

Il flickering e' necessario. soprattutto se hai un numero di oggetti elevato su scanline. l'alternativa e' vedersi cancellare un sacco di sprites. buck roger non implementa alcuna contromisura in merito e per questo gioco va bene. ma altri sarebbero semplicemente inaccettabili.

se vuoi vedere flickering a chiodo guardati qualche video con il NES.
Pur essendo il nes capace di 8 sprites / scanline, quest'ultimo li aveva larghi 8pixel. praticamente dovevi accorparne 2/3 per fare un carattere del gioco. tre sprites fisici per ogni logico significano al max 3 sprites logici prima del flickering.

[Mr.8088]

no, la prima versione del SMS ha lo stesso chip degli msx.
Nelle successive la sega ha notevolmente migliorato questo chip introducendo migliorie techiche orientate al gaming.
tile patterns e sprites multicolori e 8 x scanline, palette. Ma non e' l'originale TMS. E fa la differenza.

Cio' che e' interessante e' che pero' esistono games msx1 che non sono port del SMS originale (quello con il chip msx1), che sono realizzati graficamente peggio del sms, con lo stesso hw video!

questo indica quanto fosse poco interessante per certe sw house lo stesso msx agli inizi, e quanto poco fosse l'impegno per tirare fuori qualcosa di decente. Lo stesso vale per il vecchio colecovision, con identico hw video.

[Mr.8088]

(che se ne fa l'Msx di 32 sprites su schermo quando se ne possono posizionare max 4 per linea altrimenti sfarfallano? mah)e monocromatici. Bah

In realtà su salamander ci sono sfarfallii anche sul c64.
Ma sono ben mimetizzati ( con arte direi ) dai programmatori. Il main charater e' sempre contornato da altrii caratteri che "sparano anche loro" e che seguono la "scia" della nave principale, mi riferisco agli oggetti di forma elittica.
Questi oggetti, all'inizio del gioco sono stabilmente a video, ma il loro costo e' mortale: sono 3 sprites continuamente utilizzati!
In altre situazioni contingenti, dove servono sprites, (se uno non fa attenzione non nota), in realtà non sono mai presenti tutti e tre insieme in tutti i frames. Quindi flickerano, ma non si nota molto, perche' l'occhio e' ingannato dalle altre animazioni sempre sugli stessi oggetti.
Questa tecnica rende disponibile sprites per altri usi, ma e' di fatto un mux a livello di schermo sugli sprite.

Formalmente un mux e' una tecnica di "ripartizione" frame/scanline based di risorse limitate (come gli sprites), per avere l'illusione di avere l'illusione di avere + oggetti simultaneamente sullo schermo.

Sul C64 la ripartizione avviene piu' spesso a livello di bande orizzontali (mux su interrupt) o quando la prima non e' possibile frame based.
Sugli msx, SMS, NES, Colecovision, la ripartizione e' scanline based e piu' raramente frame based.

Questo per le differenti scelte operate dagli ing. che hanno progettato i controllers video.

[zilog_z80a]

In realtà su salamander ci sono sfarfallii anche sul c64.
Ma sono ben mimetizzati ( con arte direi ) dai programmatori. Il main charater e' sempre contornato da altrii caratteri che "sparano anche loro" e che seguono la "scia" della nave principale, mi riferisco agli oggetti di forma elittica.
Questi oggetti, all'inizio del gioco sono stabilmente a video, ma il loro costo e' mortale: sono 3 sprites continuamente utilizzati!
In altre situazioni contingenti, dove servono sprites, (se uno non fa attenzione non nota), in realtà non sono mai presenti tutti e tre insieme in tutti i frames. Quindi flickerano, ma non si nota molto, perche' l'occhio e' ingannato dalle altre animazioni sempre sugli stessi oggetti.
Questa tecnica rende disponibile sprites per altri usi, ma e' di fatto un mux a livello di schermo sugli sprite.

Formalmente un mux e' una tecnica di "ripartizione" frame/scanline based di risorse limitate (come gli sprites), per avere l'illusione di avere l'illusione di avere + oggetti simultaneamente sullo schermo.

Sul C64 la ripartizione avviene piu' spesso a livello di bande orizzontali (mux su interrupt) o quando la prima non e' possibile frame based.
Sugli msx, SMS, NES, Colecovision, la ripartizione e' scanline based e piu' raramente frame based.

Questo per le differenti scelte operate dagli ing. che hanno progettato i controllers video.

Main charater(semmai character), oggetti ellittici, MUX? Frame Based? Ma te li sogni la notte questi termini?


Salamander sul C64 e su MSX sono titoli su cui ho consumato mani e joystick (preferisco l'MSX in quanto ha piu livelli).
Innanzitutto gli "oggetti ellittici" sono gli "option" e la scelta da parte dei programmatori di farli "flickerare" è di parte, ma sicuramente potevano evitare con il multiplex, visto che nonostante questa tecnica che moltiplica gli sprite sullo schermo, resta il fatto che orizzontalmente sullo schermo del C64 sono visualizzabili fino a 8 sprite. I proiettili sono caratteri ridefiniti, riconoscibili dal fatto che cambiando colore del fondale, per esempio da rosso a blu, cambia anche quello dei nostri proiettili, cosa evidente ancora di più se si usa il laser o il ripple laser(anelli laser).

MUX, cosa diavolo vuol dire MUX? Il mux è un termine usato quando vengono miscelate due fonti multimediali diverse, nel caso grafico in contesto un "mux" è considerata una combinazione di sprite e caratteri per definire una singola figura, ma in ogni caso è un qualcosa di raro utilizzato solo nella computer art.
I programmatori della Imagine nella versione C64, hanno fatto una pessima programmazione per quanto riguarda il multiplex e lo si nota particolarmente in evidenti rallentamenti quando sullo schermo sono presenti piu di 8 sprite. Per compensare questa loro lacuna hanno pensato bene di rappresentare tre "option" con lo stesso medesimo sprite alternandone velocemente la posizione......mux su interrupt??? Ma che vor dì? Boooh!!

Formalmente un mux e' una tecnica di "ripartizione" frame/scanline based di risorse limitate (come gli sprites), per avere l'illusione di avere l'illusione di avere + oggetti simultaneamente sullo schermo.

Senti, lascia perdere, che è meglio....che diavolo vuol dire sta frase? NULLA!!!!

Su MSX, Coleco e tutte le macchine che usano il TMS9918, il flickerio degli sprite è una routine di multiplexing che evita il totale oscuramente del quinto sprite sulla stessa linea!!! Soliltamente il TMS9918 dopo il quarto sprite in linea, gli altri vengono oscurati, per evitare questo viene attuata una routine di multiplex che alterna le posizioni degli sprite nel caso ve ne sono piu di quattro sulla stessa linea; è ovvio che piu sprite ci sono piu il flickering rallenta ed è evidente.
In Salamander MSX è proprio quello che avviene quanto gli option diventano tre; poiché la Viper è composta da due sprite (bianco e azzurro), questa piu tre option, fanno 5 sprite in linea, ed ecco che entra in azione la routine di multiplex.
Spesso programmatori capaci sopperiscono questo inconveniente con sprite software generati dal charset ridefinito, dove spesso diventano veri e proprio tiles a seconda della grandezza, che vengono gestiti a velocità ottimale e indipendente dallo scrolling, proprio grazie alle ottime capacità dello Z80 e della Vram dedicata alla VDP.

Ti consiglio di studiarti questi tre video:

[zilog_z80a]

Si possono fare esempi nei quali il C64 surclassa tranquillamente un MSX2+ per via della sua notevole flessibilità sulla gestione sprites.

Spero che sia un errore di scrittura!!! Addirittura un C64 surclassa un MSX2+ sulla gestione degli sprite???????????? Un MSX2+??? Il cui V9958 supera persino il chip grafico dell'Amiga???????????????

Spero sia un errore! XD

[Mr.8088]

Spero che sia un errore di scrittura!!! Addirittura un C64 surclassa un MSX2+ sulla gestione degli sprite???????????? Un MSX2+??? Il cui V9958 supera persino il chip grafico dell'Amiga???????????????

Spero sia un errore! XD

Ciao, gekido. Allora guarda, per fare un paragone basta questo http://www.youtube.com/watch?v=oyf2W239eRY
se vai al 00:10. Quel coso viola che vedi volare, e' largo quasi 160 px (prima che ti arrampichi su qualche specchio ti dico che sono 80 pixel multicolori -> 160 di larghezza)
Per fare una cosa analoga con un msx2+ che dispone di sprites a 16x16 pixels, ti servirebbero 160px nel caso peggiore, tutti affiancati (a meno che tu non li usi ingranditi tutti ma non rende bene come il c64)
10 sprites allineati sono oltre le possibilita di limite su scanline (il v9938/58 e' limitato a 8 sprites su scanline). Per cui siamo fuori delle possibilità della macchina.

In piu' non voglio citare il discorso del multicolor. il v9958 dispone di sprites multicolori, e vero, ma non puo' generare che un colore differente per riga orizzontale alta 1px di sprite. Questo obbliga, per fare uno sprite come quello del c64 a combinare 2 sprites. Il che fa salire il conteggio ben oltre a 10 sprites su scanline.

Non cercare di arrampicarti su improbabili specchi. il c64 puo' tappezzare di 8 sprites larghi 24 pixel lo schermo per una larghezza totale di 192 pixels. Il v9958 arriva a 16*8/scanline=128

Io sono una persona obbiettiva. Non rigiro parole, non prendo pezzi di affermazioni su internet senza pensare. Parlo per dati oggettivi e di fatto. E Questo e' un dato di fatto. Punto.

Se poi mi parli di grafica di background, allora sono d'accordo che il v9938/58 e' superiore di gran lunga in termini di risoluzione/n. colori palette al VIC-II. Ma questo e' un'altro discorso. Io parlo di sprites hw.

In questa particolare situazione un msx2+ a livello sprite e' ancora una spanna sotto al c64. Il che significa che non e' possibile, senza flickering, riprodurre cio' che vedi sullo schermo del c64 nell'esempio riportato.

[Mr.8088]

Main charater(semmai character), .... ma sicuramente potevano evitare con il multiplex, visto che nonostante questa tecnica che moltiplica gli sprite sullo schermo, resta il fatto che orizzontalmente sullo schermo del C64 sono visualizzabili fino a 8 sprite.

No, non potevano evitarlo.... la motivazione e' proprio quella che hai dato tu. 8 sprites comunque al max. Se eviti il multiplexing degli oggetti ellittici in un certo frame impegni 1 sprite in piu', fisso.
Se invece alterni in frame gli sprites (che e' una forma di multiplexing, a livello di frame e non di scanline come era usuale sul c64). il pratica al frame 0 vedi un oggetto ellittico al frame 1 vedi l'altro oggetto ellittico ma stai usando sempre 1 sprite hw.

Quindi ti avanza 1 preziosissimo sprite da usare per altri scopi.
Non so se mi sono spiegato chiaramente.

Per oggetti elittici intendo quelle cose che sparano insieme alla tua nave (non conosco il termine usato per l'arma ma penso che tu abbia capito cosa intendo)