VCS : Monaco GP W.I.P.

[Dr_Who]

E qui il codice in assembler :

destra	ldx Posizione_X	; carica nel registo X il valore di posizione orizzontale dello sprite (Posizione_X)
		cpx #152		; confronta il valore contenuto nel registro X con il valore 152 
		bcc salto		; se il valore di Posizione_X è minore di 152 vai alla riga "salto" , altrimenti continua con la successiva
		lda #160		; carica nell' accumulatore A il valore 160
		sbc Posizione_X	; sottrai a 160 il valore di Posizione_X
		tay			; sposta il risultato dall' accumulatore al registro Y
		sty risultato	; e salvalo nalla variabile "risultato"
		lda Mascheramento-1,y		; carica nell'accumulatore A il valore letto in ROM alla
                                                        ;posizione (Mascheramento-1)+Y
		sta mask		; salva il valore appena caricato nella variabile "mask"
		jmp salto_2		; vai alla riga "salto_2"
salto
 		lda #255		; carica nell' accumulatore A il valore 255
		sta mask		; e salvalo nella variabile "mask"
salto_2	
		……..
		altre istruzioni
		……..

################# la porzione di codice dove risiedono i valori di mascheramento


Mascheramento
	.byte #%00000000	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=1
	.byte #%10000000	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=2
	.byte #%11000000	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=3
	.byte #%11100000	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=4
	.byte #%11110000	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=5
	.byte #%11111000	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=6
	.byte #%11111100	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=7
	.byte #%11111110	; posizione in ROM puntata da (Mascheramento-1)+Y , dove Y=8


################### la porzione di codice de kernel video dove vengono attivati
################### gli sprite . Rispetto al codice originale , è stata aggiunta
################### SOLO l'istruzione "and mask"

		lda Valore_Sprite	  ; carica nell'accumulatore A il valore "originale" rappresentante il
                                          ;disegno dello   sprite
		and mask		; esegue l'operazione di AND tra il valore sprite ed il valore della
                                        ;"maschera"
		sta GRP0		; da applicare , e poi salva il risultato nel registro di visualizzazione dello
                                        ;sprite.

Questo codice ha il pregio può risiedere in qualunque punto del programma, e quindi non sottrae "tempo" e "spazio" alla sezione del Kernel video .


Incidentalmente queste operazioni di mascheramento , possono anche eseguire effetti grafici anche "carini" quali la simulazione del riflesso di una luce sulla superficie dello sprite , la sua scomparsa progressiva , e via con la fantasia...

[MacDLSA]

...fa anche abbastanza schifo vedere i due grossi bordi verdi ai lati...

Hehe, già !

MA (c'è sempre un "ma" ...) in un'ipotetico gioco prettamente a sviluppo VERTICALE con sprites che devono scomparire da un lato per poi riapparire dall'altro, questa sorta di, appunto come diciamo noi, "mascheramento" può senz'ombra di dubbio tornare utile (e poco "dispendiosa") per poter delimitare l'area di azione in modo da FARLA SEMBRARE a tutti gli effetti VERTICALE, mentre ben si sa che in una "normale" visualizzazione TeleVisiva tale area ha invece uno sviluppo orizzontale...

Prendi, ad esempio, un sempre ipotetico Pac-Man:
sappiamo che sul coin-op originale il monitor è messo in verticale perchè il gioco è stato ideato a sviluppo, appunto, verticale.
Poni la situazione in cui il nostro Pac, come pure anche un fantasma, debba percorrere un tunnel per poter scomparire da un lato e per poi riapparire dall'altro.
Nel caso di un' "area di gioco a pieno sviluppo" orizzontale (non "fedele" alla configurazione dell'originale, quindi) avremo la condizione da te descritta, "tipica" del VCS, e cioè con lo sprite che progressivamente si "scompone" in due parti.
Nel caso, invece, di un'area di gioco DELIMITATA con entrambi i "tricks alla Pitfall" e alla "Frogger", avremo una configurazione "generale" in cui il campo di gioco è "ristretto" (nel caso del VCS, haimè, VERAMENTE ristretto !) da una maschera che PERO' rende l'apparenza del gioco più "fedele" all'originale !
Ovviamente è solo un'esempio che, parlo sempre di VCS, limiterebbe assurdamente l'area di gioco !
[ In alcuni altri casi, invece, questo "limitare" ha avuto un più che buon successo (ved. "riedizione" di Donkey Kong su C=64 )]

Potrebbe MAGARI essere redditizio produrre per un "gioco verticale" un playfield "di mascheramento" in modo da rendere l'area di gioco perlomeno "quadrata"... un' IBRIDO, una VIA DI MEZZO, insomma, tra l'avere un "verticale PURO" ed un' (orribile) orizzontale !!!

[Dr_Who]

Nuovo aggiornamento...

Intanto ho dato anche io un "nome in codice" al progetto:

MONACO di MONZA - GP

gioco di parole , giusto per evitare ogni problema di (c) , coi tempi che corrono assàmai...

Allora, ho stravolto completamente il lavoro sino ad ora fatto : il gioco è pensato per un monitor ad orientamento verticale (come l'originale), e quindi adesso le auto hanno uno scorrimento orizzontale .
Il restringimento della sede stradale ora avviene in modalità più fluida tramite l'utilizzo delle singole scanline e non più a "blocchi" di playfield.

Guardando il filmato, non passa inosservato un difetto grafico. Se devo essere sincero, per un attimo mi sono sentito "orgoglioso" nel vedere questo "difetto" , che appare quando viene gestito più di uno sprite in un singolo frame video. Il TIA (Television Interface Adaptor) del VCS è in grado di visualizzare e gestire solo due sprite per ogni frame video : lo sprite del giocatore 1 e lo sprite del giocatore 2. Tuttavia è possibile visualizzare (o meglio "riposizionare") su diverse scanline (linee video) lo sprite del giocatore 1 (o del giocatore 2) ; questa operazione di riposizionamento porta il TIA a lavorare al di fuori delle sue specifiche di lavoro, e come effetto di ciò appaiono delle righe nere (8 pixel di lunghezza) in corrispondenza della scanline dove risulta posizionato lo sprite. Per il riposizionamento di uno stesso sprite è necessario scrivere una routine relativamente complessa perché prevede un timing ben preciso delle diverse istruzioni /operazioni da far eseguire al TIA (e quindi alla CPU che gli sta dietro).
Nel mio caso ho usato lo sprite del giocatore 1 (registro GRP0 del TIA) per generare prima il cespuglio d'erba nella zona superiore dello schemi, poi per generare l'auto del giocatore, ed infine per generare nuovamente il cespuglio. Le auto controllate dal computer sono invece generate dallo sprite del giocatore 2 (registro GRP1).

Qui sotto altri esempi di "difetti" grafici relativi al multi-sprite


Star Wars - Parker Brothers


Air-Sea Battle - Atari


Grand Prix - Activision by Crane (modificato tramite il Debugger di Stella per fare "risaltare" le righe)


Monaco di Monza - con in più l'auto controllata dal VCS (per un massimo di 1+5 macchine presenti per singolo frame video).

Al momento il demo è giocabile , anche se necessita di qualche ottimizzazione. E' presente anche la parte con lo sfondo sull'acqua , mentre manca ancora quello della galleria.

Qualche numero: grafica multi-sprite (ci è voluto più di una settimana di lavoro solo per capire come funzionava), utilizzo di tre kernel video differenti, poco meno di 300 righe di codice , 780 bytes di codice programma utilizzato (rispetto al totale di 4096 bytes disponibili di una cartuccia da 4 KB , quindi senza bankswitch) , 14 bytes di memoria ram utilizzata (contro i 256 bytes disponibili).

Onestamente, dopo qualche settimana di lavoro sul VCS , non avrei mai pensato di arrivare a questo punto. Non fraintendetemi, la grafica è appena sufficiente , il gameplay è quello che è e non ci sono chissà quali prodezze "programmatorie", ecc...ecc... , però considerato il mio totale digiuno su questa macchina, sono abbastanza soddisfatto; e questo mi basta al momento.

La parte più complicata è il reperimento delle informazioni per la programmazione; può sembrare strano considerando i due o tre siti/forum del VCS pieni zeppi di roba, ma alla fine della fiera questa "roba" è a volte solo poco più utile del solito tutorial stile "Hello World" ; molto più utile , ma enormemente dispendioso , leggere tra le righe (in tutti i sensi ) del listato disassemblato di un gioco già fatto...
Il fatto che la maggior parte delle volte è necessario operare al di fuori (o oltre) alle specifiche della macchina, a dover pensare "out of box" . Tanto di cappello ai primi programmatori di questa console !!!

[retrogamer]

ti auguro buona fortuna dr who!
spero che il tuo videogame venga bene.
ps= ti suggerisco di migliorare gli sprites, non sembrano tanto macchine da F1

[musehead]

Che spettacolo!!!

Complimenti, Dr_Who, è veramente un lavoro ammirevole e, lo dico con totale sincerità, quel ridimensionamento morbido della carreggiata con tanto di linea colorata di rottura fa una bella figura in senso assoluto. Considerata l'inesperienza con la console ed il relativamente poco tempo impiegato mi pare un risultato eccellente. Complimenti vivissimi!

E con tutto il patrimonio che hai risparmiato (14 bytes utilizzati?!?) intendi aggiungere altro?

[Dr_Who]

@ Retrogamer : grazie. In effetti le auto non vogliono assomigliare a macchine da F1 ; tuttavia, anche se avessi voluto disegnare una F1 , sicuramente avrei fatto un obbrobrio : sono tanto negato nel disegno a mano libera , quanto negato nella computer graphic. Avrei potuto tranquillamente disegnare dei semplici rettangoli . Al momento non ho nessuna intenzione di continuare a lavorarci sopra (come ho detto all'inizio, in realtà non ho nessuna intenzione di fare un gioco fatto e finito) . Poi chissà, nei mesi a venire, se avrò un po' di tempo e sopratutto voglia ...

@ Gianluca : gentile come sempre, quasi la lacrime agli occhi ( ) . Sebbene i tuoi rinfrancanti commenti possano spronarmi ad andare avanti , come ho detto a Retrogamer, non è che abbia voglia di continuare ; la mia era pura e semplice curiosità (e ti assicuro che di curiosità me ne sono tirate via parecchie ! ) . Tutto lo "spazio" a disposizione potrebbe essere comodamente utilizzato per la parte sonora , ma sai , sono negato sia nel disegno che nella musica , quindi non sarei "artisticamente" in grado di far emettere un suono minimamente gradevole al VCS ( eccezione fatta per il campanello di casa ! ).
Piccola nota: le due righe rosse che delimitano la strada sono costituite dall' elemento "playfield" : in tal modo , semplicemente andando testare il bit (generato direttamente dal TIA) di "avvenuta collisione" tra l'elemento "sprite" e l'elemento "playfield" , mi è stato possibile verificare in modo molto semplice e veloce , se l'auto tocca il bordo pista (con il conseguente rallentamento di velocità e relativa perdita di "tempo sul giro" ). Quindi, oltre che ad essere esteticamente belle , risultano essere anche estremamente utili.

Sicuramente una bella esperienza.

p.s. è pronta (e dovrebbe anche funzionare nell' Atari 2600 "reale", ma mai provata) una routine che permetterebbe di gestire su tre display a 7 segmenti, le tre cifre (centinaia, decine e unità) della velocità raggiunta dall'auto , quasi come nel coni-op di Monaco GP.

[Ocram0806]

Waooow, quando ero piccolo era il mio sogno riuscire a programmare un video gioco sull'atari 2600!

[MacDLSA]

Ohhh, che bello !!!!!!!!!!!!
Complimentissimi, Mirko !
Io direi che questo è veramente un'ottimo inizio (si vede che ci sai fare con il linguaggio macchina...) !
Hehe... lo scrolling orizzontale è MOOOOOOOOOOLTO meno "esoso"del verticale, vero ? .

[Dr_Who]

...direi che questo è veramente un'ottimo inizio...

ed anche un' ottima fine , mio caro Marco ! E grazie !

Riguardo lo scrolling non saprei dirti...sarà perché su certe cose sono sempre stato un bastian contrario , ma lo scrolling orizzontale lo trovo molto più complicato se si tratta di "spostare" il playfield (o peggio ancora lavorando sul background) , mentre se si tratta di scrollare sprites allora verticale o orizzontale lo trovo pressoché indifferente.

[MacDLSA]

ed anche un' ottima fine...

Hehe, io ci ho provato a farti "redimere" dalla tua "dichiarata" volontà nel NON proseguire la realizzazione di questo Monaco...

Per la questione dello scrolling, intendevo dire che per l'hardware del VCS è molto meno "dispendioso" uno scrolling orizzontale di uno verticale...
Ricordo (con piacere !) tempo fa una discussione su VANGUARD, noto e bellissimo shooter spaziale in cui si alterna uno scattosissimo scorrimento (o SPOSTAMENTO, come dici tu ) in orizzontale ad uno in verticale del playfield, dipendentemente dalla fase di gioco in cui ci si viene a trovare. Ebbene, feci la fatidica domanda: "Costa di più uno scrolling orizz. o uno vert. ?" alla quale mi fu risposto, in termini che allora non conoscevo proprio moltissimo (non che, a dire la verità, anche oggi stesso io ci capisca più di tanto... ), che per il VCS erà più semplice gestire un' orizzontale.

[ Breve O.T. : Vanguard
A dire la verità, oltre al fattore "scrolling", in quel frangente si trattava di discutere sulla differenza di metodologia di sparo tra la versione PAL e quella NTSC. Ora, partendo dal presupposto che l' astronave che si controlla subisce un sostanzioso rallentamento quando sta sparando (tasto di fuoco + direzione dello stick = sparo in "quella" direzione), la curiosità che mi era balzata "al polpastrello" fu, infatti, dopo aver provato il titolo NTSC sull'emulatore, che lo sparo era "automatico" !

Immediatamente pensai a dei settaggi che sulla versione PAL non c'erano o erano stati omessi... o ancora una difettosità nell'emulazione...
NO !
E' proprio così : l'astronave del Vanguard NTSC spara da sola, senza l'utilizzo del tasto di fuoco che, invece, serve a far cessare lo sparo (!!!???!!!???!!!???!!!???!!!???!!!???!!!???!!!??? che ca.ata COLOSSALE !!!???!!!???!!!???!!!???!!!???!!!???!!!???!!!???) !
E gli american(acc)i che continuavano impeterriti a sostenere che il "loro" era COMUNQUE migliore...

Io gli dissi (erano almeno in 5...) di andare a comprarsi una pistola, inserire il caricatore e successivamente CONTINUARE A PREMERE SUL GRILLETTO PER EVITARE DI FAR PARTIRE UN COLPO...

Quindi: INCREDIBILE !
Il Vanguard "nostrano" era stato alla fine dichiarato VINCITORE nei confronti del suo gemello "oltreoceanico" !!!
Un caso su mille, veramente !
fine O.T. ]

[Dr_Who]

Mac, non conosco i termini della discussione a cui ti riferisci, ma probabilmente hanno usato il termine "dispendioso" / "esoso" nel senso che se viene utilizzato un playfield precalcolato (memorizzato nella cartuccia) da fare scrollare , esso occupa più spazio in rom in termini di numero di bytes se lo scroll avviene verticalmente , mentre occupa meno spazio se lo scroll è orizontale. Il rovescio della medaglia di uno scroll orizontale sono due: 1) risulta molto meno fluido del verticale 2) è necessaria una routine abbastanza complessa per effettuare lo spostamento a destra (o sinistra) dei 30 bit che compongono il "disegno" nei tre registri del playfield (PF0, PF1, PF2) nel caso si utilizzi un playfield in mirroring , o addirittura è ancora più un casino se si utilizza un playfield asimmetrico (in questo caso si devo "spostare" 60 bit su 6 resgistri (FP0/PF1/PF2+PF0/PF1/PF2); tra l'altro non è una semplice e sola operazione di spostamento dei bit (fattibile semplicemente con le istruzioni shift-left / shift-right) , ma è necessario anche swappare i bit dei registri PF0 e PF2 poichè i registri PF0 e PF2 hanno i bit invertiti.
Quindi in termini di pura programmazione è molto più dispendioso lo scrolling orizontale rispetto al verticale.

Adesso non sto qui a farla lunga, ma se interessa posso anche darvi qualche "numero" e darvi qualche info più tecnica al fine di meglio argomentare quanto esposto sopra .