Beiträge von wwelti

    Hallo Weideblitz,


    Jaja, ich gebs ja zu. War blöd ausgedrückt von mir, "Textur-Speicher" zu sagen. Sagen wir einfach "Video-Speicher". Der Speicher einer Grafikkarte wird heutzutage nicht mehr speziell unterteilt in Textur- und Bildspeicher (das war mal früher so mit Voodoo-Karten, glaub ich).


    Und 32 MB Video-Speicher sollten definitiv mehr als genug sein, vor allem bei der niedrigen Auflösung 1024x768! Selbst für das Spiel sollte das noch reichen! Für die Tests allein wären bei der niedrigen Auflösung auch 8 MB schon genug! Also ist tatsächlich die GPU der Flaschenhals. Oder der Video-Speicher wurde so schmalbandig an die GPU angebunden, daß es nicht für mehr reicht... Ich muß zugeben, daß ich das schon recht seltsam finde: 32 MB Video-RAM, und trotzdem schafft er nicht mal den Verfolgungs-Test mit ausgeblendeten Fenstern (richtig?) in der niedrigen Auflösung 1024x768. Damit steht die Leistung der GPU im krassen Mißverhältnis zur Video-Speicherausstattung!


    Was genau ist an der angezeigten CPU-Belastung nicht einleuchtend? Wenn 53% Last angezeigt werden, die Frame-Rate allerdings schon halbiert ist, bedeutet das lediglich, daß für die volle Frame Rate 106% CPU-Leistung benötigt würden, was natürlich nicht geht!


    Wobei ich der Einfachkeit halber GPU und CPU-Leistung zusammengefasst darstelle. Wenn Du checken willst, ob Deine CPU-Leistung ausreichen würde (und davon gehe ich schon aus!), probier doch einfach mal eine Auflösung von 640x480 Pixeln einzustellen und dann PixPerAn zu starten. Wenn dann alles flüssig läuft, ist das der Beweis :-). Denn die CPU hat dann immer noch genau so viel zu tun, wie bei 1024x768, doch die GPU hat wesentlich weniger Füll-Leistung zu erbringen.


    Wenn Dein Laptop eine nicht-interpolierte 1:1 Darstellung von 640x480 beherrscht (also verkleinertes Bild mit schwarzen Trauerrändern), kannst Du übrigens PixPerAn trotzdem sinnbringend ausführen. Wenn er die Auflösung nur gestreckt beherrscht, wird allerdings die Gamma-Einstellung nicht funktionieren. Wobei Du natürlich einfach den ermittelten Wert von 1024x768 übernehmen könntest, da das Panel wohl digital angeschlossen ist. Für die anderen Tests ist eine interpolierte Darstellung nicht gar so schlimm (wenn auch nicht unbedingt förderlich) :-).


    Wenn die Kästchen einen bräunlichen Ton haben, heißt das, daß helle Farben einen leichten Braunstich haben, denke ich. Die Gamma-Einstellung ist allerdings nicht für alle Tests zwingend notwendig, nur der "Flaggen-Test" und die Schlierenbilder benötigen den ermittelten Gamma-Wert. Wobei der Flaggen-Test allerdings m.E. der präziseste Test überhaupt ist, jedenfalls wenn der Gamma-Wert bekannt ist. Deshalb habe ich da auch so einen Aufwand betrieben.


    Viele Grüße
    Wilfried

    Hallo Phantom1,


    Schon gut, dann sag ich halt nicht Texturen, sondern Surfaces :-). Eine Surface ist ein Objekt, das u.a. Grafiken im Video-Ram verwalten kann. Daß die Terminologie nicht ganz korrekt ist, stimmt schon. Aber Texturen kennt jeder, Surfaces nicht.


    Und ich benutze Surfaces für Grafiken. Schon alleine, weil die AntiAliasing-Textdarstellung in Echtzeit nicht schnell genug wäre. (Ursprünglich hatte ich auch SubPixel-AA drin, aber hab's wieder 'rausgenommen, bevor ich noch Ärger wegen den entsprechenden Patenten bekomme) Außerdem habe ich ja tatsächlich ein paar Grafiken (vor allem im Spiel :-), die natürlich auch in Surfaces landen.


    Also, das Programm braucht tatsächlich einen Haufen Texturspeicher (soll heißen zusätzliches VideoRam, über den Double-Buffer hinausgehend). Für die Tests eher nicht so arg viel, für das Spiel dafür um so mehr. (Wenn nicht genug Speicher vorhanden ist, wird statt Video-Ram normales RAM verwendet, was aber tierisch auf die Performance schlägt)


    Was VSync in Deinem Programm angeht: Ja, Du hast es da einfacher. Du verwendest allerdings auch kein Double-Buffering, sondern einen Backbuffer, der einfach jeweils nach einem VSync kopiert wird (nehme ich mal an, richtig?). In diesem Falle entfällt diese Problematik natürlich, da Du keinen DirectX-Flip-Befehl für den Seitenwechsel benutzen musst.
    Diese Methodik (Backbuffer) wäre für ein Vollbild-Programm wie PixPerAn allerdings nicht anzuraten.


    Was das Anpassen an die Vertikalfrequenz angeht: Es gibt gute Gründe dafür, daß alle Leute mit derselben Vertikalfrequenz testen sollten; wie's aussieht wohl am Besten mit 60 Hz.


    Viele Grüße
    Wilfried

    Hallo Weideblitz,


    Das mit den 30 und 60 Hz wollte ich nur noch mal klar herausstellen, damit jeder versteht, was Sache ist :-).


    Tja, in der Anleitung hatte ich beschrieben, wieviel Texturspeicher die Grafikkarte haben sollte (8-32 MB, je nach dem). Ich fürchte, Deine Grafikkarte hat zu wenig: nämlich 0 MB (und verwendet für Texturen sowie für den Frame-Buffer per UMA den Hauptspeicher des Rechners), kann das sein?


    Die Besonderheit des Flicker-Screens ist, daß er so gut wie gar keine Texturen verwendet, und dazu noch sehr wenige Objekte beinhaltet. Daher braucht dieser Screen mit Abstand am wenigsten Leistung.


    Solange mit dem Vertical Retrace synchronisiert wird (dafür sorgt der VSYNC, ob er jetzt durch den Treiber oder durch das Programm aufgerufen wird), gibt es nichts zwischen 60 Hz und 30 Hz .. logisch, es wird ja immer gewartet, bis ein Bild komplett angezeigt wurde, bevor zum nächsten weitergeschaltet wird. Wenn's also gerade eben nicht für 60 Hz reicht, fällt man gleich auf 30 Hz herab.


    Soo performant muß die GPU (graphic processing unit) auch nicht sein, aber sie braucht genug Texturspeicher, und sollte in der Lage sein, Grafiken mit halbwegs zeitgemäßer Geschwindigkeit zu transportieren. Eine gewisse Grund-Leistung muß vorausgesetzt werden, denn an 32 Bit Farbtiefe führt kein Weg vorbei, und die volle Bildschirm-Breite möchte ich eigentlich auch ausnutzen. Nur hätte ich nicht erwartet, daß ein halbwegs moderner Notebook trotz Abschalten aller unnötigen Fenster keinen regulären Test mit 60 Hz schafft... (schafft er nicht mal den Verfolgungs-Test?!?)


    Schafft es eigentlich der Schlierentest von Phantom1? .. obwohl, ich schätze ja: Er verwendet eine viel kleinere Bildfläche.


    Tja, man könnte wohl eine speziell optimierte Version von PixPerAn machen, die auf die "klassische" Art (wie alte DOS-Spiele) funktioniert, und die Animation differenziell erzeugt. Ich muß zugeben, daß ich diesen Aufwand nicht für nötig hielt, da selbst mein alter Notebook noch genug Performance hat, und der Test doch eher "Gamer-orientiert" ist (und eine Gamer-Grafikkarte wird wohl keine Performance-Probleme haben :).


    Die CPU braucht eigentlich überhaupt nicht besonders leistungsfähig zu sein. Die Grafikkarte ist in der Tat viel wichtiger; wobei das wichtigste Merkmal die Größe des Texturspeichers sein dürfte.


    Was wir jetzt wegen dem Notebook machen, weiß ich leider auch nicht. Wobei ich vermute, daß der zum Zocken sowieso nicht allzu gut geeignet ist, kann das sein?


    Viele Grüße
    Wilfried

    Hallo mic,


    Genau so ist es! Die Möglichkeit, einen VSync direkt in ein Programm einzubauen, hat man grundsätzlich. Problematisch ist dann nur, wenn der Treiber beim Bildseitenwechsel (Page flip) auch einen Vsync macht. Dann wartet man sozusagen doppelt, und halbiert somit die Frame-Rate.


    Ab Version 1.0 ist diese interne Synchronisation eingebaut, d.h. man muß sich eigentlich gar nicht mehr um die Treibereinstellungen (bezüglich des VSYNC) zu kümmern. PixPeran versucht auch automatisch die interne Synchronisation zu aktivieren, wenn es nötig ist (also wenn der Treiber nicht synchronisiert). Und falls diese automatische Einstellung versagt, kann man immer noch mit Shift-F7 und Shift-F8 die intere Synchronisation von Hand ein- oder ausschalten.


    Kurz gesagt: Alles im grünen Bereich. Klappt doch alles wunderbar bei Dir :)


    Viele Grüße
    Wilfried

    Hallo Weideblitz,


    Tja, ich denke das kann ich alles genau erklären... :)


    > PixPerAn kommt ich nicht über angezeigte 30 fps hinaus, was den Test dann unsinnig macht.


    Das werden wir noch sehen... :)



    > 1. Der Grafikkartentreiber meines Notebooks (Toshiba Satellite Pro 4600, Penztium III 750 MHz, 128 MB RAM, Windows 98
    > SE) bietet als einstellbare Bildwiederholfrequenzen die Optionen "Standardeinstellung", "Optimal" und "60 Hz" an. Die
    > Ergebnisse sind unter PixPerAn allesamt identisch - bei konstant 30 fps und ca. 53% CPU-Auslastung. "Frames lost" wird
    > kontinuierlich hochgezählt.


    Na, das ist doch schon ziemlich eindeutig. PixPerAn läuft mit 30 fps, das heißt aber noch lange nicht, daß die Vertikalfrequenz auch 30 Hz beträgt (schau mal im OSD ... ups ... Laptops haben das vielleicht gar nicht). Die CPU-Auslastung von 53% deutet darauf hin, daß es die Grafikkarte gerade eben nicht schafft, 60 fps zu ermöglichen. Dank Synchronisation (die scheinbar doch schon im Grafiktreiber aktiviert ist) wird dadurch die Frame-Rate glatt halbiert; damit auch die CPU-Last (53% statt 106%). Laptop-Grafik ist oftmals nicht übermäßig leistungsfähig, wobei mein alter Samsung-Laptop mit ATI-Grafik da keine Probleme hat...


    Alle Bildschirme von PixPerAn bieten die Möglichkeit, alles Überflüssige an Fenstern auszublenden (durch Drücken der Leertaste). Versuch' das doch mal. Vielleicht reicht es dann. mit F12 (gedrückt halten) kannst Du dann nachprüfen, ob die Framerate nun hoch genug ist.


    > 2. Bei Shift+F8, also der Aktivierung der Synchonisation von PixPerAn zur Bildwiederholfrequenz sinkt die
    > Bildwiederholfrequenz auf konstant 20fps und ca. 36% CPU-Load.


    Auch das ist kein Wunder. Offensichtlich ist im Treiber VSync ja sowieso schon aktiv. Wenn dann nochmal pro Frame ein VSync (Warten auf den vertikalen Rücklauf) gemacht wird, gehen pro Programm-Frame 3 Bildschirm-Frames ins Land. So kommen wir genau auf 20 fps und 36% CPU-Last.



    > 3. Der Grafikkartentreiber für die Grafik-CPU (Trident CyperBlade XP) besitzt die Option "Unterschiedliche Bildwiederholrate
    > aktivieren". Möglicherweise steckt die VSync-Option dahinter, aber das geht aus der Beschreibung nicht hervor. Eine andere
    > Option bietet der Treiber nicht.
    > Wenn diese Option aktiviert ist, zeigt PixPerAn im Hauptmenü nur noch konstant 20 fps an bei ca. 70% CPU-Auslastung.


    Das wiederum ist ein bisschen merkwürdig. 70% für nur 20 fps?


    > 4. Wird nun wiederum die Synchronisation unter PixPerAn mit Shift+F8 zugeschaltet, sinkt die Bildwiederholfrequenz auf
    > konstant 15 fps bei ca. 53% CPU-Auslastung.


    Diese Option (unterschiedliche Bildwiederholrate) scheint eine Menge Performance zu kosten. Sagen wir mal: Laß sie besser aus :)


    > 5. Mit Aktivierung der Option "Unterschiedliche Bildwiederholrate aktivieren" wie unter 3. und 4. flackert im Hauptbildschirm von
    > PixPerAn ALLES, was nicht zur blauen Hintergrundfarbe gehört, also auch die Textfenster. Das Flackern erfolgt mit den 20
    > bzw. 15 Hz und ist daher so heftig, das keine erträgliche Bilddarstellung möglich ist.


    Das hört sich sich so an, als würde das Double-Buffering mit dieser Einstellung nicht mehr vernünftig funktionieren...


    > 6. Nach ca. 20 maligem oder häufigerem Starten von PixPerAn mit Aktivierung von "Unterschiedliche Bildwiederholrate
    > aktivieren" passiertes es zweimal nicht repproduzierbar, daß PixPerAn für ca. 2 Sekunden weg, der Bildschrim vollständig
    > schwarz war und danach zurückkehrte, allerdings dann ohne Flackerei! PixPerAn hattte sich sozusagen "selbstgeheilt"!? Die
    > Bildwiederholfrequenz wurde nun wieder 30 fps ohne interne Synchronisation angezeigt.


    Das hört sich für mich nicht regulär an. Wer weiß, was der Treiber da macht. Da kann ich nur nochmals sagen, laß diese Option besser deaktiviert :)


    > 7. Bei deaktivierter Option "Unterschiedliche Bildwiederholrate aktivieren" werden auch bei allen Tests in PixPerAn bei
    > ausgeschalteter Synchronisation konstant 30 fps angezeigt mit zwei Ausnahmen:
    > Ausnahme a): Im Flicker-Bild, welches man mit F9 erreichen kann, werden konstant 60 fps angezeigt!
    > Ausnahme b): Im Erläuterungsbildschirm werden 60 fps angezeigt aber erst dann, wenn das Feld "Leertaste drücken!" aufblinkt.
    > Im Spiel selbst werden wieder nur 30 fps angezeigt.
    > In beiden Fällen werden keine "Fames lost" mehr gezählt.


    Das wiederum ist leicht zu erklären. Der Flicker-Screen ist von Haus aus nicht sehr Ressourcen-hungrig, und läuft deshalb mit vollen 60 fps. Für den Erläuterungs-Bildschirm zu Spiel muß ich erklären: Während das Feld "Leertaste drücken" noch nicht angezeigt wird (das sollten ca. 10-20 Sekunden sein), wird die Hintergrundgrafik des Spieles erzeugt. Deshalb dauert es auch nur beim ersten Mal Starten des Spieles so lang. Während der Berechnung wird der Screen nur statisch angezeigt, ohne Redraw. Erst wenn die Berechnung fertig ist, wird wieder der normale Bildaufbau-Zyklus verwendet, und das "Leertaste Drücken" Feld angezeigt.


    > 8. Mit der Taste F10 kann man wohl jedwede Bewegungen/Animationen in PixPerAn anhalten. In der Anleitung habe ich das
    > nicht gelesen. Habe ich es ggf. übersehen?


    Hmm... ob ich da noch eine Pause-Funktion eingebaut, und die glatt vergessen habe? Werde ich bei Gelegenheit überprüfen :)


    > 9. Wenn ich im Bildschirm Schlierenbilder, welches man mit F6 erreichen kann, mit der Maus einen der Balken anklicke, bleibt das
    > Auto genauso stehen, wie mit F10. Wenn ich den Balken dann verschiebe, sinkt die Bildweiderholfrequenz auf 20 fps ohne
    > signifikante Änderung der CPU-Auslastung. Wenn ich anhalte den Balken zu bewegen, steigt sie wieder auf 30 fps, egal ob mit
    > oder ohne gedrückter Maustaste.


    Das ist Absicht. Wenn Du mit der Maus den Balken anklickst, kannst Du in "Echtzeit" die Schlieren-Charakteristik-Kurve einstellen. Da die Berechnung dafür halbwegs aufwendig ist, fällt währenddessen die Frame-Rate ab. Da die Bewegung des Autos hierdurch sehr unschön aussehen würde, wird es einfach so lange angehalten.


    > Ich kann mir diese Effekte nicht erklären. Ich bin auf deine Antworten gepannt. ;)


    Zusammengefasst ist Die Grafik Deines Laptops gerade eben ein kleines bisschen zu langsam. Abhilfe schafft wahrscheinlich, wenn Du innerhalb der Tests alles Unnötige per Leertaste ausblendest. Um die Frame-Rate dann noch zu überprüfen, halte F12 gedrückt. (Der erste Punkt in der Sektion "Allgemeine Hinweise" der Anleitung erklärt dies übrigens auch)


    > P.S.: Upps, habe gerade die Postingkrone bekommen. Na denn, Prost![/quote]


    Glückwunsch. Wie kann man die sehen? :)


    Viele Grüße
    Wilfried

    Hallo,


    Ich hab das Problem durch Umbenennen der Datei "lösen" können. Ansonsten hätte Freenet immer nur die alte Datei (trotz vorherigem explizitem Löschen derselben, und anderer Dateigröße) immer wieder übernommen X(


    Naja, jedenfalls gibt's hier jetzt wirklich Version 1.01:



    Edit: Ich bin aber auch so doof... es ist nur mein Web-Cache das gerade rumbugt :/... die Version war von Anfang an die Richtige.


    Viele Grüße
    Wilfried

    Mist! Ich krieg' die neue Version nicht hoch auf Freenet. Was da landet ist immer nur die alte! Was ist bloß los?!


    Prad: Was nun?

    Hallo iche,


    es war zum Glück nicht weiter schwierig den Fehler zu reproduzieren und zu finden. Er trat immer dann auf, wenn eine Schlierengrafik gespeichert wurde, und dann der Schlierenbilder-Test verlassen und nochmals betreten wurde. Danke jedenfalls nochmals für die Hilfe.


    Damit gibt's eine neue Version von PixPerAn: (es wurde nur der Fehler korrigiert, weiter nichts)


    @Prad: Bitte übernehmen :D


    Edit: ARGH! Freenet übernimmt irgendwie nicht die neue Version. Ich lade sie zwar dauernd hoch, aber was ich testweise wieder 'runterlade, ist immer noch die alte :--( Was issn da bloß los...


    Edit2: Mit dem alten Link kriegt man immer noch die Version 1.0, obwohl ich die Datei jetzt auf meinem Freenet Account gelöscht habe (?!?). Daher habe ich jetzt kurzerhand diesen Link auf die neue Version umgestellt.


    Viele Grüße
    Wilfried

    Hi Newboardmember,


    Naja, unglaubwürdig möcht ich nicht sagen. Es könnte vielmehr sein, daß es auf irgendeiner Ebene -- die sich uns noch nicht erschlossen hat -- irgendetwas anders ist, als wir alle erwarten. Ich glaube Dir jedenfalls schon, daß Du genau das gesehen hast, was Du berichtest.


    Nicht die Ränder des Bildes solltest Du beobachten, sondern die komplette gerasterte Fläche. Auf der nativen Auflösung sollte sie perfekt gleichmäßig sein, von etwas weiter betrachtet nur als neutrales gleichmäßiges Grau erscheinen. Jeder einzelne schwarze Pixel sollte auch von bloßem Auge als scharfes kleines Mini-Quadrat zu erkennen sein.


    In einer interpolierten Auflösung sollten die einzelnen schwarzen Pixel nicht mehr so gut einzeln erkennbar sein, und auch nicht als kleine Quadrate. Außerdem sollte die Fläche nicht perfekt gleichmäßig, sein, sondern "übergeordnete" Unregelmäßigkeiten in einem größeren Raster zeigen, sozusagen eine Art übergeordnete Struktur.


    Um sicher zu gehen, Copy&Paste- die Grafik mal in Paint hinein und schau sie Dir bei zwei- oder vierfacher Vergrößerung an. Bei nativer Auflösung sollte sich dadurch kein "qualitativer" Unterschied in der Darstellung ergeben, nur die Größe ist halt größer.


    Viele Grüße
    Wilfried

    Hallo haribo,


    Ich möchte darauf hinweisen, daß 99% der Tests noch mit dem alten Programm gemacht wurden. Der dort verwendete Test ist durchaus sehr sinnvoll, allerdings wohl nicht unbedingt der genaueste. Durch die Kombination der Tests bei PixPeran (die sehr unterschiedlich funktionieren) sollte sich ein, so hoffe ich, ein differenzierteres Bild ergeben.


    Davon abgesehen, scheint es durchaus bei einigen Monitortypen eine recht große "Serienstreuung" zu geben, denn die extremen Unterschiede die teilweise geschildert wurden, können unmöglich nur auf Unterschiede in der Wahrnehmung zurückgeführt werden.


    BTW, Soviel ich weiß, verwendet PC Games trotzdem auch den alten Test :)


    Viele Grüße
    Wilfried

    Hallo mic,


    Es scheint, daß Dein Treiber VSync unter DirectX schon aktiviert hat (es kann bei einigen Treiberversionen passieren, daß dies nicht von Hand einstellbar ist, wie ich festgestellt habe). Die OpenGL-Einstellung ist eine ganz andere Sache und hat nix damit zu tun.


    Wenn Du nun mit Shift+F8 noch zusätzlich den internen VSync aktivierst (der ist nicht die DirectX-Einstellung), wird sozusagen doppelt synchronisiert, d.h. zweimal pro Frame wird auf den vertikalen Rücksprung gewartet. Daraus ergibt sich dann eine halbierte Frame Rate, also 30 Hz.


    PixPerAn Version 1.0 hat eine Art "Halbautomatik", es untersucht die Frame-Rate und "schätzt", ob der Vsync schon im Treiber aktiviert war. Damit man aber immer noch die volle Kontrolle hat, kann man mit Shift+F8 und Shift-F7 fest einstellen, ob die interne Synchronisation an oder aus sein soll. Auf die Treiber-Einstellung selbst kann ich nicht so direkt zugreifen, jedenfalls nicht auf allgemeine Art. Die zusätzliche Einstellung innerhalb von PixPerAn hat nach außen keinerlei Wirkung (d.h. wirkt sich nicht auf andere Programme oder das System aus).


    Wie schon in der Anleitung beschrieben: Das, worauf es eigentlich ankommt, ist eine stabile Frame Rate von 60 Hz zu bekommen, und dazu noch eine flüssige und ruckfreie Bewegung. Also funktionierte es ja eigentlich auf Anhieb ganz gut :)


    Viele Grüße
    Wilfried

    Hallo iche,


    Danke für den Fehlerbericht. Tja, man findet sie selber nie alle. Ich werde gleich probieren ihn zu reproduzieren, wobei ich jedoch meine, das schon mal probiert zu haben.


    Bringt er beim "Abstürzen" eine Fehlermeldung? Hängt er sich komplett auf, oder kommst Du zurück zu Windows? Welches Betriebssystem verwendest Du? Wie ist genau die Tastatur-Eingabefolge (Wenn Du nur Tastaturbefehle verwenden würdest) um den Absturz zu produzieren?


    Tja, zu umfangreich, das glaube ich inzwischen auch fast. Hast Du eine Idee, wo ich vereinfachen könnte, oder die Bedienung schneller kriegen?


    BTW vielen Dank für die Testergebnisse. Sie wirken auf mich recht plausibel, auch wenn ich staune, wie "unzerschliert" das Schlierenbild bei Dir aussieht! Du siehst garantiert auch aus den Augenwinkeln nicht das allergeringste Flackern bei dem Monitor?


    Viele Grüße
    Wilfried

    Hi Audiali,


    So was ähnliches, ja: Bei mir sind es auch horizontale herumzuckende Streifen, aber sie treten nur sehr selten auf: Bei "gerasterten" Grafiken (so wie die Beispielgrafik weiter oben hier im Thread), und auch nur dann, wenn die Grafikkarte noch nicht lange an ist. (Ob der Monitor schon länger läuft, z.B. an einem anderen Computer, ist egal). Tja, wie's aussieht ist die Signalübertragung per DVI leider doch nicht so störungssicher, wie man es erwarten sollte. Find ich natürlich auch ein bisschen bitter. Möglicherweise hängt das auch von der Kombination Monitor - Grafikkarte ab.


    Was mir allerdings auch aufgefallen ist: Es gibt noch eine andere Gelegenheit, bei der solche Streifen gelegentlich auftreten: Nämlich in 32-Bit-Modi unter DirectX, so ist es schon bei PixPerAn oder Gothic2 aufgetreten. Interessanterweise sind in solchem Falle die Streifen genau dann stärker zu sehen, wenn der 3D-Chip mehr arbeitet, z.B. wenn ich die Grafikausgabe "einfriere", so daß nur noch dasselbe Bild statisch angezeigt wird, sind sie auf einmal weg. Vielleicht also doch auch Treiber-Bugs oder generelle Probleme des Grafikchips?


    Allerdings habe ich normalerweise keinen Ärger damit. (ein Glück:-)


    Viele Grüße
    Wilfried

    UPDATE!


    Ich habe die Anleitung geändert und folgenden Punkt zum Ergebnis hinzugefügt:


    Panel-Update-Frequenz


    Die hat entweder einen festen Wert in Hz, oder passt sich jeweils an die Vertikalfrequenz an. Da das Wissen darüber durchaus wichtig ist, wenn man den Monitor für schnelle Animation nutzen will, habe ich diese Information ins Testergebnis integriert.


    Vorher hatte ich dies unter "Besonderheiten" dazugeschrieben:


    "Besonderheiten: Panel-Update-Frequenz ist fix auf 60 Hz, und wird nicht an die eingestellte Vertikalfrequenz der Grafikkarte angeglichen."


    Da dies aber etwas ist, was für jeden TFT-Monitor von Interesse sein sollte, habe ich es als "regulären Punkt" aufgenommen. Sollte es noch Fragen zu dem Thema geben, scheut euch nicht, ins FAQ-Forum zu posten!


    Viele Grüße
    Wilfried

    Hallo Iche (und Deepstep),


    Interessieren täts mich schon mal: Warum hast Du für den Schlierentest das alte Testprogramm verwendet?
    Wenn es Probleme mit dem neuen gibt, die es mit dem alten nicht gibt, könnte man die vielleicht ausräumen... wenn man es mir mitteilen würde :)


    Naja, ich gebs ja zu: Die Anleitung kann einen erstmal erschlagen. Und man muß so viel machen :-). Aber auf der anderen Seite: Wie soll anderes sichergestellt werden, daß _wirklich_ die korrekten Bedingungen herrschen? Z.B. daß nicht eine falsche Vertikalfrequenz eingestellt ist? Wenn das beim alten Test passiert, merkt das einfach niemand... Oder die Problematik mit der internen Update-Frequenz eines Monitors, die entweder fix ist oder sich an die Vertikalfrequenz hält. Die Effekte hierdurch treten auf jeden Fall auf, egal welches Programm verwendet wird, und sind maßgeblich daran beteiligt, wie flüssig die Bewegungsdarstellung ist. Aber es wird einfach nicht darüber gesprochen. Ich habe das Gefühl, kaum jemandem fällt es auf ;)


    Viele Grüße
    Wilfried

    Hi Torti,


    Ich komme leider gerade nicht ganz mit: Die "Pixelgeschwindigkeit" ? Ist das die Geschwindigkeit des Autos in Pixeln/Frame? Aber die kann man doch direkt einstellen, und muß sie folglich auch nicht ermitteln.


    Daß andere Werte als 60 Hz für die Vertikalfrequenz der DirectX-Modi defaultmäßig verwendet werden, ist heutzutage gar nicht so selten. Für Röhrenmonitore macht dies ja auch Sinn. Das heißt aber auch: Für TFT's mußt Du das oftmals in den Treibereinstellungen erst umstellen, um die 60 Hz auch in DirectX-Programmen(Spiele, Pixperan, usw) zu haben.


    Das Programm(Pixperan) zeigt einfach nur an, mit welcher Frame Rate es läuft. Das _sollte_ identisch sein mit der Vertikalfrequenz. Wenn nicht, läuft irgendetwas schief.

    Hallo Torti,


    Die Vertikalfrequenz des Monitors kann man immer nur im Betriebssystem (bzw. Grafikkartentreiber) einstellen. Der Monitor hat keine Möglichkeit, diese zu beeinflussen, daher kann man sie auch nicht im OSD einstellen (sehr wohl aber ablesen!) PixPerAn versucht immer, die Frame-Rate genau mit der Vertikalfrequenz zu synchronisieren, da dies für optimal flüssige Bewegung notwendig ist. Dies wiederum ist für einen Schlierentest notwendig.


    Wegen dem Gamma-Faktor: 2.03 hört sich in der Tat wesentlich besser an :-). Merkwürdig. Also ändert eine Einstellung des Kontrastes bei diesem Monitor in Wirklichkeit den Gamma-Faktor? D.h. Du könntest theoretisch auch durch Drehen am Kontrast-Regler des OSD's die grauen Quadrate quasi verschwinden lassen? Das sollte eigentlich nicht sein. Hmmm... das macht die ganze Sache wesentlich komplizierter.
    Wenn Du schon bei der "Default-Einstellung" alle Graustufen gut unterschieden kannst (auch die dunklen), solltest Du die Kontrast-Einstellung vielleicht besser doch nicht für den Test ändern.


    Was die Schlierenbilder angeht... Es ist schon nicht so einfach die Parameter so einzustellen, daß das "Foto" so aussieht wie die echten Schlieren. Wo sind denn die Unterschiede, bzw. was würdest Du gerne einstellen, klappt aber nicht?


    Viele Grüße
    Wilfried

    Frage: Wie kann man Produktionsdatum, Seriennummer, usw. für einen TFT-Monitor herausfinden?


    Die folgenden Informationen stammen aus diesem Thread:
    Es gibt System-Programme, die Monitor-Daten auslesen können:
    - NaViSet von NEC-Mitsubishi, bietet auch Möglichkeiten zur Steuerung des Monitors
    - Das Freeware-Utility Aida32 hier.