MoonshadoW 2 work in progress

[Raffox]

Dipende da quanta memoria hai a disposizione. Sono abbastanza certo che Paolo abbia scelto di utilizzare caratteri ridefiniti hires per ottimizzare lo spazio, senza dover ricorrere alla mappa colori necessaria per una multicolor. In effetti in una conversazioe, a suo tempo, mi aveva raccontato che durante lo sviluppo del gioco lo spazio in memoria era finito e doveva fare i salti mortali per farci entrare qualcosa...

[Darkerror]

Sí ho notato... molte volte, nel codice, ci sono salti a routines, magari piccole, collocate nei posti piú disparati...
Purtroppo al momento non so quanta memoria libera ho (non è ancora finito) ma grazie allo sprite-flipping e ottimizzazione dello spazio (tra $0000 e $3FFF) dovrei riuscire ad avere un po di spazio in piú...
Ohaaaaa che onore parlare con lui...
Ho letto che dal '90 non avete piú avuto contatti.... peccato...
Cmq, magari già sta notte, inseriró il diario...  (contiene molti aspetti tecnici proprio su Moonshadow)

[Darkerror]

Diario di settembre 2018
16.09.2018

mi sta tornando la voglia di programmare (dopo 2 giorni un pò giù di corda)
questa mattina ho provato a modificare la routine irq dello status oggetti:
ho messo 2 pixel di puntatore oggetti in centro in un irq
subito dopo 7 sprite che custodiscono gli oggetti in un altro irq
e poi un altro irq per disegnare altri 2 pixel dell'indicatore centrale nello status...
praticamente nel bordo superiore ho ottenuto 3 raster irq perfettamente stabili.
l'idea era di far scorrere 7 oggetti verso dx e/o sx
il motivo di tutto sto casino? semplice: non mi piace come viene gestito il passaggio da un oggetto all'altro.
per ora swappa solo i frame degli sprite... sì ok, puoi portare fino a 9 oggetti, però non mi ispira... sembra molto confusionario
sono quindi tornato al primio sistema ma credo che userò quello originale... il puntatore che si sposta è molto più immediato...
 la mia intenzione era avere più oggetti da trasportare in un sistema immediatamente comprensibile...


Provando un paio di assestamenti ho scoperto che posso usare il banco c000 ffff (tanto il Vic II vede solo ram)
senza grossi problemi e quindi sto valutando se è il caso di ripartire da quasi 0 e
spostare tutto da 4000 a c000... avrei molta più memoria per il codice...
vedremo...
ieri ho finito lo status sotto e devo dire che ne sono proprio compiaciuto...
è mooolto simile all originale ma uso meno memoria... tutto in $0000...
sto ora valutando il colore delle stelle... mi piacerebbe lt grey ma dovrei usare il monocolore... al momento invece sto

usando il multicolor perchè ci sarà il cuore che batte e dovrebbe essere a caratteri... non so ancora...
il problema è che bianco è troppo forte... troppo intenso
vediamo... ok beh... lt grey è bello... ma forse bianco sa meglio
devo provare a metterci le lune... mi ero arenato proprio lì... stavo disegnando le lune per ottenere un'eclissi più bella,
 animata, ma il risultato non mi piaceva molto...


sto nuovamente provando a modificare il sistema di gestione status oggetti in alto...
voglio provare a mettere 5 oggetti in fila e, non so come, oscurarne metà a dx e a sx...


ok è notte ma ho finito di spostare tutto a c000... il problema grosso è che non posso caricare tutta la memoria...
dovrei usare exomizer tutte le volte... troppo casino... cmq ho risolto lo

stesso:carico c000 dfff normale, e000 efff in runtime, copio in runtime da a000 in d000 dfff.
in $a000 metterò poi roba da decomprimere in runtime...

ho capito ora che prima devo fare il gioco uguale e poi migliorarlo...

17.09.2018

sto provando soluzioni per gli oggetti in alto... effetti sonori come tomb raider, credo userò 5 sprite,
status centrale in due irq distinti e disegnato in runtime,
e 2 sprite che coprono metà del n 1 e del n 5...
il tutto che scorre... non swappa

questa mattina ho studiato anche una nuova routine per stampare i blocchi nelle stanze...
la mia, al momento, è tre volte più lenta dell'originale... (è nata come prova per fare moltiplicazioni... :-) )

ok, tutto a posto ma non mi piace... lo sprite del puntatore è troppo bislungo... sembra mongolo...
ora proverò a costruire uno sprite espanso perchè proprio non ho intenzione di usarne 2...
quello che non mi piace molto è che arriva a filo dell'area di gioco
(in realtà scende fino alla prima riga ma, essendo vuota, non sembra)
il fatto di essere in Italia e non in Germania mi priva di avere un c64 vero sottomano per testarlo...
temo che tutto sia ok  solo sull'emulatore...
se visualizzato su di un crt credo che la parte alta del puntatore scomparirà
costringendo il giocatore a regolare il monitor... cosa abberrante quanto castrante...

(stavo valutando l'idea di acquistare un c64dtv o un the c64 mini solo per testare il tutto...
ma ho i miei dubbi che siano ambedue davvero fedeli all'originale sotto questo aspetto:
in poche parole collegarli ad un monitor crt)

ho anche lavorato un po su un decompressore di dati in runtime
(mi servirà per modificare sprite e set di caratteri durante il gioco)...
 beh... devo ammettere che è complicato... però... troverò un sistema piccolo e funzionale...

 
ok... stautus up: provato ad espandere.... una schifezza indicibile...
ok... due possibilità:

            - la prima è... disegnare lo sprite puntatore in runtime sopra a quello dell'oggetto
                ma non posso far ciclare i colori,devo sfruttare il multicolor e ciclare quello...
            - la seconda è... tornare al sistema di Galimberti... ovvero 6 oggetti, puntatore e busto guy...

 
( la cosa che pocanzi ho detto di aver capito... mi sa che non l'ho capita tanto bene...)

vabbè... mi concentro sul cuore...
entro questa notte voglio avere un bel cuore pulsante... sullo schermo ovviamente... il mio pulsa già abbastanza...
sto seriamente pensando di usare 3 sprite... in overlay...

ok... il primo frame del cuore è fatto... davvero bello mi pace molto

19.09.2018


il cuore è a posto, batte bene e posso regolare il tempo del battito
(indispensabile perchè quando il pugnale si avvicina il cuore deve battere più in fretta)

20.09.2018

pochissimo tempo e tanto stress
ho comunque ridisegnato gli sprite del cuore contratto... ora è più bello e verosimile...
sto pensando di aggiornare il sito su Lycos e aggiungere questo diario...


21.09.2018

per come si svilupperà il gioco, con le nuove idee che ho avuto questa notte, è fondamentale avere più di 6 oggetti al seguito...
per lo più sarà indispensabile avere più pozioni di energia... e

serviranno, credetemi che serviranno... altrimenti sarà tutto troppo frustrante...

ho modificato gli sprite della luna e anche quelli del puntatore status oggetti...
devo ammettere che l'ambiente di sviluppo "C64Studio" è davvero fenomenale... lo sprite editor è molto versatile...

ok... ho fatto la registrazione su Altervista.. così potrò pubblicare questo diario più eventuali screeshot e magari anche beta test download...

22.23.09.2018

sto lavorando come un pazzo su sto fatto dello status in alto...
ci sono vicino ma non è affatto semplice...
anzi... direi che è un vero casino...
non demordo ma... mamma mia...
ho finalmente scoperto perchè Paolo Galimberti ha deciso di lasciare la prima riga di caratteri vuota...
 il motivo è che lo sprite delle gambe del guy sfarfallano se la y è troppo vicina allo status...

sto pensando seriamente di metterci sì uno sprite sopra agli oggetti: da $03 a $1d... ma sotto niente sprite...
 usare due caratteri e dargli lo stesso colore dello sprite puntatore...
ci sono riuscito... status ok... nessun farfallio.... tutto perfetto... ma non mi piace

24.09.2018

ora sto lavorando ad una routine per far scorrere gli oggetti a dx e sx
sì... sta venendo bene... comincia a piacermi... lo scrolling è buono e devo dire che il tutto sembra anche leggero
(il movimento sta in irq).... devo però spostare i puntatori in alto nel banco 0000-0fff... così posso usarne 2

ho pensato ora... devo ricordarmi di ritagliare un po di spazio anche per gli easter eggs... ovviamente non li troverete nel diario...


25.09.2018

dopo vari tentativi mi son deciso a riscrivere la routine di movimento ex-novo e cercare di troppi non sprecare puntatori in 0 page...
tutto nuovo e sembra funzionare meglio... ma... accidenti che lavoro...
il mio problema più grande è che scrivo il codice di getto... senza pianificare su carta a priori

26.09.2018

come al solito la mia mente vaneggia... progetti futuri? primo moonshadow 3 ma con un nome diverso.
secondo nosferatu the vampier ma fatto meglio... terzo... una bella avventura punta e clicca in

stile maniac mansion...
vabbè... andiamo avanti...
allora... algoritmo per oggetti status in alto finito... ora lo scrivo e vediamo che succede.
ok problemi risolti... tutto funziona bene...
 ma ora ho il classico maledetto problema dell'MSB
riscritto molte cose e snellito il codice...
rimane ancora il problema msb... potrei saltarlo se stringessi gli oggetti entro $ff ma non mi piacciono tutti ammassati...
facciamo così: se non sono proprio pirla ci riesco... se mi arrendo... beh... allora sono un po pirlotto!!!
sono legato all'interrupt perchè così non ho rallentamenti di sorta... benchè fuori sia più veloce...
ma temo che penalizzerà qualcosa che ancora non ho scritto...
 però devo fare i conti con i cicli... altrimenti esco fuori dal rastertime...
(forse è più facile del previsto: se muovo solo l'ultimo sprite a sx e dx ma senza uscire da $ff... )

[Darkerror]

Diario di ottobre 2018

08.10.2018

Dopo una piccola vacanza trascorsa 24h su 24 con mia moglie e mia figlia, rieccomi qui...
piano piano ci sto riuscendo... lo status oggetti comincia a piacermi... mi ero perso in un bicchiere d'acqua...

ok il movimento è buono... gli oggetti scorrono e scompaiono bene...
ora però devo modificare la velocità: 1 pixel per frame di movimento è davvero pochino...
voglio che lo scorrimento parta piano,
poi accelleri di brutto,
 per poi decellerare e fermarsi...
così non si hanno tempi di attesa molto lunghi ma si capisce che scrolla e non swappa...
spero di finire entro questa notte così domani potrò dedicarmi allo swap delle stanze...
ok, tutto perfetto... ora è il momento dell'aggiornamento frame oggetti e colori in buffer...
sono stanco... lo faccio domani mattina...
sarò quindi in ritardo di un giorno su... tutto il tempo che voglio... kein problem...

09.10.2018
funziona tutto perfetto... solo ho notato ora un piccolo flicker se gli sprite oggetto sono pieni...
 devo forse abbassare un po tutto...
(ho notato che anche nell'originale, se si ha lo scudo tra gli oggetti,
nell'angolo in alto a sinistra gli sprite degli uccelli che volano
 si mischiano spesso e volentieri allo sprite dello scudo)

tutto a posto... è sera tardi ma comincio già a studiare le stanze


11.10.2018

ho studiato molto...
 ma alla fine...
 devo ammettere che la routine che ha scritto lui è davvero bellissima e velocissima...
potrei accellerarla un po ma comporterebbe un notevole lavoro...

magari ci ritornerò sopra... non so... per ora sto continuando a disassemblarla...
non è facile poichè è tutto nidificato...
per scrivere la mia routine ci ho messo 35 minuti...
non so lui quanto ci abbia impiegato però davvero complimenti...
quasi quasi allego qui sotto le due routine...
così potete vedere il grado di nidificazione che ha usato... davvero bello...

ho notato anche che i colori dei blocchi sono salvati in memoria...
io avevo pensato di usare il numero del blocco per ricavare il colore risparmiandomi memoria:
in pratica... se i blocchi da 0 a 9 compongono l'erba...
significa che tutti i blocchi da 0 a 9 devono avere colore verde... per esempio.
ci sarebbero un paio di limitazioni o quanto meno un paio di blocchi ripetuti...
non so ancora... vedremo poi...

ho pensato che siccome uso gli stessi indirizzi di memoria per la mappa,
per i blocchi e pure per la grafica...
mi conviene usare la sua routine completa...
cambiano solo un paio di variabili..

nulla di più...
lavoro in meno...
bene bene

ho finito ora di importare la routine... funziona egregiamente...
ancora complimenti a Paolo Galimberti...


12.10.2018

ho appena scaricato bluegrifon per creare pagine web...
nei prossimi giorni costruirò il sito e lo metterò online...
sono stanco... vado a dormire... sono però soddisfatto...
domani inizioerò la routine per muoversi dentro le varie stanze.




P.S.: questa era la mia routine per stampare le stanze:

jsr stampa_blocchi_stanza
;------------------------------------------------------------- rout stampa stanza ------------

; indirizzo : 4427 in $21 + $22
; pure in $23 e $24
print_room:
 lda #$27; chr_vid_lo ; $27
 sta $21
 sta $23
 lda #$f4;chr_vid_hi ;$44
 sta $22
 sta $24
 lda #$01
 sta $28
; mem colore
lda #$27
sta $30
lda #$d8
sta $31

lda #$01
sta $32 ; colore corrente

lda #$01
sta $33
lda #$80
sta $34


;warte:



;stampa 4 blocchi in verticale

;lda $27 ; diventa 1 o 0 in interrupt

;bne warte
lda #$01
sta $26
sta $44 ;<--------   flag per irq si o no diventa =1 se deve stampare sprite neri... =0 quando finito di stampare la stanza


lda #$82
sta $50
lda #$19
sta $52

;---------  routine moltiplicazione:
; moltiplica $50 ( numero blocco da $a200 ) per 25 e trova quale blocco iniziare a leggere...
; salva il risultato in a + y ------ deve poi finire in $33 + $34

lda #$00

sta $56 ;<----- lobyte della moltip

lda #$00
sta $57 ;<----- hibyte della moltip

 clc
ldx $52

lopuno:
clc
lda $56
adc $50 ;era 50
sta $56
lda $57
adc #$00
sta $57
dex
bne lopuno


;-------------------------- fine moltiplicaz
 


;-------- aggiunge moltip a base blk

clc
lda $33
adc $56
sta $33
lda $34
adc $57
sta $34

;--------------------------------------
ciclo_x:

              lda #$01
              sta $25 ; contatore di blocchi y
              ;sta $26 ; carattere da stampare

        qui_x:

                    ldx #$05 ; 04 = quattro caratteri in y

              qui_y:
                    ldy #$05 ; 05 = cinque caratteri x
 
                    ;lda $26 ; per ora é un carattere
                   
                    qui:
                         
                          clc
                         
                          lda ($33),y
                          sta ($21),y
                          lda $32 ; colore
                         
                          sta ($30),y
                         
                          dey
                bne qui
                   
                clc
                      lda $21
                      adc #$28
                      sta $21
                     
                      sta $30
                     
                      lda $22
                      adc #$00
                      sta $22
                      clc
                      lda $33   
                      adc #$05
                      sta $33
                      lda $34
                      adc #$00
                      sta $34
                      clc
                      ;-----------mem colore
                     
                      ;lda $30
                      ;adc #$28
                      ;sta $30
                      lda $22
                      adc #$94
                      sta $31
                      clc
                   
                   dex
                 
            bne qui_y

 inc $32
          inc $26

          inc $25
          lda $25
          cmp #$05 ; 5 = 4 blocchi vert -------- 6=5 blocchi vert
    bne qui_x

;fine stampa 4 blocchi verticale
      clc
      lda $23
      adc #$05
      sta $23
     
      lda $24
      adc #$00
      sta $24
      clc
lda $23
sta $21
sta $30
lda $24
sta $22
adc #$94
sta $31
clc
                   
inc $28
lda $28
cmp #$09
bne ciclo_x

lda #$00
sta $44

 ; ----------------------------------------------------             fine stampa stanza
rts




 funziona tutto alla perfezione...
ho rimappato la memoria colore e le prove di salto tra una stanza e l'altra
(come quando si usa la sfera) funzionano a meraviglia.
ho provato a ficcare tutta la routine in interrupt e far disegnare la stanza ogni frame ma,
purtroppo, è troppo lunga e troppo macchinosa esco fuori di moltissimo dal rastertime...
forse... non sono ancora sicuro, userò il sistema che avevo escogitato inizialmente:
 riempire di sprite (neri pieni espansi in x e y) tutto lo schermo in modo da nascondere la stampa dei blocchi...
e rimuoverli una volta finito e raggiunto l'inizio del nuovo frame
tutto questo perchè non posso usare il blank screen, i bordi sono aperti,
quindi si vedrebbe lo status in alto sparire per un po...

ora stavo lavorando alla gestione dei tasti e del joystick... tanto per distrarmi un po...


13.10.2018

 dopo le stanze... problema che credevo moooolto complicato,
 mi trovo faccia a faccia con i movimenti del personaggio... lo scoglio forse più grande...
ho perso molto tempo (praticamente tutto ieri e parte di questa mattina) a studiare lo storyboard...
questo perchè dovevo aver ben chiaro in mente come risolvere i problemi che si porranno in seguito e,
 soprattutto, come passare da un mondo (livello) all'altro.
 In Moonshadow non ho particolarmente apprezzato il cambio di set caratteri e multicolor...
è davvero fastidioso tra la foresta e la grotta...
però non mi attira l'idea di usare sempre il teletrasporto...
a meno che non sia contemplato nello storyboard...
in altre parole: se per passare dalla foresta al castello bisogna solo varcare una porta...
beh...
il flicker è ovviamente palese e di pessimo gusto...
così come nauseante risulterebbe l'uso smoderato del teletrasporto.

Se invece per accedere, bisogna scavalcare qualcosa di invalicabile...
beh...
allora il teletrasporto è d'obbligo (quindi flickerless).

lo storyboard mi è servito soprattutto per la fine...
credo sarà una cosa che strapperà qualche lacrima ai più attempati giocatori di c64...
abbandonando per un secondo l'argomento, questa mattina ho notato che gli effetti sonori sono integrati nella musica...
quindi non dovrei usare altro spazio... purtroppo sono zero assoluto in programmazione di musiche ed sfx...
imparerò alla fine...

mamma mia che casino...
la routine che ha scritto mi è quasi incomprensibile...
complicatissima...troppi reindirizzamenti... sto impazzendo a sbrogliare la matassa...
è tutto annidato...
forse in sorgente era ok... ma così... è un incubo...
quasi quasi mi scrivo una routine ex novo...
ho contato più di venti tra puntatori e variabili...
solo per andare a sx...
senza contare salti, collisioni e irq...

ok ho deciso: ne scrivo una tutta mia...


14.10.2018

sto scrivendo la routine del joystick... a dir la verità credo che, usando lo stesso principio,
 arriverò a scrivere più o meno la stessa routine... ma almeno è farina del mio sacco...
giochi tipo vardan o gng non mi piacciono molto a causa del pessimo sistema di controllo...
 mentre altri tipo creatures e moonshadow hanno un sistema splendido...
in gng bisogna sempre premere il tasto fuoco per sparare,
in moonshadow spari di continuo tenendo premuto e,
ciò nonstante, accetta altri movimenti...

ok è tutto a posto...
ora ho un puntatore che rispecchia esattamente lo stato del joystick con combinazioni multiple...
è il momento di mettere su video i due sprite e farli muovere.
in irq odio l'indirizzamento indiretto indicizzato...
preferisco valori in pagina 0 presi direttamente come creatures...


15.10.2018


ok il movimento dello sprite rispecchia il joystick alla perfezione...
 ora vorrei attivare i frame in modo da testarne i movimenti prima di mettermi a programmare le collisioni...
nel pensare questo mi è venuto in mente lo sprite mirroring (usato in impossible mission credo)...
non sarebbe male, risparmierei un sacco di memoria usando una lookup table unica di conversione
potrei dargli in pasto tutti gli spirte dei nemici oltre che del protagonista...
(a proposito... non so ancora il nome... stavo pensando a Tal/lus...chissà come ci sono arrivato...)
il tutto in runtime... (ho notato che rispetto al raster irq, ho ancora un sacco di tempo ove la cpu non fa nulla...)
ora provo a scrivere la routine e la lookup table... vediamo che succede...


16.10.2018

ok la lookup table era abbastanza complicata ma l'ho finita...
tutta la routine funziona egregiamente...
ora devo provare in realtime se è utilizzabile o meno...
questa notte ho avuto un problema enorme...
in c64studio, per fare delle prove sui byte degli sprite ho caricato il banco e000...
quando ho chiuso mi ha salvato le modifiche e da lì in poi i primi 4 irq non funzionavano più...
(cioè... funzionavano ma risultava tutto nero senza sprite... nulla)
stavo nel frattempo scrivendo la routine di mirroring e sono impazzito a cercare l'errore...
alla fine il problema era il file incluso e000 corrotto...
non così grave...
ma ho perso un sacco di tempo...
la routine non è poi male...
non uso pagina 0 e per girare 33 sprite in realtime il tempo impiegato non è proprio tanto

ora provo a modificare e usare la pagina 0...
vediamo la differenza...

senza pagina 0 è di poco più veloce... quindi niente pagina 0
(indirizzamento assoluto contro indiretto)

peccherò di presunzione ma non capisco perschè non ha usato lo sprite mirroring...
avrebbe potuto sbatterci dentro un sacco di nemici in più...

ho avuto ora un'idea per riempire lo spazio lasciato vacante dallo score (eliminato in questa mia versione)

ricaricando i simboli presenti sui bordi del poster originale,
 quelli costituenti la protezione anti pirateria,
potrei far in modo che si debba completare una frase per poter sbloccare la porta di

accesso al nipote del serpentone... hahahahahahahahahah

ho notato che tramite il RLE potrei mettere le mappe compresse in memoria
 e arrivare quindi ad un'area di gioco decisamente più grande anche di quanto fin'ora ipotizzato...
non so se riuscirò ad implementare tutte queste cose insieme,
però... beh... chi vivrà vedrà...
fino ad ora sono soddisfatto.
non dimentichiamoci che ora il nostro barbarello può trasportare da 0 ad oltre 254 oggetti...

questo Tallus è decisamente un mulo da traino...
 io già lo vedo scorazzare felice per la foresta con 256 scudi sulla testa...


avevo già notato prima ma non mi ero soffermato più di un tot...
a scapito della memoria ha preferito risparmiare sul codice
(ha sprecato ben 2 sprite vuoti solo per la morte)

sono a buon punto e lo sprite mirroring in realtime funziona alla perfezione...
ho finalmente capito perchè l'animazione del personaggio ha un frame fuori dal coro:
o l'aveva dimenticato o l'ha disegnato in un secondo momento...
fatto stà che quel frame è stato aggiunto e non poteva concatenarlo ai precedenti
poichè avrebbe dovuto riscrivere tutti i puntatori ai frame di sparo,
di abbassarsi ecc.
bisogna tener conto che stiamo parlando delle locazioni da c000 in avanti...
quindi per testarlo ecc bisognava usare sempre exomizer o simili...

ok animazione perfetta... quasi...
mi manca ancora msb e un piccolo dettaglio appena comincia la corsa


17.10.2018

dettaglio inizio corsa sistemato... ora passo all'msb

ok msb risolto... non sono soddisfatto al 100% ma funziona...
dovrò forse apportare qualche modifica (quasi sicuramente)
ora che Tallus si muove posso passare alla gestione delle stanze in funzione del personaggio...
in Moonshadow non vi è alcun clipping...
io invece credo dovrò aggiungerlo...
per clipping intendo che si può uscire dall'area di gioco
(come mostrato in un piccolo video su Youtube che ho caricato anni fa...)


18.10.2018

ci ho impiegato una vita ma ora ho un sistema stabile di gestione delle interazioni stanze-personaggio...
è stato davvero complicato gestire sto maledetto/benedetto MSB...
il problema grosso è stato che non potevo usare l'oldschool 2*x,
 volevo assolutamente un movimento sì da due pixel ma in cui Tallus potesse anche trovarsi in una posizione di mezzo...
ora mi metto a cercare la lookup table del salto...
ok la lookup table del salto non mi serve...
a dire il vero non so neppure se c'è...
faccio a modo mio...
ma più tardi...
ora mi son ricordato che devo spostare la gestione dello status oggetti
e
la gestione del battito perchè al momento sono disattivate...


19.10.2018

ora funziona tutto nuovamente: il cuore batte e lo status oggetti lavora alla grande
sto scrivendo le routine di gestione delle collisioni tra Tallus e background.
il primo passo è già ok: ho la colonna del carattere sotto ai piedi... in mezzo
ora lavoro sulla riga...
wowwwwww ho notato ora una piccola imperfezione nella posizione raster in alto...
devo correggerla subito.

risolto... ma ho notato che in alto mi son dimenticato l'msb di Tallus...
beh...
non avrei potuto farlo prima poichè Tallus non esisteva ancora...
risolto anche msb in alto
ok anche la y (riga) è perfetta.... flickerless

mmmmmmmmm....
devo creare una lookup table con gli indirizzi iniziali delle row...
necessariamente
fatto... tutto ok... ricaviamo il chr sotto i piedi...
che bello... devo giocare con gli accessi alla ram/rom
che palle... ho risolto ma non sono soddisfatto...
non mi piace interrompere gli irq per leggere la ram...


20.10.2018

ho controllato un pò e ho notato che devo necessariamente sostituire
 tutti i valori della gestione movimenti con variabili...
poi ho avuto altri impegni...


21.10.2018

non ho avuto voglia di far nulla...
 ma ho letto molto su Ready64, csdb, lemon ecc.


22.10.2018

sto riprendendo in mano le routine dei movimenti...
 devo modificarle parecchio...
ho bisogno di molti più puntatori per ottenere una gestione 100% sicura...
sarà un lavoraccio... posso dire quindi che,
se anche tutto funziona, sono a metà dell'opera...
sto riscrivendo le routine dei movimenti tutte da zero...
mi sono soffermato a pensare... e...
ho constatato che è ovvio che non riuscivo ad arrivare ad un dunque:
Lui ha usato delle macro per gestire i movimenti...
tutti insieme...
nemici,
personaggio principale,
sparo,
spari nemici...
ovvio che era complicato disassemblare...
non ho usato Regenerator... non ci ho proprio pensato...
forse sarebbe sato più semplice... vabbè... ormai...
tanto peggio per me...


23.10.2018

tra ieri sera e questa mattina ho finito la routine per le scritte negli sprite.
funziona davvero bene... mi piace molto...
 ha bisogno ancora di un paio di ritocchini ma è già molto bella...
Nell'originale non mi piaceva molto poichè era troppo veloce e si faticava a leggere...
mi sarebbe piaciuto molto usare 7 sprite in reverse (per coprire tutta l'area)
anzichè 6 positivi
 e usare 4 o 6 rasterbar per colorare l'interno delle scritte
ma non ho molta volgia di impazzire con $ff più o meno uno ecc...
forse più avanti lo implementerò, non è difficile, ma per ora sono già soddisfatto così...
non so esattamente come ha fatto Paolo Galimberti a scrivere la sua
 (non l'ho nè controllata nè decompilata);
come base ho usato una routine scritta da Testicle e presente su Codebase64...
ok la routine è finita completamente: ho usato 7 sprite espansi,
 ha righe raster multicolori stabili e non rallenta per niente... (per ora)
stavo pensando però di estrapolare la routine dall'irq e
attivarla solo ad ogni frame update... non so... vedremo


24.10.2018

mi rimetto al lavoro sulle routine di gestione del movimento...
 questo mi porterà via moooolto tempo, però è la base della giocabilità...
ho spostato la routine collisione piedi con chr all'interno dell irq perchè mi dava problemi...
 come detto..
SEI CLI no mi piacciono fuori dall'irq...
appunto...
 con un chr andava bene...
 con 6 risulta troppo lento... quindi sfarfallii


25.10.2018

è tutto il giorno che penso alle ottimizzazioni da apportare...
è complicato...
 vedremo se potrò usare rle per i livelli...
 è difficile...
 forse potrò usare la compressione solo per il font caratteri e per la definizione dei blocchi..
 ho studiato un sistema per passare da un mondo all'altro senza glitch...
ok... ottimizzato il banco 0000-3fff....
ho guadagnato moooolto spazio....
 riallocato gli sprite scrolling text....
 ora ho  spazio per il font completo...
ok ci sono... uso il multicolor nello status sotto...
così posso creare gli sprite oggetto e arma solo con i caratteri...


26.10.2018

sto trasformando gli sprite delle armi in caratteri...
potò ovviare al problema di cui soffriva l'originale:
i colori degli oggetti non erano giusti poichè il multicolor era diverso...
ho introdotto una nuova arma presa direttamente da Antiriad...
lanciare pergamene mi è sempre sembrata una minchiata...
forse introdurrò, al posto della pergamena, lo scudo come in g'n'g...
volevo provare a vedere quanto è veloce una routine per copiare lo sprite selezionalo in alto
e convertirlo in caratteri nello status sotto.
nix
uff... l'idea era buona... ma purtroppo devo desistere...
non posso disegnare i caratteri esattamente in mezzo allo status...
(cioè... anzichè 3x3 dovrei usarne 4x4)
pensando e ripensando ho così notato, per la prima volta,
 che nello status sotto è riportato l'oggetto correntemente in uso...
questo è però del tutto inutile poichè l'oggetto corrente
è già evidenziato in alto dal puntatore...
ciò significa che non ci sarà più l'oggetto nello status sotto...
cmq stesso discorso vale per le armi... userò uno sprite...
ormai lo spazio scarseggia nel banco 000-3fff...


27.10.2018

ok... purtroppo non posso usare RLE perchè, dopo la compressione,
ho un consumo di memoria maggiore...
credo che userò exomizer...
e per il titolo (che deve decomprimersi nella zona dello scrolling text)
scriverò una routine fissa con una tabella contenente i dati delgli sprite del titolo in RLE nativo creato ad hoc...
le armi continueranno ad essere sprite (consumo meno spazio)
 e per i relativi frames ricopierò direttamente dalla memoria degli sprite nel gioco un frame alla volta.
come detto prima non ci sarà più alcuno sprite oggetto...
 e userò i caratteri rimanenti per disegnare barre energetiche animate o cose simili...
magari le fiamme per il titolo...
è credo il miglior compromesso...
stavo anche studiando un modo per comprimere (della metà) i dati dei colori dei blocchi...
devo vedere come si comporta exomizer...
al momento sto lavorando un po alla realizzazione delle pagine da caricare sul sito...


28.10.2018

ho costruito il sito (con NVU) e l'ho messo online questa notte...
su Ready64 ho effettuato la registrazione e postato il link...
ho scelto come webhosting il sito "byethost16.com" per la totale assenza di banner e popup...
facendo tesoro dei vari commenti letti in giro, mi sono imbattuto in una affermazione particolare:
 la mappa di gioco è davvero ostica...
bhe... effettivamente non è proprio chiarissima...
 devo ammetterlo...
sto valutando di crearne una leggermente più comprensibile...

30.10.2018

Un paio di giorni di pausa per caricare il sito, testarlo, correggere gli errori (non sono un esperto di html)...
ora è a posto...
Con mia grande gioia Roberto Nicoletti, Webmaster di Ready64,
è propenso ad ospitare il gioco una volta terminato...
Questo mi ha dato una spinta in più nel cercare di terminarlo...

credo che entro oggi mi rimetterò al lavoro... sulla routine del movimento:
l'ho scansata il più possibile... ma ora... mi tocca...
questo succede perchè sono insicuro e, a causa di altri problemi,
sono troppo stressato e manco di lucidità...
quasi quasi proverò il sistema Jeff Minter...
...chi se ne frega se quando si spinge il joystick a destra Tallus va in alto...
giusto?...
cmq ho pensato che tra la foresta e il castello userò la stanza neutra di passaggio
(ove cambiare font, mappa e blocchi in runtime)
mentre per passare da forseta o castello a grotta userò il teletrasporto...
stavo pensando che magari sarebbe bello se l'ultima stanza,
ove uccidere il mostruoso mostro, fosse in scrolling parallattico
tipo Flimbo's Quest...
vedremo... non so se ci starà tutto... e non voglio usare il multiload...
Fin da bambino l'ho odiato...
versione su cassetta impossibile,
su disco... noioso,
su cartuccia... beh... non ho nozioni sufficienti per una cosa del genere...
quindi... single load...
ho riscritto il diagramma della routine movimenti... è la prima volta che non scrivo di getto...
spero di non aver dimenticato nulla...

[Darkerror]

Diario di novembre 2018

02.11.2018

un po di distrazione... leggendo un po Ready64 mi sono fatto coinvolgere dalle avventure testuali,
ne ho provate un paio sullo smartphone e devo dire che mi intrigano parecchio...
certo ci vuole mooolto tempo per studiare una storia che regga tutto un gioco...
però non è male... ci si diverte moltissimo...
ho trovato una enorme difficoltà nell'interazione con il computer...

il parser molte volte mi faceva salire il nervoso: "non conosco questo termine"... "i can't understand" e così via...

l'unico parser che mi è piaciuto abbastanza, senza arrivare allo scumm,
è quello dell'avventura Atlantide - Sipe 1986...

così ho perso un po di tempo per analizzare il listato basic...
(era compresso e rilocato... forse era stato scritto su un c128)
non è complicato,
con un uso maggiore di assembly si possono tirare fuori cose interessanti...
ma credo che sia un altro genere di avventura (credo si cataloghi: scelta multipla)... boh...
però mi piace...
con un parser così, fai quello che devi fare,
non ti incasini la testa parlando come uno straniero: uso chiave su porta...
e hai più tempo per concentrarti sulla trama...

ho giocato un po a soulless...
l'ho giocato solo per vedere con che velocità stampava le stanze...
ma funziona su un principio differente...
qui sotto c'è un pezzetto della routine che stampa i blocchi:

.C:43ff   A2 00      LDX #$00
.C:4401   BD 08 5B   LDA $5B08,X
.C:4404   9D 47 CE   STA $CE47,X
.C:4407   BD E7 60   LDA $60E7,X
.C:440a   9D 47 DA   STA $DA47,X
.C:440d   E8         INX
.C:440e   E4 06      CPX $06
.C:4410   D0 EF      BNE $4401
.C:4412   C6 08      DEC $08

mettendo un break a 4412 e controllando con icu si vede chiaramente
che la stanza viene disegnata non a blocchi consecutivi ma

bensì ad elementi, ovvero stampa mattone dopo mattone, è sicuramente una buona idea,
ma credo che il contro sia la scarsa varietà dei fondali...
forse ha risparmiato un po sulla memoria...
non so... non ho controllato (e neppure mi interessa)
cmq lo schermo viene oscurato ( all'indirizzo $3fac lda #$0b)
infatti si hà quel triste effetto retrò (anche lo status sotto scompare)
se dopo, a 3fae mettiano 3 nop sostituendo sta $d011,
si vede che la stanza viene disegnata...
e la velocità sembra uguale a Moonshadow se non inferiore...
quindi mi ritengo soddisfatto...e, soprattutto, mega complimenti a Paolo Galimberti...

il paragone con Soulless è pazzesco:

Moonshadow 1990 - Soulless 2012
                Odyn    -    Endurion




significa che proprio non si poteva fare più di così... o forse si... boh...

una cosa mi ha però impressionato di Soulless.....
il titolo...
è bellissimo il modo in cui ha ottenuto i colori dentro ai caratteri del titolo...
probabilmente lo utilizzerò per riempire la scritta MoonshadoW
oppure solo per l'interno del numero 2...

Dopo uno scambio di opinioni con Raffox,
ho deciso di provare ad implementare nello status sotto,
l'effetto shining che avevo pensato...
ci sto lavorando...
ma non sono molto soddisfatto... non so...
dovrei forse ritornare al monocromatico...
mi serve uno sprite in più... uffa....

quindi devo usare assolutamente 16 caratteri per disegnare lo sprite dell'arma
(ricreato dallo sprite nel gioco)
vabbè...
fatto: uso solo 12 caratteri per disegnare lo sprite...
 e risulta centrato...

[Darkerror]

Ho controllato bene... mi rimangio tutto quello che ho detto su Soulless... poi spiegheró il perchè
Peró rimane comunque un lasso di 22 anni...

[Raffox]

Novità? :D
Ti ho inviato un pm

[Darkerror]

Diario    Novembre  2018
 

03.11.2018


ho eliminato il loading del file e33.01, quindi anche la routine del load (più spazio libero)
Scrivendo con Raffox ho programmato la prima bozza dell'effetto illuminazione nel pannello di status...
non è male, ma probabilmente ci tornerò sopra dato che, con ogni probabilità, i caratteri hires lasceranno spazio ad
una ben più colorita e versatile immagine Bitmap
non so come farò con i caratteri che disegnano l'arma in uso, non so se dovrò cambiare banco dato che avevo previsto di usare
la memoria video base per il titolo, per le scritte a video durante il gioco ecc...
vedremo...
per ora cerco di proseguire con i movimenti...


04.11.2018

riscrivendo la routine dei movimenti ho notato che non posso usare lo sprite-flipping per Tallus,
 il carico di lavoro è troppo oneroso per la cpu, perdo un intero frame...
per ora proseguo normalmente, poi, una volta terminato vedrò se riuscirò a suddividere la routine di flipping e inserirla
...magari...
nell'interrupt...
ok, dx e sx il movimento è pressochè perfetto...
ho riscritto tutto ed ora ho i risultati desiderati...
la routine è forse un po più complessa (incasinata) di quella originale, ma funziona...
ora funziona con puntatori e lavora in priorità sulle gambe.... è anche già predisposta per accettare variabili come
is_falling, is_jumping, ecc.
anche le collisioni sembrano lavorare bene... sono felice...un po di rammarico per il flipping ma cmq felice...
anche il riconoscimento del tasto fuoco è a posto... e ormai è passata la mezzanotte...

05.11.2018

continuo a ripensare a Soulless... ho detto una sciocchezza:
l'area di gioco è maggiore (il pannello inferiore è più piccolo rispetto a Moonshadow)
quindi credo che la velocità sia uguale... però il sistema è molto furbo e pratico... non me la sento di modificare
nuovamente la routine, le mappe, tutto... però... probabilmente donerebbe spazio prezioso...

cmq è geniale questo sistema... mi rimangio quello che ho detto: si possono ottenere ambienti decisamente vari ed interessanti...
molto più versatile del sistema a blocchi fissi...
Endurion è Endurion

07.11.2018

ho lavorato tutto ieri sugli interrupt... ora sono ad un punto in cui, forse, posso utilizzare lo sprite-flipping, ma per ora è

disabilitato, lo proverò una volta che la gestione dei movimenti sarà completa e i nemici saranno sullo schermo...
questo perchè dovrò cambiare nuovamente tutti i puntatori agli sprite...
finita la routine abbassarsi: è ok... funziona bene e i due sprite non si distaccano durante lo spostamento...
sono ora alla metà della routine del salto... funziona bene... per ora...
sono stanco però... sono già le due del mattino...

08.11.2018

il salto dritto funziona egregiamente...
anche le collis funzionano (per ora solo su salto dritto verso il basso)
mi sa che ho riscritto la stessa routine perchè ho lo stesso errore:
se salto e poi premo verso il basso le gambe sono ok
(perchè ho modificato lo spirte) ma il busto è più in su di 8 pixel...


09.11.2018

per scongiurare tutti gli errori possibili sto aggiungendo un sacco di variabili...
lo sapevo che sarebbe stato un lavoraccio...
mi sa che ho risolto anche il problema di quando salti mentre sei abbassato...
proseguo ora con la routine di caduta (se gli togliamo il pavimento da sotto i piedi, per esempio)
cambio di programma...al momento ho continuato con la gestione delle stanze...
ora swappa bene anche in alto (non era ancora implementata)...
appena finito la gestione della caduta saprò se anche la routine stanza_giu funziona a dovere...
però sono davvero soddisfatto... ho ottenuto, fin'ora, delle routine davvero stabili...
ed il gioco comincia dalla locazione giusta...non più dalla stanza numero 1...

è diventato tutto un casino...
devo rilocare di nuovo tutto nel banco 4000-7fff uffaaaa......
ho finito ora di rilocare parte delle memorie e dei puntatori...
 le stanze funzionano di nuovo... ma ho problemi coi colori


10.11.2018

sono le 18:28... ho finito ora di spostare tutto a $4000
ora posso rimettermi al lavoro sulle collisioni con i caratteri...
mi spiego meglio:
la soluzione che avevo adottato prevedeva la memoria video a $f400
e per leggere il carattere sotto ai piedi di Tallus,
 per verificare le collisioni,
dovevo necessariamente mettere la routine di estrapolazione del carattere in interrupt.

questo perchè
il Kernal doveva essere disabilitato quindi, durante l'irq,
 potevo leggere il carattere senza rallentamenti dovuti ad un SEI...
tutto questo spostamento ha una spiegazione mooooolto semplice:
 non sono capace di costruire una catena di irq con il Kernal disattivato.
quindi,
 avendo necessità di estrapolare il carattere sotto i piedi più e più volte in funzione della y di Tallus,
 va da sè che una sola lettura durante l'irq non era sufficiente.
ecco il motivo vero della rilocazione!

userò il banco 0 ($c000-$ff00) come archivio e per decomprimere sprite e stanze...
 se ci riesco...
ho appena finito di riscrivere le routine di estrapolazione carattere sotto i piedi...
 le divisioni erano sbagliate... MSB

riguardo i caratteri che costituiscono collisione, nell'originale, ho notato che sono in ordine sparso:
uno qua e uno là... non so perchè... io farò diverso... ovvero:
lascierò i primi 128 caratteri senza valore, da 127 a 191 per creare i pavimenti e da 191 a 255 per i muri...
così un semplice bcc o bcs mi alleggeriscono dall'uso di un'altra lookup-table...
ovviamente questi valori sono a titolo indicativo... giusto per chiarire il concetto...
so che, eventualmente, farci un trainer diventa incredibilmente facile:
 basta cambiare un valore e Tallus può agevolmente passare attraverso i muri...
ma non è destinato alla vendita... ;-)


12.11.2018

ho avuto troppi problemi da risolvere (non inerenti il gioco) e quindi mi sono dovuto astenere da Moonshadow 2...
spero di avere adesso un po di tempo per andare avanti.


13.11.2018

ho finito la routine che visualizza l'oggetto selezionato , all'interno del pannello sotto
non sono soddisfatto ma cmq va già bene...


15.11.2018

ho avuto davvero poco tempo a disposizione...
 proseguo a singhiozzo...
e questo non mi piace ma purtroppo non posso fare null'altro...
ok finalmente le routine di caduta in corsa e normale sono terminate...
 (manca solo controllo collisioni con muri)
ora lavoro sul salto diagonale...


16.11.2018

uffaaaaa mi sa che è meglio se ricomincio da capo...non sono per nulla soddisfatto...
credo che mollerò lì per il momento...
devo creare un paio di programmi per modificare i caratteri nei blocchi...
(mi serve per le collisioni: pavimento, muri, ecc)


17.11.2018

 il programma l'ho scritto e funziona anche bene... ma credo che non mi servirà...
mi sto creando uno screenmaster su pc.. poichè è troppo lungo creare blocchi e mappe su c64


18.11.2018

ok, ricostruire uno screenmaster non serve... la versione 2 di charpad è ottimale...
ho importato tutto e da qui riesco a fare quello che devo...
ho una visione chiara dei blocchi e devo ammettere che ce ne sono diversi inutilizzati.
per disegnare le mappe di gioco userò screenmaster originale ma con alcune modifiche: aggiungerò un tasto "c" per ciclare i colori

dei blocchi (ora esiste un blocco uguale ma con colore diversro) e un tasto "b" per cambiare il blocco on the fly...

per rispetto credo che eliminerò la statua del gargoyle blu...
penso che a Paolo Galimberti sia costata molta fatica e credo sia una cosa davvero sua personale...
(gli ha dedicato ben 3 blocchi e più di 40 caratteri)

tirando le somme:
caratteri vuoti = 50
blocchi liberi = 73


19.11.2018

sto lavorando alla conversione del set di caratteri e alla rilocazione dei blocchi con il programmino che mi sono scritto...
liberato tutto... e raggruppato i caratteri divisi tra solidi (ove camminare) e null (background)


20.11.2018

volevo provare a disegnare un blocco e vedere come sta... tombe e croci son venute abbastanza bene... però ho notato che potrei

modificare il multicolor per la stanza durante la sua creazione ottenendo così una gamma maggiore di colori...
ho provato solo a sostituire il rosa con il grigio medio... è bello... ma non ovunque...


21.11.2018

dovrò modificare lo status in alto.. ci sono troppi difetti che non mi piacciono per niente...
altro lavoraccio... ma guadagno 3 sprite e due caratteri... magari dovrei mettere 6 oggetti... boh vediamo...


23.11.2018

ho commesso un grosso errore nel calcolo delle collisioni col pavimento mentre corre
e per risolverlo,
sto riscrivendo dall'inizio la routine di caduta...
mooooolto laborioso....


25.11.2018

sto riscrivendo la routine di estrapolazione row (riga sotto piedi)

ho finito ma non sono ancora convinto... la routine di salto però ora è perfetta...


26.11.2018

sono ad un ottimo punto... funziona quasi tutto perfettamente...
credo che caricherò le routine di rilevamento column and row su Ready64 nella rubrica "pillole di programmazione"
poichè le ritengo davvero veloci e precise...
(ovviamente, prima, qualche esperto dovrà valutarne la qualità)
tutto perfetto... salto, salto diagonale, caduta, tutto perfetto...
sono soddisfatto..
mi rimane solo da sistemare il frame dello sprite...

c'è stato un momento di disperazione in cui avrei voluto abbandonare tutto... davvero...
poi ho deciso di riscrivere tutto dall'inizio e le cose piano piano funzionavano..

ora ho ottenuto una gestione dei movimenti (collisioni comprese) migliori dell'originale... sono soddisfatto...


27.11.2018

oggi inizierò, forse, a costruire le routine dei nemici...
popolamento stanze, tipo nemico ecc...
questo sarà abbastanza semplice come lavoro...
la cosa che mi porterà via molto tempo credo sarà la gestione dello sparo...
però sono così contento di ciò che ho ottenuto fino ad ora...
ho bisogno di ordine...
ora pulirò il codice dalle routine inutilizzate,
poi sistemerò le collisioni con i muri (ancora assenti)
poi devo scrivere la routine dello sparo
e solo dopo potrò iniziare coi nemici porte e oggetti...
-ok... ora è moooolto più pulito...
-ok... ora funziona anche la collisione muri....
comincio ad essere stanco...
troppi problemi da risolvere (non inerenti il gioco)...
testa piena...
uffa


28.11.2018

devo rimodificare il set di caratteri per ovviare al problema delle scale
(non ci si può saltare sopra in diagonale altrimenti si rimane bloccati)
piano piano sta prendendo la forma che desideravo da sempre...
le collisioni sono giuste...
finalmente....
il rischio di rimanere imbrigliati dentro le pietre non esiste più...

(OFFTOPIC: credo che l'idea originale fosse che Tallus dovesse essere sprovvisto di armi all'inizio, per poi trovare il pugnale

solo nella terza stanza in cima alle scale... non so perchè sia stato modificato ma sono certo che dovesse essere così...
ho visto da tempo lo sprite del pugnale ma solo più avanti ho capito dove doveva essere posizionato...
probabilmente, dato il placcato raffigurante Tallus con la spada presente nella confezione,
 un pugnale, non fosse esattamente un gran chè da trovare;
cmq posterò più tardi un paio di foto )


29.11.2018

ho provato a reimplementare lo spriteflipping ma i rallentamenti, ora,
son fin troppo evidenti... niente spriteflipping in realtime...

Qui il link all'ultima versione... giusto per testare movimenti e collisioni

http://darkerror.byethost16.com/00_cade_1_perfekt.prg

[tsm_carmine]

A proposito di IRQ con Kernal disattivato, probabilmente hai già risolto oppure il problema non era questo, ma basta mettere il salvataggio dei registri all'ingresso, il recupero all'uscita e ricordarsi che la CPU salterà a $FF48 ogni volta.

Il Kernal fa:

Codice: [Seleziona]

.,FF48 48       PHA             save A
.,FF49 8A       TXA             copy X
.,FF4A 48       PHA             save X
.,FF4B 98       TYA             copy Y
.,FF4C 48       PHA             save Y
(omissis: controllo del flag BRK e salto al vettore relativo)
.,FF58 6C 14 03 JMP ($0314)     do IRQ vector (iIRQ)
E all'uscita:

Codice: [Seleziona]

.,EA81 68       PLA             pull Y
.,EA82 A8       TAY             restore Y
.,EA83 68       PLA             pull X
.,EA84 AA       TAX             restore X
.,EA85 68       PLA             restore A
.,EA86 40       RTI

[Darkerror]

Wow... grazie.. non sapevo che saltasse sempre lí... durante le prove (e strascichi di queste sono ancora presenti nel codice) avevo scritto le serie di pha che richiamavo all'ingresso e in uscita... ma saltava sempre in posti diversi per poi piantarsi con un jam...
Ora so il perchè: il set di caratteri andava a scrivere su quelle locazioni...stupido errore mio data l'incompetenza....
Grazie ancora per la delucidazione... giuro che se non me lo avessi spiegato, non credo sarei mai riuscito a capire il perchè andava sempre in jam...

[tsm_carmine]

Figurati, il bello è che ho sbagliato pure io 

la CPU salta in realtà all'indirizzo contenuto in $FFFE / $FFFF, che col Kernal attivato è $FF48, altrimenti può essere qualsiasi cosa.

[Roberto]

Diario    Novembre  2018

credo che caricherò le routine di rilevamento column and row su Ready64 nella rubrica "pillole di programmazione"

Se vuoi inserire una "pillola" puoi creare un thread apposito e poi segnalarlo alla redazione 

[teppaboy]

Bene, bene, Moonshadow insieme a Montezuma sono sempre stati i miei gioci preferit! Spero che tu riesca in questa impresa di fare un seguito di MS :-)
Se ti serve una mano, ti posso dare qualche consiglio....

Wanax

[Darkerror]

Buon natale a tutti

[Oighen]

Dato che stavo "monitorando" questo progetto da attento osservatore, riporto ciò che Darkerror ha aggiornato sul forum di Lemon64 nel topic di questo progetto:

Hi all,
Sorry but i've lot of work to do... no more freetime for this project...
From 02.2019 i'm back in Germany...
I think in September i'll find more time for moonshadow2...

Thx

Per ora pare che il progetto sia sospeso per mancanza di tempo, con la speranza che in Settembre possa essere ripreso.

Riporto anche qui per completezza (e perchè forse altri, come me, si erano chiesti il motivo della mancanza di aggiornamenti nel 2019).