schnelstmöglich dividieren?

[Memnarch]

@Blackfin: Danke^^.
Allerdings weniger zeit im Moment dran weiterzuarbeiten. Sourcecode auf der Arbeit geschrieben, und wenn ich dran weitermachen will muss ichs im moment zuhause machen...dafür muss ich dan nochmal alles schreiben XD.(da hab ich dan aber auch nen Dualcore mit 2.66GHZ pro REALEM Kern )

Wenn es mal interressiert:

http://www.devmaster.net/forums/showthread.php?t=1884

Dieser Artikel hat mir sehr geholfen. Konnte am anfang vllt 4 Bilder pro sekunde anzeigen. Obiger Artikel hat mir gut verdeutlicht wie man soetwas optimieren kann. Bein aktueller Softwarerasterizer basiert auch auf obigem + Einigen anderen sachen wie z.B. depthbuffer etc.(texturemapping geht übrigens auch schon...wenn auch etwas...meh im aussehen^^)

@Amateurprofi: hat das beispiel überhaupt nen sinn? ansonsten hätt ichs mit nem shift wert um einiges kleiner als 32 probiert...o.O

EDIT: bin auch im Moment zuhause sehr beschäftigt...mit ner Art PreCompiler Thread auf 3DGamestudio.de

MFG
Memnarch

[Delphianer]

Hallo,

wenn Du Geschwindigkeit auf Kosten der Genauigkeit steigern kannst/willst, hätte ich auch noch einen Vorschlag.
Du könntest die Ergebnisse der Division in einem Array abspeichern, z.B. 4096 x 4096. Das hieße aber, dass Du Deine Werte für Divisor und Dividend auf 4096 Werte eindampfen müsstest. Das Array ließe sich sicher auch noch in Maßen vergrößern. Wenn die Genauigkeit ausreicht, bist Du mit einem Array-Zugriff rasend schnell.

Viele Grüße,

Lutz

[Memnarch]

Ah, sone art lookup table? Sowas nutz ich schon für die COS/SIN funktionen^^.

Nur wie soll ich die einrichten?
Wenn die formel X/Y ist dan sowas wie:


Ergebnis := Tabelle[x][y];

oder wie?
Von der genauigkeit könnte es reichen weil der finale schritt der division immer für die Pixelkoordinaten also Integer ist. Aber wie soll ich die aufbauen?

EDIT: vergiss es, das haut sich automatisch in die Fritten, den die Fläche eines Dreiecks kann auch width*Height des bildschirms sein, dann ist sowieso schluss >.<

[Memnarch]

Ich nochmal:
Also im Moment ist es ja so, dass ich bei jedem Pixel dividieren muss. Allerdings werkelt da noch so einiges nebenher, womit das nicht die einzigen operationen wären.

Stellen wir uns mal vor, ich dividiere nicht im rasterizer, sondern speicher im Rasterizer nur pro pixel die werte für die Formeln ab. Wenn der rasterizer durchgelaufen ist, gehe ich durch diesen FormelBuffer und kalkuliere dann erst die Farbwerte der pixel. Einerseits kann ich dann ungestört alle Berechnungen direkt hintereinander ausführen(mh...-> optimierung hier vllt besser möglich weil ich nicht mehr switchen muss?) andererseits werden mehrfach berechnungen der farben pro pixel absolut verhindert(kommt hier noch nicht zum tragen, aber bei komplexeren umgebungen). Eine formel kann im schlimmsten fall mehrfach überschrieben werden, aber der finalstep kalkuliert erst.

Jemand noch Ideen?


MFG
Memnarch

[Amateurprofi]

Zitat von Memnarch:

@Amateurprofi: hat das beispiel überhaupt nen sinn? ansonsten hätt ichs mit nem shift wert um einiges kleiner als 32 probiert...o.O

Ich vermute bit4bit wollte sowas ähnliches machen wie mit 1/Wert zu multiplizieren, statt durch wert zu dividieren. So wie es da steht funktioniert das offensichtlich nicht,

Vielleicht könnte bit4bit mal erläutern was er sich dabei gedacht hat.

[Memnarch]

oh klasse 1/wert zu multiplizieren wär super...dan hab ich wieder ne float und müsste truncaten >.<

[Amateurprofi]

na ja, bit4bit's idee war sicherlich, das nicht auf Float-Basis zu machen sondern bei Integer-Werten zu bleiben.
Warten wir doch mal seine Erklärung ab, wie er sich das gedacht hat.
Vielleicht funktioniert das ja irdenwie.
Ich hab mich mit dieser speziellen Thematik bisher noch nicht beschäftigt und kann keine fundierte Aussage machen ob das prinzipiell möglich ist oder nicht.
Schneller wäre diese Version vermutlich.

[Memnarch]

Wenn dass wirklich das ist was bit4bit's Idee war, und das funktioniert, bin ich dochmal gespannt.

[gammatester]

Eine Frage, die bisher unbeantwortet ist: Wie oft ändert die der Divisions-Wert und in welchem Bereich liegt er? Zu Division via inverser Multiplkation gibt's seit ewigen Zeiten Beispiele: http://www.cs.uiowa.edu/~jones/bcd/divide.html oder http://www.azillionmonkeys.com/qed/adiv.html
und viele andere. Wenn Wert lokal-konstant ist, oder nur einen relativ kleinen Bereich umfaßt, kann man die Inversen vorberechnen bzw in die Routinen packen, die Wert berechnen (brauchst Du den überhaupt zu was anderen als zum Dividieren?).

[Memnarch]

Wert ändert sich pro Triangle, nicht voraussehbar da sich umgebung/triangles verändern.

Gerade mal getestet:

bit4bit's methode funktioniert SO:

Delphi-Quellcode:

 Wert2 := Integer((2 shl 12) div Wert);
   Ergebnis := Integer(((A*x + B*Y + C*Z) * Wert2) shr 13);
   Ergebnis2 := Integer(((A*x2 + B*Y2 + C*Z2) * Wert2) shr 13);
   Ergebnis3 := Integer(((A*x3 + B*Y3 + C*Z3) * Wert2) shr 13);[/U]

Dem gegenüüber die 'alte' methode:

Delphi-Quellcode:

   Ergebnis := (A*x + B*Y + C*Z) div Wert;
   Ergebnis2 := (A*x2 + B*Y2 + C*Z2) div Wert;
   Ergebnis3 := (A*x3 + B*Y3 + C*Z3) div Wert;

Wenn ich beides Jeweils 100Millionen mal ausführe (wert2 natürlich nur einmal kalkuliert)
Stellt sich heraus, beides ergibt dasselbe ergebnis, Bit4Bits methode ist aber 4mal SCHNELLER. Seine methode braucht ca 1Sec. Meine 4Sec.