[C64] QUOD INIT EXIT Opzioni

[saimo]

Ne sono molto contento, grazie mille

[saimo]

Ciao ragazzi,

sono in vacanza per qualche giorno, cosa che mi ha permesso di venire a salutarvi e informarvi di quanto segue...

Come indirettamente rivelato dalla discussione su MAH, ho ripreso a sviluppare i videogiochi: fermo restando quanto dicevo sopra, non ho saputo resistere e, quindi, ho successivamente rilasciato il succitato MAH e la versione 1.5 di QIE. In più, ho da poco iniziato a lavorare a QIE II: potete già dargli un'occhiata guardando questo primo video: https://www.youtube.com/watch?v=BZgkkQjeQv8 (raccomando di guardarlo in HD, per poter godere dell'aggiornamento a 50 fps) ;)

Messaggio modificato da saimo il 22 Dec 2015, 20:50

[The Ancient One]

Ciao saimo e bentornato su queste pagine!

H visto il video è sono morto dal ridere.
Il maialino "a propulsione" è simpaticissimo!!!! :-))))

[saimo]

Ciao saimo e bentornato su queste pagine!

Grazie!

H visto il video è sono morto dal ridere.
Il maialino "a propulsione" è simpaticissimo!!!! :-))))

Eh eh
La propulsione (ufficialmente denominata "fartro") era già presente anche nel primo gioco, solo che lì aveva un ruolo più marginale. Qui sarà necessaria per raggiungere parti altrimenti inaccessibili dei livelli e dipenderà dalla carica, che si otterrà raccogliendo bottiglie di Gasorade (queste due ultime cose sono ancora da implementare, per cui nel video ancora non si vedono - si vede soltanto la barra indicatrice della carica nel mezzo dell'HUD).

[saimo]

Se siete curiosi, di recente ho pubblicato una seconda anteprima video di QUOD INIT EXIT II: https://www.youtube.com/watch?v=dLiwBliI9jg&vq=hd720.
Tra non molto rilascerò una versione "minima" per cartuccia 16 kB (giusto il tempo di sfruttare al massimo i 2 kB che mi rimangono), mentre per la versione completa i tempi saranno decisamente più lunghi (spero non più di un annetto).

[saimo]

Ci siamo, il rilascio è imminente. Nel frattempo...

[saimo]

E finalmente è rilasciato!

http://www.retream.com/QUOD_INIT_EXIT_IIm



Rimanete sintonizzati per sviluppi del gioco senza restrizioni di memoria (questa è la versione "minimus" da 16 kB) ;)

[TheRuler]

Ciao SAIMO! stupendo questo QIE!
Hai mai pensato di cimentarti in un gioco basato sul basic 3.5 della serie 264? La mancanza del SID e soprattutto degli sprite dovrebbe solleticare il tuo gusto di sfida!

[saimo]

Ciao SAIMO! stupendo questo QIE!

Grazie!
Approfitto per mostrarvi un'anteprima (un po' vecchiotta ormai) di un livello per QIE IIo: https://www.youtube.com/watch?v=DhGTmhUfj04

Hai mai pensato di cimentarti in un gioco basato sul basic 3.5 della serie 264? La mancanza del SID e soprattutto degli sprite dovrebbe solleticare il tuo gusto di sfida!

Non mi interessa, mi spiace. Il C64 mi interessa perché è il computer con cui ho iniziato.
Nota a scanso di malintesi: QIE IIm è programmato interamente in assembly.

[saimo]

Oggi è stato il turno di QUOD INIT EXIT IIm: ho appena rilasciato una versione aggiornata.

Lista dei cambiamenti:
* vasche d'acqua ridisegnate;
* mappa ritoccata in alcuni punti;
* salvata un po' di memoria (che ha permesso quanto sopra);
* migliorata la documetazione.

Per i non esperti di C64, ho anche migliorato l'installer per Windows e aggiunto l'installer per AmigaOS 4.

La nuova versione è disponibile da https://retream.itch.io/quod-init-exit-iim. Chi aveva comprato il gioco direttamente dal sito RETREAM, dovrebbe già aver ricevuto un'email con il link per il download.

[saimo]

Ho pensato di augurarvi Buon Anno con la versione 1.7 di QUOD INIT EXIT. Come sempre, è gratis ;) Scaricatelo dalla sua nuova pagina su itch.io (c'è anche un installer per Windows che si occupa di tutto per chi non vuole smanettare con gli emulatori).



Changes list:
* added clock (slows everything down);
* added pill (protects from poison);
* slown down score decrease;
* recalibrated probabilities of items;
* changed Zampo and turbofart design to match the one in QIE II;
* changed randomization logic;
* randomized platforms at each restart, so that they are always different;
* added fried egg;
* added a little background animation;
* touched up / updated HUD;
* removed game over message so that, at the end, the final score remains displayed;
* sped up a bit intro/outro messages;
* adapted to newer and better framework;
* optimized.

[saimo]

Negli ultimi 10 mesi ho lavorato a MAH v2.0 (un altro gioco C64) e la cosa mi ha portato ad aggiornare anche QUOD INIT EXIT: ora ho appena sfornato la v1.8!

Ecco i link per scaricarla (gratuitamente):
* itch.io: https://retream.itch.io/quod-init-exit
* CSDb: http://csdb.dk/release/?id=159349

Per gli utenti Windows c'è anche un installer che permette di lanciare il gioco come fosse un'applicazione nativa.


CHANGELOG

1. Fixed mice appearing in the HUD (and maybe even worse things) due to beyond-boundary writes.
2. Fixed flagging of subsequent pill catches (there were actually counted up to 255, although that was not visible in the HUD after catching the poison).
3. Fixed screen initialization ($d016 was not initialized).
4. Fixed poo drop (if started when Zampo was in mid air, the poo would stop in mid air as well).
5. Changed points handling: now they start decreasing only after catching the toilet roll, but do it at twice the speed.
6. Changed pause controls: now [F1] pauses and unpauses.
7. Added return to BASIC by means of [RESTORE].
8. Touched up dawn, morning, and sunset skies graphics.
9. Touched up pill icon.
10. Shifted vertical alignment of text characters 1 line down.
11. Changed intro text.
12. Changed scrolltext.
13. Made a few optimizations (in particular, moved all the variables to the zero page).
14. Added a separate loader (based on the Covert Bitops Autoconfiguring Loader/Depacker) that loads the game more quickly from disk (the game itself is still a single file that can be loaded directly, so who uses other speed-up solutions does not need this loader).
15. Added EasyFlash version.
16. Touched up manual.

[TheRuler]

E' veramente carino e giocarlo su vero hardware è molto divertente.
Ho letto la storia delle origini del gioco, poi ci spiegherai in cosa consiste il complex joke. ;-)

[saimo]

E' veramente carino

Grazie

e giocarlo su vero hardware è molto divertente.

Concordo (esperienza che ho potuto fare per la prima volta solo qualche mese fa).

Ho letto la storia delle origini del gioco, poi ci spiegherai in cosa consiste il complex joke. ;-)

Davvero troppo lunga: ci metto tempo a raccontarla persino a voce...

[saimo]

Questa risposta è relativa a osservazioni fatte nella discussione di MAH.

Update 2, siccome sono a corto di platform ho preso anche Quid init exit 2m, in attesa dell' "o" ;-)

Ooooh, grazie mille!

I comandi sono molto ostici, o meglio, bisogna prenderci la mano coi salti visto che dalla cima del livello trovarsi in fondo a terra è un attimo. I salti sono pixel perfect! dannato ;-)

No, no, affatto: il controllo è basato su caratteri. La difficoltà che trovi è conseguenza naturale del fatto che Zampo è un personaggio che si sviluppa in orizzontale e, quindi, graficamente ha una area di contatto col terreno potenzialmente enorme (al contrario di uno sprite che sta in piedi, la cui area di contatto è facilmente identificabile). Spiego meglio.
Zampo tocca il terreno con le zampe anteriori e posteriori, che sono belle spaziate tra loro. Ora, considerando i frame in cui le zampe sono a terra (per via della sua corsa buffa "a molla", Zampo saltella e in qualche frame non tocca nulla), si possono verificare tre casi:
a) tutte le zampe toccano terra;
b) solo le zampe anteriori toccano terra;
c) solo le zampe posteriori toccano terra.
Se avessi gestito le collisioni al pixel (cosa che, peraltro, sarebbe stata molto costosa in termini di CPU), allora la soluzione sarebbe dovuta essere stata realistica (altrimenti, a che pro fare controlli al pixel?) e, quindi, considerare Zampo appoggiato al terreno solo nel caso a). Tuttavia, immagina quante volte l'occhio sarebbe rimasto ingannato a causa del fatto che lo sprite è largo e l'azione di gioco è dinamica! Allora ho adottato una soluzione più semplice: vengono controllati i due caratteri contigui che si trovano nell'area delimitata dalle zampe. In questo modo, non è troppo difficile regolarsi (basta prendere lo spazio tra le zampe come riferimento) e Zampo non cade se non quando va davvero troppo al di là del bordo - anzi, a volte tale metodo è così tollerante che si può verificare il caso in cui Zampo poggia solo su un paio di zampe, con un effetto che starebbe benissimo in una puntata di Road Runner:



(L'immagine l'avevo fornita a chi si lamentò in questa recensione, per dimostrare proprio quanto dicevo sopra).

Un altro fattore che sicuramente contribuisce alla difficoltà è il layout delle piattaforme: è fatto apposta per richiedere salti precisi (e l'uso della turbofart).

Poi, tieni presente una cosa: essendo un gioco di 1 solo livello, non potevo farlo troppo facile. QIE IIo, invece, avrà più livelli che vanno da una difficoltà ridotta a una come (o leggermente maggiore a) quella di QIE IIm.

Comunque, sì, sono stato cattivo!

Molto carino Saimo, un gioco pulitissimo!

Grazie! Era un peccato sprecare il motore di scrolling scritto per il finale di MAH (ooops, ho appena svelato un segreto?!?), utilizzandolo appunto solo per il finale. Mi è venuto spontaneo immaginarci un platformer che facesse vedere che il C64 è capace anche di fare scrolling a tutto schermo "illimitato", e persino tutto ad alta risoluzione e con abbondanza di colori.

Posso consigliarti di proporre anche questo ad hellfire64?

Un'idea non male (ma MAH è stata una sua iniziativa personale). Fammi vedere se per caso ha acquistato il gioco: se lo ha fatto, evidentemente non gli è venuta voglia di recensirlo... Sì, l'ha preso.

Un altro youtuber eccezionale è, lo conoscerai, the 8-bit guy. Penso che non solo apprezzerebbe Quod, ma del tuo MAh ne sarebbe entusiasta (e dunque ne verrebe fuori una bella vidorecensione).

Veramente fino a pochi giorni fa non lo conoscevo: poi su Lemon64 hanno linkato una sua recensione del C64 Mini e l'ho visto per la prima volta. Appena posso, provo a contattarlo.

Messaggio modificato da saimo il 2 May 2018, 10:19

[TheRuler]

Faccenda salto: capito tutto alla perfezione, immaginavo si trattasse di una scelta precisa, una volta presa la mano è facile e divertente.

Come hai creato gli sprite era difficile da capire ma una volta vista questa immagine è stato tutto più chiaro. Idea brillante. L'hai copiata da qualche altro gioco o è tutta farina tua?

Domanda sciocca, visto che hai creato 3 layer due monocromatici hires e uno multicolor low, cosa ti ha vietato di creare 4o5 layer monocromatici hires? CPU time o ram? Il VICII quanti layer supporta?

[saimo]

Come hai creato gli sprite era difficile da capire ma una volta vista questa immagine è stato tutto più chiaro. Idea brillante. L'hai copiata da qualche altro gioco o è tutta farina tua?

Entrambe le cose
La tecnica di sovrapporre sprite multipli non l'ho inventata io: è già presente in altri giochi, anche degli anni 80 e 90. Tuttavia, che io sappia, prima d'ora al massimo erano stati usati uno sprite hires e uno multicolor (e, in genere, quelli multicolor con i 2 colori condivisi per tutti gli sprite fissi - vedi in fondo), mentre in QIE, QIE IIm e soprattutto MAH sono andato ben oltre (sulla pagina di MAH ho fornito anche i dettagli).
Allo stesso tempo, posso dire che la tecnica me la sono inventata io perché da ragazzino, quando ero totalmente isolato dal resto del mondo, l'idea mi venne in totale indipendenza (ma, d'altra parte, si tratta di un'idea semplicissima). Non ero però mai riuscito a combinarci niente, e la fissa mi rimase per sempre... ed è proprio una delle cose che, nel 2007, mi ha spinto a programmare di nuovo per il C64 e a fare, quindi, QIE (che usa 4 sprite hires per ogni oggetto).

Domanda sciocca, visto che hai creato 3 layer due monocromatici hires e uno multicolor low, cosa ti ha vietato di creare 4o5 layer monocromatici hires? CPU time o ram? Il VICII quanti layer supporta?

Non è una domanda sciocca: mica è una conoscenza comune sapere quanti sprite ha un C64!
Ecco tutte le caratteristiche:
* ci sono 8 sprite (c'è un trucco per ottenere un nono sprite nel bordo a destra, ma è una cosa complicata e praticamente inutile);
* ogni sprite è totalmente indipendente dagli altri (tranne che per un aspetto riportato sotto);
* ogni sprite può assumere una qualunque posizione su schermo e oltre;
* ogni sprite può essere monocromatico (1 colore + trasparenza) hires o multicolore (3 colori + trasparenza) lowres;
* gli sprite hires hanno una risoluzione di 24x21 pixel;
* gli sprite lowres hanno una risoluzione di 12x21 pixel (ma visivamente sono larghi quanto gli sprite hires, e quindi i pixel hanno il classico aspetto "largo" 2x1);
* ogni sprite ha 1 suo colore selezionabile liberamente tra i 16 della palette;
* i 2 colori extra degli sprite multicolore sono gli stessi per tutti gli sprite (cioè, ci sono sono 2 registri per specificare i 2 colori extra di tutti gli sprite multicolore);
* ogni sprite può essere ingrandito 2x orizzontalmente e/o verticalmente;
* le collisioni tra sprite vengono segnalate in un registro apposito (è a 8 bit, e ogni bit dice semplicemente se il corrispondente sprite è coinvolto in una collisione o meno; è difficile da usare e ha utilità limitata, ma allo stesso tempo è uno strumento prezioso e, per i miei giochi, fondamentale);
* dopo che uno sprite è stato disegnato su schermo, è possibile spostarne la posizione verticale più in basso (e magari cambiarne grafica, colore e posizione orizzontale) in modo che quando lo schermo arriva a quel punto lo sprite viene ridisegnato di nuovo (l'effetto finale è che su schermo si vedono più degli 8 sprite; questo effetto si chiama "multiplexing").

In QIE IIm ho mi sono limitato a sovrapporre 3 sprite per i nemici, cibo e Gasorade perché uso anche 3 sprite per Zampo, 1 sprite per la turbofart e 1 sprite per l'HUD: quando tutti questi elementi sono allineati orizzontalmente il totale fa 8 e, quindi, non potrei chiedere di più al C64. Però faccio uso del multiplexing per mostrare su schermo contemporaneamente fino a 1 nemico, 1 oggetto da prendere, Zampo, turbofart e HUD, cioè 11 sprite (con colori totalmente indipendenti perché multiplexo anche i colori condivisi, per così dire). Anche se poi il numero di sprite disponibili fosse stato maggiore, ci sarebbe voluta più RAM per ogni oggetto (più dati = più RAM) e anche più occupazione del bus (più dati = più attività DMA = meno tempo per la CPU). Inoltre, moltiplicare gli sprite richiede anche più calcoli e un design che eviti che sulle stesse righe debbano comparire più di 8 sprite (altrimenti gli sprite iniziano a flickerare - che è una cosa orribile e giustamente poco tollerata)
In MAH, come dicevo sopra, ho spinto le cose ben oltre, per cui ci sono parti del gioco dove sono disegnati 40 sprite contemporaneamente o ci sono bestie grandi 48x42 pixel a 6 colori (tutti hires, chiaramente) che usano 13 sprite ciascuna.

[TheRuler]

Interessantissimo e molto tecnico. E' bello sapere cosa fa muovere e mettere a video tutti quei pixel.

Domanda: il c64 può ingrandire 2x sia H che V (da 24x21 a 48x42) parli dei giant patrol? sembrano low res raddoppiati e nel ref-card scrivi 4x, si intende 4 volte la superficie, giusto?

[saimo]

Domanda: il c64 può ingrandire 2x sia H che V (da 24x21 a 48x42) parli dei giant patrol? sembrano low res raddoppiati e nel ref-card scrivi 4x, si intende 4 volte la superficie, giusto?

Tutto giusto! L'effetto "giant" è l'unica cosa che sfrutta lo zoom.
A scanso di equivoci, però, le bestie 48x24 che cito nel post precedente non sono zoomate, ma sono proprio interamente hires. Quando le vedrai capirai.

[TheRuler]

Sei sul "Commodore History part 3" de "the 8 bit guy"! ;-)

[saimo]

Sei sul "Commodore History part 3" de "the 8 bit guy"! ;-)

Ah, la versione del 2012 fa un'apparizione di pochi secondi a 30:21. Grazie per la segnalazione

Visto che ci troviamo (anche se è la discussione sbagliata): poi ho seguito il tuo consiglio e gli ho proposto MAH, ma mi ha risposto che sebbene gli sembrasse interessante non aveva tempo.

[TheRuler]

E' lui ad essersi fatto la cartuccia immagino. Carina!

Sei sul "Commodore History part 3" de "the 8 bit guy"! ;-)

Ah, la versione del 2012 fa un'apparizione di pochi secondi a 30:21. Grazie per la segnalazione

Visto che ci troviamo (anche se è la discussione sbagliata): poi ho seguito il tuo consiglio e gli ho proposto MAH, ma mi ha risposto che sebbene gli sembrasse interessante non aveva tempo.

Peccato ma immagino sia vero, ha in progress diversi video hardware, difficile che faccia un gameplay solo per MAH, in riferimento alla serie "history of commodore" ha appena concluso la parte del C64. La prossima è per la serie 264.

[TheRuler]

Ciao Simone!
Ho visto l'aggiornamento per QIEIIm, purtroppo non ho una easyflash e mi dovrei limitare all'uso di VICE per giocarlo, poco male, ma il fatto che tu non l'abbia rilasciato in formato disco ha una spiegazione tecnica?

Continua così! Diciamo che di questi tempi abbiamo tutti più tempo da dedicare ai nostri hobbies, uno dei quali per me è giocare al C64 (realHW) i giochi di Saimo. ;-)

[saimo]

Ciao Simone!
Ho visto l'aggiornamento per QIEIIm,

Ah, chiedo scusa per essermi dimenticato di avvertirvi! Grazie quindi per il tuo intervento.
Approfitto per chiarire che non si tratta di un aggiornamento di QUOD INIT EXIT IIm, ma una preview di QUOD INIT EXIT IIo, il fratello maggiore, in quanto non è limitato a 16 kB come il fratellino minore (ulteriori spiegazioni sono date nella documentazione inclusa sulla cartuccia stessa).

purtroppo non ho una easyflash e mi dovrei limitare all'uso di VICE per giocarlo,

E vuoi sapere una cosa abbastanza ridicola? Sono nella tua stessa situazione

poco male, ma il fatto che tu non l'abbia rilasciato in formato disco ha una spiegazione tecnica?

Fino a un certo punto c'era anche il codice per il disco (e la cosa mi permetteva di testare il gioco su C64 reale), ma poi l'ho tolto. La ragione è che il gioco (sia IIm che IIo) nasce proprio per la cartuccia, che mi consente di sfruttare al massimo i 64 kB di RAM del C64. Infatti, a parte che il loader del disco prende un po' di quella RAM, così posso avere mappe enormi senza dovermi preoccupare dei caricamenti e ricaricamenti. Ad esempio, la versione per disco di IIm (fatta a posteriori), ogni volta che uno vuole rigiocare il livello deve attendere l'intero ricaricamento: questo perché non ci sono risorse per tenere una copia della mappa o memorizzare via facendo le modifiche fatte ad essa durante il gioco, in modo da poterle annullare e poter permettere quindi una ripartenza veloce. Col IIo, poi, ho mappe ancora più grosse...

Continua così! Diciamo che di questi tempi abbiamo tutti più tempo da dedicare ai nostri hobbies, uno dei quali per me è giocare al C64 (realHW) i giochi di Saimo. ;-)

Volendo proprio trovare un lato positivo nella tragedia, sono contento di poter contribuire.

[TheRuler]

Immaginavo, grazie per la spiega. La RAM del C64 è da sempre il vero limite. Pensa se avesse avuto sin dalla partenza, che so, 1MB. Impensabile per l'epoca ovviamente, sarebbe costato quanto un AppleII, ma programmare sarebbe stato MOOOLTO più facile, non dovendo preoccuparsi della bizzarra mappatura della memoria adottata da Commodore.
Tutto quelòlo che so l'ho imparato da the 8-bit guy, in un suo video sullo sviluppo del suo gioco "Planet X2" ha spiegato come ha imparato ad ottimizzare la ram e riuscire ad utilizzare anche la porzione di 8KB mappata dal Kernal con un trucco (peraltro l'uovo di Colombo, se tenti di scrivere su quella porzione lui butta tutto in ram), tutta roba che immagino tu saprai già.

ad ogni modo, questo è il punto (3 minuti):
https://youtu.be/NB_VBl7ut9Y?t=779

E vuoi sapere una cosa abbastanza ridicola? Sono nella tua stessa situazione