Warum haben Emulatoren eine Eingabeverzögerung?

Dank der Eingabeverzögerung fühlt sich die Steuerung von Super Mario World auf dem Super Nintendo Emulator unter Recalbox nicht so an wie früher. Permanent springe ich zu spät ab und lande im Nichts.

Ist der Grund für das frühzeitige Game Over wirklich eine Verzögerung bei der Eingabe von Befehlen über das Joypad. Oder bin ich einfach alt geworden? 

Um herauszufinden, ob und wo wie groß die Latenz ist, habe ich die Zeit zwischen dem Drücken des Knopfes auf dem Controller bis zur Reaktion auf dem Bildschirm gemessen.

Wie wird die Eingabeverzögerung gemessen?

Ab dem Apple iPhones 7 kann man im Slow-Motion Aufnahmemodus bis zu 240 Bilder pro Sekunde aufnehmen. Ich habe gleichzeitig den Fernseher und den Druck auf den Joypad-Button gefilmt und die Bilder zwischen diesen beiden Ereignissen im Schnittprogramm gezählt. Beispielsweise habe ich 84 Frames beim SNES 9x Next Emulator gezählt. Das Joypad wurde seitlich gefilmt, damit ich sehen konnte, ob der Button schon gedrückt wurde oder nicht. Durch mehrere Durchläufe habe ich diese Ergebnisse verifiziert. BlueTooth und Wifi waren auf der Raspberry Pi nicht aktiviert bei den Tests.

Die Eingabeverzögerung in Millisekunden kann man ausrechnen, in dem wir die Variable F in der folgenden  Formel mit den gezählten Frames des iPhone Videos ersetzen:

(1000 milliseconds in a second ÷ 480 frames per second) × F
= (2.08333333333 × F) ms

Beispielrechnung
2.0833333333 × 84 frames =
~ 171 ms

Wieso durch 480 und nicht durch 240?

Wenn ich eine Sekunde einer Stoppuhr mit der Slow-Mo-Funktion vom iPhone filme, dann zeigt Final Cut Pro für genau diese Länge 480 Frames an. Eine Sekunde bzw. 1000ms in der Realität entsprechen also 480 Frames bei mir im Schnittprogramm. Die Frames sind einfach doppelt vorhanden.

Ich weiß nicht warum das so aber es ist so. Man kann also nicht einfach die 240 Frames pro Sekunde nehmen sondern eben die 480 Bilder pro Sekunde. Meine Vermutung ist, dass dies technisch bedingt ist.

 

Wie groß ist die Eingabeverzögerung in Millisekunden?

Die so ermittelten Werte habe ich verglichen mit denen von Sonic Mania auf der PS4 und dem Systemmenü von Recalbox. Das neue 2D-Jump&Run von SEGA hat die geringste mir bekannte Latenz auf der PS4. Das Menü der Recalbox kam mir immer sehr responsiv vor. Trotzdem wollte ich es genauer wissen.

Zusätzlich habe ich die Recalbox mit einem PlayStation 4 Joypad per USB-Kabel und mit dem Wireless Controller der XBOX 360 getestet und gegenübergestellt:

Kabelgebundenes Joypad Wireless Joypad Emulator oder System
~71 ms  n/a Original Super Nintendo
an CRT TV mit Super Mario World
~83 ms n/a PS4
Sonic Mania
~83 ms ~88 ms Recalbox Raspberry Pi 3
System Menu
~96 ms SNES Classic Mini
Super Mario World
n/a ~112 ms Wii U
Virtual Console und
Super Mario World
~152 ms n/a Recalbox Raspberry Pi 3
PocketSNES (Super Nintendo)
n/a ~160 ms Recalbox Raspberry Pi 3
picodrive (MegaDrive)
n/a ~171 ms Recalbox Raspberry Pi 3
Snes9x next (Super Nintendo)

 

Die Zahlen zeigen, dass der Raspberry Pi 3 mit Recalbox bei der Emulation eine deutliche Eingabeverzögerung von einer sechstel Sekunde hat. Dies ist gegenüber der PlayStation 4 und dem Menü der Recalbox mehr als doppelt so hoch.

Dazu kommen noch Unterschiede bei den emulierten Systemen picodrive (MegaDrive) und Snes9x next (Super Nintendo). Der SNES Emulator ist bis zu 11 ms langsamer als die Emulation des MegaDrive. Zu guter Letzt zeigt sich auch die Latenz des kabellosen XBOX 360 Gamepads mit Original MS Wireless Adapter in Form von bis zu 5 ms.

Das echte Super Nintendo an einem Röhrenmonitor hat, wie erwartet, das geringste Lag mit 71 ms. Das Super Nintendo Mini hat dabei „nur“ fast 100 ms Verzögerung bei den Eingaben vom Joypad gezeigt.

Grafische Auswertung der  Eingabeverzögerung von Emulatoren

Vergleich des Input Lag von Recalbox auf einem Raspberry Pi
Vergleich des Input Lag von Recalbox auf einem Raspberry Pi. Geringere Werte sind besser.

Woher kommt die Eingabeverzögerung?

Mein Fernseher, der Samsung KS7090, hat bei 1080p mit 60hz eine Verzögerung von 21 ms bis das Bild über HDMI im Game Mode angezeigt wird. Woher kommt aber das restliche Lag?

Meine Vermutung ist, dass es ein Mix aus der Emulation und der geringen Leistung des Raspberry Pi 3 ist. Der SNES Emulator Pocketsnes lässt einige Effekte (Mode7) weg aber soll eine geringere Eingabeverzögerung haben.  Bei meinen Tests war der Unterschied unter 22ms zwischen den beiden.

Ein schneller PC könnte hier bessere Ergebnisse erzielen. Vermutlich wäre ein SNES Classic Mini oder eine gehackte Wii (U) in dieser Hinsicht besser aufgestellt, weil die Emulatoren direkt vom Hersteller kommen.

Haben kabellose Controller ein Lag?

Ja, haben sie. Es ist zwar mit bis zu 5 ms sehr gering aber es ist vorhanden. Laut Tests auf Youtube sind übrigens besonders Controller von 8Bitdo von Lag geplagt. Selbst nach einem Firmware-Update.

Der original PS4 Controller hat den Vorteil, dass man ihn mit einem langen Micro USB-Kabel ohne Lag betreiben kann. Ich persönlich nutze die kabellosen XBOX 360 Controller mit dem original XBOX 360 Wireless Adapter für Windows. Der funktioniert natürlich auch direkt am Raspberry Pi. Zudem sind die Controller von Microsoft und Sony nicht mal teurer als der Chinaschrott von 8Bitdo.

Wenn ihr schon gedrückt habt und Sonic macht das hier, dann habt ihr ein extremes Lag-Problem

Danksagungen

Danke an Philipp, Christian und Mo für die tatkräftige Hilfe beim Ausrechnen der Beobachtungen. Einen noch größeren Dank an Ingo für das beharrliche Hinterfragen und das Bereitstellen des echtes Super Nintendos mit CRT Monitor.

Was kann man gegen die Eingabeverzögerung machen?

Selbst das Einschalten des Game Mode am TV und die Verwendung von Controllern mit Kabeln hat wenig genutzt.   Es liegt in diesem Fall an der Hard- und Software. Da das Menü aber genau so schnell reagiert wie die PS4 unter optimalen Bedingungen, liegt das Problem definitiv in der Emulation und nicht an der Ein- bzw. Ausgabehardware wie Joypads oder TV.

Am Ende wird die Eingabeverzögerung von einer sechstel Sekunde vielen Person nicht auffallen. Viele Menschen sind sehr glücklich damit und werden das nie bemerken. Nur wer früher wirklich viel auf original Hardware gespielt hat wird merken, dass es sich nicht so anfühlt wie damals. Oder man gewöhnt sich eben dran. Mir wird leider diese erlernte Feinmotorik mit dem falschen Timing zum Verhängnis. Es dauert einfach sehr lange, bis ich mich wieder entsprechend „kalibriert“ habe.

Messaufbau mit echtem Super Nintendo und Röhrenmonitor.

 

Emulatoren auf dem Raspberry Pi hat eine spürbare Latenz

An meinem Fernseher haben folgende Geräte absteigend die geringste Latenz, wenn ich Super Mario World spielen möchte:

  1. SNES Classic Mini
  2. Wii U Virtual Console
  3. Recalbox (PocketSNES)
  4. Recalbox (Snes9x Next)

Die Recalbox baut man sich mit einem Raspberry Pi nach dieser Anleitung zusammen. Das SNES Classic Mini kann man hier günstig bestellen.

40 Antworten auf „Warum haben Emulatoren eine Eingabeverzögerung?“

  1. Schöner Artikel, sehr interessant!
    Hätte nicht gedacht, dass der Game Mode im Monitor mehr ausmacht als ein Wireless Controller.

    Hast du RecalBox auf Standard gelassen oder übertaktet oder/und force_turbo=1 sowie avoid_warnings=2 in der config.txt eingetragen? Pi 3 immer konstant auf z. B. 1300 MHz laufen zu lassen spart Zeit, da keine CPU cycles verloren gehen durch das dynamische hoch- und runter Takten der CPU.
    LibreELEC ist damit z. B. wesentlich flotter im Menü als ohne force_turbo=1.

    Ein RTOS-Kernel wäre natürlich auch fein. Damit lässt sich die allgemeine Latenz im Rechner auch verringern. 1700 vs. 83 us sind nicht viel, aber es summiert sich ja alles, jeder Prozess der läuft. Man muss es nicht übertreiben, aber vielleicht ist die Latenz im Emu ja dadurch auch wesentlich höher als 1,7 ms. Wäre einen Versuch wert.

    1. Noch eine Option, force USB 1 über die cmdline.txt und noch andere Tricks, um den Rechner möglichst flott zu machen. Den CPU scaling governer braucht man im turbo mode natürlich nicht mehr auf performance zu ändern. Den RecalBox Manager, sowie möglichst viele unnötige Services (was (h)top, ps so anzeigt) kann man noch deaktivieren. Je weniger läuft desto flotter ist alles.

      Zu guter letzt fällt mir noch ein, dass jeder Emu mehrere Emu Cores hat, die man nutzen kann. Findet man bei den scrape Einstellungen zu jeder ROM einzeln. Manche ROMs laufen mit manchen Cores total lahm, manche deutlich schneller. SNES 9x vs. 9x next vs. catsfc z. B. Doom und StarFox 1+2 brauchen sehr viel Ressourcen. Da merkt man die unterschiedlichen Emu Cores.

      Achso und dann gibt es noch Batocera Linux, ein Fork von RecalBox. Man könnte mal kurz antesten, ob da was anders ist.

  2. Achso bitte mal Retro Shader, Glättung und Rewind aus machen in Emulationstation. Das verbraucht auch unnütz Ressourcen, auch wenn es schöner aussieht und praktisch ist. Lieber maximale Performance und mehr Reserven als irgendwelche Hänger.

    Auflösung runter schrauben bringt sicherlich auch Einiges.
    Also bei N64 max. 640×480 statt FullHD. So wie das Bild ruckelt, wird der input lag auch steigen. Die Frage ist, ob der Monitor dann nicht beim Strecken auf Vollbild viel Verzögerung macht. Der Pi dürfte jedoch flotter sein, wenn er weniger rechnen muss.
    Übrigens, über 3,5 mm analog Video out ist der Pi deutlich langsamer als über HDMI out.
    Ob PAL vs. NTSC ROMs was ausmachen? 50 vs. 60 Hz. Bei PAL hätte der Pi weniger zu rechnen. Vielleicht Kleinigkeiten, aber nicht immer trivial. Man weiß nicht wie HDMI out und Monitor sich da jeweils verhalten.

    In Kodi gibt’s übrigens ne Einstellung Bildwiederholfrequenz an der Monitor anpassen. Das verhindert bei Filmen Ruckler und doppelte Bilder. Wenn der Pi da 24 oder 50 Hz auf 60 Hz hoch rechnet, wird er merklich langsamer, als wenn er es nativ anzeigt und der Monitor umschaltet.

    1. Hi, die Tests habe ich natürlich ohne Shader, mit unterschiedlichen Cores (siehe Tabelle) und per HDMI gemacht. Das ROM war ein US Rom weil ich nicht noch weniger Bilder pro Sekunde haben will.
      Die Auflösung wurde von Recalbox schon passend für die Emulatoren gewählt. Der Pi war bis zur Grenze übertaktet und Luftgekühlt, damit er nicht runtertaktet.

      Mehr ging nicht. Das Lag bekommt man nicht weg.

    2. Ab RetroArch Version 1.7.2 gibt es ein sehr interessantes Feature, um den Input Lag zu verringern.
      Nennt sich „Run-Ahead“.
      In der aktuellsten Beta (Version 5.16) von batocera.linux (ein Fork von Recalbox) ist RetroArch 1.7.3 integriert und somit auch dieses neue Feature.

      Diese Version (5.16 für den Pi3) funktioniert im Gegensatz zur derzeit aktuellsten Recalbox-Version (18.04.20) auch mit dem neuen Pi3+.

      Es gibt von der 5.16 auch eine Version für den PC (x86_64):

      @Marc
      Hast du es schon ausprobiert? Wann gibt es dazu einen Blog-Eintrag von dir? ;-)

    3. Ich kenne batocera. Es war mal ein Blogeintrag geplant, in dem ich beide Distributionen vergleiche. Das ist nämlich von einem der ehemaligen Entwickler von Recalbox. Allerdings sind die Unterschiede recht minimal. Der Typ ist einfach schneller mit Features aus Retroarch .Dafür ist meiner Ansicht nach das Frontend schlechter. Batocera hatte ich bei den Odroid Artikeln genutzt.

      Wenn Recalbox das drin hat mache ich ggf. ein Update. Ich hatte aber gelesen, dass run-ahead mehr Leistung braucht. Die haben wir auf einem Pi (selber einem 3b+) nicht. Mal sehen, wie dann die Performance in SNES Spielen ist, die etwas mehr Power brauchen.

    4. Also als minimal würde ich die Unterschiede zwischen batocera und Recalbox nicht bezeichnen.
      Ich finde batocera inzwischen um einiges besser als Recalbox.
      2 Dinge sind mir beim Vergleich besonders aufgefallen:

      – batocera enthält im Gegensatz zu Recalbox eine wesentlich aktuellere Kodi-Version (Kodi 17.6 statt Kodi 16)
      – bei batocera gibt es im Gegensatz zu Recalbox keine Probleme mit PS3-Controllern was die Steuerung von Gamecube/Dreamcast/Kodi angeht (siehe hier: )

      Gibt mit Sicherheit noch ne Menge weiterer Unterschiede.

      Warum findest du das Frontend bei batocera schlechter? Bis zur derzeit aktuellen Recalbox-Version waren die Frontends doch identisch oder nicht?

      Der Pi3 ist übrigens performant genug um die Run-Ahead Funktion in SNES Spielen zu nutzen… man muss vorher nur den entsprechenden Libretro Core ändern ;-)
      Siehe hier:

    5. Da steht:

      I tested this feature with Super Mario World on SNES, but unfortunately the Pi3 seems to be not powerfull enough. The Game slows down a bit, with Run-Ahead enabled and Number of Frames to Run Ahead 1 or 2.
      Even overclocking the Pi3 to 1300MHz did not improve the performance.
      Maybe the Pi3+ is better.

      Und der Pi3B+ ist nun leider auch nicht soooo viel schneller. Selbst PCs straucheln damit. Ich teste das gerne offiziell, wenn es in Recalbox drin ist. Wenn die das wegen der Performance überhaupt reinnehmen. Der Lead-Entwickler von Recalbox hatte auf meinen Artikel hin im Forum dort ja auch geschrieben:

      We both know it will never reach the latency of a modern computer or a dedicated box. But it can be slightly improved, maybe to a point where you can feel „more comfortable“ when playing, without ever reaching what a PC can do.

    6. Da steht aber auch weiter unten:

      Edit: Just did a bit more testing on my Pi3 with different SNES Emulator-Cores and when you change the Core to CATSFC or POCKETSNES, you get fullspeed with „Runahead latency reduction“ (but you also have to activate the option „Runahead Use Second Instance“, otherwise you will get sound problems.).
      With SNES9X_NEXT it is almost fullspeed.
      Only with SNEX9X it is slow.

      Probier die 5.16 von batocera doch einfach mal mit deinem Pi3 aus ;)
      Das Image ist doch schnell mit etcher auf eine microSD geklatscht ^^

      Mich würde echt mal interessieren, was dann dabei rauskommt, wenn du den gleichen Test damit machst, wie in diesem Blogeintrag hier :-)

    7. With SNES9X_NEXT it is almost fullspeed.

      Hat man Bock auf einen ruckeligen SNES Emulator? Ein Grund, warum ich Henkaku für sinnlos halte.

      Wie gesagt, wenn Recalbox entscheidet, dass es reinkommt gerne.

    8. Ich hatte das nur ganz kurz getestet und es war mein subjektiver Eindruck. Vielleicht hilft es ja schon den Pi3(+) ein wenig zu übertakten, um mit aktiviertem Run-Ahead Super Mario World mit SNES9X_NEXT als Core flüssig zocken zu können.
      Ich werde es jetzt am Wochenende nochmal mit verschiedenen Einstellungen + Übertakten ausprobieren, ob ich es nicht auch mit SNES9X_NEXT auf meinem Pi3 in fullspeed zum Laufen bekomme.

      Verstehe nicht, wieso du so auf Recalbox beharrst? Meiner Meinung nach ist batocera um einiges besser.

      Alternativ zum Pi3(+) kannst du batocera 5.16 ja auch mal mit nem PC ausprobieren.

      Irgendwie habe ich aber das Gefühl, dass du eine Abneigung gegenüber batocera hast :-/

    9. batocera hat nicht das Browserinterface und nicht das Skinsystem mit den schönen zusammengesetzten Bildern, die man beim Scrapen bekommt.

      Wie gesagt, zu der Zeit des ODroids hatte ich auf dem Pi und dem odroid Batocera am laufen. Sie sind sich sehr ähnlich. der Unterschied, ist dass der Batocera-Typ sehr schnell Änderungen bei den Emulatoren übernimmt – aber dafür selber nicht testet und gefühlt auch nicht selber spielt. Recalbox ist ingesamt optimierter wenn man wirklich spielen will.

      Beispiel war der N64 Emu der unter Batocera auf 1080p läuft. Das ist viel (!) zu hoch für den Pi. Besser sind die 640×480 von Recalbox.

      Deswegen nutze ich Batocera nicht. Auf dem RPi3B+ läuft bei mir gerade auch was anderes. ;-)

    10. Das Browserinterface finde ich zwar ebenfalls ganz nett, aber kann darauf auch verzichten.
      Was genau meinst du mit „Skinsystem mit den schönen zusammengesetzten Bildern, die man beim Scrapen bekommt“? Meinst du Screenscraper? Das funktioniert schon seit einiger Zeit wieder (ein Fehler wurde gefixt).

      „Recalbox ist insgesamt optimierter wenn man wirklich spielen will“
      Das sehe ich nicht so… im Gegenteil! Batocera hat zum Beispiel keine Probleme mit PS3-Controllern per Bluetooth. Bei Recalbox funktioniert entweder die Steuerung bei Kodi und Gamecube nicht, oder es gibt den Bug bei Dreamcast-Spielen, dass wenn man den Analog-Stick komplett nach links oder oben macht, dass im Spiel dann nach rechts bzw. unten gesteuert wird.
      Alles andere, was ich bisher verglichen habe, war zwischen Recalbox und batocera mehr oder weniger gleich.
      Also ich sehe absolut keinen Vorteil von Recalbox gegenüber batocera (ausser dem Browserinterface, auf das man aber meiner Meinung nach verzichten kann und dem neuen Theme, welches ich aber auch nicht so besonders toll finde, dass man es unbedingt haben müsste).

      „Beispiel war der N64 Emu der unter Batocera auf 1080p läuft.“
      Stimmt auch nicht! Habe es gerade auf meinem Pi3 ausprobiert und N64 läuft in 640×480 und nicht in 1080p. (Mag sein, dass bei einer älteren Version von batocera der N64 Emu default-mässig mal auf 1080p Auflösung eingestellt war, bei der 5.16 läuft N64 per default auf jeden Fall in 640×480).

      Also ich finde, du solltest der aktuellen batocera 5.16 mal eine Chance geben.
      Wie gesagt ist das Image ja schnell auf eine microSD aufgespielt. Und microSD-Karten bekommen man doch hinterhergeschmissen (9-10€ für 32GB).

    11. Ich habe es mal auf eine leere Karte gepackt. Wo soll diese Einstellung „Runahead latency reduction“ denn bitte sein? Im RetroArch Menü? Unter Settings und Options finde ich nichts.

  3. Kommt bei SNES auf die ROM drauf an. Doom, Starfox 1+2 laufen weitaus ruckeliger als andere ROMs. Das sind allerdings einige der wenigen, die extreme Ressourcen brauchen, bei Emulation und auch auf originaler Hardware. Ein Raspi 2 ist mit den 3 ROMs hoffnungslos überlastet, da ruckelt der Sound und die fps brechen ein.

    Batocera nutze ich an 2-3 PCs zum Test, RecalBox am Raspi 2 übertaktet auf 1050 MHz.
    Leider unterstützt Batocera noch nicht die sparsame Nvidia GT 1030 (ruckelt extrem schon im Menü, derselbe PC mit ner HD 4550 lief damit ruckelfrei), ist aber auf der langen todo-Liste nebst PCSX2, usw. Da wird noch einiges Interessantes kommen.
    Run ahead klingt gut, aber wenn es CPU frisst…muss man testen, auch bei jedem System einzeln. Am PC oder Odroid XU4 sicher kein Problem, am Raspi könnte es dadurch auch wieder ruckeln.
    Interessanter fände ich RTOS-Kernel… Da müsste man die Entwickler von RetroArch, Emulationstation, RecalBox, Batocera, RetroPie, Lakka mal fragen wie man das umsetzen kann. Und wenn es nur 2 ms lag verringert, der Sound läuft damit auch flüssiger.

    Batocera ist schon recht fortschrittlich, hat aber aus Gründen von Compilation Zeit den Web Manager raus geschmissen. Mir egal, über SMB lässt sich auch kopieren. Beim Skin ist eigentlich alles gleich geblieben. Eines von beiden hatte da eine neue Version drin, die vertikal scrollt und musste etwas fummeln, um die alte einzustellen, war nicht ganz fehlerfrei. Geht aber nach wie vor mit Scrape Bildern. Attract mode nutze ich nicht.
    Die beiden sind noch relativ identisch, driften aber immer mehr auseinander. Batocera ist halt mehr testing, nutzt neuere Cores und endlich ein aktuelles Kodi stable. RecalBox hat z. B. andere neue Emus drin als Batocera und umgekehrt. Mitunter hat RecalBox dann Funktionen, die Batocera nicht hat. Da sei nur mal X68000, Amiga und Intellivision zu nennen.
    X68000 kommt wohl auch endlich in Batocera 5.16…die sind da echt fix. Akumajō Dracula X68000, R-Type X68000, yeah. Bei multi Disk ROMs muss man ne m3u anlegen, klappt aber super.

    Eine interessante Alternative zum Raspi und Odroid XU4 ist ein Pentium J5005, extrem sparsam, aber wesentlich schneller. Von Asrock passiv gekühlt oder Intel Nuc aktiv gekühlt.
    Dolphin und PCSX2 sind da allerdings auch etwas lahm logischerweise.

    1. Habe es jetzt meinem Pi3 nochmal kurz getestet und wenn ich ihn auf 1.300MHz übertakte (Standardtakt 1.200MHz) und zusätzlich beim Libretro Core SNES9X_NEXT die Rewind-Funktion (Zurückspulen) deaktiviere, läuft Super Mario World mit aktiviertem Run-Ahead (Number of Frames to Run Ahead = 2 + Runahead Use Second Instance = ON) flüssig.

      @Marc
      Du findest die Run-Ahead Funktion im RetroArch Quick-Menu (Hotkey + B) unter „Latency“

      Ich nutze für batocera nen alten NUC (mit i5-3427u), den ich relativ günstig bei ebay geschossen hatte (mit 4GB RAM und 30GB SSD für 130€). Damit laufen Dreamcast und Gamecube Spiele flüssig.
      Hatte unterschiedliche CPU/GPU-Kombinationen mit batocera getestet und mein Ergebnis hier gepostet:

    1. Batocera und RecalBox haben laut Web Alert App Updates erhalten, seit heute erhältlich.
      Erstaunlich, trotz Sommer und Fußball.

      Der Absturz des alten ES Menüs wurde behoben, RetroArch hat ein Update bekommen, Emus für Laserdisc und X68000 sind erhältlich, WLAN/BT läuft besser.
      Wenn Laserdisc images nur nicht so riesig wären…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website zeigt Benutzerbilder über gravatar.com an.

Wie bekomme ich einen verifizierten Account? - Login