@Green Tentacle . Da die fitnesstudios zu haben muss man sich was einfallen lassen.
BASIC-Programme - "wirbleibenzuhause"
-
Snoopy -
26. März 2020 um 15:00 -
Erledigt
Es gibt 103 Antworten in diesem Thema, welches 26.082 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Gibt es das auch als CBR-Datei, damit man es sich auf ein FC ziehen kann? Oder das neue Kung Fu Flash?
TSB ist ein Onefiler von $8000 bis $cfff mit Stellen, die beschreibbar bleiben müssen ($c000.. ist Farbram für die Grafik, $c500.. ist Parameter-Puffer, $cc00.. ist Videoram nach MEM). Ein paar Bereiche werden u.U. ausgetauscht (bei NRM, MEM, INST und GRAPHICS). Kung Fu Flash?
Arndt
-
@Green Tentacle . Da die fitnesstudios zu haben muss man sich was einfallen lassen.
Na dann bastel mal ein entsprechendes Controler-Set für Combat School :emojiSmiley-123:
-
Gibt es das auch als CBR-Datei, damit man es sich auf ein FC ziehen kann? Oder das neue Kung Fu Flash?
TSB ist ein Onefiler von $8000 bis $cfff mit Stellen, die beschreibbar bleiben müssen ($c000.. ist Farbram für die Grafik, $c500.. ist Parameter-Puffer, $cc00.. ist Videoram nach MEM). Ein paar Bereiche werden u.U. ausgetauscht (bei NRM, MEM, INST und GRAPHICS). Kung Fu Flash?
Arndt
Ok, dann geht das natürlich nicht. Oder doch - es müsste sich halt erst ins RAM kopieren, irgendwie wäre das bestimmt möglich. Ich bin aber kein Fachmann.
Das Kung Fu Flash ist ein neues Modul, Hier gibt es Infos dazu:
Bitte melde dich an, um diesen Link zu sehen.
Ich hab eins hier, Bigby bietet ab und zu über den Marktplatz fertig aufgebaute Module an.
-
Vielleicht freeze ich es für mein Archiv mal, kurz vor dem Animations-Start, dann muss man gar nicht mehr warten.
Wenn du es so speicherst, hast du aber immer das selbe Bild. Der zufällige Aufbau ist dann außen vor. Für ein einzelnes Bild würde
ich nur die Bitmap speichern und dann den Code für die Animation hinzufügen.
Und weil wir gerade bei "Linien ziehen" sind: Gab es für Homecomputer nie so etwas, wie das Hobbythek Bilderrätsel, bei dem man mit einem Filzer auf dem Bildschirm einem Leuchtpunkt folgen und am Ende dann das bildlich dargestellte Wort erraten musste? Das wäre doch gar nicht so schwer umzusetzen, oder?
Hallo Retrofan, ich habe so ein Programm für den C64 fertig. Ich brauche nur noch jemanden zum Testen. Ich halte es aber für sinnvoller das Programm
für den PC zu schreiben. Dann kann man statt des Filzstiftes mit der Maus dem Lichtpunkt folgen.
Sieht auf jeden Fall schon grafisch stark aus.
Danke. Mit Animation wird's noch besser.
Eine Zufallsfunktion, was die Farben sowie die Dicke der Kreisringe angeht, könnte noch cool sein.
Beides ist möglich. Zufällige Farben sehen wahrscheinlich nicht so gut aus, weil die Farben zueinander passen sollten.
Unterschiedlich dicke Kreisringe vertragen sich nicht so gut mit der Animation. Aber das Programm ist noch ausbaufähig,
ich teste noch ein bisschen herum.
Ist der CCS64-Emulator schneller als der Vice-Emulator?
Ich war mal so frei, das zu kompilieren (läuft danach ungefähr 4,5mal schneller).
Ja, die kompilierte Version ist um einiges schneller. Das liegt aber auch zum Teil daran, dass du die
Zahl der Kreise reduziert hast.
Gruß,
Neptun
-
Wenn du es so speicherst, hast du aber immer das selbe Bild. Der zufällige Aufbau ist dann außen vor. Für ein einzelnes Bild würde
ich nur die Bitmap speichern und dann den Code für die Animation hinzufügen.
Das stimmt natürlich, der bessere Weg ist über die WARP-Funktion des CCS64 und dazu noch eine kompilierte Version des Programms zu nehmen, wie es etwa der User "EgonOlsen" weiter vorne gemacht hat, dann geht's auch so schon richtig flott, bis das Bild voll aufgebaut ist und die Animation startet.
Ist der CCS64-Emulator schneller als der Vice-Emulator?
Er lässt sich, meiner Erfahrung nach, auf jedenfall wesentlich schneller beschleunigen als alle anderen C64 Emulatoren, da er bei weitem die geringsten Ansprüche an die CPU des PC's stellt. Schon auf wirklich alten Rechnern, läuft der CCS64 bereits in Fullspeed ohne Frameskipping. Ich bekomme ihn auf meinem PC, der jetzt auch nicht gerade top-aktuell ist, auf 37-fachen Speed (3700%), das geht dann schon ordentlich ab. Musst du mal ausprobieren auf deinem System mit der Version 3.9.2 des CCS64, du wirst dich wundern wie schnell man ihn bekommt. Im Menue des Emu's kann man maximal bis zu 100-fachen Speed einstellen, aber ich weiss nicht, ob das in der Realität überhaupt möglich ist, wegen der Bildwiedergabe. Wahrscheinlich wird man nicht auf die vollen 10000% Speed kommen, aber mal sehen wieviel Speed dein PC da dann schafft, da könntest du mal eine Rückmeldung geben, es würde mich interessieren.
-
Ich war mal so frei, das zu kompilieren (läuft danach ungefähr 4,5mal schneller).
Ja, die kompilierte Version ist um einiges schneller. Das liegt aber auch zum Teil daran, dass du die
Zahl der Kreise reduziert hast.
Ich verstehe nicht, was genau du meinst!? Ich habe an dem Programm doch gar nichts in der Richtung verändert...jedenfalls nicht bewusst.
-
- Offizieller Beitrag
Hallo Retrofan, ich habe so ein Programm für den C64 fertig. Ich brauche nur noch jemanden zum Testen. Ich halte es aber für sinnvoller das Programm
für den PC zu schreiben. Dann kann man statt des Filzstiftes mit der Maus dem Lichtpunkt folgen.
Nur wegen der Maus müsstest du nicht zum PC wechseln – die gibt es auch für den C64. Ich weiß aber nicht, inwiefern sich der Spaß ändert, wenn man dem Punkt mit dem Mauspfeil folgt, statt mit dem Filzer. Ich kann die Frage ja mal in die Runde werfen ...
-
Ich verstehe nicht, was genau du meinst!? Ich habe an dem Programm doch gar nichts in der Richtung verändert...jedenfalls nicht bewusst.
Also, in dem Programm, das ich gepostet habe steht die Anzahl der Kreise auf 11. Zeile 80: n=11
Das heißt, es sind immer 11 Kreise sichtbar. Bei deinem kompilierten Code werden aber immer 8Kreise gezeichnet. Könnte ein Tippfehler sein, oder der Compiler hat ein Problem mit dem
Programm.
Gruß,
Neptun
-
Also, in dem Programm, das ich gepostet habe steht die Anzahl der Kreise auf 11. Zeile 80: n=11
Das heißt, es sind immer 11 Kreise sichtbar. Bei deinem kompilierten Code werden aber immer 8Kreise gezeichnet. Könnte ein Tippfehler sein, oder der Compiler hat ein Problem mit dem
Programm.
Ahhhh, ok. Vielen Dank für den Hinweis. Ja, der hatte tatsächlich ein Problem mit dem Programm. Weil du da beim Initialisieren des Arrays immer mal mit GOTO aus der inneren Schleife springst. Was der Interpreter bei dieser Schmutzigkeit macht, war mir nicht klar. Dieser Fall ist mir in all meinen (über 100) Testfällen auch noch nie untergekommen. Deswegen habe ich das in der Compiler-Runtime falsch behandelt und den Stack nicht entsprechend bereinigt. Ist jetzt korrigiert, im Anhang ist eine richtig laufende Fassung. Das sollte auf die Geschwindigkeit selber aber eigentlich keine große Auswirkung haben, weil auch das alte Programm durchaus alle 11 Kreise bearbeitet hat...nur lagen eben immer ein paar davon irgendwie außerhalb, weil das Array nicht vollständig mit "guten" Kreispositionen initialisiert worden ist.
-
Nachtrag zu dem ++colors.prg von eben: Das muss man natürlich auch wieder mit SYS20000 starten. Leider kann ich den Post oben nicht mehr editieren, weil...Gründe...
-
Weil du da beim Initialisieren des Arrays immer mal mit GOTO aus der inneren Schleife springst.
Ja, das stimmt. Das C64-Basic erlaubt das Verlassen der Schleife mit Goto, warum
sollte man es nicht nutzen. Exit For oder ähnliches gibt es ja nicht. Die Alternative
sieht auch nicht sehr elegant aus. Man müßte die Schleifenvariable auf den Endwert
setzen und dann mit Goto zu dem Next springen. Außerhalb der Schleife springt man
dann flaggesteuert wieder vor die Schleife.
Ist jetzt korrigiert, im Anhang ist eine richtig laufende Fassung.
Getestet und funktioniert.
Hier noch mal eine überarbeitete Version der konzentrischen Kreise mit 16 Farben.
Sollte etwas schneller sein:
Code
Alles anzeigen1 goto10 2 ifc1=cthenq=1:return 3 ifc2=cthenq=2:return 4 ifc3=cthenq=3:return 5 ifc1=.thenq=1:c1=c:return 6 ifc2=.thenq=2:c2=c:return 7 ifc3=.thenq=3:c3=c:return 8 q=sand3:ifqthenreturn 9 q=peek(a-1)/h(x2)and3:return 10 poke56,160:clr:dimc(61e2):clr:poke56,92:clr:sys58648 20 v=53248:pokev+33,.:pokev+32,11:dimc1,c2,c3,c,q:s=rnd(-ti) 30 p=32576:w$="wait..":fori=ptop+126:pokei,.:next:fori=.to1:z=v+i+i 40 pokez,136+48*i:pokez+1,235:poke24568+i,253+i:pokev+39+i,3:next 50 poke56576,198:pokev+24,16*7+8:pokev+17,59 60 pokev+23,3:pokev+29,3:pokev+21,3 70 poke56334,.:poke1,51:fori=.tolen(w$)-1:b=v+8*(asc(mid$(w$,i+1))and63) 80 forj=p+i+61*int(i/3)toj+21step3:pokej,peek(b):b=b+1:next:next 90 poke1,55:poke56334,1 100 n=11:a=24576:m=.5:p=n-1:vr=23552:fr=55296-vr:e=1e6:u=16:w=15 110 k=320:d=k-1:t=198:g=24^2:dimx(p),y(p),qx(3,p),qy(7,p),f(w),h(3) 120 fori=.tow:readf(w-i):next:fori=.to3:h(3-i)=4^i:next 130 printchr$(158)chr$(147):f=16*5+2:fori=vrtoi+999:pokei,f:next:pokev+22,24 140 fori=.top 150 x=int(rnd(1)*k):y=int(rnd(1)*2e2):ifi=.then180 160 forj=.toi-1:dx=x-x(j):dy=y-y(j):ifdx*dx+dy*dy<gthen150 170 next 180 x(i)=x:y(i)=y:next 190 fory1=.to199step8 200 fori=.to7:y=y1+i:forj=.top:dy=y-y(j):qy(i,j)=dy*dy:next:next 210 forx1=.todstep8 220 fori=.to3:x=x1+2*i:forj=.top:dx=x-x(j):qx(i,j)=dx*dx:next:next 230 c1=.:c2=.:c3=.:fory2=.to7:s=. 240 forx2=.to3:r=e:fori=.top:r1=qx(x2,i)+qy(y2,i):ifr1<rthenr=r1 250 next:q=.:c=f(m+sqr(r)/4andw):ifcthengosub2 260 s=s*4+q:next:pokea,s:a=a+1:next 270 pokevr,c2+u*c1:pokefr+vr,c3:vr=vr+1:next:next:pokev+21,. 280 fori=.to96:pokev+32,i:next 290 poket,.:waitt,1:poke56576,199:sys58648:poket,.:poke56,160:clr:end 310 rem farbliste 320 data 10,02,09,08,07,13,05,03 330 data 14,06,04,00,11,12,15,01 340 rem 2020 by neptun 350 :Gruß,
Neptun
-
Ja, das stimmt. Das C64-Basic erlaubt das Verlassen der Schleife mit Goto, warum
sollte man es nicht nutzen. Exit For oder ähnliches gibt es ja nicht. Die Alternative
sieht auch nicht sehr elegant aus. Man müßte die Schleifenvariable auf den Endwert
setzen und dann mit Goto zu dem Next springen. Außerhalb der Schleife springt man
dann flaggesteuert wieder vor die Schleife.
Nee, eine Art BREAK gibt es nicht. Weil es im Prinzip auch gar keine Schleifen gibt. Ja, steile These, aber: FOR und NEXT hängen im BASIC V2 nicht direkt zusammen, wie sie das in einer modernen Sprache tun würden. Es sind voneinander unabhängige Befehle, die nur über den FOR-NEXT-GOSUB-Stack verbunden sind. Es kann kein BREAK geben, weil der Interpreter gar nicht wissen kann, welches der zu unterbrechende Schleifenblock sein soll...weil es strukturell gar keinen gibt. Deswegen sind mit FOR-NEXT alle möglichen Schmutzigkeiten möglich. Ich bin davon überzeugt, dass mindestens die Hälfte davon quasi "aus Versehen" entstanden ist und gar nicht bewusst so entworfen worden ist. Ich kann problemlos ein Programm mit einem FOR und 25 NEXT schreiben...oder umgekehrt. Völlig blödsinnig, aber syntaktisch korrekt.
-
Nur wegen der Maus müsstest du nicht zum PC wechseln – die gibt es auch für den C64.
Ja, aber ein C64 mit Maus ist selten.
Hier mal die C64-Basic-Version des Hobbythek-Bildschirmrätsels zum Testen:
Bitte melde dich an, um diesen Anhang zu sehen.
Code
Alles anzeigen1 goto10 3 dx=x2-x1:dy=y2-y1:ifdx=.anddy=.thenreturn 4 ifabs(dx)<abs(dy)then7 5 s=sgn(dx):f=dy/dx*s:y=y1 6 forx=x1tox2steps:b=x(x)+y(y):pokeb,peek(b)orh(xand7):y=y+f:next:return 7 s=sgn(dy):f=dx/dy*s:x=x1 8 fory=y1toy2steps:b=x(x)+y(y):pokeb,peek(b)orh(xand7):x=x+f:next:return 10 poke56,92:clr:c$=chr$(147):gosub220:m$=" bitte warten ...":printm$ 11 deffnbt(i)=asc(mid$(x$,i))+m*asc(mid$(x$,i+1))-n 12 m=16:n=1105:p=828:cl=p:d$=chr$(17):u$=chr$(145) 13 readx$:ifx$="#"then40 14 fori=1tolen(x$)step2:pokep,fnbt(i):p=p+1:next:goto13 40 a=24576:d=504:e=v+16:t=255:k1=20:k2=46:dimp(1),x(319),y(199),h(7),pg(99) 50 s=1:fori=.to7:h(7-i)=s:s=s+s:next:fori=.to319:x(i)=iandd:next:z=.:print 52 fori=atoa+7680step320:printz;u$:forj=itoi+7:y(z)=j:z=z+1:next:next 55 p=15*64:fori=ptop+62:pokep,.:next:z=v+8*86:poke56334,.:poke1,51 56 fori=.to7:pokep+3*i,peek(z+i):next:poke1,55:poke56334,1:poke2040,15:q=. 60 r1$=chr$(18):r2$=chr$(146) 61 syscl:printspc(t)spc(t)spc(61)r1$"s"r2$"tart" 62 printspc(51)r1$"l"r2$"oesung ansehen":printspc(51)r1$"e"r2$"nde" 63 printchr$(19)d$d$:fori=.to3:a$=" ":b$=a$:ifi=qthena$=">":b$="<" 64 printd$,a$"raetsel"str$(i+1)b$:next 65 poke198,.:wait198,1:geta$:ifa$="e"then210 66 ifa$="s"ora$=chr$(13)then440 67 ifa$=u$thenq=q-1and3:goto63 68 ifa$=d$thenq=q+1and3:goto63 69 ifa$<>"l"then65 70 printc$:gosub410 80 poke2,16*1+6:syscl+3:pokev+17,59:pokev+24,16*7+8:poke56576,198:pokev+32,6 95 k=0 100 readx$:ifx$="#"thengosub400:c=0:gosub180:gosub220:goto61 110 ifx$="-"thengosub400:goto95 120 z=.:fori=1tolen(x$)step2:p(z)=fnbt(i):z=z+1:ifz<2then140 135 z=.:ifk=.thenk=1:x1=2*p(0):y1=p(1):x3=x1:y3=y1:goto140 137 x2=2*p(0):y2=p(1):gosub3:x1=x2:y1=y2 140 next:goto100 180 fori=.to99:pokev+32,i:next:pokev+32,c:ifc=15thenreturn 190 poke198,.:wait198,1:return 210 sys58648:poke56,160:clr:poke198,.:end 220 poke56576,199:sys58648:v=53248:printchr$(5)chr$(8) 230 pokev+33,.:pokev+32,9:return 400 x2=x3:y2=y3:gosub3:return 410 restore:fori=1toq+1 420 readx$:ifx$<>"#"then420 430 next:return 440 printc$chr$(144)m$d$:pokev+32,15:pokev+33,15:gosub410 450 b=a:u=0 455 z=0:printu;u$ 460 readx$:ifx$="#"then500 470 ifx$="-"thenpg(u)=z:u=u+1:goto455 480 fori=1tolen(x$)step2:pokeb,fnbt(i):b=b+1:z=z+1:next:goto460 500 pg(u)=z:u=u+1 510 z=a:printc$"los geht's":forw=.to2e3:next 520 fori=.tou-1:printc$"neue linie":p=pg(i) 521 x1=peek(z+p-2)*2+k1 522 y1=peek(z+p-1)+k2 523 pokev,x1andt:pokee,-(x1>t):pokev+1,y1:pokev+21,1:c=2 524 fork=.to10:pokev+39,c:c=7-c:forw=.to4e2:next:next 525 printc$ 530 forj=.top/2-1 540 x2=peek(z)*2+k1 550 y2=peek(z+1)+k2:z=z+2 570 gosub710:x1=x2:y1=y2 600 nextj 601 printc$"ende der linie":forw=.to2e3:next:pokev+21,. 609 nexti 610 printc$"fertig."d$:c=15:gosub180:s=.:poke198,. 620 ifs=.thenprint"taste zur rueckkehr ins menue" 630 forw=.to800:ifpeek(198)thengosub220:goto61 640 next:s=1-s:printc$;:goto620 690 : 710 dx=x2-x1:dy=y2-y1:ifdx=.anddy=.thenreturn 720 ifabs(dx)<abs(dy)then750 730 s=sgn(dx):f=dy/dx*s:y=y1 740 forx=x1tox2steps:pokev,xandt:pokee,-(int(x)>t):pokev+1,y:y=y+f:next 745 return 750 s=sgn(dy):f=dx/dy*s:x=x1 760 fory=y1toy2steps:pokev,xandt:pokee,-(int(x)>t):pokev+1,y:x=x+f:next 765 return 800 rem 2020 by neptun 810 : 900 data mecedamemidajkianibcannigicaaceefockbaoigicakmoibcanakeagilpeimpckibjk 901 data ggakhcaocaajmaaohbaliaamcaajeaamgcajeabjlpjeaiiiabjojeaiikfklpibjgicfi 902 datalpajcagompijkmabfnagckioaklfgilpeimpckeaakibfkcaaclkdackaeakpfgilpeimp 903 data ckacakamjkaabjlpimanlpgompkmangpag,# 2000 data kjgijjcjijnjfjikbjblmijlhiplbicmlhdmfhcmpgplkgjlfgblbgikpfojnfcjmfgi 2001 data nfnhoffhpfngbgfghgifogpemgdelecjcebjaeljodekldnkhdflddllocpljccmecdm 2002 data obcmibpldbjloablkaikianjgacjfagigakhiapgkaegoalfdbdfiboeobkeecjekcke 2003 data adoehdncedobfdobdddbaddboccblcpakcmakcialcfamceancdapcdacdfaedgagdga 2004 data jdgaldfamdfandgaodjandlakdoahdbbfddbhdnbhdmbjdhchghcdgcbdglafhlafhcb 2005 data hgcbbhneghkelhjebikehioemidfbjlffjegijpgjjkh,- 2006 data gjgigjlhejbhcjigoiagkijffiefaibflhafhhbfchdffhaghhlgihfhkhnhmhiimhki 2007 data lhkikhjijhhiiheihhphpgffjgofegjgbgghaggiagbjcgljegekigmkmgdlbhilghll 2008 data lhmlaillfiilkidloimkcjekejljgjbj,- 2009 data lgmdigocldocleii,- 2010 data ielijdgdddbfjdlfodhgbefhcegiceki,- 2011 data pdjipdgiodihldlghdagbdhfhcfi,- 2012 data odajccliocefjcbfecafobbfjbeffbjfbbagnaiglabhjalhjagijabjlaljnaekbbmk 2013 data fbdljbilobllecmlicllncjlbdflfdalidjkldbkndjj,# 3000 data fgigegngdgdhaglhnffimfeipfkhcgchdgmgegigdgegeggg,- 3001 data kgodjgbeigceigceagbgcgegdgigcgmgbgchofkhlfdiefmhifpgefmgafkgmeigkefg 3002 data ieaghelfiegfiepekeielepdkeodiemdgekdgeidfcjefcmefcoeecoedcnecckebcle 3003 data acjeccieccfecceedcdeeceeechefegdgebdhepcjeockeocmeocneocoeocbfmcdfmc 3004 data gfnchfjcgficffjccfjceffcbfgcoeicpeeccfbcpeacmeacoembpelbcfmbefnbdfmb 3005 data cfkbpeibnejboeebpecbbfdbdffbcfabbfkadfnaffabefeahfoalfgbpfkbcgnbcgbc 3006 data cgeccggccghccgjccgkcbglcbgmcagncagpcpfpcofpcnfocmfadofddpfedagfddggd 3007 data ggldigldjgmd,- 3008 data mfgikfmijfkilffi,- 3009 data ohbmnhdmmhdmkhdmfgjkdggkagekofakkfmjjfljhfjjdfgjpecjidnhidkhmelikdfh 3010 data kdehafniefohlfeijfjijflilfpimfdjnffjofhjnfkjofkjpfmjbgojegakjhdlmhfl 3011 data ohelnhillhjlihhlghglehelegfklhbmnhbm,- 3012 data hgbeggaeegaeagpdmfpdlfeejfjehfoegfcfffhfhfjfkflfmfnfpfag,- 3013 data echedcfedceeccgedche,- 3014 data ecleecjedcjedcmeecme,# 4000 data lfoeifbfefefhfjfdfkfpelflelfielffelfcekfbekfpdjfndifmdgflddfldpeldle 4001 data mdgepdbecekdjencienchemcfekcdejcaejcndjcndccndnbodcbaekadefaiedameea 4002 data peiacfoadfhbcfnbbfccpegcmehcnejcbfgccffcefgchfjckfncnfcdpfidbgodcgce 4003 data dggecgkeagme,- 4004 data hifjhinjgijkeidlcihlphklnhllkhmlhhmldhklahhlngeljglkhgckhggkggjkdgnk 4005 data pfalifdlneglcegldefldecleeokeejkeeakdeijcepiaegiodmhldchhdahbdogkckg 4006 data gcjgbcigobjgmbnglbhgmbmfpbcfdcieicodocgdedadjdmcndlcbelceelcgemcgenc 4007 data geocfebddefdaekdndaeldfekdkejdpekdffndkfbenfieofbfofjfmfmfegagpgdglh 4008 data fgfiggajgghieglhcgbhpfggnfofkfifhfefofafdgoefgoeggpehgcfiggfjglflggg 4009 data mgbhngihngaiogkipggjbhnjdhdkghhkjhikmhhkohfkphakphkjphcjmhkijheiehci 4010 data bheipgjipgfipgaiogkhngchmgfgjggfahefhhdflhefohffphhfailfaiofaicghhhg 4011 data phfgaiggbijgbingphpgahdhahghfhehihfhlhghnhjhaimheihi,- 4012 data cehjdeikdenkceblcedlbeelpddlodclmdjljdplfdcmbddmnccmjcamfcmlbchlobal 4013 data lbjkjbbkibjjhbmiibeijbnhlbhhnbchmbpgpblgcckggclgkcmgbdahfdchkddhndph 4014 data aemi,- 4015 data meibjehbeefbodfbodjbodpbodccodhccehcfegcjedcmepb,- 4016 data gfkegfgeffdeefbecfaepecenegepegepeheoehelegekegejefehefefefedeiebeke 4017 data benebeafdedffeefieffkeefmedfnedfafdfdfbfffoe,- 4018 data gdejfdoiedjiddpicddjadgjpchjpcgjocfjoccjncnilccijclhgcmhecaidcficcmi 4019 data dccjdcijfcnjgcdkjchklckkocmkbdnkddmkfdjkgdekhdnj,- 4020 data lenelepekeafjepejenejelekekelele,# 5000 data hflfgfbgdfcgafcgnecgkebgjelfaedfpdiepdeendndldedldpcldicldacmdjboddb 5001 data benaeejahegameeaafdaffeajfgamfjapfnacgdbegjbfgacfgicfgpceggddgndbgee 5002 data agieagdf,- 5003 data lfnfjfjggfahefdhdfghcfihafihoeihmeghledhkeahgejgfenfhemfhepfjeegkehg 5004 data mejgpejgdfjgffhghfegifpfjfmf,- 5005 data afcjcfpigfmijfiiofeipfdiagcieglhgghhigehkgdhmgfhmgkhmgnhmgciogiipgmi 5006 data ogbjmgcjjgajgglicgniofajkfejffjjhfljlfakaggkbghkdgkkiglkmgokogblpgfl 5007 data oghlngjllglljgmlggbmegdmdgcmcgamagnlpfilpfelhfikafpjiejkaeflaellpdam 5008 data odcmmddmlddmkdbmjdplhdlledllcdjlbdhladelbdalddnkedmkhdlkkdkkndjkeebk 5009 data lejjgeejbeajndnikdlihdajedbjbdajadmibdiiddciddnhddkhedehgdchiddhkdgh 5010 data mdlhaeciheii,- 5011 data cemddebeeefefeheheiekehelefemebeneldmehdleedkecdiebdfecdeeeddehd,- 5012 data dfmdefbefffegfhejfielfhemffenfbeofldnfhdmfedlfcdjfbdgfcdffedefhd,- 5013 data afgeoeneneafnecfneffpegfafffbfgfdfffdfcfdfafcfne,# 6000 :Gruß,
Neptun
-
Ja, das stimmt. Das C64-Basic erlaubt das Verlassen der Schleife mit Goto, warum
sollte man es nicht nutzen. Exit For oder ähnliches gibt es ja nicht. Die Alternative
sieht auch nicht sehr elegant aus. Man müßte die Schleifenvariable auf den Endwert
setzen und dann mit Goto zu dem Next springen. Außerhalb der Schleife springt man
dann flaggesteuert wieder vor die Schleife.
Falls ich mich recht erinnere, baut FOR eine Referenz auf die Variable auf den Stack, und NEXT zählt bei Bedarf den mit TO gegebenen Wert dazu (wobei das Inkrement glaube ich auch zusammen mit dem höchsten Ziel-Wert auf dem Stack steht). Was also passiert, wenn man eine Schleife "grußlos" verlässt, ist, dass der Schleifen-Müll auf dem Stack stehen bleibt. Macht man das oft genug, müllt man sich den Stack total zu.
Mein Vorschlag wäre daher, beim Verlassen die Variable auf den letzten Wert zu setzen, und dann ein letztes NEXT durchzuführen, dass erkennt, dass die Variable hoch genug ist (oder niedrig genug bei negativem Step), den Mǘll vom Stack entfernt, und dann weiter läuft. Der nächste Befehl kann ein GOTO sein. Beispiel:OK, habs nicht ausprobiert, sollt aber so oder so ähnlich funktionieren.
Nachtrag: Habs doch ausprobiert. Funzt! Wichtig ist nur, dass im Programm-Ablauf nicht zweimal dieselbe Variable "genexted" wird. Das gibt einen Fehler "?NEXT WITHOUT FOR ERROR IN .."
-
Falls ich mich recht erinnere, baut FOR eine Referenz auf die Variable auf den Stack, und NEXT zählt bei Bedarf den mit TO gegebenen Wert dazu (wobei das Inkrement glaube ich auch zusammen mit dem höchsten Ziel-Wert auf dem Stack steht). Was also passiert, wenn man eine Schleife "grußlos" verlässt, ist, dass der Schleifen-Müll auf dem Stack stehen bleibt. Macht man das oft genug, müllt man sich den Stack total zu.
Das mit dem Stack stimmt im Prinzip, aber in diesem Fall wird immer wieder eine neue Schleife mit derselben Laufvariablen gestartet. Die ersetzt dann den jeweils auf dem Stack verbliebenen Eintrag für diese Variable (und killt alle später auf den Stack gepushten Einträge). Das wusste ich auch nicht, deswegen hat meine Compiler-Runtime das auch anfangs nicht korrekt behandelt. Das ist eine dieser Eigenschaften, von denen ich denke, dass die mehr aus Zufall so sind wie sie sind.
-
Falls ich mich recht erinnere, baut FOR eine Referenz auf die Variable auf den Stack, und NEXT zählt bei Bedarf den mit TO gegebenen Wert dazu (wobei das Inkrement glaube ich auch zusammen mit dem höchsten Ziel-Wert auf dem Stack steht). Was also passiert, wenn man eine Schleife "grußlos" verlässt, ist, dass der Schleifen-Müll auf dem Stack stehen bleibt. Macht man das oft genug, müllt man sich den Stack total zu.
Das mit dem Stack stimmt im Prinzip, aber in diesem Fall wird immer wieder eine neue Schleife mit derselben Laufvariablen gestartet. Die ersetzt dann den jeweils auf dem Stack verbliebenen Eintrag für diese Variable (und killt alle später auf den Stack gepushten Einträge). Das wusste ich auch nicht, deswegen hat meine Compiler-Runtime das auch anfangs nicht korrekt behandelt. Das ist eine dieser Eigenschaften, von denen ich denke, dass die mehr aus Zufall so sind wie sie sind.
Danke für die Korrektur. Sehe ich es richtig, dass jedes "next" diesen Eintrag bloß erneuert? Stimmt nun meine Aussage mit dem Stack-Müll, den man hinterlässt, wenn man nicht zuende "nextet"?
-
Sehe ich es richtig, dass jedes "next" diesen Eintrag bloß erneuert? Stimmt nun meine Aussage mit dem Stack-Müll, den man hinterlässt, wenn man nicht zuende "nextet"?
Ja, aber eben nicht unter allen Bedingungen. Das ist nur dann ein Problem, wenn du verschiedene Schleifen mit verschiedenen Variablen per FOR öffnest und nicht zum Ende durchlaufen lässt. Dann ist der Stack beim 11. FOR voll und du bekommst einen Out Of Memory Error. Wenn du immer dieselbe Variable benutzt, ist das ok. Also soweit das ok sein kann, sowas zu bauen. Oder wenn du die FORs in per GOSUB angesprungenen Unterprogrammen öffnest, aus denen du vor dem "Durchnexten" mit RETURN zurückspringst, dann ist das auch ok, weil das RETURN den Stack bis zum aufrufenden GOSUB abräumt (FOR und GOSUB landen auf demselben Stack).
-
Sehe ich es richtig, dass jedes "next" diesen Eintrag bloß erneuert? Stimmt nun meine Aussage mit dem Stack-Müll, den man hinterlässt, wenn man nicht zuende "nextet"?
Ja, aber eben nicht unter allen Bedingungen. Das ist nur dann ein Problem, wenn du verschiedene Schleifen mit verschiedenen Variablen per FOR öffnest und nicht zum Ende durchlaufen lässt. Dann ist der Stack beim 11. FOR voll und du bekommst einen Out Of Memory Error. Wenn du immer dieselbe Variable benutzt, ist das ok. Also soweit das ok sein kann, sowas zu bauen. Oder wenn du die FORs in per GOSUB angesprungenen Unterprogrammen öffnest, aus denen du vor dem "Durchnexten" mit RETURN zurückspringst, dann ist das auch ok, weil das RETURN den Stack bis zum aufrufenden GOSUB abräumt (FOR und GOSUB landen auf demselben Stack).
Danke für die Info!
-
Jo genau richtig, RETURN schließt alle FOR-Schleifen.
Ansonsten kann man NEXT so verwenden, wie es passte.
z.B.
10 :for a=1 to 99:
11 :if a=10then:a=100:next:goto20
12 :ifa=20then:a=99
15 :next
20:print"hallo"
Schönen Gruß. -