antialiasing manuell (software-mode) nachprogrammieren.

rapso

manche systeme (z.b. ps2) machen "edge antialiasing"

dabei ist es wichtig dass man von hinten nach vorne zeichnet. das zeichnen der einzelnen elemente z.b. dreiecke läuft dann so ab, dass erst das innere gezeichnet wird (auf normale art und weise).
danach (jetzt kommt's ) die kanten des elementes, dabei wird "line antialiasing" gemacht, das kann man ziemlich gut optimieren und muss schlussendlich auch keine vergrößerte version des ganzen bildes zeichnen, sondern mischt temporär pro linie.

natürlich ist das ab einer gewissen anzahl von linien langsammer als normales MSAA.

rapso->greets();

Helium

Was aber am Ende beim Antialiasing rauskommt sind einfach nur weiche Übergänge bei hohen Kontrasten. Wäre auch ne Möglichkeit, dieses "Weichzeichnen" nur da anzuwenden wo der Farbunterschied einen bestimmten Wert überschreitet.

Anti-Aliasing hat absolut gar nichts mit Weichzeichnen zu tun.

Offensichtlicher wird das ganze, wenn man das ganze aus dem Audio-Bereich kennt. Dann versteht man z.B. auch warum das überhaupt Aliasing heißt: Bei einer bestimmten Samplerate kann man maximal Frequenzen darstellen, die halb so hoch sind, wie die Samperate. Wenn man versucht eine höhere Frequenz darzustellen erhäklt man stattdessen einen Alias, der dem eigentlichen ton entspricht, nur um die halbe Samplerate gespiegelt (Nyquist-Frequenz). Solche Aliasse stören. Die lösung ist einfach eine höhere Samplerate zu nehmen (z.B. doppelt so hoch) und anschließend alle Frequenzen über der halben Ziel-Samplerate rauszufiltern und dann die Samplerate runterzurechnen.

Bei der Bildbearbeitung ist es nicht anders. Dinge, die quasi eine zu hohe "Frequenz" für die Auflösung haben (sprich kleiner sind als ein Pixel) führen zu Aliasen (das Phänomen des Alias könnte man nur wirklich erkennen, wenn man das Bild in den Frequenz-Bereich transformieren würde). Wenn man eine höhere Auflösung verwendet sind Dinge, die vorher zu klein waren möglicherweise nicht mehr zu klein und passen nun auf einen Pixel.
Kanten von Objekten sind quasi unendlich dünn. Deswegen kann man sie auch durch Oversampling nie komplett Alias-frei halten. Dennoch kann man die Qualität deutlich verbessern.

interpreter

[quote="rapso"
auch bei multisampling wird das bild in vielfacher auflösung gerendert und dann runterskaliert. informier dich über den wahren unterschied
[/quote]
Quellen? Bei Multisampling wird eben nicht in höherer Auflösung gerendert.

rapso

interpreter schrieb:

rapso schrieb:

auch bei multisampling wird das bild in vielfacher auflösung gerendert und dann runterskaliert. informier dich über den wahren unterschied

Quellen?

informier dich einfach. nvidia.com ati.com usw.

interpreter schrieb:

Bei Multisampling wird eben nicht in höherer Auflösung gerendert.

sind wir im kindergarten?
doch
nein
doch
nein

rapso->greets();

interpreter

rapso schrieb:

informier dich einfach. nvidia.com ati.com usw.

Ich habe meine Infos aus der DX9 Doku. Die Infos da sollten wohl stimmen, oder?

0x00000001

@loki:

Wie wäre es mit einem Alphakanal für die Bitmap? Entweder Du tust ihn schon im Grafikprogramm dazu oder erechnest ihn beim Laden der Bitmap. Benötigt zwar 33% mehr Speicher, aber dafür ersparst Du Dir die ganzen Vergleiche beim blitten.

rapso

interpreter schrieb:

rapso schrieb:

informier dich einfach. nvidia.com ati.com usw.

Ich habe meine Infos aus der DX9 Doku. Die Infos da sollten wohl stimmen, oder?

die infos stimmen, vielleicht aber deine interpretation davon nicht, oder dein englisch.

schau dir einfach diese presentation von nvidia an, die haben sogar bunte bildchen die das verdeutlichen dass auch bei msaa der framebuffer in vielfacher größe existiert.

rapso->greets();

rapso

0x00000001 schrieb:

@loki:

Wie wäre es mit einem Alphakanal für die Bitmap? Entweder Du tust ihn schon im Grafikprogramm dazu oder erechnest ihn beim Laden der Bitmap. Benötigt zwar 33% mehr Speicher, aber dafür ersparst Du Dir die ganzen Vergleiche beim blitten.

die vergleiche beim blitten resultieren in zwei "and" und einem "or". beim blenden müßte er hingegen 2"mul" und ein "add" haben.

aber er hätte weniger aliasing, da hast du recht

rapso->greets();

loki1985

0x00000001 schrieb:

@loki:

Wie wäre es mit einem Alphakanal für die Bitmap? Entweder Du tust ihn schon im Grafikprogramm dazu oder erechnest ihn beim Laden der Bitmap. Benötigt zwar 33% mehr Speicher, aber dafür ersparst Du Dir die ganzen Vergleiche beim blitten.

auch keine schlechte idee.... ich denke das teste ich mal aus.

dürfte ja fast meiner ersten überlegung entsprechen.

0x00000001

rapso schrieb:

die vergleiche beim blitten resultieren in zwei "and" und einem "or". beim blenden müßte er hingegen 2"mul" und ein "add" haben.

Versteh ich nicht. 2 AND und 1 OR? Er muss doch die Pixel in der Nachbarschaft anschauen ob die transparent sind. Wenn man das ganz naiv implementiert hat man schonmal 8 Vergleiche.
Mit dem alphakanal hat man zwar die langsameren operationen, aber dafür nur einmal pro Pixel.

Erklär mal bitte genauer wie Du das meinst, ich komm nicht drauf

rapso

0x00000001 schrieb:

rapso schrieb:

die vergleiche beim blitten resultieren in zwei "and" und einem "or". beim blenden müßte er hingegen 2"mul" und ein "add" haben.

Versteh ich nicht. 2 AND und 1 OR? Er muss doch die Pixel in der Nachbarschaft anschauen ob die transparent sind. Wenn man das ganz naiv implementiert hat man schonmal 8 Vergleiche.
Mit dem alphakanal hat man zwar die langsameren operationen, aber dafür nur einmal pro Pixel.

Erklär mal bitte genauer wie Du das meinst, ich komm nicht drauf

da er ja auf geschwindigkeit aus ist, unterstell ich ihm dass er das möglichst schnell machen möchte.

eine möglichkeit wäre

im main loop

for(u32 a=0;a<pixelzahl;a++)
{
  u32 MaskIndex = (pScreen[a]==ALPHAPIXEL);
  MaskIndex--;
//hier die 2und und ein or, kann man mit mmx schneller machen, oder cmov
//man sparrt zwar den vergleich nicht, doch der kostet kaum was,
//was man einsparrt ist ein conditionaljump was auf nem p4 bis zu 30takte kostet
  pOut[a]  = (pScreen[a]&MaskIndex) | (pOut[a]&(MaskIndex^0xffffffff)); 
}

rapso->greets();

0x00000001

OK der Code da mag schnell sein, aber glätten tut der nix
Ich mit meinem Halbwissen würde nach wie vor behaupten, dass ein vorberechneter Alphakanal die schnellste Möglichkeit ist.

rapso

0x00000001 schrieb:

OK der Code da mag schnell sein, aber glätten tut der nix
Ich mit meinem Halbwissen würde nach wie vor behaupten, dass ein vorberechneter Alphakanal die schnellste Möglichkeit ist.

ich hab ja auch nichts anderes behauptet, ich merkte nur an dass er 2and und ein or gegen 2mul und 1add tauscht was sehr viel langsammer sein kann, zumal er, wenn er per channel blendet, er 6 oder 8 muls 3 oder 4 add und noch ne menge maskierung hat (esseiden er nimmt mmx).

es würde also eventuell sogar schneller sein wenn er FSAA machen würde
wäre aber fallspezifisch .

rapso->greets();

TGGC

Also ich kenne es nur als Faltung. Und ihr?

Bye, TGGC (Wähle deine Helden)

Helium

TGGC schrieb:

Also ich kenne es nur als Faltung. Und ihr?

Ich sehe da immoment nicht, was du da falten willst? Einen Weichzeichnungsfilter, der wie gesagt nichts damit zu tun hat?

TGGC

Wieso Weichzecihnungsfilter? Du meinstest doch selbst schon, das nicht.

Bye, TGGC (Wähle deine Helden)

Helium

JA, dann erklär mir doch bitte einfach, was du da Falten willst.

TGGC

Das Bild als Funktion interpretiert mit einer zweiten Funktion.

Bye, TGGC (Wähle deine Helden)