4. SFML schnelle alternative

SFML schnelle alternative

  • M

    Wollte mal wissen ob ihr gute Alternativen zur SFML kennt. Es soll einfach nur schneller sein da die SFML bei mir so unglaublich langsam ist. Teilweise wenn ich nur ein einfaches Fenster erzeuge, taktet mein 8-Kerner schon hoch und der Grafikkartenlüfter läuft auf Volldampf. Also kennt dazu wer eine Alternative oder einen Weg die SFML schneller zu machen?

    0

  • MrBambi schrieb:

    Es soll einfach nur schneller sein da die SFML bei mir so unglaublich langsam ist.

    Es ist das genaue Gegenteil davon - SFML rendert so schnell die Grafikkarte kann 😉

    Wahrscheinlich läßt du SFML ohne Framerate Limit laufen. Benutze einfach sf::Window::setFramerateLimit, wenn du es langsamer haben wilst 😉

    0
  • ?

    MrBambi schrieb:

    Wollte mal wissen ob ihr gute Alternativen zur SFML kennt. Es soll einfach nur schneller sein da die SFML bei mir so unglaublich langsam ist. Teilweise wenn ich nur ein einfaches Fenster erzeuge, taktet mein 8-Kerner schon hoch und der Grafikkartenlüfter läuft auf Volldampf. Also kennt dazu wer eine Alternative oder einen Weg die SFML schneller zu machen?

    Das was Th69 schreibt stimmt, sofern du nichts anderes einstellst wird dein Programm so schnell bearbeitet wie nur möglich.Wenn nichts anderes im Hintergrund läuft geht eben die gesamte Rechnerleistung für deine Anwendung drauf.
    Daher ist das, was du beschreibst, nicht die Schuld von SFML sondern deine eigene 😛

    0
  • M

    Achso. Nun das wusste ich nicht. Ich hab nämlich schon öfters gelesen das Frame-limits eher schlecht sind. Aber wenn das so ist dann danke für die Antworten.

    0

  • Habe gerade gelesen, daß SMFL auch direkt setVerticalSyncEnabled unterstützt (so daß du also nicht selber den optimalen Wert herausfinden mußt).

    0
  • S

    MrBambi schrieb:

    Achso. Nun das wusste ich nicht. Ich hab nämlich schon öfters gelesen das Frame-limits eher schlecht sind. Aber wenn das so ist dann danke für die Antworten.

    Frame Limits sind dann schlecht, wenn man die Geschwindigkeit des Spieles daran fest macht. Das ist absolut daneben.

    Aber wenn man alles so schnell rendert wie was die Graka hergibt, dann ist das genauso schlecht, weil man Strom verschwendet.

    Die Lösung ist VSYNC: Damit wird alles nur so schnell gerendert wie es der Bildschirm auch darstellen kann.

    Code dazu:

    window.SetFramerateLimit(0);
window.UseVerticalSync(true);
    0
  • R
    Mod

    Scorcher24 schrieb:

    MrBambi schrieb:

    Achso. Nun das wusste ich nicht. Ich hab nämlich schon öfters gelesen das Frame-limits eher schlecht sind. Aber wenn das so ist dann danke für die Antworten.

    Frame Limits sind dann schlecht, wenn man die Geschwindigkeit des Spieles daran fest macht. Das ist absolut daneben.

    auf PCs: ja
    auf festen platformen ist es gaengier und wenn man es richtig macht, spricht nichts dagegen.

    Aber wenn man alles so schnell rendert wie was die Graka hergibt, dann ist das genauso schlecht, weil man Strom verschwendet.

    Die Lösung ist VSYNC: Damit wird alles nur so schnell gerendert wie es der Bildschirm auch darstellen kann.

    esseiden das groeste ziel ist latenz minimierung. dann koennte man es mit tripplebuffering moeglicherweise besser hinbekommen.

    0

  • rapso schrieb:

    esseiden das groeste ziel ist latenz minimierung. dann koennte man es mit tripplebuffering moeglicherweise besser hinbekommen.

    Ist Triple-Buffering bei z.B. D3D oder OGL so umgesetzt, dass man damit die Latenz minimieren kann?
    Bei Triple-Buffering hat man ja im Prinzip die drei Puffer "current", "next" und "render".

    Und wenn ein "render" Frame fertig wird, dann kann man entweder
    a) so lange warten bis "current" fertig ausgegeben wurde, und dann
    current = next
    next = render
    render = anfangen neues Frame reinzurendern
    oder
    b) sofort
    next = render
    render = anfangen neues Frame reinzurendern

    Bisher dachte ich immer dass bei Triple-Buffering (a) verwendet wird. Was natürlich ganz schlecht für die Latenz wäre.
    Wenn ich jetzt darüber nachdenke hat (a) aber kaum genug Vorteile gegenüber (b) als dass es Sinn machen würde. Ausser halt dass bei (a) die Grafikkarte nicht immer auf Vollgas läuft...

    ps: Naja, doch... (a) führt vermutlich auch zu weniger Jitter in den zeitlichen Frame-Abständen - also zu "flüssigeren" Animationen. Speziell wenn man "nur" zwischen 1.0 und 2.0 mal so viel Frames rendern kann wie auch angezeigt werden, würde bei (b) vermutlich ein wilder Jitter rauskommen. Hmmmm.

    rapso schrieb:

    auf PCs: ja
    auf festen platformen ist es gaengier und wenn man es richtig macht, spricht nichts dagegen.

    Vermutlich ganz blöde Frage, aber da ich es nicht sicher weiss: ist es bei "aktuellen" Konsolen (Xbox 360 oder später) "OK" z.B. fix 60 FPS zu verwenden?
    Früher gab es ja immer das Problem PAL vs. NTSC - aber mittlerweile sollten ja vermutlich alle TVs 60 FPS können, egal wo sie verkauft werden.
    Und: weisst du ob es eine De-Factor Standard Framerate bei Smartphones gibt - und wenn ja, welche das ist (auch 60 FPS?)?

    0
  • S

    Schon auf der 360 verwenden die Devs fixe Frameraten für Physik als Beispiel. LA Noire ist hier ein negatives Beispiel. Weil wenn du auf dem PC das FPS Limit aufhebst, dann ist Autofahren eher Glücksspiel. Daher halte ich das nach wie vor für doof. Macht Ports nur aufwändiger.

    http://gafferongames.com/game-physics/fix-your-timestep/

    0

  • @Scorcher24
    Es geht hier um Grafik-Frames.

    0
  • R
    Mod

    hustbaer schrieb:

    Und wenn ein "render" Frame fertig wird, dann kann man entweder
    a) so lange warten bis "current" fertig ausgegeben wurde, und dann
    current = next
    next = render
    render = anfangen neues Frame reinzurendern

    welchen sinn wuerde dann tripplebuffering machen?

    b) sofort
    next = render
    render = anfangen neues Frame reinzurendern

    es gibt immer ein bild was angezeigt wird und eines in das reingerendert wird und 'shared' dazwischen einen buffer mit dem beide flippen koennen.wenn as rendering 90hz schafft und der monitor 60hz, swapt das rendering bei jedem zweiten monitor-frame zweimal mit dem temp buffer.

    Wenn ich jetzt darüber nachdenke hat (a) aber kaum genug Vorteile gegenüber (b) als dass es Sinn machen würde. Ausser halt dass bei (a) die Grafikkarte nicht immer auf Vollgas läuft...

    in dem fall reicht double buffering, oder gibt es einen vorteil fuer 3 buffern gegenueber 2?

    ps: Naja, doch... (a) führt vermutlich auch zu weniger Jitter in den zeitlichen Frame-Abständen - also zu "flüssigeren" Animationen. Speziell wenn man "nur" zwischen 1.0 und 2.0 mal so viel Frames rendern kann wie auch angezeigt werden, würde bei (b) vermutlich ein wilder Jitter rauskommen. Hmmmm.

    rapso schrieb:

    auf PCs: ja
    auf festen platformen ist es gaengier und wenn man es richtig macht, spricht nichts dagegen.

    Vermutlich ganz blöde Frage, aber da ich es nicht sicher weiss: ist es bei "aktuellen" Konsolen (Xbox 360 oder später) "OK" z.B. fix 60 FPS zu verwenden?
    Früher gab es ja immer das Problem PAL vs. NTSC - aber mittlerweile sollten ja vermutlich alle TVs 60 FPS können, egal wo sie verkauft werden.
    Und: weisst du ob es eine De-Factor Standard Framerate bei Smartphones gibt - und wenn ja, welche das ist (auch 60 FPS?)?

    ich glaube ps3 kann noch auf pal ausgeben, mit hdmi sollten 60hz aber immer gegeben sein.
    bisher hatten alle phones die ich in der hand hatte 60hz (bzw 59.94), aber ich weiss nicht ob das zufall ist oder ein standard, ich wuerde vermuten dass es einfacher ist auf gaengige komponenten zurueckzugreifen (ein 1080p display driver duerfte nicht viel anders zwischen TV und phone sein, aber verlass dich nicht auf meine aussage).

    0

  • rapso schrieb:

    hustbaer schrieb:

    Und wenn ein "render" Frame fertig wird, dann kann man entweder
    a) so lange warten bis "current" fertig ausgegeben wurde, und dann
    current = next
    next = render
    render = anfangen neues Frame reinzurendern

    welchen sinn wuerde dann tripplebuffering machen?

    frameraten zwischen 30 und 60 Hz ohne tearing möglich machen~~, ohne dass die GPU dabei immer auf 100% läuft~~.

    EDIT: ohne dass die GPU auf 100% hochgeht wenn das Rendern mal schneller geht als die Bildausgabe. So lange das Rendern länger dauert als die Bildausgabe ist die GPU dabei natürlich immer auf 100%, was ja auch so sein soll.

    0

  • ps:
    DirectX macht genau das was ich ursprünglich vermutet hatte, also Variante (a):
    http://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering

    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.[1] This is the case when using triple buffering in DirectX, where a chain of 3 buffers are rendered and always displayed.

    Hier nochmal beschrieben (Absatz "UPDATE"):
    http://www.anandtech.com/show/2794/4

    0
Anmelden zum Antworten