Mir hat's beim Anblick des Listings im Thread Bitte melde dich an, um diesen Link zu sehen. in den Fingern gejuckt, insbesondere bei dem Trick mit DIMF%(8000). Ich hatte mich schon lange gefragt, ob über das Array auch Grafik erzeugt werden kann (Antwort ja) - und ob es performanter ist (im konkreten Fall ... eher nein).
Warnhinweis am Anfang:
Das ist eine reine Machbarkeitsstudie. Der Ansatz ist robust wie ein Kartenhaus - eine unbedachte Änderung im Code und die Grafikerzeugung macht Murks. Nett, es mal gesehen bzw. gemacht zu haben. Ich hab viel über Speicherverwaltung im C64 gelernt.
Vorüberlegungen:
Ausgangspunkt bei meiner Überlegung war das Integer-Array F%. Integer ist beim C64 ein 16Bit-Zweierkomplement, erstes Bit ist das Vorzeichenbit (Wert -32768), der Rest ganz normal (16384, 8192,...,1). Abgelegt wird der Integerwert wie folgt: zuerst das höherwertige Byte, dann das niederwertige. Da im Array alle Werte ohne Lücken aufeinanderfolgen kann über den Index indirekt auf den darunterliegenden Speicher zugegriffen werden.
Zuerst heißt's herausfinden, wo genau das Array im Speicher liegt. Und da gibt's den großen Pferdefuß: die Zuordnung ist nicht fest. Sobald eine neue Variable eingeführt wird, verschiebt sich das Array - samt Inhalt (und aus Grafik wird Murks). Ergo: zuerst alle Variablen definieren und erst danach herausfinden, wo das Array liegt. Am besten das Array als letztes anlegen - so gibt es kein zeitraubendes Verschieben durch neue Variablen und die Adresse kann über die Endeadresse des Arrayspeichers (in $31,$32 bzw. 49,50) ermittelt werden und damit der Startbereich des Grafikspeichers in F%. Es macht das Leben einfacher, wenn man in dem Zuge gleich dafür sorgt, dass die Arrayelemente auf einer geraden Adresse beginnen (falls das nicht der Fall ist - einfach eine Zahlenvariable einführen, der Speicher verschiebt sich dann um 7 Byte).
Genug der Worte, hier der abgewandelte Code aus dem anderen Thread - er hat leider nicht gewonnen durch die Eingriffe. Ich hab' versucht, den Kern und die Bedeutung der Variablen beizubehalten.
0 rem 2015-08-23 j@klasek.at
1 rem optimiert
2 rem 2015-09-29 tale-x f%-experiment
3 rem nach run/stop mit goto27 zum textmodus
4 ti$="000000"
5 dimmi(319),ma(319),xp,yp,r,fl,xr,yr,x,y
6 dimbi%(7,1),ad,s
7 z7=7:z8=8:m7=504:z2=2:z3=3:z4=4:z5=5:e4=40:z1=1
8 yl=200:n1=-1:n5=.5:z=0:nh=900:eh=100:hs=160:sf=56:vz=14:e=1
9 dim li(199)
10 s=1:bi%(0,0)=-32768::fort=0to14:bi%(7-(7andt),1-int(t/z8))=s:s=s+s:next
11 a=0:fort=0to99:li(t*2)=a:li(t*2+1)=a:a=a+z1:if(3anda)=0thena=a+156
12 next
13 dim f,q,z,a$,f%(8000):if(peek(49)and1)thendimqq
14 a=8001-((peek(50)*256+peek(49))-8192)/2:fort=0to199:li(t)=li(t)+a:next
15 forx=0to319:mi(x)=yl:ma(x)=n1:next
16 poke53265,59:poke53272,24:poke53280,2
18 s=97:fort=1024to2023:poket,s:next
19 fory=30to-30stepn1:xp=int(z4*sqr(nh-y*y)+n5)
20 forx=-xptoxp:xr=x/sf:yr=y/vz:r=sqr(xr*xr+yr*yr)
21 f=cos(r)-cos(z3*r)/z3+cos(z5*r)/z5-cos(z7*r)/z7
22 fl=z:xp=hs+x-y:yp=eh+z2*y-int(e4*f+n5)
23 ifmi(xp)>ypthenmi(xp)=yp:fl=e
24 ifma(xp)<ypthenma(xp)=yp:fl=e
25 ifflandyp>=zandyp<ylthengosub29
26 next:next:poke53280,3
27 forq=n1toz:geta$:q=a$=" ":next:sys58648:printti$:end
28 :end
29 ad=li(yp)+int(xp/z8)*z4:f%(ad)=f%(ad)orbi%(xpandz7,ypandz1):return
30 :
31 rem ** c64 hat written 2015-08-20 by michael kircher
Alles anzeigen
Die wichtigsten Zeilen:
13 - Ggf. Verschiebung des Speichers durch Hinzufügen der Variable QQ
14 - Berechnung, an welchem Index die Speicheradresse 8192 liegt. Danach wird auch keine Variable mehr hinzugefügt
29 - Bildpunkt setzen
Viel Spaß beim Ausprobieren und Experimentieren. Kleines Beschleunigungspotenzial sehe ich noch in Zeile 29 bei int(xp/z8)*z4, da könnte man ein Wertearray für xp verwenden.
Ach ja, die Zeiten:
Das ursprüngliche Listing hatte im Vice 53:17 Minuten gebraucht, diese Fassung hier 54:09.
Viele Grüße
Tale-X