4. antialiasing manuell (software-mode) nachprogrammieren.

antialiasing manuell (software-mode) nachprogrammieren.

  • I

    [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.

    0
  • R
    Mod

    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();

    0
  • I

    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?

    0
  • 0

    @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.

    0
  • R
    Mod

    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();

    0
  • R
    Mod

    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();

    0
  • L

    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.

    0
  • 0

    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 🙂

    0
  • R
    Mod

    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();

    0
  • 0

    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.

    0
  • R
    Mod

    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();

    0

  • Also ich kenne es nur als Faltung. Und ihr?

    Bye, TGGC (Wähle deine Helden)

    0
  • H

    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?

    0

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

    Bye, TGGC (Wähle deine Helden)

    0
  • H

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

    0

  • Das Bild als Funktion interpretiert mit einer zweiten Funktion.

    Bye, TGGC (Wähle deine Helden)

    0
Anmelden zum Antworten