Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: ice00 - 24 Maggio 2004, 22:51:08
-
Ok, tengo il forum di Ready64 aggiornato sul minigame in corso di sviluppo: qui
http://digilander.iol.it/ice00/download/lss.zip (http://digilander.iol.it/ice00/download/lss.zip) trovate l'eseguibile in via di sviluppo che di volta in voltà aggiornerò. Il file è criptato e la password è "Ready64 è fantastico" tutto in minusolo, attaccato e senza le virgolette, così solo chi segue questo forum potrà provare il gioco prima del rilascio ufficiale e potrà proporre miglioramenti e correggere eventuali bug.
Il platform vuole essere piccolo clone di The Great Giana Syster.
Il personaggio è già disegnato e l'animazione utilizza due soli frames (in totale 4 sprite per avere il movimento a sinistra e quello a destra).
Probabilmente per risparmiare spazio il frame del salto rimarrà uno di quelli già presenti.
Ho iniziato a scrivere il codice semplicemente prendendo il sorgente di EFNY di Cadaver commentato sull'articolo "dissect" che invito tutti a leggere perché spiega nel minimo dettaglio come il gioco sia realizzato (guardate anche "scroll" perché spiega molte tecniche per realizzare lo scroll).
Ho cominciato a togliere tutto quello che penso non mi serva e cercato di ridurre al minimo le routine utilizzate per risparmiare spazio.
Al momento non mi preoccupo dello spazio (sperando che siano diponibili 8KB, ma se fossero 4KB vedrò di sacrificare qualcosa), inoltre l'eseguibile non è compresso e ottimizzato nello spazio.
La grafica di EFNY utilizza blocchi di caratteri 4x4 (32x32 pixels). Come dice Lasse, è preferibile utilizzare potenze di due, quindi blocchi 2x2, 4x4 perché si guadagna in facilità di gestione utilizzando l'aritmetica binaria (rispetto ad esempio a un 3x3 - che per la cronaca era la dimensione dei caratteri utilizzati in MArkanoid dello scorso anno).
2x2 mi sembrano troppo pochi, perché porterebbe ad avere una mappa molto grande in termini di occupazione di spazio. Probabilmente per un platform così, il meglio sarebbe caratteri 4x2, ma temo di sprecare troppo spazio per le mappe, per cui ho optato per 4x4.
Il blocco del terreno è composto da solo 2 caratteri base ripetuti sui 4x4, così come per le lance accuminate nel terreno.
Le nuvole si mangiano invece 8 caratteri (4x2), ma ho ottenuto 3 blocchi diversi per avere nuvole sul'orrizzonte ad altezze diverse.
In caso di problemi di spazio, tengo un solo tipo di nuvola e cancello 2 blocchi.
Al momento non aggiungo altri elementi decorativi (come siepi/alberi) per non occupare spazio e perché forse rileverà le collisioni tra sprite/dati se questo serve a ridurre il codice di gestione delle collisioni.
Lo schermo tiene 5 blocchi di caratteri in altezza, per cui mi rimane una linea vuota in basso per il titolo e ben 4 righe in alto per metterci il punteggio e contatori vari.
Ci sono pertanto due interrupt attivi (li vedete perché ho lasciato le lineette grigie colorate) che servono per modificare i paramentri dello scroll.
Infatti, lo scroll è ottenuto in hardware con una velocità tra 1 e 4 pixels (come spiegato nell'articolo) e spostando tutti i caratteri (ben 40*20) quando lo scroller hardware ha terminato il max scroll (8 pixels).
Questo si mangia metà raster line disponibili, anche perché bisogna spostare oltre alla grafica anche i colori.
A differenze di EFNY, ho optato per avere gli stessi colori per ogni blocco. Questo implica che si può effettuare lo scroll di 1/4 di locazioni di memoria (come spiegato in "scroll" e implementato in Metal Warrior 1).
Dato che non viene utilizzato il buffer video (perché porterebbe via troppo codice), questo riduce il codice da eseguire per fare lo scroll (che risulta parecchio comunque).
Col joystick in porta 2 potete provare lo scroll su una piccola mappa (potete volare sopra le lance, perché ancora non c'è il controllo collisioni).
Il prossimo passo è quello di aggiungere i mattoni in aria e attivare il salto.
Poi penso di mettere i diamanti da prendere come sprite e utilizzare un nemico
mono sprite ma qui devo ancora pensarci su.
Per stasera termino qui.
bye
S.T.
-
Ciao
mettendo come password
ready64èfantastico
non riesco a decomprimere il file :confused:
-
La password è propio quella e da me con unzip a riga di comando non da nessun problema.
Qualcuno lo apre?
-
neanche a me lo apre... è meglio se cambi la pwd, credo che sia la "è" a dare problemi
-
Ho tolto la "è" dalla password. Provate ora.
Altrimenti il mio zio su linux non va come da voi.
bye
S.T.
-
Non funziona nemmeno a me.
Se apro l'archivio con winace, riesco a vedere l'interno (lss.prg , credo) ma non si riesce ad estrarre niente.
Ti segnalo anche che il forum è tornato visibile a tutti, e quindi anche altri possono accedere al file (non tutti i mali vengono per nuocere).
Dobbiamo trovare un altra idea per non divulgare troppo il file :)
-
OK!! :D
senza la "è" funzia
-
Perfetto!! ;)
-
Il file è criptato (opzione -e), il che forse è diverso da essere protetto da password del tipo Winzip (opzione -P).
Se la gente che legge il forum lo scarica non c'è problema, ma se lo scarica qualcono dall'area del download del sito è meglio che non lo sappia utilizzare, altrimenti sarebbe un pò diffcile dire che il gioco non era mai stato pubblicato prima della competizione.
(qui posso dire che era per testare lo sviluppo del gioco con altri italiani)
bye
S.T.
-
Ok, tengo il forum di Ready64 aggiornato sul minigame in corso di sviluppo
Sto studiando il disassemblato e ho un paio di domande da porti visto che puo' tornarmi utile :)
Vedo che ci sono molte volte
LDA $0CA3,X
...
LDA $0C8B,X
etc ripetute piu' volte nel codice.
Usare un puntatore in pagina 0 richiederebbe un piccolo overhead per caricarlo, ma poi si ridurrebbero sia i byte di codice che i cicli impiegati, giusto? ad es
lda #$0c
sta $fc
lda #$a3
sta $fb
...
lda $fb,x
etc.
Tra l'altro mi occorre un chiarimento sulla differenza sostanziale tra lda($fb,x) e lda($fb),y ...
Il primo prende come indirizzo ($fb+($fc <<8))+X e da li' legge il valore
il secondo prende come ind. ($fb+($fc <<8)), legge il valore e somma Y
...
o e' il contrario? Spesso mi confondo
:overkiller:
-
CODE
lda #$0c
sta $fc
lda #$a3
sta $fb
...
lda $fb,x
Giusto,però occhio all'ultima istruzione.Se usi LDA $FB,X carichi solo il byte basso o alto dell'indirizzo da cui andare a prendere i dati;quel che ti interessa,invece,è caricare il contenuto delle locazioni $0ca3 in avanti.
Per ottenere l'effetto voluto,basta sostituire LDA $FB,X con LDA ($FB),Y.
Tra l'altro mi occorre un chiarimento sulla differenza sostanziale tra lda($fb,x) e lda($fb),y ...
con lda ($fb),y l'indirizzo puntato da $FB-$FC viene incrementato di y locazioni,e il contenuto dell'indirizzo ottenuto viene caricato nell'accumulatore.
con lda ($fb,x) il puntatore $FB-$FC viene incrementato di x locazioni,e il valore nell'indirizzo puntato dal vettore ottenuto viene caricato nell'accumulatore.
Esempio
nel primo caso
$FB $FC
01 08 --> y= 3 -> lda ($fb),y -> A contiene il valore in $0804
nel secondo caso
$FB $FC
01 08 --> x=3 -> lda ($fb,x) -> A contiene il valore nella locazione puntata da
$FE-$FF
Da notare che nel programma di Ice00,pur usando X come indice si ottiene un effetto analogo al primo modo di indirizzamento,poichè non viene modificato l'indice X,ma il contenuto dei vettori $82-$83 e $86-$87.
Ciauz
-
Poi volevo chiedere anch'io una cosa a Ice00 :D
Per abilitare/disabilitare gli interrupt,invece che caricare opportunamente i registri appositi, non si potrebbe sostituire il tutto con un normale SEI e CLI?
Se fosse equivalente,ci sarebbe il vantaggio di risparmio di cicli macchina e di bytes...
Buonanotte a tutti :)
-
Sto studiando il disassemblato e ho un paio di domande da porti visto che puo' tornarmi utile
Accidenti, non è necessario ricorrere al disassemblato: aggiunto il sorgente allo zip (anche se è un pò più avanti, perché comincio a mettere le routine di salto).
le LDA aaaa,x e STA aaaa,y sono le più semplici da utilizzare e finchè non c'è la necessità di ridurre il codice per problemi di spazio, preferisco rimanere sul semplice.
Del resto usando Exomixer come compressore, le tecniche di scrittura del codice cambiano parecchio:
lda #4
jsr routine
lda #5
jsr routine
routine:
xxxx
rts
può essere compresso meno di
lda #4
xxxx
lda #5
xxxx
con xxx=parecchie istruzioni
pertanto l'ottimizzazione va fatta come ultimo passo.
-
Per abilitare/disabilitare gli interrupt,invece che caricare opportunamente i registri appositi, non si potrebbe sostituire il tutto con un normale SEI e CLI?
Lo credevo anche io fino a che non mi sono imbattuto negli High score saver da installare nei miei cracks :)
Questo ad esempio e' quello che ho dovuto fare in Netherworld
SEI
jsr noirq
lda #$00
sta $d01a; blocca gli interrupt in arrivo
LDA #$37
STA $01
jsr ioin
[...]
noirq
jsr l; prima LEGGO da DCOD per liberarmi gli irq pendenti
LDA #$7F; poi blocca tutto
STA $DC0D
STA $DD0D
l LDA $DC0D
LDA $DD0D
rts
ioin
ldx #2
t lda $00,x
sta $4000,x
inx
bne t
LDX #$00
LDY #$41
sec
jsr $fd1a; prima copio i vettori correnti a $4100
jsr $fd15; poi ripristino quelli veri
rts
Non sai quante volte mi si e' bloccato prima di arrivare alla soluzione finale :)
-
Per ottenere l'effetto voluto,basta sostituire LDA $FB,X con LDA ($FB),Y.
Ah gia' ora ho notato bene la tabella degli opcode. Si puo' fare solo con Y.
nel primo caso
$FB $FC
01 08 --> y= 3 -> lda ($fb),y -> A contiene il valore in $0804
nel secondo caso
$FB $FC
01 08 --> x=3 -> lda ($fb,x) -> A contiene il valore nella locazione puntata da
$FE-$FF
Ok, ora credo di aver capito
lda ($fb),y per leggere un Array puntato da $fb/$fc e con indice Y. In effetti la uso spesso anche nei miei trainers.
lda ($fb,x) e' un array di puntatori, per selezionare un puntatore con indirizzo $fb+X e da li' andare a leggere la locazione puntata da $fb+X/$fb+X+1 .
Quindi e' bene che x sia incrementato sempre di 2 se abbiamo una serie di puntatori.
Minc*a, da usare solo se costretti :P
-
Per abilitare/disabilitare gli interrupt,invece che caricare opportunamente i registri appositi, non si potrebbe sostituire il tutto con un normale SEI e CLI?
Se fosse equivalente,ci sarebbe il vantaggio di risparmio di cicli macchina e di bytes..
SEI e CLI disattivano/riattivano le interruzioni, ma non appena le si riabilitano, tutte le interruzioni che erano avvenute durante la disabilitazione verranno eseguite subito.
Nel caso di raster interrupt, ci serve proprio avere l'interrupt a quel preciso raster, pertanto se avviene due linee dopo perché l'interrupt era disattivato, non ci serve più avere l'interruzione.
Non so se questo risponda alla domanda.
p.s. mi era morto il collegamento e la risposta era rimasta nel limbo; devo ancora guadrare il codice per Netherworld
-
Ok,grazie a IAN e Ice00 per le risposte ;)
:ciauz:
-
binary e sorgente sono ora aggiornati:
- c'è la rilevazione collisione col gli oggetti a piedi del personaggio
- c'è il salto ed eventuale ricaduta con effetto accelerazione di gravità e rallentamento
Provate a saltare sui blocchi (occhio che non c'è la rilevazione collisione con la testa, quindi saltando solo in alto sotto un blocco, si finisce sopra passandoci attraverso!
Se cadete sulle lance attualmente non morite (serve per verificare meglio il comportamento della collisione)
Dopo alcuni tentativi ho scartato la rilevazione collisione hardware perché c'era il rischio di atterrare a metà blocco ed ho inserito quella di EFNY.
Questa collisione legge il carattere sotto i piedi del personaggio e se maggiore di un valore lo considera di una collisione.
L'effetto spiacevole di questa tecnica è che devo controllare la posizione al centro dei 3 byte dello sprite, quindi se vi avvicinate troppo ai bordi, cadete senza essere arrivati alla fine.
Probabilemente il codice da apportare per verificare tutti e tre i byte non sono molti di più, ma se così non da troppi problemi lo lascio.
I caratteri dei blocchi sicuramente li cambio perché non sono troppo brutti.
Allo stato attuale, se l'eseguibile è compresso siamo sui 1,4KB.
bye
S.T.
-
Ok,l'ho scaricato.Proximamente gli dò un'occhiata ;)
-
Aggiornamento della mattina (piovosa ma vacanziera) [il file è sempre lo stesso con la solita password di sbloccaggio].
Aggiunti tutti i controlli delle collisioni anche a destra e sinistra del personaggio: ora ci si blocca tra il primo e il secondo blocco e se si salta non si riesce più a fermarsi a metà blocco come avveniva prima (provate lss2 e lss3 per vedere la differenza).
A questo punto costruisco una mappa pressoche completa, così da valutare l'occupazione di memoria e se già così senza nemici o diamanti da prendere il gioco risulta giocabile.
Per la cronaca, mi sono assicurato che Lasse mi abbia dato l'autorizzazione a riutilizzare parte del suo codice nel minigame, così da non andare contro a una delle regole.
bye
S.T.
-
Altro aggiornamento (lss4)
Adesso c'è poco più di 1/4 di mappa effettiva, in cui sono stati aggiunti i diamanti da prendere.
I diamanti sono 1 semplice carattere. Una routine di collisione ne rileva la presenza e rimpiazza il carattere con uno spazio nella mappa di memoria schermo.
Questo significa che ripartendo con la mappa per un nuovo gioco, i caratteri saranno presenti ancora.
Rimane un piccolo problema: quando il personaggio muore (supponendo di avere più vite), ci sono due alternative:
1) ripartire da inizio mappa (abbastanza frustante) e in questo caso ci sarebbero di nuovo i diamanti già presi.
Probabilmente questo sistema renderebbe il gioco un attimo più longevo
2) ripartire da dove si è arrivati. Rimane il problema di dove posizionare il personaggio nella mappa in modo che riparta da una situazione sicura
Suggerimenti?
Ho notato che può esistere ancora un caso in cui ci si può "arrampicare" a metà blocco coi salti: durante la parabola discendente di un salto.
Devo aggiugere il controllo collisione anche durante questa fase.
Il codice compattato non è aumentato di molto, il che mi porta a supporre che posso avere almeno 2 schermi più musica, ma prima devo aggiungere un pò di nemici.
bye
S.T.
-
Ciao
Ho guardato solo in parte le aggiunte di lss3.Il controllo del salto in avanti e all'indietro mi è sembrato un pò troppo difficile...potresti provare a modificare la routine del controllo del joystick,in modo che preveda la pressione contemporanea dei tasti su/sinistra su/destra ( ammesso che tu non l'abbia già fatto,come ti ho detto ho guardato solo parte delle aggiunte e non ho ancora scaricato lss4 ).
2) ripartire da dove si è arrivati. Rimane il problema di dove posizionare il personaggio nella mappa in modo che riparta da una situazione sicura
Suggerimenti?
Potresti scegliere la prima soluzione se gli schemi non sono eccessivamente lunghi e complessi.
Nel secondo caso,invece,potresti implementare una routine che posizioni lo sprite del protagonista sulla prima riga della schermata corrente e rigeneri gli sprite dei nemici più avanti ( per esempio,dalla decima riga di schermo in poi... );a questo proposito,si può implementare un contatore che scatta ogni tot righe;quando il contatore scatta,viene salvato almeno il registro degli sprite attivi ( che determina quanti nemici ci sono attualmente ) e dei puntatori agli sprite ( per sapere in che zone di memoria sono salvate le definzioni degli sprite stessi ).
Ho notato che può esistere ancora un caso in cui ci si può "arrampicare" a metà blocco coi salti: durante la parabola discendente di un salto.
Io l'ho notato anche quando lo sprite cade sulle lance e lo si fa uscire...ma è ininfluente,visto che in quel caso si muore :D
Bye :ciauz:
-
Ho notato che può esistere ancora un caso in cui ci si può "arrampicare" a metà blocco coi salti: durante la parabola discendente di un salto.
Io ho notato che fin dall'inizio se ci si gira verso sinistra e stando attaccati al bordo sx non puo' saltare piu' di tanto, come se avesse un mattone sopra la testa :)
-
Il controllo del salto in avanti e all'indietro mi è sembrato un pò troppo difficile...
Ok,ho capito dove sbagliavo:prima si preme destra/sinistra,e poi su... :stordita: comunque la routine di controllo del salto mi sembra piuttosto complessa;proverò ad esaminarla con più attenzione :mellow:
-
Io ho notato che fin dall'inizio se ci si gira verso sinistra e stando attaccati al bordo sx non puo' saltare piu' di tanto, come se avesse un mattone sopra la testa
E' vero. Forse ho tolto troppi controlli che c'erarano sull'asse x di cui mi sembravano ininfluenti. Proverò a controllare.
Ok,ho capito dove sbagliavo:prima si preme destra/sinistra,e poi su
Esatto. Corrisponde a premere DX sul joystick e quando si vuole saltare si porta a DX/UP.
-
Inserito lss5.prg
Essenzialmente adesso c'è il pannello in alto in cui si vedono gli score: c'è il tempo che decresce, le vite, i bonus e i punti.
Dato che fino a sabato non ho tempo di tornare a scrivere codice, vi chiedo se può andar bene aver messo l'high score (attualmente sempre a 0) sotto allo score.
Questo dovrebbe evitarmi di produrre uno screen apposito con l'highscore, ma non so se è troppo antiestetico.
Il prossimo step è quello di far perdere le vite e finire il livello, in modo da produrre lo schema del gioco.
Ho inserito anche lo sprite del nemico come definizione sul codice, anche se per adesso non è ancora usato.
Compresso, ora siamo sui 1,8KB.
bye
S.T.
-
può andar bene aver messo l'high score (attualmente sempre a 0) sotto allo score.
Sì,secondo me non disturba affatto l'estetica :)
Ciao
-
@Stefano:
Giusto un paio di correzioni, inezie per la verita'.
1)
jsr writeGameTitle
jsr SCREEN
E' inutile chiamare la routine di stampatitolo solo per settare il bianco, fai
lda #1
jsr $e536
e' sufficiente
2)
lda #254
and $DC0E
sta $DC0E
Basta un SEI (e ovviamente CLI quando finito di trasferire e risettato $01 a $37)
3)
.byte $00, $01, $01, $01 ; white -> BK_CLOUD blocks
metti a 1 anche il primo byte o durante lo scrolling iniziale il primo carattre della nuvola resta nero
edit: C'e' un problema con il kernel v2 (punteggi in blu) ma almeno non dovrebbe rompere come in Markanoid ;)
-
Adesso inserisco le modifiche (e io che mi chiedevo come mai nello scrolling c'era il nero sulla nuvola, tanto che avevo pensato di non utilizzare più la nuvola alta!)
Col Kernel V2 dovevo ancora provare, ma prima della fine ho tutti i kernel che mi hai dato da provare!!!
altri aggiornamenti saranno disponibili stasera
-
Col Kernel V2 dovevo ancora provare, ma prima della fine ho tutti i kernel che mi hai dato da provare!!!
Col kernel v.1 addirittura non si pone il problema perche' il cls usa sempre il bianco ;)
-
Non molto codice è stato inserito in lss6:
1) i vari bug fix + highscore lasciato dov'è
2) la routine di collisione in fase di discesa per evitare di rimanere su metà blocco. Più difficile del previsto.
Ho dovuto far indietreggiare il personaggio prima di attuare il controllo sotto i piedi, altrimenti rimaneva una minima possibilità di rimanere appesi.
3) La routine di inserimento dei nemici: viene inserito su X fisso e Y variabile a seconda della mappa.
Penso di inserire un carattere sulla mappa (carattere comunque vuoto) che indichi che ci deve essere un nemico.
Quando si inserisce i nuovi caratteri della mappa durante lo scrolling, se c'è tale carattere si inserisce il nemico con X fisso (la posizione all'estrema destra) e Y dato dalla posizione del carattere sulla mappa.
I nemici saranno quindi sempre in partenza dalla stessa posizione. Per dare un minimo di variabilità, dovrò fare in modo che il loro movimento inizi con un ritardo casuale.
Il movimento sarà destra/sinistra e cambierà direzione quando c'è una collisione durante il cammino o non c'è più terreno sotto i piedi.
bye
S.T.
-
lss7.prg: adesso c'è un nemico con relativo movimento (forse un pò troppo veloce) su un blocco (dato che i nemici sono aggiunti durante lo scrolling, il nemico si trova spostandosi a destra).
A questo punto provo ad optare per una collisione hardware sui sprite per rilevare se il personaggio devo morire o lo deve fare il mostro (perché il personaggio è in fase di salto discendente).
L'unico problema è che lo sprite principale utilizza il colore comune di background per i capelli e pertanto i due dovranno essere molto compenetrati per avere la collisione.
Vediamo come funzionerà
bye
S.T.
-
Ascolta,non puoi togliere le linee grigie generate dal raster?
-
certo, servivano solo in fase iniziale.
Ho inserito la collisione hardware e sembra funzionare bene.
L'unica cosa è che ho dovuto inserire il controllo che il nemico devo morire quando il personaggio è in fase di salto discendente, solo se la sua velocià ha un certo valore positivo, altrimenti era facilissimo ucciderlo saltando sopra ad un blocco.
Per Venerdì metto il linea quaste modifiche.
bye
S.T.
-
lss8.prg:
Come promesso i mostri adesso ci sono e funzionano.
La mappa è leggermente più lunga e alcuni mostri sono inseriti (anche più di 1 in contemporanea).
Al momento li potete uccidere ma ne siete immuni.
Per non avere effetti sgradevoli, ho dovuto fermare un mostro che stia andando a dx e raggiunge il fine schermo, aspettando che l'utente faccia avvenire lo scrolling in modo che si leggano i caratteri futuri della mappa e decidere se il movimento debba continuare a destra o cambiare.
Se il mostro arriva all'estrema sinistra (senza incontrare ostacoli) viene rimosso.
Al momento non c'è nessuna variante casuale nella posizione o inizio movimento dei mostri, che pertanto appariranno sempre allo stesso momento e nello stesso punto.
L'eseguibile è sempre sonno i 2K, perciò c'è ancora un 50% disponibile di cui potenzialemente 25% per le mappe e ultime aggiunte per gestione gioco, + un 25% per la musica.
Questo implica che la musica deve stare sotto i 2KB (compressi ~ 1KB), pertanto è escluso una musica come l'anno scorso (3,2KB non compressi).
Temo che dovrò scrivere una apposita routine musicale o tentare con qualche editor che risparmia memoria (come Ninjatracker che però si mangia da solo 850 byte per il player)
bye
S.T.
-
lss9.prg:
aggiunto il passaggio di livello a fine schermo (devo inserire il calcolo bonus, adesso c'è solo lo scorrimento), con cambio di colore per segnalare che siamo nella caverna.
Il secondo livello è per ora la copia del primo, tranne che per i primi 5 blocchi.
Chiedo il votro parere: i primi 5 blocchi sono con la "terra" sopra (per dare l'idea che prima ci trovavamo li sopra) e i mattoni sotto.
il dubbio è quale soluzione (esteticamente) tra queste è la migliore:
1) "terra" sopra, mattoni sotto (come primi 5 blocchi)
2) "mattoni sopra e sotto
3) "terra" sotto e mattoni sopra (parzialmente come i blocchi dopo il 5)
Correto il movimento del nemici: se arriva a destra, non si ferma , ma torna indietro, altrimenti era facilissimo vedere bloccati i nemici a destra (il che non era bello)
Nelle mappe, i nemici che si trovano sopresi su un blocco, sono ora inseriti non più sul primo carattere, altrimenti succedeva che rimanessero bloccati ad andare a detra-sinistra istantaneamente, dato che quando apparivano sono alla estrema destra e contemporaneamente alla sinistra del blocco.
Rimane comunque il caso che un nemico su blocchi sospesi rimanga bloccato a fare destra sinistra durante lo scrolling, il che non ho ancora capito perché.
Luca/Fire sta iniziando con la musica col SidWinder. Vediamo quanto grande sarà il tutto, altrimenti ora che ha anche un C64C (!!!) potrebbe provare usando un player più piccolo.
bye
S.T.
-
Quando finisci un livello e sei ancora in fase di salto, appena inizi il livello successivo lo sprite finisce sotto il pavimento :-)
Debuggando ho notato che $10dd (yActSpeed) rimane a FF/FE. Azzera yActSpeed ogni volta che finisce un livello e dovrebbe andare a posto, ho creato questo diff file
--- lss.s Mon Jun 21 03:32:14 2004
+++ C:\q\lss\beta9\lss_my.s Mon Jun 21 03:30:14 2004
@@ -275,6 +275,8 @@
jmp intLoop
screenPassed:
+ lda #0
+ sta yActSpeed
inc level ; go to next level
lda level ; check if we have win
-
In effetti avevo notato qualcosa di strano quando ho aggiunto ieri sera un pò di mappa e questa finiva in alto e si passave lo schermo saltando.
Metto il fix in cima al loop, dato che adesso ho aggiunto anche schermate di fine gioco e calcolo bonus, pertanto è da utilizzarsi in più punti.
bye
S.T.
-
lss10.prg:
date un occhio alle nuove nuvole e diamante disegnate da Luca/Fire!
bye
S.T.
-
lss10.prg:
date un occhio alle nuove nuvole e diamante disegnate da Luca/Fire!
bye
S.T.
Bene... continuo a seguire gli sviluppi con molto interesse. Ora le nuvole sono molto più... "morbidose", e curate.
Cambierai anche gli sprite dei nemici?
-
Non è in programma, ma visto che Luca è bravo anche con la grafica e non solo con la musica, non si sa mai :)
bye
S.T.
-
lss10.prg:
Il sorgente non e' aggiornato, e' la parte che piu' mi interessa (http://digilander.libero.it/iANCooG/sweat.gif)
-
strano che il sorgente non sia aggiornato.
Aggiunto lss11:
adesso si riesce a saltare a destra e subito dopo a sinistra se si premono i tasti durante il salto.
Corretto anche quel famoso errore che se vai a sinistra non salta il alto (errore che si riperquote in certi casi anche durante il gioco)
bye
S.t.
-
strano che il sorgente non sia aggiornato.
Se qualcosa puo' andar male lo fara'.
Prova a riuploadare lo zip, i primi $4000 bytes sono solo zeri (quindi e' inutile anche tentare di riparare il file) :o
-
appena uploaded.
speriamo che vada
-
appena uploaded.
speriamo che vada
Ok ora va. E il baco del salto a sx ora non c'e' piu', bravo! (http://digilander.libero.it/iANCooG/trink4.gif)
Resta ancora da capire come fixare la linea di raster sull'utima riga... tutta questione di temporizzazione, immagino ;)
-
Per il raster di solito basta qualche nop, per cui al momento non me ne sono preoccupato. Poi magari scopro che non basta ....
bye
S.T.
-
lss12.prg:
per la gioia di Luca/Fire adesso si può arrampicarsi su di un blocco, saltando in alto (come in Giana) e il comportamento non è più da Ghost and Goblin.
Funziona solo se si salta in alto e si va a destra, non il contrario (giusto per risparmiare un pò di codice).
Il raster è fissato spostando lo scrolling un pò di cicli dopo (non aggiungendo nop, ma spostando l'ordine di esecuzione).
Adesso rimane solo il bug che ogni tanto ci si arrampica a metà blocco...
bye
S.T.
-
La modifica del raster e' perfetta, anche aggiungendo una musica non sgarra di un pixel ;)
Ho notato che il contatore dei diamanti non era ancora finito, passati a 10 appare un ";". Qualche mese fa ebbi lo stesso problema con il trainer di Kungfu master e trovai una soluzione con google, un routine per convertire un valore binario in BCD.
Ti posto il diff delle mie modifiche rispetto al sorgente della beta12
--- lss.s Mon Jun 28 21:58:30 2004
+++ C:\q\lss\beta12\lss_2.s Tue Jun 29 01:20:28 2004
@@ -890,30 +890,20 @@
jsr STRING ; put the name of the game
rts
Sscore:
- .byte 5,"POINTS BONUS LIFES LEVEL TIME ",CHS_DIAM1,0
+ .byte 5,"POINTS BONUS LIVES LEVEL TIME ",CHS_DIAM1,0
;=================================
; Write the score
;=================================
writeScore:
lda bonus ; write the number of bonus
- and #$F0 ; high nibble
- lsr
- lsr
- lsr
- lsr
- clc
- adc #48 ; add '0'
- sta $400+40+14
- lda bonus
- and #$0F ; lo nibble
- clc
- adc #48 ; add '0'
+ jsr bin2bcd
+ jsr atoax
+ stx $400+40+14
sta $400+40+15
lda lifes
- clc
- adc #48 ; add '0'
+ ora #$30
sta $400+40+22
lda level
@@ -922,18 +912,8 @@
sta $400+40+29
lda time ; write the time
- and #$F0 ; high nibble
- lsr
- lsr
- lsr
- lsr
- clc
- adc #48 ; add '0'
- sta $400+40+35
- lda time
- and #$0F ; lo nibble
- clc
- adc #48 ; add '0'
+ jsr atoax
+ stx $400+40+35
sta $400+40+36
ldx #0
@@ -966,15 +946,15 @@
lsr
lsr
lsr
- clc
- adc #48
+
+ ora #$30
wra1:
sta $400+40+2,y
iny
pla
and #$0F
- clc
- adc #48
+
+ ora #$30
wra2:
sta $400+40+3,y
inx
@@ -1840,3 +1820,46 @@
.byte $01, $01, $01, $01, $01 ; white -> BK_CLOUD blocks
.byte $08, $08, $00, $08, $08
.byte $08, $01, $08
\ No newline at end of file
+
+; convert binary to BCD without division.
+; Entry: binary number between 0 and 99 in accumulator
+; Exit: BCD number in accumulator (unpack to get ASCII)
+; original found <http://groups.google.com/groups?selm=166%40harvard.ARPA&oe=utf-8&output=gplain>
+; adapted and optimized(?) by iAN CooG
+bin2bcd:
+res = $95
+ php ; save previous processor mode
+ sed ; enable bcd arithmetic
+ ldx #8 ; #bits to convert
+ ldy #0 ; clear result
+ sty res
+bloop: asl ; test msb
+ tay ; save binary number
+ php ; save result of msb test
+ lda res ; multiply bcd by 2
+ clc
+ adc res
+ plp ; add one if msb was set
+ adc #0 ; adds 1 only if carry set
+skip: sta res ; update bcd result
+ tya ; restore binary number
+ dex
+ bne bloop
+ lda res ; return result in accumulator
+ plp ; restore processor status
+ rts
+
+; input a=$12 output x= $31 "1" a= $32 "2"
+atoax:
+
+ pha ; save A for lo-nibble fetch
+ lsr
+ lsr
+ lsr
+ lsr
+ ora #$30
+ tax
+ pla ;lo-nibble fetch
+ and #$0F
+ ora #$30
+ rts
-
Non ci avevo fatto caso al bonus!!!!
Adesso vedo il fix, o se mi conviene utilizzare direttamente l'aritmatica decimale come fatto per il punteggio.
Thanks.
bye
S.T.
-
Adesso vedo il fix, o se mi conviene utilizzare direttamente l'aritmatica decimale come fatto per il punteggio.
Credo convenga fare come con il punteggio, visto il casino che bisogna fare per decifrare un byte, vai di SED e semplifichiamo il tutto ;)
Tanto non ci saranno piu' di, diciamo, 30 diamanti per livello no?
-
Esatto.
Al momento ho applicato la patch, visto che funziona e raggruppa il tutto sotto atox.
Domani vedo di togliere bin2bcd usando l'aritmetica decimale.
Per il max numero di diamanti non c'è problema: raggiunta una certa quota, si guadagna una vita e il tutto si resetta. Devo implementarlo ancora.
Intanto ho messo che il bonus non si azzeri passando di livello, ma solo se si muore.
Domani sera il tutto sarà in lss13.prg
bye
S.T.
-
lss13.prg
Oltre al fix del bonus, notate le nuove piattaforme simil 3D disegnate da Luca.
I mostri sono leggermente ritoccati da Luca: il primo ha un look più professionale.
Il secondo perde un pò di fascino rispetto a prima.
bye
S.T.
-
lss13.prg
Lo zip e' rovinato :(
C'e' nessuno? possibile che nessuno se ne sia ancora accorto? o sono l'unico a seguire il thread? :stordita:
Io sono un tuo fedele seguace e il thread lo tengo sempre d'occhio :P
-
Lo zip e' rovinato :(
C'e' nessuno? possibile che nessuno se ne sia ancora accorto? o sono l'unico a seguire il thread? :stordita:
Oddioddio, guarda, lasciamo stare: le ho provate tutte per ripararlo, nulla nulla nulla di nulla. Stefano l'avrà aperto e richiuso giusto per verificare se corrotto, ma la cosa era più subdola...mannagg, non so neanche se le piattaforme le ha messe a terra o sospese... :doh:
-
lss13.prg
Lo zip e' rovinato
C'e' nessuno? possibile che nessuno se ne sia ancora accorto? o sono l'unico a seguire il thread?
Io sono un tuo fedele seguace e il thread lo tengo sempre d'occhio
Il thread è seguitissimo a giudicare dai log, tu hai semplicemente
postato per primo :sgrat:
A questo punto attendo ansiosamente i nuovi ritocchi alla nuova grafica (sulla programmazione devo sorvolare :D ), non farò mancare i miei commenti a Luca/FIRE, che nel frattempo saluto.
:ciauz:
-
Ci sono anch'io;in questi ultimi giorni ho avuto dodicimila cose da fare e ho perso un pò di vista il thread ( sono ancora a lss11 :o )
-
Eggià, mi pare giusto: la rabbia dello zip scassato mi ha fuorviato effettivamente dagli oneri classici di un neoiscritto al forum: salutare e presentarsi.
E allora buongiorno a tutti, 8bit per sempre. :hail:
-
Ciao e benvenuto :)
-
Appena rispedito.
Ultimamente il servizio upload di digiland lascia a desiderare...
Comunque il sorgente non era corrotto e se avete dasm potete compilarlo tranquillamente.
Adesso dovrebbe però essere corretto il file.
bye
S.T.
-
Ooops! L'uso dei caratteri nei blocchi di piattaforme in verticale (fine primo livello, inizio del secondo livello) va mantenuto
1 1
2 2
1 1
2 2
..........
Il secondo sprite pensavo peggio...provato ad usare l'inversione di ombreggiatura col marrone?
-
Si, quella verticale non è giusta, ma non so se l'effetto 3D riesca bene su quella verticale.
Se cambio l'ombreggaitura, ne risentono anche i colori di Sara, perché i colori comuni sono fissi
-
:confused: Non ho capito la risposta :confused:
Semplicemente, asserivo che la sequenza dei caratteri in un blocco 4*4 non è stata corretta.
Vedi l'ulimo ostacolo in verticale del primo livello? Ed il primo muro a sinistra quando comincia il secondo livello? Ecco, devi semplicemente sostituire la giusta sequenza:
1 2 C C---> 1 1 C C
1 2 C C---> 2 2 C C
1 2 C C---> 1 1 C C
1 2 C C---> 2 2 C C
errata ---> giusta
Nemici: uno ha il colore variabile rosso chiaro, l'altro il verdino, pensavo che il colore mobile degli sprite potesse essere qualsiasi, perciò proponevo il marrone... :( evidentemente c'è qualcosa che non so...
-
Ecco la patch per la correzione dell'imprecisione grafica:
>2548 4f 4f 40 40 50 50 40 40
>2550 4f 4f 40 40 50 50 40 40
-
Si, quello mobile si può cambiare, che corrisponde al colore non sugli occhi e non sulla parte sinistra. Pensavo che l'effetto che proponevi fosse relativo al colore della parte sinistra. Devo allora provare il marrone per colore primario.
Quello che non torna dei blocchi verticali è che essendo simil 3D, sono "mattoncini" piccoli in alto e più grandi in basso, per cui mettendoli sovrapposti si ha mattoni grandi e subito dopo mattoni piccoli.
Non ho ancora provato come appaiono, dato che torno a programmare domani sera.
bye
S.T.
-
lss13b.prg (http://mio.discoremoto.virgilio.it/yotsuya/lss13b.prg)
Ecco il mio piccolo frankenstein per verificare al volo come le piattaforme devono essere.
Ma, giocaccio maledetto! Perché dà bonus anche quando il tempo è zero?
-
ops... se tento di eseguire il file ricevo SINTAX ERROR IN 49135
Attendo informazioni :)
Avrei una domanda.
Per rendere questo diario ancora più completo potreste indicare anche quali strumenti state utilizzando. Che ne dite?
Mi pare di capire che Stefano usi 64ASM per assemblare, ma per la grafica della mappa cosa utilizzate?
(Se posso tirare a indovinare direi Bgedit3 di lasse per la mappa)? E per gli sprite?
Grazie :)
-
Per assemblare uso DASM (scelto perché mi permette di settare facilmente le aree di memoria con .ORG e includere files esterni) + ci sarà EXOMIXER per compattare prima del rilascio.
Gli sprite li disegno sempre con lo sprite editor di Andrew Colin (Introduzione al Basic): sono lentissimi perché in BASIC, ma ormai sono abituato così (alla fine rilascio anche le SVF di vice con il tutto).
Luca ha usato un altro editor che adesso non ricordo il nome.
Per i caratteri, ho usato BGEDTI3 di Lasse, ma non per la mappa.
La mappa è fatta in assembler da cose tipo:
.byte BK_SPACE, BK_CLOUND_UP ....
.byte BK_WALL1, BK_SPACE
.byte BK_SAPCE, BK_SPACE
.byte BK_GR1, BK_KILL1
Il tutto va testato per vedere come appare (o usare un pò di immaginazione per capire come deve apparire).
Forse avendo BGEDIT (quello di EFNY), avrei potuto usare la mappa generata dal programma, ma non so come disponga i byte e non l'ho trovato in rete.
bye
S.T.
-
Syntax Error?
Ma che stranezza, io lo carico tranquillamente trasportando il file sul VICE...
Ho solo corretto la sequenza di caratteri con l'editor del VICE, e salvato 0800-2704, tanto per far vedere come dovrebbe essere.
-
lss13b.prg (http://c64.rulez.org/~luca/lss13b.prg)
Niente, non so perché ma il disco remoto di Virgilio, mai usato in precedenza, è una vera fregatura! Lo piazzo su un server fino alla beta release corretta prevista, dopodiché farà PUFF e sparirà nel nulla.
-
Sembra strano anche a me in effetti... nessun altro ha scaricato il file e ha avuto il mio stesso problema?
Se pensi che l'upload su virgilio abbia potuto danneggiare il file, puoi mandarmi il file per email a
robnicoletti (chiocciola) email (punto) it
EDIT:
ah ok... leggo adesso le modifiche al tuo messaggio :)
lss13b.prg
Niente, non so perché ma il disco remoto di Virgilio, mai usato in precedenza, è una vera fregatura! Lo piazzo su un server fino alla beta release corretta prevista, dopodiché farà PUFF e sparirà nel nulla.
Se vuoi mandarmelo lo stesso bene, altrimenti aspetto non ho fretta.
-
Riscarica il file dal nuovo link, mai più Virgilio, diiiiiocenesalvi!
-
Riscarica il file dal nuovo link, mai più Virgilio, diiiiiocenesalvi!
Ok adesso funziona correttamente!
Effettivamente adesso l'effetto è molto più convincente, almeno secondo me. :)
-
Ma, giocaccio maledetto! Perché dà bonus anche quando il tempo è zero?
Perché con tempo uguale a 0 Sara deve essere bella che morta, per cui non ci sarà mai questa eventualità.
Da stasera aggiungo i controlli per far morire il personaggio, per cui dopo non accadrà più
bye
S.T.
-
Ah ecco! ;)
Non è un bonus time ma un suddendeath time!
Messi a posto poi i blocchi tra $2548-2557?
-
Messi a posto poi i blocchi tra $2548-2557?
si, visto che vengono comunque bene
bye
S.T.
-
lss14.prg:
adesso ci sono tutti i controlli di morte. Il gioco è pressochè completo come engine.
Musica e schermi sono tutto ciò che rimane da aggiungere.
C'è sempre che ogni tanto un nemico si blocca ad andare avanti indietro in un punto, sopratutto quando lo scrolling si ferma.
bye
S.T.
-
Azz adesso si' che diventa difficile.
Mi e' capitato piu' di una volta di trovarmi dopo un salto proprio di fronte al nemico, ma dato che gli sprites si muovono tutti alla stessa velocita' e' impossibile sfuggirgli anche correndo indietro. Ho provato a rallentare i nemici facendo eseguire la moveMonster una volta si' e una no :D
;=================================
; Move the monsters
;=================================
moveMonster:
lda flipflopwait
eor #$01
sta flipflopwait
beq forceret
ldx #7
loopMovMon:
lda xActSpeed,x
[...etc...]
bne loopMovMon
forceret:
rts
flipflopwait:
.byte 00
Almeno e' un po' piu' "fair"
-
Così mi sembra troppo semplice. ho allora settato lo spastamento nemici a 3 pixel, per cui c'è lo spostamento medio di 1.5 pixel, così è un pò più difficile.
Ogni tanto mi sembra che la collisone non abbia effetto, ovvero, salto sul mostro, esso sparisce e subito dopo muoio. Forse per un qualche motivo la collisione è retriggerata e avendo velocità zero, muoio, anche se il nemico è già scomparso.
Devo indagare
bye
S.T.
-
Ogni tanto mi sembra che la collisone non abbia effetto, ovvero, salto sul mostro, esso sparisce e subito dopo muoio. Forse per un qualche motivo la collisione è retriggerata e avendo velocità zero, muoio, anche se il nemico è già scomparso.
Ti confermo che capita anche a me e spesso. Prima scompare il nemico e una volta a terra si muore lo stesso. Forse vengono settati contemporaneamente i flag.
-
Qualcosa non mi torna.
Settando un pò di breakpoint e analizzando lo stato ho notato che:
in checkEnemy, l'istruzione che pone actTye,x a 0 è chiamata per due volte prima che effettivamente il nemico sparisca.
Questo dovrebbe accadere solo una volta.
E' chiaro che 1 volta su 10 capita che la velocità sia 0 per cui in realtà si muore.
bye
S.T.
-
in checkEnemy, l'istruzione che pone actTye,x a 0 è chiamata per due volte prima che effettivamente il nemico sparisca.
Questo dovrebbe accadere solo una volta.
Ho testato anche io, la collisione viene sentita anche a sprite spento, quindi credo l'unico sistema sia quello di muovere via lo sprite anche se spento
;lda #0
;sta actType,x ; the monster is disabled
txa
asl
tay
lda #0
sta actType,x
sta $d000,y; position the current X sprite at 0,0 (invisible anyway?)
sta $d001,y
rts
o cmq una cosa del genere. Ora anche il punteggio viene incrementato solo una volta, prima ogni nemico veniva contato come 2 :)
-
lss15.prg
Con questo sistema funziona, anche se rimane il perché l'altro non vada.
Ho aggiunto il primo prototipo di musica di Luca, ma siano out di oltre 200byte.
Ho tolto la parte inutilizzata iniziale dal player e sono sceso a 178 byte.
Poi con la versione modificata di sidld ho posto a zero i byte del player che non risultavano essere utilizzati dalla musica:
sono sceso a +16, dato che sequenze di byte a zero si comprimono meglio (accidenti, questo stratagemma potevo farlo anche l'anno scorso)
Mal che vada a questo punto giostrando sul codice i 16 byte si tolgono, anche se la mappa 2° deve ancora essere completata (ho messo dei nuovi caratteri per i blocchi).
-
Riorganizzando un po' l'inizio del sorgente sono sceso a 4091 bytes, non e' molto ma almeno e' sotto i 4kb.
--- lss.s Mon Jul 05 23:11:24 2004
+++ C:\q\lss\beta15\lss_my.s Mon Jul 05 23:38:14 2004
@@ -108,8 +108,7 @@
;sta $DC0E
sei
- lda #251
- and $01
+ lda #$33
sta $01
; set pointers
lda #$38
@@ -147,8 +146,7 @@
bne copy2
; restore pcr
- lda #04
- ora $01
+ lda #$37
sta $01
cli
;lda #01
@@ -162,26 +160,22 @@
;ora $D016
;sta $D016
- ldx #8 ; set common char multicolor
- stx $D022
- inx
+ ldx #7
+ stx $D025 ; set sprites common colors
+ inx ; 8
+ stx $D022 ; set common char multicolor
+ inx ; 9
stx $D023
+ stx $D02A ; set color for sprite 3
+ inx ;10
+ stx $D027 ; set color for sprite 0
+ stx $D028 ; set color for sprite 1
- ldx #7 ; set sprites common colors
- stx $D025
ldx #2
stx $D026
- ldx #10
- stx $D027 ; set color for sprite 0
- ldx #10
- stx $D028 ; set color for sprite 1
ldx #5;3
stx $D029 ; set color for sprite 2
- ldx #9
- stx $D02A ; set color for sprite 3
-
-
ldx #$FF ; set sprites multicolor
stx $D01C
@@ -206,8 +200,9 @@
stx $D01A ; IRQ mask register
cli
; use VIC interrupt
- lda #$01
- sta $D019 ; Interrupt indicator register
+ ;lda #$01
+ ;sta $D019 ; Interrupt indicator register
+ stx $D019 ; Interrupt indicator register
lda #RASTER0
sta $D012 ; Reading/Writing IRQ balance value
lda #$1B
@@ -907,7 +902,7 @@
rts
Sbonus:
- .byte 5,"BONUS: TIME*32",0
+ .byte 5,"BONUS: TIME*20",0
;=================================
@@ -1508,7 +1503,7 @@
jsr STRING ; put the name of the game
rts
Sscore:
- .byte 5,"POINTS BONUS LIFES LEVEL TIME ",CHS_DIAM1,0
+ .byte 5,"POINTS BONUS LIVES LEVEL TIME ",CHS_DIAM1,0
;=================================
; Write the score
Ricordati del liVes e non liFes ;)
Poi ho usato anche l'opzione -n di Exomizer (toglie l'effetto di decompressione per risparmiare una decina di bytes)
Ma tanto dovrai aggiungere altri livelli, giusto? Quindi non so se ne vale la pena :mellow:
-
Ok, allora vai, o la va o la spacca! :metallica:
É chiaro che la musica così com'è spacca i timpani, difatti il modello, se qualcuno ce l'ha in mente, era la musichetta del primo Mario Land per Gameboy: semplice, con una brevissima intro all'inizio di un livello, e poi 2 differenti jingle che si ripetono ogni 2.
Ecco, io per ora ho messo solo uno dei 2, ci vuole l'altro per spezzare il primo tema, ma la memoria già piange!
Altra mazzata: il file dei soli dati era di 5 blocchi, il file completo risultante di circa 9. Questo a casa mia vuol dire che il player in fondo in fondo è di circa 4 blocchi, cioè molto simile ai player più leggeri, come quello del Ninjatracker. Non vale la pena allora cambiare editor...
Ovvio che non potrò mettere musica e qualche jingle, però potrei divertirmi, previa spesa di una decina di byte, a giocare con i settori già presenti nel file per creare un facile jingle di game over, come in Markanoid.
Ovvio anche che in lss15.prg la musica non si ferma mai, mentre in teoria deve riprendere dopo una morte o un game over, ripetendo i 6 secondi iniziali.
ice00: quando ho previsto una musica grande da $1000 a $1a00, mi hai scritto:"Che bello, allora possiamo fare un sacco di livelli!". Ora che sappiamo che la musica sarà proprio grossa come detto, hai detto che inserirai due livelli causa spazio.
Che mi son perso? :huh:
Vado a comporre il pezzo mancante, pregate per me... Ma alla fin fine: vi piace o no?
:c64:
-
Vado a comporre il pezzo mancante, pregate per me... Ma alla fin fine: vi piace o no?
:c64:
Molto bella, versione SID de 'Il tema di Lucignolo', composta da Fiorenzo Carpi per lo sceneggiato di Comencini, Pinocchio. B)
Gran sceneggiato e gran colonna sonora.
-
ice00: quando ho previsto una musica grande da $1000 a $1a00, mi hai scritto:"Che bello, allora possiamo fare un sacco di livelli!". Ora che sappiamo che la musica sarà proprio grossa come detto, hai detto che inserirai due livelli causa spazio.
Che mi son perso?
Infatti, visto quanto bene si era compressa MArkanoid dello scorso anno che era lunga lunga, pensavo che i livelli potressero essere molti (1 livello sono molti byte, ma sono anche lunghe sequenze tipo BK_SPACE, BK_SPACE,... che si comprimono parecchio).
Adesso bisogna mettere mano al codice è ottimizzarlo al meglio. Prima però finisco il livello 2, per vedere quanto cambia in termini di byte.
bye
S.T.
-
Esatto Ready64! :mattsid:
Sono giorni che scrivo ad ice00 che c'ho Comencini in testa e lo devo far uscire, anche se in una versione mmmm...bah, personale.
-
Ma è già in linea l'eseguibile con la colonna sonora?
-
Molto bella, versione SID de 'Il tema di Lucignolo', composta da Fiorenzo Carpi per lo sceneggiato di Comencini, Pinocchio.
Grazie...oddio "bella" proprio no, per ragioni di spazio è molto statica, alrimenti variegavo al limone il tutto prendendomi il giusto spazio per i fronzoli...
Ma è già in linea l'eseguibile con la colonna sonora?
Con la colonna sonora incompleta...e già così come puoi vedere siamo in lacrime. :doh:
-
Provo a studiarmi i sorgenti di Ninjatracker e SIDWinder per vedere se oltre al player, c'è qualche speranza di risparmiare byte da come organizzano i dati, oppure se sono effettivamente molto simili.
Intanto provo a vedere cosa si può togliere (be, utilizzare tutte variabili a pagina 0, invece di solo alcune, dovrebbe liberare qualche altro byte)
-
Eh ma io comunque la termino su SIDwinder, poi al limite si vedrà. ;)
-
Ho notato che avete anche tolto le nuvolette dal livello sotterraneo, stavo quasi per farvelo notare - poi per fortuna non ce n'è stato bisogno :)
A parte questo, come avrete notato ho messo in rilievo il thread, e ci rimarrà finchè lo sviluppo del gioco non sarà finito. Dopodichè si potrebbe anche lucchettare, giusto per porre un sigillo al diario e per tramandarlo ai posteri.
Questo ovviamente con il consenso di Stefano, ma anche di tutti gli altri che hanno partecipato alla discussione (è un'idea).
Per la musica: io ritengo che sia davvero buona, ma posso capire l'eterna insoddisfazione dell'artista.
-
lss16.prg:
4091 bytes, dopo le patch, aver tolto la vita ogni 4000 byte (che mi sembrava in ogni caso buggata). Ho messo una vita ogni 15 diamanti, dato che con soli due livelli, al max si guadagna una vita.
Completato il livello 2: non difficile.
Musica si resetta ad ogni press fire.
Attulamente questa versione potrebbe già gareggiare.
Aspettiamo gli sviluppi della musica di Luca col SidWinder, proviamo a restringere ancora, altrimenti questo potrebbe rimanere la versione definitiva.
A proposito, ancora non lo ho comunicato qui, ma dopo la fine della competizione ho intenzione di creare LSS 2 (senza limiti di spazio), sfruttando questo engine e ampliandolo per renderlo migliore.
Ho intenzione di creare un editor di mappe in java in modo che ogni utente di Ready64 possa creare una mappa (quindi potenzialmente oltre 130 livelli!)
Poi rilasciarlo in versione cassetta, con caricatore con musica e screen come ai bei tempi, lasciando magari il compito ai crackers di rilasciare la versione disk.
Grazie per il rilievo :)
bye
S.T.
-
:sonno: C'ho fatto nottata, ma ho finito la musica prima dell'appuntamento di Spresiano! ...di Spres..zzzzzzzZZZ :sonno:
Eh! Oh! Ci sono, accumulo le ultime forze!
Cominciamo con le gran mazzate: occupa da $1000 a $196D, e dentro c'è una signora musichetta più il jingle "ricavato" da suonare durante la pausa del "press fire to play", esattamente come in Markanoid.
É tutto ricavato, anche il difficile loop che ricongiunge le due parti è un signor tarocco a scopo risparmio che sembra funzionare, e spero non sia il sonno. Ho risparmiato su tutto, rimanendo ben al di sotto della spesa in memoria preventivata.
Per capirci, rispetto al file inserito con dolore precedentemente, ora ci sono in più solo circa 120bytes, e secondo me ci si presta ad una buona compressione, dato che ho fatto il diavolo a 4 per avvicinare i valori uguali tra di loro...daaaai 120bytes si trovano suuuu!
Vediamo come va e (se va) se vi piace
-
120 bytes sembrano alla portata, anche perché dovrebbero essere sui 60 byte in più compressi, quindi penso che con piccoli ritagli dovremmo restarci dentro.
Così anche stasera un'altra nottata anche per me :)
(accidenti ho L'HVMEC 0.3 pronta per il rilascio da una settimana e non ho il tempo per farlo....)
-
Grazie per il rilievo :)
er...
purtroppo l'idea mi è venuta in mente tardi, visto che il gioco ormai si avvia alla conclusione, ci rifaremo la prossima volta!
-
Comunque,se posso esprimere il mio giudizio sulla musichetta è molto carina... semplice ma davvero accattivante :P
-
Aaaah grazie Alberto, queste sono le soddisfazioni! :D
La musica finita ora ce l'ha solo ice00, che sta premendo col sedere sulla valigia per farcela entrare; spero ti piaccia anche la versione definitiva.
Lo ripeto: sono l'Uomo Chiamato Risparmio.
Ready64: dì la verità siamo stati fulminei! :mattsid:
-
lss17.prg:
Dimensione 4258, ma altri 20 byte li recuper finendo di piazzare a 0 gli ultimi byte del player che SIDLD mi dice non utilizzati.
Siamo a più 142, segno che purtroppo il compresso della musica si comprime molto meno di quanto sperato.
Ma la musica è fantastica, pertando adesso devo scervellarmi per ridurre qualcosa. Alla peggio si riduce la lunghezza del livello, o si tolgono qualche blocco carattere. Vediamo.
bye
S.T.
-
Sìììììì, fatemi tanti complimenti! :metallica:
Accidenti santa compressione vergine e martire, pensavo molto meglio! :doh:
Evabè, però oddio, penalizzare i livelli per la musica...io sono disposto a tagliuzzare qualcosa se necessario, pur ribadendo di essermi tenuto e trattenuto più di quanto sarebbe plausibile.
Già così, dopo il generoso voto di 16% datoci dalla rivista di ALIH per Markanoid, stavolta rischiamo di scendere sotto il 10% ;) dato che il gioco in sé con due livelli due ha davvero poca sfida, e quindi vale per quello che mostra (e vale anche parecchio direi!), ma non per l'attività ludica vera e propria. Vale invece la regola delle 3P: Però Pare Potente. :D
Importante per ice00: mi rimangio le parole, e dico che mi sembra il caso di fare il restart della musica solo e dico solo quando il livello cambia, indifferentemente dalle vite perse, altrimenti si rischiano ridondanza ed esaurimento. Inoltre, cos'è quel bug che fa un flash bianco in alto a sinistra quando entra scorrendo il secondo livello?
-
ice00:
ci pensi tu a passare alla gentaglia di HVSC il file .sid?
Se sì, dagli il commento:
TITLE: Lucignolo (0:06-0:26)
ARTIST: Fiorenzo Carpi
COMMENT: from the TV series "Pinocchio"
-
Dopo la fine della sistemazione del player + qualche ottimizzazione minore sui blocchi siamo a 4250.
Serve intervento drastico sul codice.
Tempo che altre migliorie sulla dislocazione del codice (spostare certe routine in altre posizione per agevolare la compressione) non potranno migliorare di più di 30-40 bytes.
Quello che mi viene in mente è generare del codice a runtime:
per esempio questo
N SET 4 ; from line 4 until 24
REPEAT 20
lda $0400+N*40+1,x
sta $0400+N*40,x
N SET N+1
REPEND
Che sono ben 20*6=120 bytes, presumo di difficile compressione, bisognerebbe riuscire a crearli con del codice che li costruisca.
Ci sono ancora 50 giorni alla scadenza, speriamo di riuscire a compattare il tutto
Importante per ice00: mi rimangio le parole, e dico che mi sembra il caso di fare il restart della musica solo e dico solo quando il livello cambia, indifferentemente dalle vite perse, altrimenti si rischiano ridondanza ed esaurimento. Inoltre, cos'è quel bug che fa un flash bianco in alto a sinistra quando entra scorrendo il secondo livello?
Infatti. Concordo.
Il colore di sfondo non è impostato correttamente durante lo scrolling iniziale?. Sul primo livello c'era la nuvola nera, poi corretta. Penso che per risolverlo basta eliminare i mattorni che ci sono sopra, così non si vede niente :)
bye
S.T.
-
Sìììììì, fatemi tanti complimenti!
Bravo! (http://digilander.libero.it/iANCooG/trink4.gif) :P
Già così, dopo il generoso voto di 16% datoci dalla rivista di ALIH per Markanoid, stavolta rischiamo di scendere sotto il 10% ;)
Mah, alle volte esagera proprio con i giudizi negativi, come nel caso di Markanoid, pero' c'e' da dire che il panorama delle uscite e' spesso deprimente.
-
; install custom chars
; transfer characters codes to 14336
ldx #00
;lda #254
;and $DC0E
;sta $DC0E
sei
;lda #251
;and $01
lda #$33
sta $01
; set pointers
lda #$38
sta CTO+1
lda #$D0
sta CFROM+1
lda #0
sta CTO
sta CFROM
copy: ; copy the chars
lda (CFROM,x)
sta (CTO,x)
inc CFROM
inc CTO
bne copy
inc CFROM+1
inc CTO+1
lda CTO+1
cmp #$40
bne copy
; set pointers
lda #<char
sta CFROM
lda #>char
sta CFROM+1
lda #$00 ; from char 64
sta CTO
lda #$3A
sta CTO+1
copy2: ; put the new chars
lda (CFROM,x)
sta (CTO,x)
inc CFROM
inc CTO
bne copy2
questa routine è di 69 byte: è possibile dimezzarla?
Di persè si tratta di copiare due zone di memoria locate in certe posizioni.
Sto pensando se il Kernal ha codice simile da poter richiamare per effettuare la copia.
-
Alcune modifiche che mi vengono in mente per risparmiare qualche byte:
ridurre lunghezza scritte da stampare:
GAME OVER -> END
WELL DONE SARA: YUO ARE THE BEST -> WELL DONE
29 byte -> potenzialmente 15 risparmiati
Togliere la velocità a 1,5 pixel dei mostri e ripristinarla a 2: questo dovrebbe togliere 10 byte -> 5 potenziali
Usare 4 cifre per il punteggio al posto delle 6:
con due livelli non penso si vada oltre 9999 di punteggio, quindi:
->si toglie tutta la gestione a 6 cifre (aggiunta punteggio, confronto, copia highscore, stampa) e la si fa a 4
->Eventualemnte si stampano due 00 per simulare le 6 cifre
Risparmio non ancora stimanto ma forse sui 20 byte.
Risultato aspettative modifiche: 40 byte risparmiati.
Siamo ancora lontanissimi dai 200 e passa da togliere :(
-
Siamo ancora lontanissimi dai 200 e passa da togliere :(
Ora l'obiettivo è risparmiare 154 bytes in tutto da lss17.prg, vero?
In quest'ottica il tuo mi sembra un primo dignitoso risparmio. Effettivamente END non vuol dir nulla, rispetto al tradizionale GAME OVER, e soprattutto quei 5 potenziali bytes del movimento medio di 1.5 pixel sono stati inseriti per la giocabilità, quindi occhio, forse è il caso di sacrificarli solo in fuuro...
-
questa routine è di 69 byte: è possibile dimezzarla?
Di persè si tratta di copiare due zone di memoria locate in certe posizioni.
Sto pensando se il Kernal ha codice simile da poter richiamare per effettuare la copia.
JSR $A3BF
E' nel Basic ma puoi usarla
; move bytes routine
; $5F/$60 source start address
; $5A/$5B source end address
; $58/$59 destination end address
-
Utilizzando questa procedura del Basic, con un conto a spanne si dovrebbe passare da 69 a 57 byte con un risparmio di 12 (6 potenziali).
Chissa che a forza di byte ce la facciamo
-
Alcuni calcoli di prova fatti al volo danno 55 byte risparmiati utilizzando:
4=BK_SPACE al posto di BK_KILL nel secondo livello (tanto si vede sempre nero)
18=utilizzo solo WELL DONE
4=level, lifes, bonus come pagina 0
10=xscroll,xmap,xblock,rowleft coma pagina 0
2=time timed come pagina 0
2=removeEnemy tolta da soubroutine e messa al posto della chiamata
15=utilizzo routine Basic per installare caratteri
ne dovrebbero rimanere ancora 104
bye
S.T.
-
Utilizzando questa procedura del Basic, con un conto a spanne si dovrebbe passare da 69 a 57 byte con un risparmio di 12 (6 potenziali).
Chissa che a forza di byte ce la facciamo
50 byte, arrangiando un po' i dati
org $800
;A3BF move bytes routine
; $5F/$60 source start address
; $5A/$5B source end address
; $58/$59 destination end address
CDEND = $58
CFROM = $5f
CFEND = $5A
sei
lda #$33
sta $01
lda #$40
sta CDEND+1
lda #$D0
sta CFROM+1
lda #$D8
sta CFEND+1
JSR TRANSF
ldx #>char
stx CFROM+1
inx
stx CFEND+1
lda #$3B
sta CDEND+1
JSR TRANSF
lda #$37
sta $01
cli
;rts
;----------------------------
TRANSF:
lda #0
sta CDEND
sta CFROM
sta CFEND
JMP $A3BF
;----------------------------
org $4000; must be at start of any page $xx00
char:
-
Forza giovini che ce la si fa, santa zeropage vergine e martire.
ice00: forse è megliosostituire "POINTS" con il più riconoscibile "SCORE".
Tra l'altro: ma quanto vi invidio voi che sapete fare codice! Io non mi nego, in fondo la mia rivista sul Plus/4 e le mie piccole demo me le sono fatte tutte da me (anche se ogni volta mi chiedo "ma come ho fatto?", specie per quanto riguarda l'interrupt, che avrò usato una sola volta in "Logocompo3" riuscendo a richiamare il jmp address giusto con qualche PLA e PHP vatti a ricordare).
Ricordo che una volta provai a fare un semplice 1x1 scroll, che però soffriva di morbo di parkinson momentaneo (perché? perché non avevo eliminato l'interrupt di default che penso punti al basic?), e un'altra volta, sotto la guida di Mermaid dei Creators son riuscito a fare splitscreen e qualche riga di raster, sia in variabile tempo che spazio. Era davvero divertente, poi ho dimenticato tutto. :doh:
Eppure il mio sogno è quello di fare la demo fessacchiottola con gli effetti fessacchiottoli, niente di ché: lo scorrimento, il dycp, il charplasma, lo scorrimento non 1x1 chars e poco altro... :(
-
Ragionandoci sopra....
org $810
sei
lda #$33
sta $01
ldy #0
ldx #8
lp1
lda $d000,y
sta $3800,y
dey
bne lp1
next
inc lp1+2
inc lp1+5
dex
beq exit
cpx #$06 ; do not overwrite the predefined chars $3a00-3aff
beq next
bne lp1
exit
lda #$37
sta $01
cli
rts
;----------------------------
org $3a00 ; redefined chars are already in place!
char:
repeat 256
.byte $bd
repend
org $3b00
.byte $00
e fanno solo 38 byte. L'importante e' che siano solo 256 byte da non sovrascrivere
-
ci pensi tu a passare alla gentaglia di HVSC il file .sid?
appena mandato
e fanno solo 38 byte. L'importante e' che siano solo 256 byte da non sovrascrivere
Quasi dimezzata come volevasi :)
Adesso vado a piazzare tutti sti fix discussi oggi.
bye
S.T.
-
Trovato un altro punto: ridefinisci
rowTblLo = $ECF0
la tabella degli offset e' gia' nel kernal :)
-
lss18.prg: risparmi ottenuti:
1 : tolta un LDA, CMP rimasto spurio sul codice
4 : tolta la chiamata al reset musica quando si muore
[-2] : uso BK_SPACE al posto BK_KILL 2° livello: sembra che ci si perda, perciò non inserito
5 : utilizzo SCORE al posto di POINTS, tolto uno spazio e spostato a dx
11 : utilizzando routine con caratteri in place (qualche altro carettere può essere risparmiato se si riduce la zona di 0 tra i caratteri in place e l'ultima parte di codice
19 : utilizzo WELL DONE
13 : variabili pagina zero
Rimangono quindi +101
Attenzione: giocate parecchio adesso, per vedere se si sono effetti indesiderati che prima non c'erano.
Dato che utilizzo le nuove variabili a pagina 0, può essere che le routine kernal utilizzate possano modificare i valori.
Adesso mi rimane solo l'ottimizzazione dell'utilizzare lo score a 4 cifre al posto di 6, ed eventualemente espandere le routine chiamate una volta in place.
Nella più ottimistica delle ipotisi si dovrebbe risparmiare 30-40 byte.
A questo punto sono a corto di ottimizzazioni: ho guardato il codice ma non vedo altre cose da sfruttare :(
Qualche idea?
p.s. col la tabella del kernel si risparmiano altri 26 byte! Non ancora inserite nel file appena uiplodato
ne rimangono quindi 75
bye
S.T.
-
Attenzione: giocate parecchio adesso, per vedere se si sono effetti indesiderati che prima non c'erano.
Ok, giocato, la cosa pare andare tranquillina.
p.s. col la tabella del kernel si risparmiano altri 26 byte! Non ancora inserite nel file appena uplodato ne rimangono quindi 75
...dopodiché, tolti i 30-40 eventuali già citati, saremo sotto la cinquintina di bytes, e poi si vedrà, giusto?
Sai cosa? Mi chiedevo: dato che le voci nel pannello superiore (lives, time) sono tutte centrate, una manciata di bytes si risparmia in compressione mettendo centrati sotto di BONUS il diamante e le cifre (perché due spazi vanno ad impacchettarsi rispettivamente con quelli precedenti e successivi)? Così, tanto per fare un po' il geko...
I due problemi riscontrati nel gioco sono i soliti:
- nemici e scorrimento vivono tra di loro un brutto rapporto , che fa bloccare i primi, ed a volte dà un po' fastidio
- ancora, quando il secondo quadro al suo inizio scorre da destra, i primi 2 caratteri in verticale in alto a sinistra incontrano una maschera di colore carattere che li fa apparire per un attimo bianchi ed hires, dopodichè forse il codice usa la sua mask ma solo dopo, fino al prossimo passaggio a destra. Peccato veniale.
-
Una buona notizia: Ti ho fatto il generatore di codice per loopSG/loop2SG.
Con questo e alcune altre modifiche (tipo sostituire jsr xxxx/rts con Jmp xxxx) e exomizzando il tutto arrivo a 4102 bytes.
Evito di postare il diff perche' e' veramente lungo (9kb) e te lo mando in posta.
-
arrivo a 4102 bytes.
vabbè, dai, allora è fatta, accident'a voi masnadieri! :mavieni:
A 'sto punto davvero il truccaccio di avvicinare i #$20 uguali nel testo potrebbe essere utile.
Complimenti a IanCoog, che, ho come l'impressione, meriterebbe il jingle della sigla italiana di Starzinger per le sue intro in HF... ;)
Approposito IanCoog: ma il tuo IACcico "Minc*a" indica chiaramente un trascorso o sul ng o in chat!
Come dire: Kit-ty, la sua scienza uuu-seee-rà.
PS: qui qualcuno ha detto che la tua città, Ghiffa, è gemellata con una simile che si chiama Geipegga; ti spedirò con pacco celere la testa dell'imbecille che ha osato vomitare tale oscenità.
-
Durante una delle mie passeggiate notturne in bici (eh, guarda che ore sono!) ho pensato questo: "Ma mica è giusto in un gioco di 2 livelli 2 che venga premiato il giocatore che si è fatto ammazzare più volte, prendendo più diamanti!"
Insomma, secondo me:
quando si conclude il secondo livello, dopo il relativo bonus time, bisogna sommare (anche senza scrivere nulla su schermo!) 1000/1500 punti per vita risparmiata, ma proprio a livello di ADC$xxxx, una cosuccia così eh, di pochi bytes!
Pochi bytes che però fanno la differenza sulla (piccola?) sfida che offre il gioco.
-
Un monumento a iAN CooG/HF
:mattsid:
-
E' d'obbligo un applauso...complimenti a tutti! (clap,clap,clap) :P :D
-
Un monumento a iAN CooG/HF
:mattsid:
Alegar fioi! :D Oggi in ufficio c'e' molta rilassatezza e mi sto dilettando :)
Altra piccola ottimizzazione: non abbiamo piu' bisogno delle tabelle
blockTblLo e' sempre == $10 * Y
blockTblHi e' sempre == $24
loopWrite:
ldx xBlock
lda (actMapAddr),y ; read next block in the map for this row
tay
lda BKCOLOR,y ; read the color for this block
sta actBkColor ; remember actual color for this block
tya
asl
asl
asl
asl
sta sourcePos+1
lda actMapAddr ; next row of the map is MAPSIZE after
clc
adc #MAPSIZE
sta actMapAddr ; adjust map pointer low
lda actMapAddr+1
adc #$00
sta actMapAddr+1 ; adjust map pointer hi
ldy #$00
sourcePos:
lda BLOCKS,x ;$2400 ; read the right caracter
sta (dest),y ; write to the destination
poi cancella ovviamente le macro per creare le tabelle.
-
Con questa ultima genialata di iAN siamo a 4080!!!!! e devo ancora togliere la gestione 6 cifre dal punteggio.
Forse c'è spazio per la modiifca punteggio di Luca e per tentare di correggere bug visivo e comportamento strano mostro.
Più tardi per il rilascio che probabilmente sarà la verione che presenterò a Spresiano domenica mattina.
bye
S.T.
-
Con questa ultima genialata di iAN siamo a 4080!!!!!
Ti confermo la cifra :)
-
lss19.prg: 4088
Ho corretto il bug del secondo livello semplicemente andando a riempire il colore dello sfondo con quello aspettato.
Secondo me, dato che prima si scrolla lo schermo carattere, poi i colori, il timing è molto risicato per cui i primi 2/3 caratteri si vedono ancora col colore vecchio dello sfondo quando il raster ci passa.
Ho provato a fare quello che diceva Luca dello score, soltanto che per semplicità volevo dare 10000 punti a vita, così si toccava solo la parte alta dello score (a parte che sforerei di due byte, ma penso siano ampiamente recuperabili; comunque non so se siano troppi).
Forse le vite dovrebbero influire già sul calcolo del bonus (es: (tempo+vite<<2)*20
Non ho messo mano allo score a 6 cifre: se si dà punti anche alle vite, forse servono 6 cifre.
bye
S.T.
-
10.000 punti, per quanto tanti, non sono una scelta folle: terminare un platform a-la-Mario di 2 livelli è quantomeno facile; ecco che allora la sfida sarà quella di portare a casa più vite possibili alla fine.
Ma quando anche questa meta sarà frequentemente raggiungibile, allora saranno i cattivi colpiti, i diamanti raccolti ed il tempo di livello a fare da ago della bilancia.
Ecco perché dico: con tutto ciò che ti è rimasto, enfatizza punteggi ed hiscore!
Che detto col tono dell'Istituto Luce di marziana memoria suona come:
Come lancia che l'animo ed il corpo del Bolscevico nemico trapassa, così il giovane Balilla fende aere et carboniosa materia dell'ostacolo, per giungere vittorioso all'obiettivo della conquista panfascista!
(Fascisti su Marte - I capitoli perduti)
Ora provo lss19.prg
-
LSS19 gira come un signore, e siccome non dà adito a far partire sessioni di debugging, mi va di lanciarmi in Suggerimenti Prettamente Futili.
Ho notato che solo se si corre all'inizio del secondo livello c'è speranza di poter schiacciare il mio adorato mostro marrone ad ombreggiatura reverse, perché, se ho ben capito, il primo mostro è rosso, se ne esce un secondo è verde, se ne esce un terzo è il marrone. Chiedo: e differenziarne i punteggi? Questo renderebbe ancora più furba la sfida, specie la ricerca del terzo, che varrebbe millemilapunti!
Se poi dovessimo trovarci proprio in regime di spreco, ecco che immagino una piccola scorechart nella presentazione, come quella del caro vecchio space invaders:
©............25
§§
§R...........20
§§
§V...........35
§§
§M...........60
PRESS FIRE
-
lss20.prg: 4095
Questa è la versione finale.
Dati i 10000 punti ad ogni vita risparmiata.
Purtroppo niente over punti per il mostro marrone.
Adesso spedisco tutto al concorso, perché poi preparo (e testo) il materiale per Spresiano.
Magari era meglio aspettare l'ultimo giorno (fra 40 giorni) per spedire il tutto, ma è molto più facile che la gente ci
giochi adesso che ci sono solo una decina di entries, che quando ce ne saranno oltre 60.
Tra l'altro forse ho trovato un bug di exomizer:
win:
lda lifes
sta score ; give 10000 point for every lives
jsr clearScreen
jsr testScore
jsr writeWin ; write win string
Questa è la sequenza che da i 10.000 punti, ma in orgine era così:
win:
lda lifes
sta score ; give 10000 point for every lives
jsr testScore
jsr clearScreen
jsr writeWin ; write win string Il file risultante era di 4096 byte, ma appena lanciato si otteneva un schermo con READY subito dopo la decompressione.
-
Tra l'altro forse ho trovato un bug di exomizer
Bisognerà comunicarlo all'autore...
Ho provato ad ascoltare la musica su 6581: orrenda!
Scrivicelo cubitale:8580.
-
Tra l'altro forse ho trovato un bug di exomizer:
A me funziona in entrambi i modi. 4095 com'e' ora, 4096 com'era prima, ma una volta decompresso il dump della memoria e' identico. Uso Exomizer 1.1.4 e la mia linea di comando e'
exomizer -s $196c "lss.prg" -n -o "lss.exo.prg"
Comunque e' vero che in alcuni casi limite exomizer fallisce, ho gia' mandato un paio di mesi fa a Magnus Lind un po' di file (volutamente assurdi) che fallivano durante la decompressione e alcune migliorie per velocizzarlo durante la fase di optimizing.
Ad esempio con questo "codice" (dasm)
org $0800
L SET 0
REPEAT 4
M SET 0
REPEAT 3
N SET 0
REPEAT 256
byte $00
N SET N+1
REPEND
N SET 0
REPEAT 256
byte $60
N SET N+1
REPEND
M SET M+1
REPEND
N SET 0
REPEAT 256
byte $00
N SET N+1
REPEND
N SET 0
REPEAT 256
byte $78
N SET N+1
REPEND
M SET 0
REPEAT 4
N SET 0
REPEAT 256
byte $00
N SET N+1
REPEND
N SET 0
REPEAT 256
byte $60
N SET N+1
REPEND
M SET M+1
REPEND
N SET 0
REPEAT 256
byte $ea
N SET N+1
REPEND
rts
byte "by the time iget to arizona",$00,$08
L SET L+1
REPEND
exomizer -s $0900 "zero.prg" -n -o "zero.exo.prg"
non solo ci impiega un tempo assurdo per comprimerlo, ma il risultato finale e' che genera un file con il decompressore all'offset sbagliato e quindi sbagliando anche a decomprimerlo... qualsiasi altro compressore (provati PuCrunch, Crush/Taboo, packprg/Taboo,BYGcompactor) non fa storie.
-
Ho provato ad ascoltare la musica su 6581: orrenda!
Tutte le tue composizioni recenti vengono orrende su 8580, segno che sfrutti l'8580 a dovere
-
Tutte le tue composizioni recenti vengono orrende su 8580
LOL, ahahahah! :D Spero davvero sia una svista sennò son bell'e fregato!
-
Si, mega svista: 6581.
Infatti ho comprato un C64C solo per sentire Soulfixer sull'8580 perché sul C64 con 6581 era inascoltabile!
-
Hey quale onore! Su CSDb mi hai messo come coder *blush*
...vabbe' dai, me lo merito :D
-
Oddio, ed a sorpresa LSS guadagna una inaspettata ypsilon nel nome!
Ma.. :huh: ma come mai?
La stavo cambiando in CSDb, poi ho notato che anche nel Minigame2004 era così presentata, quindi ho rimesso tutto a posto... :huh:
-
Quando si fanno le cose stra di corsa ci scappa anche la y.
Comunque oggi a Spresiano LSS è andato a meraviglia
bye
S.T.
-
Ma dai? :mavieni:
Racconta racconta.
Oh, vedo che hai cambiato il nome in CSDb, io avevo aggiunto i credits per la grafica (non c'è la categoria "additional" per me), quindi immagino che tu abbia già provvedito a comunicarlo ai ragazzacci di Minigame2004...
-
Il gioco è stato provato sul campo da alcuni ragazzi presenti.
Ho notato che il fatto che i mostri a volte si bloccano in realtà rende più difficile le cose, perché obbliga a cambiare la strategia usata.
già comunicato a quelli del Minigame
-
Macbeth/PSW ha leggermente criticato LSS dicendo che secondo lui ci potevano stare piu' mappe... chi glielo spiega che e' gia' ai minimi termini? :P
Certo, togliendo la musica (che occupa la meta' del file) ce ne stavano di piu', ma vuoi mettere?
-
:( Uaaaaaaaaah! :(
Ecccccolpamiiiiiia! Lo sapeeevooo!
-
Comunque è andata benone,dai...avete beccato due 9 sul sito della scena :P
-
Macbeth/PSW ha leggermente criticato LSS dicendo che secondo lui ci potevano stare piu' mappe... chi glielo spiega che e' gia' ai minimi termini?
Magari non sa che è un entry per la minigame competition.
Comunque si potevano fare 4 livelli semplicemente dimezzando la lunghezza di un livello..
-
Nonononono aspetta un attimo...
Parlando del crack degli Excess +2 100%:
è il gioco ad essere buggato, o il precedente crack degli Angels? :confused:
-
http://ready64.org/smf/index.php?topic=614.0 (http://ready64.org/smf/index.php?topic=614.0)
StormFront/Excess ha rilasciato la prima versione +2 ma usando un charpacker che sporcava la zero page, Black/Angels+HF ha dimostrato come si fa una release, e StormFront ora ha rilasciato la sua versione fixata (usando un altro compattatore)