Assembler - Fragen / Antworten

[Dr. Irata]

Hallo in die Runde!
Die Idee von JAC (Peter Dell) einen eigenen Assembler-Thread aufzumachen finde ich gut - und hier ist er!!
Spezielle Dinge kann man ja dennoch ausgliedern - ist dann einfacher wiederzufinden.
Aber so ganz allgemeine programmiertechnische Dinge sind hier sicherlich gut aufgehoben!
Gruß
Peter

[Dr. Irata]

Da habe ich auch schon gleich meine erste Frage, bzw. Situation, wo ich zur Zeit "hänge":
Ich habe eine Printroutine für 6-8 Softwaresprites. Diese Routine printet diese Sprites jeweils mit einem shift auf den sichtbaren Bildschirm. Alle diese Sprites befinden sich auf der untersten Reihe - das Lowbyte ist immer gleich und das Highbyte (sagen wir mal #59) auch. Die x-Position wird über ein y-Register jeweils verändert. Die Sprites laufen einmal geprintet von rechts nach links bis sie am linken Rand sind.
Der sichtbare. Bereich ist von y=0 bis y=40
Wenn ein Sprite die 0 erreicht hat, geht er raus und über einen Zufallsgenerator (0-15) ändert er sein Aussehen und soll - und nun kommt es irgendwo im unsichtbaren Bereich zwischen 41 und 79 wieder reingeprintet werden.
Das läuft schon.
Nun passiert es logischerweise aber, daß ab und an die Sprites (sie sind 5 Werte breit) sich ab und zu ganz oder zum Teil überlagern... was blöd ist.
Ich brauche also eine sehr sehr schlanke und kurze Routine, die die Sprites per Zufall dahin printet, wo "frei" ist!!
Eine wirklich brauchbar Lösung habe ich noch nicht gefunden... wie gesagt, muss ganz wenig Zeit kosten!
Danke für die Anregungen!
Gruß
Peter

[Dr. Irata]

... Lösung gefunden ... !

[pps]

... Lösung gefunden ... !

Da bin ich ja gespannt, wie Du es gemacht hast. Ich hätte da nur eine Idee gehabt, am Ende die gefundenen Werte auch abzufragen und dann überlappende nochmals zu berechnen. Ist aber definitiv nicht möglichst schnell, da ja mit etwas Pech immer wieder neue Zahlen geholt werden müssen.

Oder als andere Idee von vornherein mit genug Abstand zu planen, dass ein Überlappen garnicht möglich wäre.

[Dr. Irata]

.. nun ja, das Leben besteht ja aus Kompromissen...
die 8 Landschaftssprites (die sind ja recht groß und brauchen etliches an Rechenpower) stelle ich so dar, daß drei übereinander stehen und zwei übereinander stehen - bleiben also insgesamt 5 - zwei hohe und drei "flache".
Die Variation mache ich, indem ich nur den ganz hohen per Zufall setzen - das Aussehen selber ändert sich allerdings auch per Zufall wenn sie links rausgehen und rechts neu geprintet werden. So bekomme ich eine sehr gute Variabilität der Landschaft. Die schnellste Routine für Zufallszahlen von 0-7 haben wir diskutiert - ich mache einfach 5x lsr
Die Zufallszahl nutze ich für das Setzen des großen Sprites und für alle Konturen.

Damit es keinen Überlappungskonflikt gibt habe ich eine "check"-Routine geschrieben.
Die anderen 4 Sprites werden immer an die gleiche Stelle des Bildschirmes (rechts noch im unsichtbaren Bereich) gesetzt.
Nun bilde ich die Differenz aus der x-Position von SpriteHoch und SpriteAktuell - wenn die Differenz kleiner als 6 ist, schiebe ich SpriteHoch um 12 Einheiten nach weiter rechts. Dann bilde ich die Differenz aus SpriteAktuell und SpriteHoch - wenn die Differenz wenige als 6 ist, schiebe ich den SpriteHoch um 12 Einheiten nach rechts.
Die Routine ist relativ schnell und wird ja auch nur benötigt, wenn ein Sprite (außer SpriteHoch) neu gesetzt wird...

Das funktioniert perfekt... hat mich einige Tage gekostet und mehrere verschiedene Ansätze...

Gruß
Peter

[Dr. Irata]

die Routine dazu sieht folgendermaßen aus:

Code: Alles auswählen

.proc check
			sec
			lda xposl0
			sbc xposl3
			sta check1
			#if .byte check1<#6
			clc
			lda xposl3
			adc #6
			sta xposl3
			sta xposl2
			sta xposl1
			#end
			sec
			lda xposl3
			sbc xposl0
			sta check1
			#if .byte check1<#6
			clc
			lda xposl3
			adc #12
			sta xposl3
			sta xposl2
			sta xposl1
			#end
			rts
			.endp

In check1 speichere ich den Differenzbetrag zwischen.
xposl0 ist die X-Position des SpriteAktuell
xposl3 ist die X-Position des SpriteHoch
xposl1 und xposl2 sind die jeweiligen Positionen der beiden anderen Sprites, die zu dem SpriteHoch gehören und die ich dann natürlich mit übertragen muss.

Aktuell will ich die Routine noch vereinfachen und die If´s rausmachen, damit das noch schneller geht... irgendwie ging der erste Versuch allerdings daneben...

[Dr. Irata]

und hier die optimierte Routine:

Code: Alles auswählen

			.proc check
			sec
			lda xposl0
			sbc xposl3
			cmp #6
			bcc @+
			cmp #249
			bcs @+
			rts
@			clc
			lda xposl3
			adc #10
			sta xposl3
			sta xposl2
			sta xposl1
			rts
			.endp

[Dr. Irata]

... zur Erklärung:

In der optimierten Version subtrahiere ich nur einmal - mathematisch reicht das ja aus, denn ob der Wert nun zwischen 0 und 6 liegt (kleiner 6) oder andersrum zwischen -6 und 0 liegt ist egal. In dem einen Fall bekomme ich eine Überlappung von links und auf der anderen eine Überlappung von rechts. Ich schiebe den SpriteHoch immer nach rechts, da er sonst in den sichtbaren Bereich geschoben wird... das muss man natürlich vermeiden!
Wenn ich also nach rechts wegschieben will und eine Überlagerung festgestellt wurde, dann muss ich maximal um 10 nach rechts schieben, dann ist eine Überlagerung auf jeden Fall ausgeschlossen.
Wenn der Wert Minus wird, dann kommt ja ein Wert von über 250 raus durch den Overflow... also muss ich auch nur einmal rechnen, aber beide Fälle abfragen. Das mache ich mit cmp #6 und cmp #249 (cmp #5 und cmp #250 würde auch reichen) - in beiden Fällen erfolgt eine Verzweigung zu @+ also dahin, wo dann die Verschiebung stattfindet. Die Verschiebung mache ich dann mit adc #10

[pps]

Negativ kann man auch mit BMI abfangen. Allerdings weiß ich nicht, ob Du auch Werte hast, die z. B. 230 sein dürfen. Dann ist das CMP #250 natürlich sinnvoller.

[Dr. Irata]

... gute Idee, aber in der Tat brauche ich zwingend den Wert!