schnelstmöglich dividieren?

[Sir Rufo]

FixedKomma ist der DatenTyp Currency (der arbeitet intern als Int64)

[Memnarch]

Nur bei Currency bin ich mir icht sicher wie das ergebnis ausschaut. Wenn es sich um einen 64bit integer handelt, wie schnell kann der im vergleich zu einem 32bit integer kalkuliert werden?(P4 hier muhaha^^).

Und den bekomm ich dann z.B per bitshift in einen Integer oder übernimmt das Delphi hier für mich?
Erstmal testen wie schnell das mit dem datentypen hier geht o.O.( er braucht ja immerhin doppelt soviel an registerplatz wie "normale" integer)


MFG
Memnarch

[himitsu]

Int64-Divisionen und Multiplicationen sind sehr langsam, da sie über mehrere 32-Bit Operationen in den 32-Bit-Registern emuliert werden.

siehe Unit System:

Delphi-Quellcode:

{ 64-bit Integer helper routines }
procedure __llmul;
procedure __lldiv;
procedure __lludiv;
procedure __llmod;
procedure __llmulo;
procedure __lldivo;
procedure __llmodo;
procedure __llumod;
procedure __llshl;
procedure __llushr;

Currency wird aber als ein Befehl über die FPU behandelt, wie die normalen Float-Typen auch.
Wenn man Currency nach Int64 castet, dann steht im Int64 natürlich ein 10000 mal größerer Wert drin, wie im Currency.
Leider kann man soeinen "krumen" Wert (auch Sicht des Zweierkomplements) nicht weg-shiften und so "schnell" abrunden.

Eventuell könnte man über die MMX-Register da noch Einiges machen wie z.B. mehrere Berechnungen gleichzeitig durchführen.

[Memnarch]

Mit MMX hab ich zwar mal angefangen, aber nicht alles gefunden was ich brauchte. Ich habe es dann gelassen.

Soll ja für sowas wie geschaffen sein, da ich eine formel 3 mal hintereinander ausführe.
Hatte aber irgendwo seinerzeit probleme damit, ka mehr wo.

Aber am ende muss truncated werden und hier ist einfach alles futsch. da geht garnichts. wenn ich truncate kann ich auch gleich DIV benutzen, es gab da keinen nennenswerten unterschied.


MFG
Memnarch

[Medium]

Um die Division bzw. alternativ non-integers wirst du vermutlich kaum herum kommen. Eventuell findest du hier (letzte Kategorie) noch ein paar hilfreiche Anregungen.

Eine Idee hätte ich noch: Weg mit den baryzentrischen Koords, und her mit einer Scanline. Dann könnte man "von oben nach unten" durch gehen, und hätte pro Y-Koordinate pro Dreieck zwei lineare Interpolationen, plus einer weiteren für jeden Pixel. Dazu das Bildchen im Anhang. p0 und p1 müssten ja nur je ein mal pro Scanline pro Dreieick ermittelt werden (hat man Adjazentsinfos, kann man benachbarte Strecken gleich weiter benutzen und müsste bis auf beim ersten Mal sogar nur eine Strecke neu interpolieren), und pro Pixel muss dann nur noch zwischen den p0 und p1 linear interpoliert werden.

[Memnarch]

@Medium: Das ist richtig wenn ich nur die Plane zeichnen will(also das rasterisieren), wenn ich aber einen wert der Vertices interpolieren muss(z.B. welchen Z wert hat der punkt P an PosXY wenn die Vertixe ABC die ZWerte SoUndSo haben), reicht es nicht wenn ich nur zwischen den Vertices interpoliere.

[Medium]

Du kannst statt der Farben doch auch einfach die Z-Koordinate da einsetzen :)

Wofür brauchst du die eigentlich?

[Memnarch]

Was? Die farben oder die Z-Koordinaten?

Die Farben werden einfach für den Farbverlauf zwischen den 3 Vertices benutzt. Jeder Vertex hat RGB farbwerte.

Besser als eine einzige Farbe, bis ich nen Texturrasterizer draus gemacht hab^^.


MFG
Memnarch

[Medium]

Ich meinte die Z-Coords :) Gouraud-Shading war klar.

[Memnarch]

Na für die Depthmap ;)
Sonst quadrutschelt es mir ja alles durcheinander ;)(Selbs wenn ich vorher sortieren würde).

Ist dieselbe Technik wie sie auch seit Jahren für alle 3dspiele angewand wird.