[C64] QUOD INIT EXIT Opzioni

[saimo]

Amanti del C64,

volevo informarvi che una nuova anteprima di HOC INIT EXIT - un nuovo gioco per C64 a cui mi dedico a tempo perso - è ora disponibile: datele un'occhiata qui.

Lista dei cambiamenti:
- aggiunta musica (di Richard Bayliss);
- aggiunti punteggi;
- aggiunta notifica di game over;
- migliorata grafica in alcuni punti;
- resa la schermata iniziale "colorosa".

Buon divertimento!

Messaggio modificato da Tsam il 22 Apr 2010, 14:44

[TheRuler]

Mi è effettivamente venuta in mente una cosa riguardando il trailer della FORTRESS.
Il movimento verticale della telecamera incide sul gameplay, più precisamente sulla difficoltà di valutare le distanze nei salti. Almeno per me.
Notavo che vicino ai limiti inferiori e superiori della mappa la telecamera NON segue verticalmente Zampo, mentre in tutta la parte centrale segue con delay pressoché zero ogni salto. Immagino sia una scelta precisa di design (e mi piacerebbe sapere i retroscena tecnici) ma ciò mi rende difficoltosi i salti, tipo al minuto 1.20.
Hai valutato la possibilità di mantenere più o meno al centro Zampo introducendo un delay nel camera movement piuttosto che fissata su di lui?
Orizzontalmente stranamente non mi crea problemi ma verticalmente mi imbanana, scusa il tecnicismo.

[saimo]

Abbi/abbiate pazienza: perché la mia risposta possa essere compresa a fondo (anche da chi non ha conoscenze tecniche), devo partire da lontano.

Il C64 è comunemente detto avere lo scrolling hardware, ma le cose stanno diversamente da come possono sembrare. Quello che offre il chip video (VIC-II) in termini di scrolling è la possibilità di spostare orizzontalmente/verticalmente la grafica dello schermo di un numero di pixel compreso tra 0 e 7. Tutto qui. E' una funzione fondamentale per ottenere lo scrolling, una componente essenziale dello stesso, ma non è lo scrolling nel complesso. Quello si ottiene a gran fatica con la CPU. A causa della potenza limitata della CPU e delle limitazioni di accesso alla memoria, tutti i giochi che scrollano hanno in comune una o più di queste caratteristiche: area di scrolling di dimensioni ridotte (è per quello che molti giochi hanno pannelli di stato inutilmente enormi sopra e/o sotto l'area di gioco), 4 colori fissi per lo sfondo, movimenti solo orizzontali e/o solo verticali, velocità di scrolling ridotta, camera che segue a fatica. (Non mi addentro nelle tecniche VSP/AGSP, che, con dei trucchi, costringono il VIC-II a eseguire un vero e proprio scrolling, al prezzo della perdita di compatibilità con tutti i C64 e di altre restrizioni.)
Nel 2015, mentre stavo sviluppando MAH, mi venne voglia di realizzare un motore di scrolling che non soffrisse di quei limiti e, cioè, che offrisse movimenti illimitati in velocità e direzione, e a schermo intero. Dopo essermici scervellato un po', mi venne l'idea giusta e la usai per implementare il finale di MAH. Tuttavia, lì era destinata a non essere apprezzata, per cui decisi di basarci un intero gioco. Scelsi quindi di farci un platform che, al contrario di tutti gli altri giochi per C64, avesse come caratteristica identitaria il fatto che il personaggio principale è sempre fisso al centro dello schermo, indipendentemente dalla velocità - e così nacque QIE II.
Il motore di scrolling e, in particolare, il fatto che la camera segue alla perfezione Zampo (quindi, come dici tu, "0 delay") è, dunque, una caratteristica centrale del gioco. In altre parole, eliminare il delay (che non sopporto, sia perché mi dà semplicemente fastidio a pelle, sia perché fa sì che quando il personaggio sia nei paraggi del bordo dello schermo il giocatore vede ben poco di quello che sta arrivando, complicando le cose) era proprio tra i miei obiettivi iniziali.
La difficoltà che sperimenti probabilmente deriva dall'abitudine. Dovrebbe farti lo stesso effetto - dico il primo gioco che mi viene in mente - anche Superfrog per Amiga.
Nota a margine: quando Zampo è ai bordi della mappa lo scrolling deve fermarsi per forza perché altrimenti verrebbero visualizzate zone di memoria estranee; in quel caso Zampo deve schiodarsi dal centro dello schermo per poter raggiungere i margini.

[TheRuler]

Abbi/abbiate pazienza ... devo partire da lontano.

Beh, mi mandi a nozze.

Molto interessante, grazie Simone.

Ora che l'hai detto mi ricordo avessi già accennato da qualche parte la storia legata al motore di scrolling per l'ultima parte di MAH e della genesi di QUOD.

fa sì che quando il personaggio sia nei paraggi del bordo dello schermo il giocatore vede ben poco di quello che sta arrivando

D'accordissimo, non lo vorrei diverso, orizzontalmente è perfetto. Mi sono solo accorto che giocando, mi trovo più a mio agio nelle parti inferiore/superiore della mappa, dove Zampo non fa scrollare vericalmente ad ogni salto. Non saprei concettualmente come fare senza introdurre ilo delay (che fa schifo pure a me se troppo lento).
Immaginavo fosse una scelta precisa ed è ottima davvero. Te lo dico sinceramente, uno scrolling così fluido e responsive faccio fatica a ricordarmelo (i tuoi giochi li gioco tutti su real hardware, a parte skill grid che un Amiga non l'ho) in giochi commerciali.

lo scrolling HW 0-7 pixel, in effetti sembra molto limitato. Pare più una bella mossa di marketing che una feature effettivamente utile. Almeno per il genere di giochi che poi sono usciti sulla piattaforma.
Come funziona realmente finiti i 7 pixel? Essendo praticamente un buffer lavora a chunk? quanto sono grandi? spostamenti orizzontali e verticali sono effettivamente separati o combinati (per il diagonale)?

[saimo]

D'accordissimo, non lo vorrei diverso, orizzontalmente è perfetto. Mi sono solo accorto che giocando, mi trovo più a mio agio nelle parti inferiore/superiore della mappa, dove Zampo non fa scrollare vericalmente ad ogni salto. Non saprei concettualmente come fare senza introdurre ilo delay (che fa schifo pure a me se troppo lento).

Beh, una terza strada non c'è. Temo dovrai farci l'abitudine

Immaginavo fosse una scelta precisa ed è ottima davvero. Te lo dico sinceramente, uno scrolling così fluido e responsive faccio fatica a ricordarmelo (i tuoi giochi li gioco tutti su real hardware, a parte skill grid che un Amiga non l'ho) in giochi commerciali.

Spero di non passare per immodesto, ma la verità è che effettivamente prima, su C64, una cosa del genere non c'era (lo stesso dicasi per l'alta risoluzione a colori, sia per sfondi che per sprite). Sono partito proprio dall'idea di fare qualcosa di nuovo (e, se me lo consenti, di rivoluzionario). Visto che citi SkillGrid, lo spirito è lo stesso di quel gioco - anche in quel caso non c'è nulla di simile a livello audiovisivo.
Nota per completezza: ora anche il port di Sonic fa scrolling senza limiti, ma in quel caso il gioco si avvale delle capacità di DMA della REU, che fa (meglio) il lavoro che in un C64 senza REU dovrebbe fare la CPU (vedi sotto).
Peccato che non puoi giocare SkillGrid su hardware vero: se uno non ha PC e monitor adatti, lo scrolling non è fluido come dovrebbe essere, e in quel caso l'effetto è un po' fastidioso, in combinazione con i 3 livelli di parallasse.

lo scrolling HW 0-7 pixel, in effetti sembra molto limitato. Pare più una bella mossa di marketing che una feature effettivamente utile. Almeno per il genere di giochi che poi sono usciti sulla piattaforma.

Oh, no: è una caratteristica essenziale, invece! Senza, non si sarebbe potuto fare lo scrolling in generale, e il C64 avrebbe sofferto come lo Spectrum o l'Atari ST.

Come funziona realmente finiti i 7 pixel? Essendo praticamente un buffer lavora a chunk? quanto sono grandi? spostamenti orizzontali e verticali sono effettivamente separati o combinati (per il diagonale)?

Una spiegazione davvero dettagliata richiederebbe troppo tempo, perciò perdonami se dovrai fare un po' di sforzo per indovinare i sottintesi in quanto segue.
Nelle modalità a caratteri (ce ne sono 3), lo schermo è una matrice di 40x25 caratteri di 8x8 pixel ciascuno. Quando si attiva lo scrolling orizzontale e/o verticale, la visuale viene ristretta per nascondere le colonne a destra e sinistra e la riga in basso, in modo che lo shift hardware faccia "scivolare" i caratteri dentro/fuori (ecco perché l'area di schemo di QIE IIo è 304x192 e non 320x200). Quando una riga/colonna di caratteri è interamente fuori, la CPU deve copiare la matrice dei caratteri una colonna/riga avanti/dietro. La stessa cosa va fatta per la COLOR RAM, un'altra matrice che specifica i colori degli stessi. Come puoi immaginare, è un lavoro enorme per la CPU. Infatti, le limitazioni che menzionavo nel precedente post sono proprio dovute a quello. Ad esempio, usare solo 4 colori fissi per tutto lo schermo fa sì che la COLOR RAM non debba venire aggiornata (dimezzando quindi il carico della CPU); lo scrolling progressivo, invece, permette di copiare i dati un po' per volta (per capirci: se la velocità di scrolling massima è 1 pixel/frame, vuole dire che la CPU può spostare la matrice in un buffer a parte distribuendo il carico in 8 frame e poi scambiare il buffer quando la copia è completata); e così via.