Può l’AI aiutare a costruire nuovi mondi tridimensionali sulle macchine Commodore a 8 bit? 3Dvibe64 nasce da questa domanda: un percorso dal wireframe al Gouraud shading e al texture mapping, fino a una pipeline 2.5D pensata anche per il C=64 stock e adattata a C=128, Plus/4, VIC-20 e PET. Un racconto di esperimenti, compromessi e ottimizzazioni, in cui le possibilità dell’AI si misurano con i limiti concreti dell’hardware.
Lavorando con l’AI generativa soprattutto nello sviluppo web e nel vibe coding applicato all’editoria digitale, ci siamo accorti presto che solo in una parte limitata dei casi serve davvero ricorrere ai modelli più potenti. Le loro capacità diventano preziose nella progettazione, nell’analisi di un’architettura o davanti a problemi particolarmente ostici; per molte attività quotidiane bastano modelli più leggeri ed economici. Da questa esperienza è nata la curiosità di portarli su un terreno diverso, lontano dai linguaggi e dai framework che dominano lo sviluppo contemporaneo. Qualcosa di più esotico, presumibilmente meno presente nei dati di addestramento: scrivere un renderer 3D per il Commodore 64.
L’obiettivo iniziale era realizzare della grafica 3D poligonale solida, facendo comparire sullo schermo oggetti tridimensionali con superfici riempite. I primi risultati hanno incoraggiato ad alzare progressivamente l’asticella. Il progetto si è allargato a pipeline di rendering sempre più avanzate, costruite attorno all’architettura del C=64 e considerando, almeno nella prima fase, un’espansione SuperCPU come limite dell’accelerazione. Ogni risultato apriva una possibilità ulteriore: migliorare l’illuminazione, rendere più leggibili i volumi, sperimentare un trattamento diverso delle superfici.
La strada è stata piuttosto accidentata. Si passava da immagini veloci e piene di errori a rendering più corretti, la cui lentezza spegneva buona parte dell’entusiasmo. Sistemare un difetto poteva rendere troppo costosa una routine; alleggerire un calcolo faceva riapparire un problema in un’altra inquadratura. Il ricorso ai modelli di AI più capaci, concedendo maggiore spazio al ragionamento e alla ricerca di soluzioni, ha permesso di trovare compromessi accettabili fra qualità e prestazioni. Sono aumentati anche i costi in token, naturalmente. Del resto, chi frequenta il retrocomputing conosce bene la facilità con cui una curiosità tecnica può trasformarsi in un hobby impegnativo per il portafoglio.
Il C=64 stock ha presto imposto un limite evidente. Con la CPU a circa 1 MHz, le modalità più elaborate diventavano difficili da conciliare con una velocità soddisfacente. Perché continuare, allora, fino al Gouraud shading e al texture mapping in tempo reale? Una ragione decisiva è stata l’esistenza del Commodore 64 Ultimate, che porta ufficialmente questa storica piattaforma fino a 64 MHz. Una disponibilità di calcolo molto diversa da quella del biscottone originale, sufficiente a dare un senso concreto alla ricerca sulle pipeline più ambiziose.
L’interesse di questa accelerazione sta anche nel rapporto con il sistema video. Aumentano i cicli di CPU disponibili per trasformare, illuminare e disegnare le scene, mentre la grafica continua a confrontarsi con le caratteristiche del VIC-II. Colori, organizzazione dell’immagine e modalità di disegno conservano quindi una precisa identità Commodore. La frequenza superiore allarga il margine di manovra, lasciando intatta la necessità di pensare il renderer attorno all’hardware.
È nato così 3Dvibe64, un engine scalabile rispetto alla potenza di calcolo disponibile e incorniciata nella dotazione originale dei 64k ram. La sua impostazione permette di definire mesh, una camera, una sorgente luminosa, materiali e processi di shading compatibili con la resa del VIC-II. Chi prepara una scena può scegliere il tipo di immagine che desidera ottenere e costruire i contenuti in funzione della macchina di destinazione. Le configurazioni leggere mantengono un interesse per il C=64 storico; quelle più impegnative trovano soprattutto nelle macchine accelerate lo spazio necessario per esprimersi.
L’engine può essere utilizzato per realizzare demo oppure come componente grafica di giochi 3D. La scelta della pipeline diventa quindi parte del progetto, insieme alla complessità dei modelli e dell’ambiente. Un trattamento più sofisticato delle superfici comporta un costo aggiuntivo, che deve trovare una giustificazione nell’effetto visivo cercato. Il wireframe, la grafica solida e il Gouraud rispondono a esigenze differenti: ciascuno offre una propria estetica e un diverso equilibrio fra leggibilità, dettaglio e velocità.
Come detto, questa libertà deve fare i conti con i 64 KB di RAM. All’interno di quello spazio devono convivere codice, dati della scena e strutture necessarie al rendering. È un vincolo che influenza tanto l’implementazione quanto la costruzione dei contenuti: ogni scelta deve trovare una collocazione nella memoria disponibile e un costo sostenibile durante l’esecuzione.
Qui emerge una differenza importante rispetto a molte produzioni della demoscene. Una demo costruita attorno a un singolo effetto o a una sequenza prestabilita può sfruttare conoscenze molto precise su ciò che apparirà sullo schermo. Sapere in anticipo quali oggetti saranno visibili e quali movimenti compirà la camera permette di spingere la specializzazione molto avanti. Un engine destinato a scene e mondi interattivi deve conservare margine per configurazioni differenti e per inquadrature decise durante la navigazione.
Il builder di 3Dvibe64 prepara automaticamente una versione del renderer specializzata in base alla scena e alla modalità selezionate. Una parte del lavoro viene quindi svolta in anticipo sul computer moderno: vengono scelti i percorsi di rendering necessari, generate le tabelle utili, organizzati i dati e predisposto il codice che sarà poi eseguito dal Commodore 64. In questo modo il 6510 può concentrarsi sulle operazioni realmente necessarie durante il rendering. L’SDK deve comunque conservare una certa flessibilità, perché deve permettere di costruire produzioni differenti, con geometrie, movimenti di camera e contenuti propri. Una demo sviluppata attorno a un singolo effetto può invece spingersi molto più avanti nella specializzazione, sfruttando conoscenze precise su ciò che comparirà sullo schermo e sulle sequenze che verranno eseguite. Per questo le prestazioni di un engine utilizzabile in contesti diversi e quelle di una demo estrema della demoscene vanno confrontate tenendo conto di obiettivi e margini di ottimizzazione differenti.
Arriviamo così a una distinzione essenziale: 3Dvibe64 si occupa della componente grafica. Il runtime è scritto in assembly per il 6510 e pensato attorno all’architettura del Commodore 64 originale. Per costruire un gioco completo occorre aggiungere le regole, le interazioni e i sistemi necessari all’esperienza desiderata. Il renderer fornisce la base per mostrare il mondo; la produzione deve stabilire che cosa accade al suo interno.
Il codice generato può essere eseguito senza ricorrere automaticamente a una CPU accelerata. È la complessità della scena a determinare se le prestazioni saranno adeguate sul C=64 storico, su una macchina con SuperCPU oppure sul C=64 Ultimate. Compatibilità e fluidità rimangono due aspetti distinti. Vedere partire una demo sul biscottone conferma una parte del risultato; valutare quanto sia piacevole osservarla o controllarla richiede una prova separata.
Mancano quindi un ambiente di costruzione e una logica di gioco pronti all’uso come quelli del celebre 3D Construction Kit. Questo restringe l’accesso ai soli esperti di assembly e di Commodore 64? Il vibe coding offre una strada anche a chi vuole sperimentare con l’assistenza dell’AI. Lo stesso approccio utilizzato per sviluppare l’engine può essere impiegato per costruire nuove demo, partendo dai file e dalle convenzioni dell’SDK.
Si può fornire all’ambiente AI, come OpenAI Codex, Google Antigravity o Claude Code, il pacchetto completo del progetto, anche attraverso uno ZIP, insieme alla documentazione e a una descrizione del risultato desiderato. Avere accesso al codice sorgente, alle configurazioni e alle risorse permette all’AI di esaminare la struttura del progetto e lavorare su formati, opzioni ed esempi effettivamente supportati. Un ambiente capace di leggere e modificare i file, compilare il codice ed eseguire test consente di applicare e verificare le modifiche direttamente sul progetto, rendendo il processo più concreto rispetto a una semplice chat che restituisce frammenti di codice.
Il pacchetto, il codice sorgente, gli esempi e la documentazione sono disponibili nel repository 3Dvibe64, da cui si possono scaricare le distribuzioni pubblicate su GitHub.
Conviene partire da una scena essenziale, verificarne il funzionamento e arricchirla progressivamente. In questo modo diventa più facile capire quale modifica abbia introdotto un difetto o aumentato il tempo di rendering. Quando la produzione assume una forma precisa, l’AI può anche proporre ottimizzazioni specifiche, sfruttando vincoli che l’engine generale deve lasciare aperti. Una scena con caratteristiche ben definite offre possibilità di specializzazione ulteriori rispetto a quelle previste dal percorso standard.
La verifica è una fase indispensabile dello sviluppo, perché il semplice fatto che il codice venga generato e compilato correttamente dice ancora poco sulla qualità del risultato finale. Bisogna controllare almeno tre aspetti distinti: che il programma funzioni, che il rendering produca immagini corrette in tutte le situazioni previste e che le prestazioni siano adeguate alla macchina di destinazione. Un errore può restare invisibile in una determinata inquadratura e comparire soltanto ruotando la camera, avvicinandosi a una parete oppure attraversando una zona particolare della scena. Allo stesso modo, una demo apparentemente corretta può diventare troppo lenta appena aumenta la complessità dell’ambiente. Per questo lo sviluppo procede attraverso cicli continui di modifica, compilazione, test, confronto delle immagini e misurazione dei tempi di esecuzione, cercando di verificare ogni cambiamento nelle stesse condizioni per capire con precisione che cosa abbia migliorato o peggiorato il risultato.
Le pipeline di rendering 3D disponibili sono:
- Mode 1: Wireframe. Disegna le mesh attraverso gli spigoli, senza riempire le superfici e lasciando visibili anche le linee nascoste. È la lettura più essenziale della geometria, con quell’aspetto a fili che appartiene all’immaginario del primo 3D domestico.
- Mode 2: Hidden-line wireframe. Mantiene il disegno a spigoli, mascherando le porzioni nascoste dalle superfici. I volumi diventano più chiari e l’immagine evita la sovrapposizione indiscriminata delle linee anteriori e posteriori.
- Mode 3: Grafica solida con shading statico. Riempie le facce, senza eseguire il calcolo dell’illuminazione dinamica delle modalità successive. Offre un aspetto nettamente poligonale e una distinzione immediata fra le superfici del modello.
- Mode 4: Flat shading dinamico. Calcola l’illuminazione per faccia, con materiali e riflettività. Ogni superficie mantiene una tonalità uniforme, mentre la risposta alla luce contribuisce alla lettura dell’orientamento e del volume.
- Mode 5: Flat shading dinamico con contorni. Riprende la pipeline della Mode 4 e aggiunge il disegno dei bordi dei poligoni. I contorni sottolineano la costruzione geometrica degli oggetti e danno all’immagine un carattere più marcato.
- Mode 6: Gouraud shading. Calcola l’illuminazione sui vertici e la interpola attraverso le superfici, con 33 livelli di shading e dithering ordinato Bayer 4×4. Lo smoothing attenua la separazione luminosa fra facce adiacenti, lasciando invariate geometria e silhouette. La morbidezza della luce aumenta, mentre il profilo esterno continua a dipendere dai poligoni del modello.
- Mode 7: Texture mapping affine. Applica texture 16×16 con campionamento nearest-neighbor, utilizzabili senza illuminazione oppure con shading flat o Gouraud. La mappatura è affine e priva di correzione prospettica: un compromesso da considerare nella preparazione delle scene, soprattutto sulle superfici viste di sbieco, dove le deformazioni possono diventare più evidenti.
Nel percorso che ha portato a questo engine, ormai orientato soprattutto al consolidamento, ai miglioramenti e alle correzioni, è rimasto un conto in sospeso con il C=64 stock. Le modalità più avanzate avevano trovato una destinazione nelle macchine accelerate, mentre il Commodore originale meritava qualcosa di altrettanto interessante da mostrare. Diverse idee, compresa una modalità “zero” dedicata, avevano prodotto risultati lontani dalle aspettative.
La svolta è arrivata osservando alcune demo ispirate a Wolfenstein 3D. Valeva la pena uscire dal perimetro del rendering realmente poligonale e tentare una pipeline 2.5D basata sul raycasting. L’obiettivo rimaneva costruire uno spazio esplorabile, accettando regole geometriche più precise per contenere il lavoro richiesto alla CPU. La forma dell’ambiente diventava parte della soluzione tecnica.
È utile precisare che la differenza non è fra raycasting e prospettiva: entrambe le tecniche possono produrre un’immagine prospettica. Il confronto, qui, è fra un renderer 3D poligonale e un raycaster 2.5D. Nel primo caso gli oggetti sono descritti da vertici e facce nello spazio tridimensionale: il motore li trasforma rispetto alla camera, li proietta sullo schermo e disegna i poligoni visibili. Questo permette di rappresentare mesh con forme, inclinazioni e orientamenti arbitrari, ma richiede più lavoro per trasformazioni, clipping e rasterizzazione.
Il raycaster 2.5D parte invece da una mappa sul piano, arricchita dove previsto da quote e aperture. Per le direzioni campionate della vista, i raggi attraversano la mappa e individuano le superfici incontrate; dalle distanze si ricavano posizione e altezza delle porzioni da disegnare, organizzate soprattutto in strisce verticali. Una distanza corretta rispetto alla direzione della camera mantiene la prospettiva coerente, evitando l’effetto “a occhio di pesce”. I vincoli geometrici rendono il problema più specializzabile: si ottiene uno spazio che appare tridimensionale, senza trasformare ogni parete come una mesh libera. Porte e rampe estendono questa rappresentazione, ma non la rendono equivalente a un mondo poligonale arbitrario. Il raycasting in generale non è limitato al 2.5D: è questa particolare architettura a esserlo.
Le prime prove utilizzavano texture molto semplici. Con l’evoluzione del progetto, la direzione visiva si è spostata verso superfici pulite, colori e contrasti capaci di richiamare l’aspetto di un engine poligonale. L’identità dei muri e dei passaggi viene affidata soprattutto alle forme, alle differenze cromatiche e alla visibilità degli spessori. La pipeline corrente lavora in bitmap multicolor a 128×144 pixel logici, con pigmenti differenti secondo l’orientamento delle pareti e un retino per il soffitto.
È nata così la Mode 8. Le mappe possono includere muri, porte, aperture con architravi e spessore e, nel percorso dedicato al multilivello, quote differenti collegate da rampe. Il movimento resta continuo, mentre la costruzione degli ambienti segue i vincoli della pipeline. Il multilivello utilizza una struttura heightfield: pavimenti e soffitti dipendono dalle celle della mappa, con raccordi inclinati nelle configurazioni supportate. La sovrapposizione libera di stanze nello stesso spazio, il cosiddetto room-over-room, rimane esclusa.
Anche all’interno della Mode 8 è stato necessario distinguere i compiti. Gli ambienti monolivello e quelli con quote differenti utilizzano due backend separati. Le scene più semplici possono così affidarsi al percorso adatto alle proprie caratteristiche, evitando di ereditare tutti i costi della gestione multilivello. Questa scelta ha avuto un peso concreto nello sviluppo: conservare un renderer specializzato per gli ambienti che lo consentono si è rivelato più efficace dell’impiego di un unico percorso generale opportunamente ridotto.
La ricerca delle prestazioni ha chiarito anche quanto conti la costruzione della mappa. Uno spazio apparentemente semplice può richiedere molto lavoro quando lo sguardo attraversa lunghe distanze o incontra numerose discontinuità. Nel multilivello, aperture e superfici successive possono aumentare gli eventi da elaborare e i profili da preparare. Gli strumenti di analisi sviluppati durante il progetto aiutano a individuare queste inquadrature e a valutarne il costo. La progettazione dell’ambiente entra così nel processo di ottimizzazione, con risultati da verificare sul percorso effettivo della demo.
I risultati hanno infine suggerito di portare questa pipeline anche su altri due 8 bit Commodore: il C=128 e il Plus/4. Entrambi hanno mostrato prestazioni migliori nelle prove in emulazione, sfruttando le rispettive possibilità di accedere in certe circostanze a frequenze superiori a quella del C=64 stock. È un’estensione interessante proprio perché richiede di adattare il lavoro alle caratteristiche di ogni macchina, conservando l’impostazione della pipeline 2.5D.
Sul C=128 con VIC-IIe si utilizzano i 2 MHz nelle porzioni del quadro compatibili con la visualizzazione. Sul Plus/4 entra in gioco il diverso rapporto fra clock della CPU e accessi video del TED. Il tempo di calcolo effettivamente disponibile dipende quindi dal funzionamento complessivo del sistema durante la demo.
Le distribuzioni dedicate sono 2.5vibe128 e 2.5vibePlus4. Nei rispettivi repository si trovano sorgenti, documentazione e demo, comprese le versioni automatiche e interattive.
La famiglia si è poi estesa al VIC-20 con 2.5vibeVic. Qui la pipeline è più essenziale: un solo livello, pareti di altezza uniforme e passaggi a tutta altezza, senza porte con architravi o rampe. È richiesta un’espansione RAM da 24 KB, con i tre blocchi da 8 KB alle aree $2000–$7FFF; il VIC-20 non espanso non è il target di queste demo. Sono disponibili due rese della stessa area fisica: monocromatica a 128×96 pixel logici, più definita, e multicolor a 64×96, con minore dettaglio orizzontale ma colori distinti. Sorgenti, PRG e documentazione bilingue sono inclusi nel repository.
Un adattamento ancora diverso è 2.5vibePet, destinato al PET 4032 con 32 KB di RAM. La vista utilizza i caratteri della ROM e i loro inversi: pareti piene e retinate distinguono gli orientamenti, mentre il pavimento puntinato separa il piano di calpestio dai volumi. La demo esplora senza interruzioni un mondo procedurale, mantenendo soltanto una finestra locale della mappa in memoria. Anche questa distribuzione include demo automatiche e interattive, sorgenti e documentazione bilingue. Le immagini mostrano l’esecuzione in VICE: non costituiscono una verifica su hardware reale.
Il porting prosegue così la stessa ricerca che ha accompagnato 3Dvibe64 fin dall’inizio: capire quali operazioni convenga preparare in anticipo, quali calcolare durante l’esecuzione e come trasformare le caratteristiche dell’hardware in scelte grafiche riconoscibili. L’AI ha fornito uno strumento per affrontare questa ricerca e percorrerla attraverso molti tentativi. Sullo schermo, però, il risultato continua a dipendere da quanto bene il codice riesca a utilizzare il tempo e la memoria del Commodore. Ed è proprio questa ostinata concretezza a rendere ancora appassionante vedere un mondo tridimensionale prendere forma su una macchina a 8 bit.
