Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: Cbm - 15 Settembre 2006, 22:57:52
-
Un'altra cosetta in basic.
10 V=53248
15 PRINT CHR$(147)
20 POKE V+21,1:POKE 2040,36
30 POKE V,170
50 FOR X=59 TO 5 STEP -1
60 POKE V+1,ABS(SIN(X/20))*210
70 NEXT X
100 GOTO 50
READY.
Il tutto è dato dalla riga 60, che imposta il movimento dello sprite solo sull'asse verticale. Sfruttando il movimento sinusoidale solo su quest'asse e mancando quindi il contemporaneo spostamento in orizzontale, si ottiene così il movimento che va su e giù tipico dello yoyo.
-----------------------------------------
ho aggiornato l'allegato con la correzione
-
Ecco uno dei tanti casi in cui e' sconsigliato usare CCS.
Con vice (e con un c64 vero) non si vede nessuno sprite, e ti spiego anche il perche': CCS riempie la memoria di pattern FF...00 al contrario rispetto al c64, prova a vedere da monitor con
M 0800
appena sono partiti i 2 emulatori.
L'ideale e' sempre definire lo sprite, senza affidarsi al contenuto della memoria.
-
Grazie per averlo fatto notare. Non l'ho definito perchè ciò che mi interessava è il movimento e poteva bastare anche il cubetto per lo scopo. Vai a sapere che invece la scorciatoia per lo sprite mi dava buca fuori dal ccs. :angry:
Ricapitolando, il programmino è visualizzabile correttamente solo con ccs64.
Stavo pensando che non tutti i mali... forse è un occasione buona per coinvolgere (finalmente) qualche nuovo nome a definire uno sprite carino ed integrarlo al posto di quello fittizio della memoria. :)
Io lancio la proposta, spero che non sfumi come lo sprite...
-
Grazie per averlo fatto notare. Non l'ho definito perchè ciò che mi interessava è il movimento e poteva bastare anche il cubetto per lo scopo.
Ora sai che non bisogna mai dare per scontato che la memoria sia riempita di FF come te lo aspettavi. Negli emulatori puoi anche far si' che all'accensione sia settata tutta la memoria piena di 00 anziche' il pattern di 64 $00 + 64 $FF ripetuti. Senza contare che alcune cartucce possono mettere altri valori, tipo la Action replay.
Vai a sapere che invece la scorciatoia per lo sprite mi dava buca fuori dal ccs. :angry:
:huh: Me la spieghi questa frase, che non si capisce un granche'?
Ricapitolando, il programmino è visualizzabile correttamente solo con ccs64.
Se lo correggi perche' sia funzionale anche su c64 (e vice e hoxs64, etc) e' meglio.
Stavo pensando che non tutti i mali... forse è un occasione buona per coinvolgere (finalmente) qualche nuovo nome a definire uno sprite carino ed integrarlo al posto di quello fittizio della memoria. :)
Io lancio la proposta, spero che non sfumi come lo sprite...
Inizia intanto a definirlo tu da codice, e magari mettendolo nel tapebuffer perche' a $0900 come l'hai messo tu, e' a rischio di sovrascrittura, se aumenti di qualche linea il codice.
20 POKE v+21,1:POKE 2040,13
21 forx=832to895:pokex,165:next
con 165 ($a5, %10100101) ci metti un pattern diverso dal $ff giusto per capire che e' lo sprite giusto.
-
Vai a sapere che invece la scorciatoia per lo sprite mi dava buca fuori dal ccs. :angry:
:huh: Me la spieghi questa frase, che non si capisce un granche'?
Come scorciatoia intendo l'aver visualizzato lo sprite senza definirlo, dando per scontato che andasse bene anche sul c64. Anche se devo dire che la situazione è stata utile per capire certe cose.
A disegnare uno sprite realistico non mi ci metto. Ho aggiunto solo il tuo codice, usando 60 invece di 165; così la forma mi sembra più vicina ad uno reale. Ora dovrebbe andare bene ovunque.
10 V=53248
15 PRINT CHR$(147)
20 POKE V+21,1:POKE 2040,13
21 FOR X=832 TO 895:POKE X,60: NEXT X
30 POKE V,170
50 FOR X=59 TO 5 STEP -1
60 POKE V+1,ABS(SIN(X/20))*210
70 NEXT X
100 GOTO 50
READY.
-
Precalcolando una tabella di valori si velocizza l'esecuzione. Data una formula y=sin(x), essendo i valori di x e y costanti e' inutile ricalcolarli ad ogni ciclo.
start tok64 Yoyo2.prg
10 v=53248:dt=49152
15 PRINT CHR$(147);
19 print"definisco sprite"
20 POKE v+21,1:POKE 2040,13
21 forx=832to895:pokex,165:next
30 POKE v,170
39 print"precalcolo sinus"
40 d=dt:FOR x=59 TO 5 STEP -1
41 poked,ABS(SIN(x/20))*210
42 d=d+1:next
49 print"fatto":v1=v+1
50 d=dt:FOR x=59 TO 5 STEP -1
60 POKE v1,peek(d)
70 d=d+1:NEXT
100 GOTO 50
stop tok64
-
Per la serie "sottilizziamo" :)
start tok64 Yoyo2.prg
10 v=53248:dt=49211
15 PRINT CHR$(147);
19 print"definisco sprite"
20 POKE v+21,1:POKE 2040,13
21 forx=832to895:pokex,165:next
30 POKE v,170
39 print"precalcolo sinus"
40 d=dt:FOR x=5 TO 59
41 poked,SIN(x/20)*210
42 d=d-1:next
49 print"fatto":v1=v+1
50 d=dt:FOR x=5 TO 59
60 POKE v1,peek(d)
70 d=d-1:NEXT
100 GOTO 50
stop tok64
mi sembrava inutile incrementare d a step uno e decrementare il ciclo for-next a step -1; partiamo direttamente da d=49211 e decrementiamo d con step -1...
il vantaggio è minimo, si accorcia il prg di un'inezia
ABS mi sembra inutile, non viene generato nessun valore negativo
ciao
-
Giusta osservazione, il buon programmatore cerca sempre di aiutare il processore a non lavorare troppo, meno calcoli da fare a runtime determinano un programma piu' veloce :lol:
-
meno calcoli da fare a runtime determinano un programma piu' veloce :lol:
Giustissimo, anche se non bisogna dimenticare che a volte si aggiungono volontariamente calcoli per rallentare; dipende da cosa si deve rappresentare.
Veloce così sembra un palleggio tipo cestista folle. ;)
-
Giustissimo, anche se non bisogna dimenticare che a volte si aggiungono volontariamente calcoli per rallentare; dipende da cosa si deve rappresentare.
mi vuoi forse dire che l'hai fatto apposta? ;)
-
Assolutamente no iAN, anche la mia era una considerazione generale. In questo caso non c'era nulla da frenare, il ritmo dettato dalla funzione sembrava fatto su misura. :)
Sono contento che la discussione si sia evoluta coi vostri contributi.