Bilinearen Filter in DirectDraw abschalten



  • Wenn ich mit DirectDraw ein Bild nicht in Originalgröße blitte, sondern es strecke:

    destSurface->Blt(&stretchRect, srcSurface, NULL, 0, NULL)
    

    dann wird automatisch dieser bilineare Filter aktiviert, der das Bild verwaschen darstellt. Kann man das abstellen, so daß das Bild pixelig aussieht, oder hat DirectDraw da keinen Einfluß drauf und man muß Direct3D nehmen?



  • Das ist etwas komplizierter, als du denskt: http://msdn.microsoft.com/en-us/library/aa918950.aspx

    Nochmal mein Tipp, nimm ein aktuelles DX oder gleich HGE... f'`8k

    Autocogito

    Gruß, TGGC (Was Gamestar sagt...)



  • In dem Text steht:

    Devices might also support arithmetic scaling, which is scaling by interpolation rather than simple multiplication or deletion of pixels.

    Und dann steht da:

    Applications cannot control the type of scaling done by the driver, except by setting the DDBLTFX_ARITHSTRETCHY flag in the dwDDFX member of the DDBLTFX structure passed to Blt. This flag requests that arithmetic stretching be done on the y-axis.

    Das erklärt, wie man den Filter einschaltet. Ich muß aber wissen, wie man ihn ausschaltet.



  • Lies!

    NES-Spieler schrieb:

    Applications cannot control the type of scaling

    f'`8k

    Autocogito

    Gruß, TGGC (Was Gamestar sagt...)


  • Mod

    eigentlich sollte jede cpu heutzutage schnell genug sein um damit selbst zu skalieren. Fall dein name programm ist und du einen NES emulator bastelst, bietet sich sowas an.



  • TGGC schrieb:

    Lies!

    Applications cannot control the type of scaling

    Ja,

    except by setting the DDBLTFX_ARITHSTRETCHY flag in the dwDDFX member of the DDBLTFX structure passed to Blt.

    Und ich dachte mir, wenn er ihn setzen kann, kann er ihn vielleicht auch ausschalten. Außerdem verstehe ich nicht, wieso Du mir den Link mit den Worten

    TGGC schrieb:

    Das ist etwas komplizierter, als du denskt

    gegeben hast, wenn Du darauf hinauswolltest, daß es nicht geht. Dann wäre der Satz "Es geht nicht. Beweis: Hier" wohl geeigneter gewesen.

    P.S.: Wenn ich das Spiegeln eines Bildes einstelle, benutzt er komischerweise keinen bilinearen Filter. Da streckt er ganz normal. Weiß einer, woran das liegt?

    rapso schrieb:

    eigentlich sollte jede cpu heutzutage schnell genug sein um damit selbst zu skalieren.

    Fragt sich nur, wie sie skaliert. Ich möchte eben ganz normale Vergrößerung ohne irgendwelche Filter:

    Das hier soll zu dem hier werden, nicht zu dem hier.

    rapso schrieb:

    Fall dein name programm ist und du einen NES emulator bastelst, bietet sich sowas an.

    Nein, ich will keinen NES-Emulator programmieren. Aber selbst wenn: Das da ist ein spezieller Grafikfilter. Sieht ganz nett aus, sollte meiner Meinung nach aber nur als Zusatzoption zur Verfügung stehen und nicht als Standard. Ich würde zum Beispiel keinen Emulator akzeptieren, der das Bild nur so darstellen könnte.



  • NES-Spieler schrieb:

    Und ich dachte mir, wenn er ihn setzen kann, kann er ihn vielleicht auch ausschalten. Außerdem verstehe ich nicht, wieso Du mir den Link mit den Worten

    TGGC schrieb:

    Das ist etwas komplizierter, als du denskt

    gegeben hast, wenn Du darauf hinauswolltest, daß es nicht geht. Dann wäre der Satz "Es geht nicht. Beweis: Hier" wohl geeigneter gewesen.

    Ich wollte nicht darauf hinaus. Dort stehen mehr Informationen als das und bei den falschen Aussagen in deinem Post koennen dir diese nur nuetzlich sein. Scheinbar bist du aber nicht in der Lage diese Webseite zu verstehen. Da ich aber nicht dein persoenlicher Uebersetzer bin: Lies! f'`8k

    Autocogito

    Gruß, TGGC (Was Gamestar sagt...)



  • TGGC schrieb:

    Lies!

    Du bist ganz schön arrogant, hat man Dir das schonmal gesagt?



  • NES-Spieler schrieb:

    TGGC schrieb:

    Lies!

    Du bist ganz schön arrogant, hat man Dir das schonmal gesagt?

    IMHO bist du schon lange genug hier, um zu wissen, wie du mit ihm umgehen musst 😉

    Bezüglich dem Thema finde ich solltest du auf rapso hören. Einfaches Strecken und auch Rotieren von Bildern ist seit Jahren von Hand auf jeder CPU effizient genug. Ich glaube mich sogar daran zu erinnern, dass es hier im Forum einen Artikel zu dem Thema gibt, mit welchem ich das vor langer Zeit einmal implementiert habe (zwar nicht mit DirectDraw, sondern mit GDI+ glaub ich. Aber das spielt eh keine Rolle, da wir hier vom Drehen und Strecken jedes Pixels im Speicher selbst reden...).

    MfG



  • /rant/ schrieb:

    NES-Spieler schrieb:

    TGGC schrieb:

    Lies!

    Du bist ganz schön arrogant, hat man Dir das schonmal gesagt?

    IMHO bist du schon lange genug hier, um zu wissen, wie du mit ihm umgehen musst 😉

    a, aber soweit ich mich erinnere, hatte ich mit ihm bisher noch nicht selbst zu tun.

    /rant/ schrieb:

    Bezüglich dem Thema finde ich solltest du auf rapso hören. Einfaches Strecken und auch Rotieren von Bildern ist seit Jahren von Hand auf jeder CPU effizient genug.

    Wie geht das eigentlich? Bzw. nach welchen Begriffen muß ich da suchen?



  • Einfaches Strecken und auch Rotieren von Bildern ist seit Jahren von Hand auf jeder CPU effizient genug.

    Wenn man ein Bild auf die native Bildschirmaufloesung skalieren moechte weil die interne Interpolation vieler Displays ja nicht unbedingt ideal ist, wird das seit FullHD aber durchaus wieder fragwuerdig...



  • So, ich hab jetzt endlich rausgefunden, wie man den bilinearen Filter abschalten kann. Wie so oft war die Lösung absolut simpel und wäre mit einer Codezeile zu beantworten gewesen. Aber nein, lieber gibt man mir Links zu sonstwas für Artikeln, die mir einen Scheiß nützen, und fordert mich auf, sie zu lesen. Das ist genauso wie damals, wo mir keiner sagen konnte, wie man Double Buffering mit der GDI realisiert, und man mir 100 Links gab, auf denen zwar beschrieben wird, wie man ein Bild auf ein Fenster blittet, aber keines mein Problem thematisierte, erstmal zwei Bilder in einen Buffer zu packen und dann diesen Buffer auszugeben, so daß die Ausgabe nicht flackert. Eine absolut simple Sache, wenn man weiß, wie's geht. Trotzdem hat's keiner hinbekommen, es mir zu erklären, und als ich es dann endlich per Zufall rausfand, mußte ich mich wirklich fragen, ob ich jetzt der erste war, der das gemacht hat. (Mein Trugschluß war gewesen, daß ich glaubte, ein Device Context würde für sich allein stehen und die HBITMAP-Variable wäre nur eine temporäre Variable zum Erstellen des Bildes. Ich hatte also nur versucht, die DCs der Bilder auf einen Back-Buffer-DC zu blitten, was dann natürlich nicht funktionierte, da der DC ja leer bzw. ungültig war. Die simple Anmerkung, daß man erstmal ein leeres Bitmap erstellen und dieses dann mit einem DC verknüpfen muß, hätte gereicht, aber nein, das war ja wohl zuviel verlangt.)

    O.k., lange Rede, kurzer Sinn, hier ist die Lösung:
    Man ersetze einfach den Aufruf

    DirectDrawCreate(NULL, &dd, NULL);
    

    durch

    DirectDrawCreate((GUID *)DDCREATE_EMULATIONONLY, &dd, NULL);
    

    Tadaa! Fertig. Von wegen

    TGGC schrieb:

    Das ist etwas komplizierter, als du denskt

    Ich habe das herausgefunden, indem ich einfach mal in den Quellcode des NES-Emulators FCE Ultra geguckt habe. Der kann den Filter nämlich ausstellen. Und neulich ist mir eingefallen, daß dieser Emulator ja mit DirectX 7 läuft. Und daraus schloß ich, daß es einen Weg geben muß, auch mit DirectDraw, und nicht nur mit Direct3D, den bilinearen Filter abzustellen. Tja, und so war es dann ja auch.

    Ich selbst habe mit DirectX noch nichts gemacht, aber darauf hätte ja mal jemand von den erfahrenen Spieleprogrammierern hier kommen können, statt mich mit irgendwelchen Schlaumeiersprüchen zu belehren.



  • Aber bedenke:

    MSDN schrieb:

    DDCREATE_EMULATIONONLY
    The DirectDraw object uses emulation for all features; it does not take
    advantage of any hardware-supported features.



  • Ich weiß. Das war auch der Optionspunkt im NES-Emulator. Da stand nicht "Disable bilinear filter", sondern "Disable hardware acceleration". Von daher war mir das schon bewußt. Aber erstens lief der Emulator damit nie langsamer, und ich hab das Teil schon auf den verschiedensten PCs laufen lassen, von 500 MHz bis 4 x 2,33 GHz, so daß ich die Hoffnung habe, daß auch meine Spiele, die ja nicht allzu anspruchsvoll sind, nicht langsamer werden. Und zweitens ist die Methode immer noch besser als "Es geht nicht" oder "Es geht nur sehr schwer. Lies diesen Artikel hier, der Dir kein bißchen weiterhelfen wird."


Anmelden zum Antworten