Ancora più ansia 
Solo 2 domande:
- sappiamo che il gioco uscirà in formato cartuccia con un adattatore per CPC std e serie Plus, giusto?
- È prevista una versione digitale per emulatori o sistemi FPGA?
18 Mi Piace
Ancora una volta, solo robaccia da IA…
:sdraiato a terra a piangere:
1 Mi Piace
Niente 4 giocatori sullo stesso schermo? Ridatemi i miei soldi che non ho ancora speso…
Rhino, davvero, sono senza parole.
Tanto di CAPPELLO a te personalmente e a tutti i ragazzi che hanno preso parte a questo progetto.
A partire da Batman Forever nel 2011, hai davvero ricaricato la community del CPC in tantissimi modi.
Grazie!
3 Mi Piace
Il gioco killer è qui come promesso.
Grazie.
1 Mi Piace
Posso solo dire:
ma che cazzo.
1 Mi Piace
In attesa di vederlo su un vero CPC, sembra impressionante, manca sempre meno 
2 Mi Piace
Semplicemente sbalorditivo!
1 Mi Piace
Semplicemente s t r a o r d i n a r i o !!!
1 Mi Piace
Sembra impressionante, ma perché avete fatto fare quel trailer scadente alla macchina del fango (slop machine)?
Trenta secondi di video in esecuzione su hardware reale avrebbero funzionato molto meglio.
1 Mi Piace
il vecchio brontolone fa il brontolone 
Non mi convince World Racing nel titolo. Real Racing Simulator suona decisamente meglio. E già che ci siamo, perché non aggiungere Gran prima di Vespertino? Ecco fatto! Abbiamo fatto centro!
OMG, immagina una versione su una cartuccia standard Plus, pieno supporto per il joypad, giocabile su un GX4000 modificato a 128K 
! Riesci a immaginarlo?
1 Mi Piace
Video interessante. Sembra confermare la mia intuizione.
Di seguito le mie intuizioni e supposizioni. Non sto giudicando né cercando di sminuire. Il risultato è davvero impressionante. Bravi!
La strategia complessiva, secondo me, ha due assi principali
Lo Z80 non ha una cache delle istruzioni. Ogni singola istruzione costa parecchio (rispetto a un i386 e successivi, dove le istruzioni eseguite molte volte all’interno di un piccolo ciclo sono molto più veloci). Un codice Z80 veloce è un codice che ha meno istruzioni eseguite per byte scritto. Di conseguenza, una regola d’oro per l’ottimizzazione del codice Z80 è: rimuovere tutte le istruzioni che non scrivono byte a destinazione. Rimuovere (srotolare) i cicli. È sorprendente quanto si possa eliminare spingendo questo approccio all’estremo. È stato proprio esplorando queste idee fino in fondo che sono riuscito a scrivere Sunny Day (for A Shadow Party) :: pouët.net
Strategia estrema di compromesso memoria-vs-CPU. Normalmente, il CPC non ha abbastanza memoria per spingere questa strategia al limite. Ma se hai una ROM esterna grande quanto vuoi, puoi andare ancora oltre. Dettagli qui sotto.
Dettagli
Esaminando i pixel del video fotogramma per fotogramma, si nota che le auto vengono disegnate con granularità a livello di byte. La larghezza si estende a sinistra e a destra a salti di due pixel. Quando uno di questi pixel non serve, è grigio. Invisibile sulle sezioni grigie della strada, visibile altrove. Questo consente routine di disegno più semplici e veloci: basta scrivere i byte, niente maschere né manipolazione di singoli bit.
Ciononostante, serve una routine di disegno estremamente veloce. Si applica la regola d’oro citata sopra.
Se l’auto non si muove verso l’alto o verso il basso (in particolare l’auto del giocatore), la routine è ancora più semplice e veloce.- Spingere queste scelte a livelli estremi, qualunque sia il costo in termini di spazio di archiviazione. Ecco perché funziona solo con una cartuccia ROM. Servono aree (di sola lettura) enormi.
Le enormi auto che ruotano nella schermata di selezione sono una semplice compressione delta. La maggior parte dei pixel non cambia e i cambiamenti sono noti in anticipo, il che rende il tutto velocissimo. Quando hai tantissimi byte di ROM a disposizione, fai semplicemente così. Di nuovo, una cosa simile c’era in Sunny Day (for A Shadow Party) :: pouët.net, dove il set di byte effettivamente scritti è n volte più piccolo di quanto sembri (se non ricordo male n=6).- Tutti gli elementi animati sono disegnati tramite «grafica-come-codice». Il disegno non richiama una routine generica «disegna qualcosa» a cui vengono passati dei dati specifici di quel «qualcosa». Piuttosto, «disegnare qualcosa» significa richiamare una routine specializzata (ad es. una routine per ciascuna auto in ogni orientamento specifico, una routine per ciascun oggetto a ogni distanza). Le routine sono codice Z80 pre-generato, concettualmente semplicissimo: scrive solo byte, niente cicli, niente di niente. (La tecnica non è nuova, è stata usata in diverse produzioni. Io l’ho fatto per le chicche delle transizioni di livello in Just Get 9).
- Un chiaro indizio della strategia «una volta dato per scontato di avere una ROM enorme, va bene avere esigenze di ROM enormi» è il numero di viste di ogni oggetto. Nel video gli autori parlano di oltre 5000 sprite. Quando hai un’infinità di byte e puoi generare migliaia di sprite con il rendering di un modello 3D di un’auto, fallo e basta. Il risultato è una resa delle posizioni 3D delle auto sulla strada incredibilmente fluida e piacevole.
Questo suppongo si applichi anche al disegno della strada. Avere un elenco sterminato di routine specializzate che si limitano a disegnare una sezione orizzontale della strada completamente finita. Si chiama la routine corretta per ogni riga. Sarà più veloce del già rapido Chase HQ, che disegna sezioni grezze e poi rifinisce le strisce bianche delle corsie. Naturalmente è più complesso di un pattern ripetitivo come in Sub Hunter, eppure quel gioco dimostra che enormi porzioni dello schermo possono essere animate fluidamente limitandosi a scrivere (usando l’istruzione push) i byte.- C’è anche il doppio buffer, ma non per l’intero schermo. Uno schermo intero in overscan corrisponde a 24k di byte utili. Con impostazioni specifiche del CRTC e forse qualche divisione dello schermo (screen split), quei 24k possono essere «compattati» (lasciando il resto della memoria non troppo frammentato). Due buffer significano 48k. Rimane comunque un’area intera scambiabile di 16k per il bank switching. Fai il bank switching di un’infinità di pagine per accedere alla ROM fisica nella cartuccia. Persino il codice può essere replicato nelle ROM.
E… non sono sicuro al 100% che questo copra tutto. Forse (probabilmente) ci sono altri segreti.
3 Mi Piace
Grazie mille per le tue parole!
1 Mi Piace
Un’analisi interessante, non dirò se sia accurata o meno!
Ma ho una domanda… In questo genere di giochi, la larghezza della strada è di solito molto maggiore rispetto a quella dello schermo visibile, dato che la strada si sposta quando ci si muove lateralmente. Le routine che proponi, che disegnano ciascuna linea orizzontale, eseguono il rendering solo dell’area visibile? Se sì, quante routine sarebbero necessarie per ogni linea orizzontale per ottenere lo scrolling orizzontale al singolo pixel? Grazie!
È qualcosa di assolutamente sbalorditivo. Semplicemente incredibile!
Congratulazioni a tutto il team per questo sviluppo fenomenale.
Ci saranno discussioni future su alcune delle tecniche utilizzate nel gioco?
1 Mi Piace
Quando ho saputo che il gioco avrebbe utilizzato migliaia di sprite pre-renderizzati memorizzati su ROM, sapevo che avrebbe avuto una fluidità di scaling e rotazione superiore a qualsiasi cosa fosse mai stata tentata prima e, vedendolo finalmente in movimento, non delude affatto. Il CPC è capace di cose straordinarie se gli si affianca una gran quantità di memoria, ma serve un sacco di lavoro per sfruttarla a dovere.
Ciò che mi ha davvero colpito è la cura e l’attenzione dedicate al frontend, ai menu, ecc. Questa è una parte dello sviluppo di un videogioco che richiede molto tempo e non è sempre divertente, eppure qui sembra tutto rifinito al massimo, con un design coerente che lega insieme ogni elemento.
Con una tale mole di impegno possiamo solo sperare che il gameplay sia all’altezza della grafica. Vedo parecchie auto a schermo contemporaneamente, il che è promettente: non hanno certo lesinato sulle vetture avversarie.
4 Mi Piace
Beh, tu, il mago del codice del Batman Group, fai una domanda di programmazione a me? Deve esserci sotto un trucco. 
E in effetti non ho fatto alcun calcolo, ed è anche per questo che ho scritto strategicamente «un fantastilione di byte», il che lascia una gradita «indeterminatezza».
Ok, fammi pensare e provo a rispondere alla tua domanda. Avere routine dedicate che scrivono un’intera linea di strada per ogni caso possibile sarebbe semplice (tempo costante, scrittura di 80 o persino 96 byte in overscan completo), ma richiederebbe un numero spropositato di routine. Un modo per ridurlo potrebbe essere fare il PUSH dei byte del colore del terreno da destra, poi chiamare routine dedicate per disegnare la strada vera e propria, e infine fare un altro PUSH di altri byte del colore del terreno. Questo modello limita in qualche modo il numero di combinazioni, ma non può disegnare quando la strada esce dai bordi dello schermo a sinistra o a destra. Mmmh, c’è un’ulteriore opzione che limita ancora il numero di routine, mantenendo al contempo una velocità complessiva elevata. Che ne dici di una tabella a cascata su due livelli: per una data geometria di linea, cerchi un elenco di routine più brevi e le chiami. Queste hanno valori di byte precalcolati per disegnare tutti i pixel e il loro numero è nettamente inferiore. Questo coprirebbe anche le situazioni in cui la linea della strada esce dallo schermo sia a sinistra che a destra, senza calcoli a runtime. Ci ho azzeccato, @Rhino ?
(attenzione, battuta in arrivo 
) Colpo di scena: nel corso degli anni i teaser di Vespertino erano finti, gli autori chiedevano alla gente sul forum e raccoglievano le risposte nel tempo fino all’arrivo di un’IA abbastanza potente a cui dare in pasto le risposte per farsi fare il lavoro vero. 
Scherzo! 
Per tornare seri: complimenti a tutto il team per questa produzione impressionante!
Dopo tutto questo tempo e tutti questi teaser, non vedo l’ora di vedere e giocare finalmente a Vespertino!
1 Mi Piace