VCS : Monaco GP W.I.P.

[Dr_Who]

Questo Work In Progress è nato più per curiosità nel capire come si programma l' Atari 2600 , piuttosto che con il fine ultimo di "sfornare" un gioco fatto&finito , quindi non so ancora dove arriverà ....

Tutto il programma è scritto in assembler , nonostante per questa console esista il BatariBasic , giusto per avere il maggior controllo possibile sulla macchina.

Al momento mi sono limitato a verificare la fattibilità della costruzione del "playfield base" e lo scorrimento dello stesso. Inutile dire che la versione per VCS ha delle grosse limitazioni per quanto riguarda la grafica , rispetto alla controparte arcade che , nonostante sia privata dell' utilizzo di un microprocessore , può vantare una grafica basata - di fatto - sull'utilizzo di bitmap memorizzate in prom.

versione Arcade

versione VCS W.I.P.

Il demo è interattivo, nel senso che la velocità dello scroll video può essere controllato dal joystick (alto-basso) , fermato completamente (velocità=0) dalla pressione del pulsante di fuoco , ed il video può anche muoversi in "retromarcia" (anche se non serve ) .....

Al momento ho tralasciato scrivere la routine "fisica" , ovvero accelerazioni e decelerazioni di velocità progressiva , e di ottimizzare il video (qualche glitch c'è ... ).
L' ideale poi sarebbe che il restringimento della carreggiata avvenga in modalità row-by-row piuttosto che a blocchi di playfield, ma questo imporrebbe la necessità di scrivere due kernel video e farli girare alternativamente , cercando di tenere basso il flicker video. Boh, vedremo...


Consigli e commenti saranno ben accettati...... (incomincio ad affilare la lama dell'ascia )

[musehead]

Fantastico!

Dal profondo della mia ignoranza, però, ti chiedo: cosa intendi per modalità row-by-row? E' una tecnica che ti permetterebbe di restringere la carreggiata in maniera progressiva? In tal caso non si potrebbe "solo" ridimensionare il playfield per singoli pixel?

La velocità dello scorrimento, comunque, è notevole. Purtroppo non ho avuto la fortuna di giocare all'originale Monaco GP (ormai la vedo molto difficile), ma come "ritmo" mi pare che il codice sia già messo bene.

Ultima curiosità: gli oggetti a bordo pista sono perfettamente speculari sia come posizionamento che come disegno. E' una coincidenza o hai "specchiato" la stessa bitmap per risparmiare memoria? In tal caso, il programma dovrebbe prevedere uno scenario speculare per tutta la partita?

Ancora complimenti, comunque!

[MacDLSA]

Un'ottima iniziativa, Mirko !!!

Monaco GP, uno dei giochi "INEMULABILI" da Mame (almeno NON il Mame "conosciuto"...), ha da sempre avuto la sua "schiera" di sostenitori, siano essi giocatori (presente !) che "tecnici" (proprio per la sua peculiarità di essere realizzato interamente con circuiti logici PRIVI dell'ausilio di qualsivoglia microprocessore).

Encomiabile la decisione di sviluppo in linguaggio macchina, tralasciando il "validissimo ma insoddisfacente" basic !

Per quanto riguarda lo scrolling verticale e relativo "senso della velocità", prova a "dare un'occhiata" al porting su VCS di Bump'n'Jump (aka Burnin'Rubber) perchè potrebbe darti qualche "indicazione" su come sfruttare al massimo questa caratteristica (per inciso, PRIVA di glitches !!!) del VCS.

Due kernel per il restringimento ? Hmmmmm... prima dovresti valutare quanto ti "porta via" (in bytes) l'operazione... semprechè tu ti sia posto un "limite" entro cui scrivere tutto il programma.

Questo Work In Progress è nato più per curiosità nel capire come si programma l' Atari 2600 , piuttosto che con il fine ultimo di "sfornare" un gioco fatto&finito , quindi non so ancora dove arriverà ....

...occhio che anche Ed Fries, il creatore di Halo2600, aveva iniziato "così"...

[Dr_Who]

Per quanto riguarda lo scrolling verticale e relativo "senso della velocità", prova a "dare un'occhiata" al porting su VCS di Bump'n'Jump (aka Burnin'Rubber) perchè potrebbe darti qualche "indicazione" su come sfruttare al massimo questa caratteristica (per inciso, PRIVA di glitches !!!) del VCS.

Ciao Marco.
Posso dirti che Bump'n'Jamp è più "spartano" per quanti riguarda il background ed il playfield . Mi spiego meglio : come puoi vedere su BnJ il colore del background è impostato in un singolo colore , così come il playfield ha un solo singolo colore; quella specie di "U" coricata e gli zig-zag bianchi che si vedono al bordo pista , sono bianchi perché è il colore del background che "viene fuori" , visto che in quel punto il playfield è assente. Ciò significa che per ogni singola scanline il background e il playfield ha 1 SOLO colore , lo mantiene per tutta la scanline.
Nel mio programma , dove c'è la casa e l'albero (creati con il "playfield") , essi hanno un colore (ad esempio rosso per il tetto), poi però per generare il bordo strada, devo cambiare il colore del playfield, e poi cambiarlo ancora sull'altro lato dello schermo , per generare nuovamente il colore corretto della casa o albero. Questo si traduce nel fatto che devo cambiare al volo in una singola scanline, almeno due colori del background, appesantendo notevolmente il kernel video. questi cambi di colore fatti "al-volo" all'interno della stessa scanline devono essere temporizzati a quasi ogni singolo clock del TIA (=pixel clock)...peccato che per ogni singolo clock della cpu del VCS , orami ne sono passati tre del TIA ( e se poi consideri che ogni istruzione della cpu necessita di almeno 2 cicli, a questo punto si sono persi ben 6 pixel della scanline).

Quindi la complessità del kernel di BnJ è molto minore rispetto a quella di Monaco GP, con tutti gli eventuali glitch video che questo comporta...

[Dr_Who]

@Muse. Ciao Gianluca. Si , lo schermo è speculare , primo perchè necessita di molto meno spazio di codice, poi perchè anche nel gioco originale i lati dx e sx sono speculari.
Per row-by-row intendo una colonna formata da un singolo pixel di larghezza, al posto di una colonna formata da un blocco di palyfield ( formato da otto pixel); facendolo per singolo pixel la resa visiva è sicuramente migliore ed evita effetti di scalettatura.
Grazie e ciao

[Ocram0806]

Complimenti!
Non sono in grado di darti consigli sulla programmazione, perchè non conosco la programmazione in assembler, ma posso consigliati di guardare queste demo di Simon Quernhorst, ----4K4U by Simon Quernhorst - Atari VCS 2600---
4K4U by Simon Quernhorst - Atari VCS 2600 - YouTube

[MacDLSA]

Ciao Marco.
Posso dirti che Bump'n'Jamp è più "spartano" per quanti riguarda il background ed il playfield . Mi spiego meglio : come puoi vedere su BnJ il colore del background è impostato in un singolo colore , così come il playfield ha un solo singolo colore; quella specie di "U" coricata e gli zig-zag bianchi che si vedono al bordo pista , sono bianchi perché è il colore del background che "viene fuori" , visto che in quel punto il playfield è assente. Ciò significa che per ogni singola scanline il background e il playfield ha 1 SOLO colore , lo mantiene per tutta la scanline.
Nel mio programma , dove c'è la casa e l'albero (creati con il "playfield") , essi hanno un colore (ad esempio rosso per il tetto), poi però per generare il bordo strada, devo cambiare il colore del playfield, e poi cambiarlo ancora sull'altro lato dello schermo , per generare nuovamente il colore corretto della casa o albero. Questo si traduce nel fatto che devo cambiare al volo in una singola scanline, almeno due colori del background, appesantendo notevolmente il kernel video. questi cambi di colore fatti "al-volo" all'interno della stessa scanline devono essere temporizzati a quasi ogni singolo clock del TIA (=pixel clock)...peccato che per ogni singolo clock della cpu del VCS , orami ne sono passati tre del TIA ( e se poi consideri che ogni istruzione della cpu necessita di almeno 2 cicli, a questo punto si sono persi ben 6 pixel della scanline).

Quindi la complessità del kernel di BnJ è molto minore rispetto a quella di Monaco GP, con tutti gli eventuali glitch video che questo comporta...

Certo ! BnJ ha un playfield piuttosto "scarno" rispetto a quello che hai creato tu, ma il tutto è assolutamente subordinato allo spazio impiegato dalle varie routine del gioco, e, come vedrai, il "comparto grafico" (se così si può chiamare) è appunto quello che ti "leva" più cicli in assoluto ! Il creare un playfield in cui in ogni singola scanline si "commuta" diverse volte il codice colore come hai fatto tu è un'ottima cosa, perchè apporta il suo "contributo" alla coreografia del gioco. Purtroppo ti "mangia" via un sacco... per cui "ALLA FINE" del programma, scopri di aver letteralmente consumato troppo ed inevitabilmente ti ritrovi con il "rileggere" tutto per tentare di "limare" il più possibile per rientrare nella quantità "target" di memoria.
Tieni presente che DI SOLITO un playfield "complesso" (con repentini cambi di codici colore all'interno di una singola linea) è DI SOLITO proprietà dei giochi "a schermata fissa" o a scrolling orizzontale... ma con un "verticale", haimè: le cose si complicano parecchio !
Non ho questa gran dimestichezza in programmazione del VCS (avevo "piantato lì" tempo fà... mentre stavo cercando di realizzare un mio "sogno"... ) ma osservando e seguendo quello che altri hanno realizzato, ne ho convenuto che più il programma ha un comparto grafico semplice e più si può pensare di migliorarlo DOPO aver scritto tutto il codice ! Praticamente al posto di "limare" (con tutte le difficoltà che ne conseguono) un'eccesso di bytes di un programma troppo lungo, si può pensare di migliorare un programma che "alla fine" rientra in quel "target" sopracitato !
E' vero, il TIA ha un clock che è esattamente TRE volte più veloce di quello del 6507, ma ho visto che esistono diversi "trick" di programmazione che consentono di sfruttare questa caratteristica per poter risparmiare parecchie linee di codice macchina... trick che, purtroppo, con il basic nun ze possono fà !

Ti posso dire che seguirò con estremo interesse questo thread, in modo di poter "carpire" qualche nozione in più a riguardo del LM !

[Dr_Who]

Grazie della segnalazione Ocram !

Mac, ciò che dici è vero , e merita una risposta "sensata" che non ti posso fornire adesso vista l'ora .

Per l'effetto "fari" nello schermo notturno dai uno sguardo anche all'algoritmo di illuminazione di Haunted House, anche se primitivo ed alquanto "flickerante"...

Preferisco questo che sto provando , almeno non flickera come Haunted House (anche se potrebbe far pensare alla fiamma tremolante di una candela...):

Lo sprite disegnato a mò di triangolo sembra comparire e scomparire - pixel per pixel - alla presenza o meno del cono di luce dei fari ; necessita solo di disegnare il muro laterale della galleria.
Se non altro è più simile a questa emulazione di MGP

[Philsan]

Un ottimo lavoro, complimenti!

[Dr_Who]

Ciao Philsan e grazie.

Certo ! BnJ ha un playfield piuttosto "scarno" rispetto a quello che hai creato tu, ma il tutto è assolutamente subordinato allo spazio impiegato dalle varie routine del gioco, e, come vedrai, il "comparto grafico" (se così si può chiamare) è appunto quello che ti "leva" più cicli in assoluto ! Il creare un playfield in cui in ogni singola scanline si "commuta" diverse volte il codice colore come hai fatto tu è un'ottima cosa, perchè apporta il suo "contributo" alla coreografia del gioco. Purtroppo ti "mangia" via un sacco... per cui "ALLA FINE" del programma, scopri di aver letteralmente consumato troppo ed inevitabilmente ti ritrovi con il "rileggere" tutto per tentare di "limare" il più possibile per rientrare nella quantità "target" di memoria.

Con la tecnica del bankswitch che di fatto aumenta la quantità di memoria disponibile per il codice del programma , la disponibilità di bytes utilizzati è un problema relativo.
Il vero problema è la temporizzazione delle "azioni" (ovvero la sequenza delle istruzioni che la cpu deve svolgere). Nel Atari 2600 ci sono due momenti nei quali è possibile fare compiere azioni alla cpu con relativa..."calma" : all'inizio di ogni singolo frame (immagine video completa) durante il vertical blank , ed alla fine del frame durante il periodo di overscan. Nel mezzo ci sta la cosiddetta generazione delle scanline, ed è qui che il fattore tempo diventa critico : si deve eseguire lo stretto necessario delle operazioni quali la scrittura sui registri del palyfield per la sua visualizzazione (solo se esso cambia) , la scrittura dei registri dei due sprites , dei due missili e della ball ; sembra poco, ma in realtà è già molto . Per fortuna c'è la parte iniziale della scanline (horizontal blank) che permette di "tirare un po' il fiato".

ma osservando e seguendo quello che altri hanno realizzato, ne ho convenuto che più il programma ha un comparto grafico semplice e più si può pensare di migliorarlo DOPO aver scritto tutto il codice ! Praticamente al posto di "limare" (con tutte le difficoltà che ne conseguono) un'eccesso di bytes di un programma troppo lungo, si può pensare di migliorare un programma che "alla fine" rientra in quel "target" sopracitato !

Questa è una questione , forse filosofica , sulla quale non concordo. E' pur vero che sempre si incomincia dallo fatidico "HELLO WORD" , ma superata questa fase , personalmente mi sono sempre trovato bene scrivendo già tutto il codice avendo la visione d'insieme completa, e poi al limite "limando" qualcosa . A mio avviso questo approccio è necessario proprio nel caso di macchine come l'Atari VCS , laddove la criticità del fattore tempo , non permette di aggiungere in un secondo momento altre operazioni da far fare alla macchina. Nella programmazione , specialmente in assembler , trovo che sia sempre più facile "togliere" piuttosto che "aggiungere"; aggiungere vuol dire aumentare i cicli macchina , vuol dire non sapere se hai registri e memoria disponibile per far eseguire quelle istruzioni in più che non avevi previste, ecc...insomma un casino !

[Dr_Who]

...la parte precedente nell'altra pagina ....


...AZZO GLI SPRITES...

Stavo allegramente giocando con gli sprites , facendoli muovere a destra e a sinistra (e già qui è un casino !), sopra e sotto , quando mi sono accorto di un problema...e non di poco conto...

Ecco come gestisce lo spostamento degli sprites il VCS. Immaginate uno sprite dalla forma di automobile presa di profilo , che avanza orizzontalmente da sinistra a destra; arrivata al bordo destro dello schermo , la macchina poco a poco scompare : prima scompare il paraurti, poi il parafango e ruota , e via via la portiera anteriore, quella posteriore , sino alla macchina completa.
Niente di strano, se non fosse che nel momento in cui i primi pixel dello sprite che scompare (giustamente) dal lato destro, esso compare sul lato sinistro dello schermo; dopo che tutta l'auto è scomparsa a destra , essa è presente a sinistra.
Tutto ciò rappresenta un grosso problema nella gestione degli sprite sui giochi a scorrimento orizzontale : man a mano che escono da un lato dello schermo , ricompaiono dall'altro lato. Una soluzione sarebbe quella di calcolare il momento in cui lo sprite tocca il bordo del video e farlo "scomparire" di colpo , in un "botto" solo ! Non molto bello da vedersi ( è come se una macchina che vi stà passando davanti al vostro parabrezza, una volta arrivata col paraurti sul bordo destro o sinistro del parabrezza , scomparisse tutta di colpo ).
In rete non si trova nessuna info od esempio decente se non i soliti demo o tutorial triti e ritriti (vai in alto, in basso , a dx , a sx....) , ma tutti o si fermano sul bordo, o "attraversano" lo schermo a mò di tunnel spazio-dimensionale.
Disassemblare un gioco già fatto è un casino (di tempo) , e così mi sono dovuto inventare qualcosa. Non so se è il modo più "elegante" (accademicamente parlando) e più "veloce" (=con meno istruzioni e cicli cpu impiegati) , ma sicuramente funziona.

Allora...uno sprite nel VCS può essere "largo" solo 8 pixel (anche se può essere "allungato", ma l'informazione base è sempre di 8 pixel) , e può essere alto per un numero a piacere di pixel (ma generalmente non supera i 16).
Esiste un motivo ben preciso per il quale uno sprite non può essere più largo di 8 pixel : una singola linea di uno sprite è gestita dal TIA del VCS da un solo BYTE . Un singolo pixel può essere "acceso=1" (visualizzato a video) , oppure "spento=0" (non visualizzato), ovvero il valore o stato che può assumere un BIT (un bit può essere solo allo stato "1" oppure allo stato "0"); ecco allora che un singolo bit ci dà l'informazione se il rispettivo pixel è visibile o non-visibile; incidentalmente , un singolo BYTE è composto per definizione da 8 BIT.....quindi in un byte è memorizzata l'informazione di 8 pixel di uno sprite , non un pixel (bit) in più.

Prendiamo ad esempio uno sprite "standard" composto da 8 pixel di larghezza (quindi il massimo) e 8 pixel di altezza ; esso è memorizzato in rom del VCS utilizzando 8 bytes (8 bytes perché lo sprite è alto 8 pixel , fosse stato alto 12 pixel, sarebbero stati necessari 12 bytes). I bit di ciascun byte saranno allo stato 1 o 0 , a seconda dello stato del singolo pixel come detto prima.


Ecco l'esempio.

Tornando al problema iniziale , quando la prima delle 8 "colonne" dello sprite supera il bordo destro dello schermo , tale prima colonna si ripresenta sul bordo sinistro ; è necessario quindi cancellare questa prima colonna , in modo tale che non si ripresenti sul lato i opposto dello schermo (perché cancellata appunto ! ) ; quando lo sprite avanza ancora, ora sarà la seconda "colonna" a dover essere cancellata , e così via per tutte le 6 rimanenti "colonne" .
Guardando la figura sopra, possiamo notare che le "8 colonne" sono nient'altro che gli 8 BIT che costituiscono l'immagine. Quindi ciò che dobbiamo cancellare sono in realtà i BIT di ciascun byte.
"Cancellare" significa che se lo stato del bit è uguale a "1" , allora deve essere posto uguale a "0" (e il rispettivo pixel sarà quindi spento/non visibile = cancellato per l'appunto !!! ) ; i bit uguali a "0" sono già cancellati .
L'operazione che "forza" a zero i bit settari a 1 (e mantiene a zero quelli già a zero" è l' AND (vedere wikipedia sotto la voce "operatori booleani")


Ecco come lavora.

Più che una vera operazione di "cancellazione" , è una operazione di "mascheramento" .
In tutto si devono compiere 8 operazioni di "mascheramento" , ovvero tante quanti sono i bit presenti nel byte (ovviamente) , al fine di cancellare/mascherare gli 8 pixel di larghezza dello sprite. Ciascun degli 8 cicli di mascheramento deve essere eseguito su tutti i byte che compongono l'immagine in "altezza" (se lo sprite è alto 16 pixel , cioè utilizza 16 bytes , tutti e 16 i bytes devono essere sottoposti ai cicli di mascheramento).

E ora il video con i risultati....

Nella prima parte lo shift sinitra-destra senza operazioni di mascheramento; nella seconda parte sempre senza mascheramento , ma con l'immagine catturata dalla finestra del debugger dell'emulatore Stella ; nella terna ed ultima parte , lo spostamento sinistra-destra con il mascheramento : lo sprite non è più visibile dall'altra parte dello schermo (sempre dalla finestra del debugger di Stella).

- TO BE CONTINUED - con il codice sorgente

[Majinga]

Bello!

Io di queste cose non me ne intendo molto. Tuttavia questa cosa di far riapparire gli sprite dall'altra parte dello schermo mi sembra alquanto una bizzarria.
Posso chiederti se è una cosa tipica del VCS o se è presente anche in altri sistemi?

[musehead]

soluzione efficace di sicuro e probabilmente, eleganza o meno, chissà da quanti giochi é usata.

lo sprite dell'albero, a questo punto, mi fa venire in mente una domanda di altra natura. é disegnato in multicolor, ma il cambiamento avviene solo oltre una certa linea. per ottenere l'effetto hai solo cambiato il colore corrispondente altra bit 1 da una determinata linea in poi? in tal caso, sarebbe impossibile per il TIA un multicolor orizzontale?

[MacDLSA]

Quando "studiavo" come realizzare lo scrolling "dedicato" al gioco che avevo intenzione di "sfornare", avevo preso come riferimento Pitfall II... In questo caso il buon Harry non arriva neppure a "toccare" il bordo destro dello schermo quando eccolo riapparire dal lato SX in una nuova schermata. Particolarità ASSOLUTAMENTE VOLUTA proprio per non dover utilizzare quei seppur pochi bytes necessari alla cancellazione di ogni singolo pixel dal lato opposto dello schermo.
Un trucco ? No... semplicemente una considerazione ... praticamente un "settaggio" del campo di azione dello sprite principale con una ridefinizione dei "bordi-limite" sx e dx: Se lo sprite "tocca" uno di questi bordi ecco che cambia completamente tutto lo schermo e ricompare sul lato opposto dello stesso, rivolto nella direzione in cui stava andando.

Se invece osserviamo giochi tipo Frogger (..."primordiale" ) notiamo che tutti gli sprites in movimento orizzontale scompaiono a destra e/o a sinistra per poi ricomparire sul lato opposto, ma in questo caso NON si "scompongono" in pixel tra una parte e l'altra dello schermo... Anche in questo caso nessun trick: lo schermo "utile" di gioco è ridimensionato tramite una "maschera" applicata sul fondale che tra le altre cose "occulta", appunto, questa "transizione" degli sprites !

TUTTO QUESTO (scusa, Mirko, se sono "recidivo"... ) ancora per risparmiare spazio "utile" nel codice macchina !

[ Mi ripeterò... thread ASSOLUTAMENTE interessantissimo !!! ]

[Dr_Who]

@ Majinga : non saprei per gli altri sistemi, è sicuramente tipica del VCS per come è arrangiato il TIA

@ Muse : quando si setta il colore dello sprite, è possibile solo attribuire un solo colore ad una singola riga (scanline); più righe dello sprite possono avere colori differenti; una volta definito il colore della riga non è più possibile cambiarlo. Quindi no, non è possibile il multicolor in orizzontale (poi con qualche espediente si potrebbe anche fare, ma non è previsto in condizioni "normali").

@MacDLSA : su Pitfall , scritto dal "Mostro" Mr. Crane , non si discute... però sarebbe stato bello vedere Harry che "pixel-per-pixel" scompare dietro lo schermo... Pitfall però è una cosa a parte : è un gioco/programma talmente "vasto" ed esoso in termini di memoria della cartuccia, che ci stà pure che non si siano "spesi" bytes per cose del genere. Ma altri giochi meno esosi...
Frogger è un altro discorso; se noti, nei bordi destro e sinistro è presente un accenno di "playfield" di colore verde; il playfield è settato con priorità alta rispetto agli sprite, ciò significa che quando uno sprite inizia a sovrapporsi al playfield, lo sprite "passa sotto" e viene quindi mascherato.

Come vedi, utilizzando il debugger di Stella , ed andando ad eliminare la prorità del playfield rispetto agli sprites, questi "saltano sù" , con l'effetto che dicevo in qualche post precedente.
Fa abbastanza schifo l'effetto...a me personalmente fa anche abbastanza schifo vedere i due grossi bordi verdi ai lati....(sopratutto adesso che conosco il perché li hanno messi)