Welcome to AEP Emulation Page - Emulation News
   
Hosting by: Uberspace.de   
Menu
· Home / News
· News Categories
· News Archiv
· Submit news

· My Account
· Search
· Forums
· Online Games
· Weblinks
· Game Reviews
· Translations
· Impressum

Downloads
 


Infos
· Museum
· Infocenter
· Das AEP Team
· Member Liste
· Top 25 Liste
· Glossar
· FAQ

Friends
· Emulation64
· 1Emulation.com
· Emu-France
· progetto-SNAPS


Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
Rommaster
Post subject: V-Sync  PostPosted: Dec 11, 2011 - 11:02 PM
Retromeister


Joined: Apr 13, 2006
Posts: 1299



Highscores in 10/2019

Gedankenexperiment :

Ein Standard-TFT mit 60 Hz Refresh-Rate (sprich 60 Bildaktualisierungen pro Sekunde, und ein PC undefinierter Leistung.

Der Monitor stellt pro Sekunde 60 Bilder dar (entspricht 16,66667 ms pro Bild).

Der PC liefert pro Sekunde 180 Bilder (entspricht 5,55556 ms pro Bild).

Fall 1 (Vsync an) :

Die Grafikkarte wartet mit der Berechnung des 2. Bildes, bis der Monitor das erste vollständig dargestellt hat. Erst dann wird das 2. Bild berechnet, an den Monitor weitergegeben und dargestellt.

Fall 2 (Vsync aus) :

Die Grafikkarte berechnet das 1. Bild. In der Zeit, die der Monitor zur Darstellung benötigt, hat die Grafikkarte zwischenzeitlich schon zwei Folgebilder berechnet, die allerdings nicht dargestellt werden können.

Der Monitor gibt folglich erst das 4. berechnete Bild wieder. Folglich gehen pro dargestellten Bild 2 berechnete verloren.

Wo liegt also der Vorteil an Vsync aus bei einem 60 Hz TFT ?

In Gedanken müßte also die Darstellung mit Vsync aus trotz höherer Framerate ruckliger wirken, oder liege ich da falsch ?
 
 
 
 View user's profile ICQ Number 
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 12, 2011 - 12:31 PM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

ja da liegste falsch. das ganze funktioniert etwas anders. bei fall 1 wird nämlich auch schon sofort das zweite bild berechnet, und bei fall 2 werden sehr wohl alle berechneten bilder dargestellt.
ich versuche es mal näher zu erläutern mit den notwenigen grundlagen.

tl;dr:
vsync ist keine spezielle sache für crts, sondern generell sinnvoll bei computergrafik.
triple buffering ist in kombination dazu empfehlenswert um performance-einbußen zu vermeiden.

Double Buffering

generell funktioniert die anzeige der computer-grafik immer mindestens mit 2 bildpuffern (double buffering), dem front- und dem backbuffer. dies muss immer mindestens der fall sein, da stets sicher gestellt werden muss, dass beim bildaufruf der anzeige auch ein frame verfügbar ist. ansonsten würde zu einem enormen bildflackern kommen (single buffering).
also zurück zu den beiden buffern.. wenn die gpu ein neues frame fertig gerendert hat, wird dies stets in den backbuffer geschrieben. unabhängig davon was die anzeige gerade macht, gibts einen sogenannten pageflip, d.h. back- und front-buffer tauschen ihre rollen. für die anzeige ist dabei jedoch immer nur der frontbuffer sichtbar, greift also nur darauf zu. damit ist dann sichergestellt, dass auch stets bildinformationen verfügbar sind. ja selbst wenn die gpu gerade mal n hänger hat, wird ja der frontbuffer nicht gelöscht und das selbe frame wird einfach weiter angezeigt.

nun zur funktionsweise von vsync...

Vsync aus (Double Buffering)

vsync ist aus, d.h. beim pageflip wird keine rücksicht genommen, wo sich gerade das anzeigegerät beim bildaufbau befindet (diese baut das bild zeilenweise auf). sobald das neue frame fertig gerendert ist, kommts in den backbuffer und es erfolgt der oben beschriebene page-flip. die anzeige macht mitten im bildaufbau einfach mit dem jetzt neuen bild im frontbuffer weiter. dabei entsteht ein bildbruch, da ja der monitor ursprünglich mit dem vorherigen frame angefangen hat. diesen effekt nennt man tearing. anders gesagt.. mit deaktiviertem vsync wirst du nie ein vollständiges bild sehen, sondern immer nur zusammengestückelte bilder. bei 180fps und 60hz ergibt sich dann eben, dass jedes angezeigte bild bruchstückhaft aus 3 gerenderten frames besteht. trotz hoher fps-zahl wirkt tearing sehr störend und ruckliger/stottender als eine niedrigere ohne tearing.

+ die gpu wird voll ausgelastet und hat stets etwas zu tun
- nervendes tearing

Vsync an(Double Buffering)

vsync ist an, d.h. der pageflip findet immer nur dann statt, wenn das anzeigegerät wieder anfängt ein neues bild mit der ersten zeile darzustellen. ist nun ein neues frame fertig gerendert und wird wie üblich in den backbuffer geschrieben, der monitor ist aber noch nicht so weit, so wird jetzt eben so lange gewartet. derweil ist die gpu inaktiv. denn im backbuffer ist ja schon ein neues frame und auf den frontbuffer wird gerade zugegriffen. erst wenn der monitor mit dem aktuellen bildaufbau fertig ist, kommt der pageflip und die gpu fängt an ein neues bild zu rendern. durch diese synchronisierung kommt es zu keinem tearing, die fps-rate entspricht der hz-frequenz der anzeige.

+ keine bildbrüche, frames werden vollständig angezeigt
- gpu muss ständig auf den monitor warten, bei rechenintensiven szenen kann es dadurch zu massiven fps-drops kommen

um die nachteile des letzteren auszubessern, gibts die option des sogenannten triple buffering...

Vsync an(Triple Buffering)

prinzipiell wie bei double buffering, nur haben wir jetzt einen zusätzlichen bildpuffer (einen sekundären backbuffer). das ganze läuft wieder so ab, dass für das anzeigegerät nur der frontbuffer existent ist, darüber hinaus weiß es von nichts. die gpu schreibt wie immer ihr fertig gerendertes frame in den (primären) backbuffer. ist der monitor nun noch nicht so weit, so macht die gpu aber jetzt bei triple buffering einfach weiter und schreibt das nächste frame einfach in den sekundären backbuffer. anschließend tauschen die beiden backbuffer ihre rolle, sodass das aktuellste fertige frame immer im primären backbuffer liegt und die gpu macht wie beschrieben weiter. ist der monitor dann irgendwann endlich so weit, so gibts den pageflip mit dem frontbuffer und dem primären backbuffer.

+ keine bildbrüche, frames werden vollständig angezeigt
+ keine performance-einbußen im vergleich zu vsync-aus
- zusätzlicher video-speicher für dritten bildpuffer nötig
(allerdings sehr wenig ca. 20-30MB, bei aktuellen graikkarten kein thema)


jo schlussendlich, mein fazit.. gibt eigentlich keinen grund vsync (+ triple buffering) nicht zu nutzen, egalb ob nun crt oder tft. performance-technisch machts keinen unterschied und man ist das lästige tearing los, was ein wesentlich angenehmeres, flüssigeres bildvergnügen ist.

hoffe mal, das hat etwas licht ins dunkel gebracht Wink

fallste noch näher ins detail gehen willst, kann ich nur diesen artikel hier empfehlen:
http://www.anandtech.com/show/2794/1
 
 
 
 View user's profile  
Reply with quote Back to top
krysmopompasOffline
Post subject:   PostPosted: Dec 12, 2011 - 12:40 PM
Retrogott


Joined: Jun 19, 2008
Posts: 2066



Highscores in 10/2019

Status: Offline
Sp00kyFox wrote:
gibt eigentlich keinen grund vsync (+ triple buffering) nicht zu nutzen

Je mehr man puffert desto größer ist das Input Lag.
Tearing kann ich aber auch nicht ausstehen daher bevorzuge ich meist V-Sync.

_________________
If you can’t run at 60 fps, you’re not a good racing game. 
 
 
 View user's profile  
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 12, 2011 - 01:45 PM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

krysmopompas wrote:

Je mehr man puffert desto größer ist das Input Lag.

nicht wenn du triple buffering nutzt, da dann die beiden backbuffer sich jeweils abwechseln und somit das aktuelleste frame stets im primären backbuffer bereit steht für den pageflip. was du meinst, ist wohl ne prerendererd buffer list oder auch flip queue, das ist aber ein anderes thema und hat erst einmal nichts mit vsync zu tun.
 
 
 
 View user's profile  
Reply with quote Back to top
krysmopompasOffline
Post subject:   PostPosted: Dec 12, 2011 - 07:04 PM
Retrogott


Joined: Jun 19, 2008
Posts: 2066



Highscores in 10/2019

Status: Offline
Sp00kyFox wrote:

nicht wenn du triple buffering nutzt, da dann die beiden backbuffer sich jeweils abwechseln und somit das aktuelleste frame stets im primären backbuffer bereit steht für den pageflip.

Leuchtet mir nicht ganz ein.
Das neueste Bild kommt doch in den 2. Puffer. Vorher muß aber noch der 1 Puffer angezeigt werden. Frames auslassen wäre keine gute Idee.

Edit:

Wikipedia meint das auch. Razz
Wenn ich eine flüssige Darstellung haben will darf ich keine Frames wegschmeißen, habe dafür aber mehr Lag:
Quote:
Another method of triple buffering involves synchronizing with the monitor frame rate. Drawing is not done if both back buffers contain finished images that have not been displayed yet. This avoids wasting CPU drawing undisplayed images and also results in a more constant frame rate (smoother movement of moving objects), but with increased latency. This is the case when using triple buffering in DirectX, where a chain of 3 buffers are rendered and always displayed.

http://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering

_________________
If you can’t run at 60 fps, you’re not a good racing game. 
 
 
 View user's profile  
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 12, 2011 - 09:24 PM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

krysmopompas wrote:

Leuchtet mir nicht ganz ein.
Das neueste Bild kommt doch in den 2. Puffer. Vorher muß aber noch der 1 Puffer angezeigt werden. Frames auslassen wäre keine gute Idee.

so funktioniert das ganze aber nicht. ansonsten bringt nämlich triple buffering (kurz: tp) nichts. die idee beim tp ist ja gerade, dass man die performance-einbrüche beim vsync mit double buffering (kurz: db) umgeht. würde die gpu beim tp nachdem es den sekundären backbuffer auch gefüllt hat einfach warten, so würde tp keinen sinn machen. sie soll ja gerade voll ausgelastet werden. daher wird sobald der sekundäre backbuffer gefüllt wurde, der sekundäre mit dem primären ausgetauscht und die gpu hat nonstop arbeit.

und, dass man berechnete frames auslässt ist im gegenteil eine gute idee. wenn das nicht so wäre, würdest du nämlich einen immer größeren lag bekommen, wenn die fps-rate höher ist als die hz-frequenz. und ja, bin auch schon mal woanders bei ner diskussion darauf eingegangen. was der wikipedia-artikel meint ist nicht tp, sondern eine render ahead queue (mit 3 buffern, welche dann fälschlicherweise als tp bezeichnet wird). die funktionieren wie eine schlange, die beiden backbuffer beim tp hingegen wie ein stack (mit größe 2) wo der boden immer entsorgt wird.

bzgl ausgelassener frames.. ich schätze mal du dachtest da vlt unbewusst an 2d-games. dort ist es natürlich schlecht so etwas zu tun, da in den frames einzelne animationsphasen zu sehen sind, welche dann übersprungen werden. allerdings haben 2d-games auch üblicherweise die eigenschaft, dass sie mit einer absolut konstanten framerate laufen, sodass sich die ganze problematik ohnehin nicht stellt.
 
 
 
 View user's profile  
Reply with quote Back to top
Retro-NerdOffline
Post subject:   PostPosted: Dec 12, 2011 - 11:48 PM
Retrokenner


Joined: Jul 02, 2006
Posts: 509



Highscores in 10/2019

Status: Offline
Die ganzen Emulatoren haben dank Multi-Task Betriebssysteme sowieso einen Input lag von 1-2 Frames, der läßt sich auch nicht beheben. Und wer meint, das ein Double oder Tripple Buffer nicht zu einer erhöhten Latenz führt sollte mal die neueren WinUAE Versionen austesten. Der neue "Low Latency Vsync", ohne jeglichen Buffer, sorgt für ein deutlich flüssigeres Spielerlebniss. Besonders gut ist das bei den Pinball Spielen von Digital Illusions zu sehen.

Vsync + Tripple Buffer mag für moderne 3D Spiele noch halbwegs sinvoll sein. Für Emulatoren von 2D Systemen allerdings nicht.
 
 
 
 View user's profile Visit poster's website  
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 13, 2011 - 01:19 AM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

Retro-Nerd wrote:

Und wer meint, das ein Double oder Tripple Buffer nicht zu einer erhöhten Latenz führt sollte mal die neueren WinUAE Versionen austesten. Der neue "Low Latency Vsync", ohne jeglichen Buffer, sorgt für ein deutlich flüssigeres Spielerlebniss.

da sollteste nicht von einem bestimmten implementierung auf die allgemeine funktionsweise schließen. gerade bei der emulation von 2d-system läuft das ohnehin etwas anders ab, da der renderingprozess nicht dem eigentlichen system unterliegt, sondern in einem virtuellen prozess stattfindet. entsprechend wird das ganze komplizierter. wer weiß was in vorherigen versionen für unoptimierte hacks verwendet wurden, um einen vsync-effekt zu erzeugen.
und nein, WinUAE wird sicherlich kein "zero" oder "single buffering" verwenden. das mindeste was eine fehler/flacker-freie darstellung ermöglicht ist double buffering, unabhängig ob nun mit vsync oder nicht. das gilt nicht nur für spiele sondern allgemein für computergrafik. sowas wie gar keinen bildbuffer gibts nicht.

Retro-Nerd wrote:

Vsync + Tripple Buffer mag für moderne 3D Spiele noch halbwegs sinvoll sein. Für Emulatoren von 2D Systemen allerdings nicht.

halbwegs? für 3d-spiele ist das ganze absolut essentiell, außer man akzeptiert bildartefakte.
bei 2d-spielen wie oben schon erwähnt allerdings nicht. diese haben üblicherweise eine durchgehend konstante framerate. entsprechend reicht vsync(db) alleine völlig aus.
bei einigen arcade-emus wie mame oder fba gibts da auch noch die option, die geschwindigkeit des spiels mit der hz-frequenz des monitors zu koppeln. ganz nützlich falls die beiden sehr dicht beieinander liegen.
 
 
 
 View user's profile  
Reply with quote Back to top
Retro-NerdOffline
Post subject:   PostPosted: Dec 13, 2011 - 01:40 AM
Retrokenner


Joined: Jul 02, 2006
Posts: 509



Highscores in 10/2019

Status: Offline
Quote:
und nein, WinUAE wird sicherlich kein "zero" oder "single buffering" verwenden. das mindeste was eine fehler/flacker-freie darstellung ermöglicht ist double buffering, unabhängig ob nun mit vsync oder nicht. das gilt nicht nur für spiele sondern allgemein für computergrafik. sowas wie gar keinen bildbuffer gibts nicht.



Da liegst du nun leider falsch. WinUAE läuft mittlerweile gänzlich ohne Buffer, da der Emulator die benötigte Hz Zahl nun selber scannt, und sich nicht mehr auf die (meist grottigen) Grafiktreiber verläßt. Das funktioniert im Falle des Amiga Emulators aber nur perfekt, wenn das Display auch native 50Hz ausgeben kann. PAL Emulatoren auf 56-60Hz LCD Monitore laufen zu lassen ist auch nicht wirklich sinnvoll.

Für mehr solltest du nachlesen, was WinUAE Programmierer Toni Wilen zu dem Thema auf dem EAB (English Amiga Board) schreibt. Der Low Latency Vsync ohne Buffer ist seit v2.3.3 Beta 1 implemenitiert.

LINK

Quote:

...wer weiß was in vorherigen versionen für unoptimierte hacks verwendet wurden, um einen vsync-effekt zu erzeugen.


Toni Wilen hat sich vorher einfach nur darauf verlassen was die Grafiktreiber von Haus aus bieten, er hat da keine Hacks benutzt. Jetzt läuft es deutlich flüssiger und senkt das Input Lag noch ein kleines Stück nach unten.
 
 
 
 View user's profile Visit poster's website  
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 13, 2011 - 03:25 AM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

Retro-Nerd wrote:

Da liegst du nun leider falsch. WinUAE läuft mittlerweile gänzlich ohne Buffer, da der Emulator die benötigte Hz Zahl nun selber scannt, und sich nicht mehr auf die (meist grottigen) Grafiktreiber verläßt....

da muss ich dir erneut widersprechen. um mal etwas weiter auszuholen. aufgrund der konstanten framerate von 2d-systemen, wird vsync in emus so implementiert, dass einige zeit im voraus schon frames berechnet werden (wodurch der lag entsteht). denn wenn man einfach ohne vezögerung neue frames anfordern würde, entspräche das einer beschleunigung des emulationsvorgans.

genau das war die alte vsync-implementierung von winuae. bei der neuen hingegen handelt es sich nicht um vsync, auch wenn es in den optionen so genannt wird (denn es verhindert kein tearing). stattdessen wird die emulationsgeschwindigkeit bzw die framerate der hz-frequenz des anzeigegeräts angepasst, was ich auch schon erwähnt hatte (feature bei einigen arcade-emus). dadurch wird das tearing konstant, es wandert nicht mehr quer über den screen.

trotzdem verwendet winuae auch mit dieser neuen methode weiterhin bildbuffer. denn wie schon gesagt, benötigt computergrafik generell mindestens einen buffer um das gerendertes bild irgendwo zu speichern und abrufen zu können, ohne gibts keine anzeige. da winuae selbst als grafiksschnittstelle ddraw oder direct3d verwendet, nutzt es somit double buffering. denn single buffering wird von beiden nicht supported.

Retro-Nerd wrote:

Toni Wilen hat sich vorher einfach nur darauf verlassen was die Grafiktreiber von Haus aus bieten, er hat da keine Hacks benutzt. Jetzt läuft es deutlich flüssiger und senkt das Input Lag noch ein kleines Stück nach unten.

siehe oben. das hat nichts mit unoptimierten grafiktreibern zu tun, sondern mit der üblichen vsync-implementierung bei 2d-emus an sich. die ganze problematik des inputlags bei vsync stellt sich bei high-level-3d-emus und 3d-spielen im allgemeinen nicht, da dort die render-rate unabhängig von der spielgeschwindigkeit ist. und somit immer im voraus frames gerendert werden können, ohne, dass es zu einem speedup kommt.
 
 
 
 View user's profile  
Reply with quote Back to top
Retro-NerdOffline
Post subject:   PostPosted: Dec 13, 2011 - 03:40 AM
Retrokenner


Joined: Jul 02, 2006
Posts: 509



Highscores in 10/2019

Status: Offline
Konstantes Tearing? Wie kommst du nur darauf? Es gibt schlichtweg kein Tearing mehr in WinUAE zu sehen, sofern ein 50Hz fähiges Display vorhanden ist, z.B. per HDMI. Und natürlich ist da auch weiterhin ein echtes Vsync. Wie Emulatoren intern die Frames aufbereiten mag auf einem anderen Blatt stehen. Fakt ist, das kein Double oder Tripple Buffer aus dem Grafiktreiber mehr nötig ist. Und dass das so ist kann man ganz leicht selber testen. Einfach mal die genannten Pinball Spiele jeweils mit No Buffer, Double Buffer, Tripple Buffer austesten. No Buffer = fast flüssige Tastatur, Double Buffer = schon leichte Verzögerung, Tripple Buffer = deutlich verzögerte Steuerung.

Quote:
...bei der neuen hingegen handelt es sich nicht um vsync, auch wenn es in den optionen so genannt wird (denn es verhindert kein tearing).


Natürlich verhindert es Tearing, wenn der Vsync aktiviert ist. Kannst du doch leicht nachtesten. Einfach mal den Vsync komplett deaktivieren. Dann hilft auch kein Double oder Tripple Buffer mehr. Eine häßliche Tearing Line wandert durchs Bild. Mit Vsync ist alles butterweich. Da sollte man dann natürlich Sachen testen, die perfekt scrollen. Wie z.B. Turrican.
 
 
 
 View user's profile Visit poster's website  
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 13, 2011 - 03:57 AM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

Retro-Nerd wrote:
Konstantes Tearing? Wie kommst du nur darauf? Es gibt schlichtweg kein Tearing mehr in WinUAE zu sehen, sofern ein 50Hz fähiges Display vorhanden ist, z.B. per HDMI. Und natürlich ist da auch weiterhin ein echtes Vsync.

nein, es handelt sich dabei um kein vsync, da hier kein durch den grafiktreiber initalisierter synchronierungsprozess zwischen anzeigeaktualiserung und pageflip vorliegt. und genau diesen mechanismus nennt man vsync. stattdessen wird manuell in einem regelmäßigen zeitintervall der pageflip verursacht. dadurch, dass das zeitintervall der hz-frequenz der anzeige entspricht, wandert das tearing nicht mehr.

Retro-Nerd wrote:
Wie Emulatoren intern die Frames aufbereiten mag auf einem anderen Blatt stehen. Fakt ist, das kein Double oder Tripple Buffer aus dem Grafiktreiber mehr nötig ist.

directdraw und direct3d lassen sich nicht mit single buffering betreiben.

Retro-Nerd wrote:

Und dass das so ist kann man ganz leicht selber testen. Einfach mal die genannten Pinball Spiele jeweils mit No Buffer, Double Buffer, Tripple Buffer austesten. No Buffer = fast flüssige Tastatur, Double Buffer = schon leichte Verzögerung, Tripple Buffer = deutlich verzögerte Steuerung.

du verwechselst hier mehrere buffer-typen und anzeige-mechanismen. bei der einstellung no buffer arbeitet der emulator in echtzeit, trotzdem wird dabei double buffering (ohne vsync) betrieben. wobei der pageflip durch die geschwindigkeitsanpassung der emulation zusammenfällt mit dem rendering eines neuen frames. bei der einstellung double bzw triple buffering wird "echtes" vsync verwendet, jedoch arbeitet hier der emulator zeitlich voraus, wodurch zu beobachtender lag entsteht.

Retro-Nerd wrote:
Natürlich verhindert es Tearing, wenn der Vsync aktiviert ist. Kannst du doch leicht nachtesten....

die normale vsync-option schon, die neue nicht. wie gesagt, sie macht das tearing konstant. durch entsprechende frameverzögerung lässt sich dann das tearing genau zwischen die oberste und unterste bildezeile packen. womit es theoretisch nicht verschwindet, aber praktisch nicht mehr sichtbar ist.
 
 
 
 View user's profile  
Reply with quote Back to top
Retro-NerdOffline
Post subject:   PostPosted: Dec 13, 2011 - 04:07 AM
Retrokenner


Joined: Jul 02, 2006
Posts: 509



Highscores in 10/2019

Status: Offline
Das poste mal auf dem EAB. Würde gern mal, nur aus reinem Interesse, wissen, was Toni Wilen davon hält. Kann ich so gerade nicht ganz nachvollziehen. Er beschreibt das dort gänzlich anders. Und nein, ich habe das ganz sicher nicht falsch verstanden.

Quote:
wie gesagt, sie macht das tearing konstant. durch entsprechende frameverzögerung lässt sich dann das tearing genau zwischen die oberste und unterste bildezeile packen. womit es theoretisch nicht verschwindet, aber praktisch nicht mehr sichtbar ist.


Du meinst die ersten sichtbaren Bildzeilen oben und unten? Da ist in WinUAE absolut überhaupt nichts zu sehen. Praktisch nicht mehr sichtbar trifft nicht zu, es ist NICHTS zu sehen.
 
 
 
 View user's profile Visit poster's website  
Reply with quote Back to top
Sp00kyFox
Post subject:   PostPosted: Dec 13, 2011 - 04:17 AM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 10/2019

ich denke schon. mir scheint, dass dir der unterschied zwischen dem zeitlichen vorrendern und der grafikanzeige mittels buffern nicht ganz klar ist. in den changelogs war schließlich auch nicht die rede von, dass nun gar keine buffer benötigt werden (was aufgrund der verwendeten grafikschnittstelle nicht möglich ist). sondern, dass keine zusätzlichen buffer benötigt werden.

originallaut changelog v2.3.3 Beta 1:
- new vsync option
* does not need extra buffers (very little input lag), make sure "no buffering" is selected


Retro-Nerd wrote:
Du meinst die ersten sichtbaren Bildzeilen oben und unten? Da ist in WinUAE absolut überhaupt nichts zu sehen. Praktisch nicht mehr sichtbar trifft nicht zu, es ist NICHTS zu sehen.

um präzise zu sein, ich mein genau zwischen der letzten und der ersten bildzeile des jeweiligen anzeigegeräts und nicht der des emulierten systems.
und doch, die formulierung trifft es präzise.
 
 
 
 View user's profile  
Reply with quote Back to top
Retro-NerdOffline
Post subject:   PostPosted: Dec 13, 2011 - 04:27 AM
Retrokenner


Joined: Jul 02, 2006
Posts: 509



Highscores in 10/2019

Status: Offline
Dann haben wir wohl aneinander vorbeigeredet. Keine Extra Buffer, dass mit den internen Double Buffer zur Grafikanzeige muß ich wohl akzeptieren. Soweit gehen meine Kenntnisse nicht. Was andere Emulatoren da anbieten wären aber dann auch nur Extra Buffer, die den schon erwähnten Input Lag verursachen.

Quote:
um präzise zu sein, ich mein genau zwischen der letzten und der ersten bildzeile des jeweiligen anzeigegeräts und nicht der des emulierten systems.


Gerade mal ein PAL Overscan Titel in WinUAE angeschaut, der auch wirklich den gesamten Bildschirm mit Grafik ausfüllt. Da ist kein Ansatz von Tearing zu erkennen. Für mich bleibt es zumindestens unsichtbar.
 
 
 
 View user's profile Visit poster's website  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © The PNphpBB Group
Credits
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 1998 - 2018 AEP Emulation Page.
You can syndicate our news via RSS using the file rss_en.xml for English headlines and rss_de.xml for German headlines.