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
Sp00kyFox
Post subject:   PostPosted: Dec 13, 2011 - 07:41 AM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 12/2019

das ganze ist auch ein nicht ganz triviales thema. habe schon anfangs gehofft, dass das nicht zur sprache kommt,
aber bzgl der emulation von 2d-systemen wird das ganze eben noch komplizierter Wink

und sorry, manchmal verwende ich unmerklich redewendungen. ich meinte mit "praktisch" nicht "in etwas" oder "überm daumen", sondern definitiv.
dass das tearing visuell wirklich nicht auftaucht. es ist eben nur theoretisch vorhanden zwischen den frames, daher nicht sichtbar.
 
 
 
 View user's profile  
Reply with quote Back to top
krysmopompasOffline
Post subject:   PostPosted: Dec 13, 2011 - 11:51 AM
Retrogott


Joined: Jun 19, 2008
Posts: 2066



Highscores in 12/2019

Status: Offline
Sp00kyFox wrote:
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.

Ist letztendlich eine Frage der Definition, ich ging von zwei unterschiedlichen Arten des TB aus.
TB ist auch mit Lag bzw. Warten sinnvoll: Wenn einzelne Frames länger zur Berechnung brauchen bekommt man damit leichter eine konstante Framerate.

Quote:
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.

Ich habe schon an 3D Spiele gedacht. Es hängt vom Fall ab. Ist die GPU unterfordert und kann sehr hohe Frameraten produzieren fällt das Auslassen von Frames kaum oder gar nicht auf und verringert den Lag.
Schafft die GPU aber in etwa die Displayrefreshrate (oder einen Teiler davon) führt das Auslassen von Frames zu einem schwankenden Abstand der Frames (bzw. dem Zeitpunkt wann diese generiert wurden). Das führt imo zu einer "ruckeligen" Darstellung, ähnlich wie wenn z.B. auf einem 60Hz Display 40fps ohne Tearing dargestellt werden sollen.

Quote:
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

Aktuelle Systeme funktionieren so, aber das ist kein Muss. Alte Systeme hatten z.T. nur eine Zeile als Puffer.

_________________
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 13, 2011 - 05:08 PM
Retrokenner


Joined: Sep 10, 2010
Posts: 208



Highscores in 12/2019

krysmopompas wrote:

TB ist auch mit Lag bzw. Warten sinnvoll: Wenn einzelne Frames länger zur Berechnung brauchen bekommt man damit leichter eine konstante Framerate.

seh ich jetzt nicht, das gegenteil scheint mir der fall. wenn die gpu warten muss, hast du schlussendlich dieselbe problematik wie bei vsync mit db. bei performance-einbrücken gibts ruckartige framedrops, die abgefangen werden könnten durch ständiges wechseln der beiden backbuffer.

krysmopompas wrote:

Schafft die GPU aber in etwa die Displayrefreshrate (oder einen Teiler davon) führt das Auslassen von Frames zu einem schwankenden Abstand der Frames (bzw. dem Zeitpunkt wann diese generiert wurden). Das führt imo zu einer "ruckeligen" Darstellung, ähnlich wie wenn z.B. auf einem 60Hz Display 40fps ohne Tearing dargestellt werden sollen.

ja gut, falls die framerate stets knapp über der displayfreshrate liegt, ist das natürlich der worstcase für framedrops. muss man dann abwegen ob lieber tearing oder n stottern. allerdings scheint mir auch der fall üblicherweise bei 2d-spielen aufzutauchen, wo die framerate halt so vorgegeben ist. in der praxis wirst du bei 3d-spielen jedenfalls eine kontinuierliche framerate abhängig von der bildkomplexität haben. womit ziemlich unwahrscheinlich ist, dass die framerate stets im wahrnehmbaren worstcase-bereich liegt.

krysmopompas wrote:

Aktuelle Systeme funktionieren so, aber das ist kein Muss. Alte Systeme hatten z.T. nur eine Zeile als Puffer.

ich sprach im allgemeinen über computer-grafik. klar wenn wir noch weiter zurückgehen gabs sogar systeme, die den elektrodenstrahl zur bilddarstellung selbst gesteuert haben. da ist dann überhaupt kein bildbuffer vorhanden.
 
 
 
 View user's profile  
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.