Float in ASM - BASIC-Routinen nutzen?

In den meisten Spielen wird mit Pseudo-Floats gearbeitet, d.h. 16-Bit-Werte, bei denen ein Byte quasi den Nachkommawert enthält. Bei diversen Projektil-in-freie-Richtung-beweg-Code verwende ich so etwas wie Bresenham. Da wird mit reiner Integer-Arithmetik gearbeitet und erhält trotzdem fast frei drehbare Linien.

Zitat von WebFritzi

Hierbei stellt dich die Frage, wie Floats im BASIC-Interpreter gespeichert werden und wo die Routinen zu z.B. Addition und Subtraktion zu finden sind.

Kuckstu hier:

https://sourceforge.net/p/acme…trunk/ACME_Lib/cbm/flpt.a

https://sourceforge.net/p/acme…runk/ACME_Lib/cbm/mflpt.a

https://sourceforge.net/p/acme…/ACME_Lib/cbm/c64/float.a

Das geschilderte Problem würde ich allerdings eher mit einer vorberechneten Sinustabelle zu lösen versuchen, nicht mit echten Floats. Also man unterteilt den Vollkreis in 256 mögliche Richtungen für den Ball und holt für jede Richtung einfach Delta-X und Delta-Y aus der Tabelle, gerne auch als Fixedpoint...

Ich habe vor kurzem mal was aehnliches programmiert (mit sich beschleunigenden und abbremsenden Figuren) und da habe ich es so gemacht wie Endurion beschreibt. Also einen 16-Bit-Wert nehmen fuer die Positionen und die Berechnungen, aber beim Anzeigen usw. wird dann durch 16 geteilt, und bei der Kollision mit Tiles, die in diesem Falle aus 2x2 Char-Bloecken bestehen, also 16x16 Pixel, muss ja dann nochmal durch 16 geteilt werden, was im Endeffekt einer Division durch 256 entspricht und somit kann man sich diesen Schritt dann einfach sparen indem man direkt das High-Byte verwendet und das Low-Byte ignoriert. Je nachdem wie hoch die Nachkomma-Aufloesung sein muss waere natuerlich dieser Schritt auch direkt denkbar fuer die Anzeige, aber mir hat da eine Aufloesung von 16 Sub-Schritten gereicht.

Zitat von spacer

flpout
jsr 43708
rts

*hust* flpout = 43708 *hust*

Zitat von spacer

Lass dich nicht durch die einfachen Schemas hier durcheinander bringen.

Die Billigschema sind was für Progger , die die ungenauigkeiten des Spiels nicht im Kauf nehmen.

Hast Du schonmal drüber nachgedacht, Dich von "spacer" in "sülzer" umzubenennen?

Zitat von Endurion

In den meisten Spielen wird mit Pseudo-Floats gearbeitet, d.h. 16-Bit-Werte, bei denen ein Byte quasi den Nachkommawert enthält. Bei diversen Projektil-in-freie-Richtung-beweg-Code verwende ich so etwas wie Bresenham. Da wird mit reiner Integer-Arithmetik gearbeitet und erhält trotzdem fast frei drehbare Linien.

Dem kann ich nur beipflichten. Mit Fließkommazahlen für solche Zwecke zu rechnen ist schlichtweg Overkill. In BASIC macht man man das nur, weil es der Interpreter implizit immer so macht. Von dieser Vorstellung, dass man nur mit Fließkommazahlen rechnen kann, sollte man sich - speziell bei Spielprogrammierung - schnell verabschieden. Ja, im wissenschaftlichen Bereich braucht man, wenn man nicht abschätzen kann, in welcher Größenordnung die Werte haben werden bzw. halbwegs genau mit diesen Werten weiter rechnen möchte. Aber bei Spielen weiß man ziemlich genau, in welchem Bereich sich die Werte bewegen und kennt die Randbedingungen (etwas von der Grafik), die ein Weiterrechnen nicht mehr sinnvoll machen. Man hat in der Regel einen sehr kontrollierten Rechenpfad umd Wertebereich.
Die Mühen der anderen Poster nicht schmälern zu wollen, aber für Spiele (und viel Anwendungen) zahlt sich der Aufwand in vielerlei Hinsicht nicht aus.

Zitat von spacer

Lohnt sich das überhaupt?

Das soll jeder für sich selbst entscheiden. So wie du vielleicht Float als einen Riesenspaß ansiehst, musst du auch die Meinung akzeptieren können, dass andere - nicht gerade unerfahrene Programmierer - eine Empfehlung abgeben, die auf Floats verzichtet. Da muss keiner den anderen zu überzeugen versuchen. Die Penetranz gewisser Postings lassen zwar daran zweifeln, aber was soll's. Ich kann damit leben und muss hier nicht um den Kaisers Bart herumstreiten.

Wenn jemand, wie man in Österreich sagt, mit der Kirche ums Kreuz gehen will, dann bitte. So lustig und spaßig ist das mit den Floats auch wieder nicht, das kann man einem vielleicht am Anfang stehenden Programmierer ruhig sagen. Nur etwas Vorgefertigtes aus dem Forum abzukopieren, wird bei weitem nicht so erfüllend sein, wenn sich jemand selbst daran macht das zu erforschen. Dazu gehört aber auch einmal Floats generell zu verstehen ...

Zitat von Endurion

In den meisten Spielen wird mit Pseudo-Floats gearbeitet, d.h. 16-Bit-Werte, bei denen ein Byte quasi den Nachkommawert enthält.

Ich frage mich immer, wo der Begriff "Pseudo-Floatingpoint" herkommt. Ist das nicht naheliegenderweise einfach "Fixpoint"? Aber ansonsten: ja, das ist für nahezu alle Anwendungen der richtige Ansatz. Ich arbeite beruflich an Signalprocessing-Software, und wenn diese auf Prozessoren ohne Floatingpoint-Hardwareunterstützung laufen soll, wird auch heute Fixpoint verwendet. Ist schneller und man kann sich ja selber aussuchen, wie genau es sein soll (16 Bit sollten für die Mehrzahl an Anwendungsfällen auf dem Cevi ausreichen).

Wo ist das Problem, zusaetzlich zur Erklaerung einen passenden Begriff zu verwenden? Muss man Anfaenger pauschal als "zu doof" einordnen, als dass man ihnen gleich auch den Namen des Verfahrens nennen koennte?

Z.B. in Wikipedia

Zitat von spacer

Diese beiden Begriffe oben erscheinen nirgends im Duden oder in einem anderen Nachschlagewerk als anerkannter Begriff.

Wo soll er als Anfänger nachlesen...?

Zitat von Claus

Z.B. in Wikipedia

...und schon wieder hat spacer es geschafft, jemand anderen für sich googeln zu lassen.

Zitat von WebFritzi

bei dem ich die Geschwindigkeit des Balls konstant halten möchte - egal, in welche Richtung er fliegt. Dafür brauche ich Floats

Ich arbeite zurzeit hauptsächlich waagerecht und senkrecht, aber aus Interesse hatte ich mich gestern mal damit befasst und mit Hilfe von BASIC V2 experimentiert, bewusst, ohne irgendwo nachzuschlagen. Gab's damals ja schließlich auch nicht!

Das einzige Problem, wenn man heute noch gern, wie früher, selbst hinter diversen Zusammenhängen steigen möchte, ist, dass man bei etwaiger Unterbreitung seiner Erkenntnisse im Indernet Gefahr läuft, dass man zur Sau gemacht wird, weil ja alles schon bekannt sei, und zwar viel genauer und besser, und man es nur noch nachschlagen müsste.

Zum Teil ist das ja auch richtig, aber wenn man erst dann davon Gebrauch macht, wenn man selbst nicht auf eine optimale Lösung gekommen ist, hat es eben den Vorteil, den JeeK bereits ansprach, nämlich das positive Gefühl, das Erfolgserlebnis, die elementaren Erkenntnisse, auf die man aufbauen kann, die Sicherheit, den Durchblick, der Lerneffekt, den Spaß an der Freude. Also ...

1. Wenn ich die Fließkommazahlen benutze, ist eine Routine, die einen Ball (ein Char) mit ständigem Richtungswechsel, aber ohne Geschwindigkeitskorrektur, per Zufall über den Bildschirm sausen lässt, sehr einfach aufgebaut (4 Zeilen). Als Steigung hatte ich immer Werte <=1, indem die Matrix bei größeren Steigungen gedreht behandelt wird.

2. Im nächsten Schritt hatte ich echte Fließkommazahlen ausgeschlossen. Die Berechnung beschränkt sich dann neben den unvermeidbaren Int-Additionen (während der Bewegung) auf nur eine Int-Division pro Flugrichtung (bzw. pro Linie), und zwar 16bit (mit low byte=0) dividiert durch 8bit = 8bit Ergebnis, und das geht so schnell, dass ich dafür keine Delta-Tabellen investieren würde. Das ist die Zahl die ständig zu einem 8bit-Counter addiert werden muss, damit bei Überlauf die entsprechende Richtungskomponente inkrementiert wird, während die andere Richtungskomponente bei jedem Schritt inkrementiert wird. Man könnte sagen, das Summanden-Byte stellt den Nachkommaanteil der Steigung dar, die stets kleiner als 0 ist. Deswegen braucht man auch kein Vorkomma-Byte. Das Counter-Byte stellt den Nachkommaanteil der theoretischen Position in X- oder Y-Richtung dar. Die Linien sehen genauso gut aus wie mit der echten Fließkommaberechnung (Linker Screenshot).

3. Das pythagoräische Geschwindigkeitsproblem. Bei einer schrägen Bewegung ist der Ball schneller als waagerecht oder senkrecht, bis zu 41%. Das kann man zwar leicht ausgleichen durch zwei Transformationstabellen, denen eine feste Hypotenuse von 1 bzw. 256 zugrunde liegt, aber damit stellt sich leider eine unschöne Eigenschaft ein, die ich schon in manchen Spielen beobachtet hatte: Eine unruhige oder zitternde Flugbewegung bei bestimmten Winkeln so zwischen 30 und 45°. Der Grund ist die Stauchung der Ankathete, die vorher 1 war. Dadurch entstehen hässliche Ecken in der Linie (Rechter Screenshot). Das kann man beseitigen, indem man nicht die Katheten bei größerem Winkel staucht, sondern bei kleinerem Winkel dehnt. Allerdings kommt es dann bei kleineren Winkeln zu Lücken in der Linie, die sich für den Ball wie Micro-Sprünge bemerkbar machen.

Fazit: Ich denke, dass ich die Geschwindigkeitskorrektur vielleicht nicht in die Linien-Berechnung einfließen lassen würde, sondern in den Zeitpunkt des Plots. Deswegen kann man weiterhin wohl einen festen Raster-Interrupt nutzen. Man muss dann nur berechnen, ob der nächste Plot schon ausgeführt werden soll. Verpasste Plots nachholen braucht man natürlich nicht; die werden übersprungen. Auf diese Weise kann man auch leichter die absolute Ballgeschwindigkeit einfließen lassen.