Logging Library für (c ++) Spiele [geschlossen]

Ich kenne viele Protokollbibliotheken, habe aber nicht viele getestet. (GoogleLog, Pantheios, die kommende boost :: log Bibliothek ...)

In Spielen, insbesondere in Remote-Multiplayer- und Multithread-Spielen, ist die Protokollierung für das Debuggen von entscheidender Bedeutung, auch wenn Sie am Ende alle Protokolle entfernen.

Nehmen wir an, ich mache ein PC-Spiel (keine Konsole), das Protokolle benötigt (Multiplayer und Multithreading und / oder Multiprozess), und ich habe gute Gründe, nach einer Bibliothek für die Protokollierung zu suchen (zum Beispiel, ich habe keine Zeit oder ich habe keine Zeit) Ich bin nicht sicher, ob ich in der Lage bin, einen für meinen Fall richtig zu schreiben.

Vorausgesetzt, ich brauche:

1. Performance
2. einfache Bedienung (Streaming oder Formatierung oder ähnliches zulassen)
3. zuverlässig (nicht auslaufen oder abstürzen!)
4. plattformübergreifend (mindestens Windows, MacOSX, Linux / Ubuntu)

Welche Protokollbibliothek würden Sie empfehlen?

Momentan denke ich, dass boost :: log das flexibelste ist (Sie können sich sogar aus der Ferne anmelden!), Aber keine gute Leistungsaktualisierung haben : ist für hohe Leistung, ist aber noch nicht veröffentlicht. Pantheios wird oft zitiert, aber ich habe keine Vergleichspunkte zu Leistung und Nutzung. Ich habe meine eigene Bibliothek lange Zeit benutzt, aber ich weiß, dass sie kein Multithreading beherrscht, so dass es ein großes Problem ist, auch wenn es schnell genug ist. Google Log scheint interessant zu sein. Ich muss es nur testen. Wenn Sie diese und weitere Bibliotheken bereits verglichen haben, ist Ihr Rat möglicherweise hilfreich.

Spiele sind oftmals leistungsintensiv und komplex zu debuggen. Daher ist es gut, Protokollbibliotheken zu kennen, die in unserem speziellen Fall klare Vorteile bieten.

log using socket (jeder Socket-Wrapper kann ausreichen) + Webbrowser websocket => Das vielseitigste, unauffälligste Protokollierungswerkzeug, das möglich ist, wird stundenlanges Debuggen kosten und Augenschmerzen vermeiden.

• asynchron (Geschwindigkeit, da der gesamte Auftrag im Browser verzögert wird)
• formatiert (Farbe, Größe etc ..)
• zuverlässig (Steckdosen ...)
• plattformübergreifend (Browser)

Nun der Bonus:

• Dynamische Filterung sehr einfach (bei Bedarf mit Javascript Regex)
• mit Protokollverlauf, Speicher und Vergleich (HTML5-Spezifikation in der "In-Browser" -Datenbank)
• Einfache Möglichkeit, Diagramme von Daten (mit SVG, Canvas oder Ähnlichem) wie Speicher , Speicherfragmentierung usw. zu erstellen.
• einfache Möglichkeit, ein 2D-Diagramm von Daten zu erstellen ( kd-Baum-Unterteilung, potenzielles Feld oder auch nur eine variable Wertvariation, usw.)
• Ermöglicht Fernprotokollierung (mit dem Browser eines anderen Computers)
• Mit HTML5 im Browser-Speicher können Sie Protokollsitzungsparameter (aktuelle Protokollfilter usw. und sogar Notizen zu jedem) speichern.
• Es ist sehr einfach, einen Fehlerbericht zu erstellen oder Trac-Tickets mit einem Klick zu verknüpfen
• Möglichkeit zum einfachen Zurückspulen der Protokollierung mit einer Zeitleisten-Benutzeroberfläche

und viele weitere Aufgaben außerhalb der Protokollierung:

• Ermöglicht Profiler-Informationen (Grafiken ...)
• kann sogar als Konsole dienen (Befehl vom Browser senden) oder sogar mit einer schnellen Benutzeroberfläche unter Verwendung von HTML oder sogar Flash-Benutzeroberfläche
• Bildunterschied im Browser (Bild mit Socket senden und im Browser mit Canvas-Bildpixelfunktionen vergleichen)
• etc...

(Fast alle der oben genannten Vorgänge können über Flash-Sockets ausgeführt werden. Speichern Sie die Datenbankfunktionen.)

Jetzt weiß ich, dass es ein bisschen lang ist, das Ding einzurichten. Aber es ist wirklich ein Zeitgewinn bei langen Projekten mit schwierigen Debugsituationen (wie in Spielen). Es ist das mächtigste, was ich seit Debuggern verwendet habe ...

Hinweis 1: Der einzige Nachteil => Überprüfen Sie den Nebeneffekt beim Debuggen des Netzwerkcodes (Auswirkungen auf die Größe des Socket-Puffers, die Latenz, die Bandbreite usw.).

Hinweis 2: Einige Browser sind aus Sicherheitsgründen standardmäßig deaktiviert. Überprüfen Sie Folgendes: config, um sicherzustellen, dass sie aktiviert sind.

Wenn es um Leistung geht, habe ich festgestellt, dass Templog so gut wie ungeschlagen ist. Mithilfe von Ausdrucksvorlagen wird die Auswertung von Protokollanweisungen verschoben, bis festgestellt wird, dass die Informationen überhaupt protokolliert werden. Da Sie die Protokollierung auch teilweise deaktivieren können (abhängig vom Schweregrad, Ursprung und der Zielgruppe einer Protokollnachricht), können einige dieser Protokollierungsanweisungen vom Compiler für Release-Builds auf Null gesetzt werden. (Ich habe tatsächlich gesehen, dass dies mit VC passiert.)

In letzter Zeit wurde der Bibliothek nicht viel getan, und anderen auf SO hat der Kofferraum in mancher Hinsicht gefehlt, aber in einer Firma, für die ich gearbeitet habe, haben wir festgestellt, dass der Typ ziemlich reaktionsschnell und einer meiner damaligen Kuharbeiter sogar Erhielt Commit-Zugriff und fügte Code hinzu, sodass es sich möglicherweise lohnt, einen Versuch zu unternehmen.

So führen Sie Ihre Anforderungen auf:

Performance

Das Beste, was ich gefunden habe. Besonders die Möglichkeit, Protokollnachrichten zur Kompilierungszeit auszuschließen und diese vom Compiler vollständig entfernen zu lassen, war sehr ansprechend.

einfache Bedienung (Streaming oder Formatierung oder ähnliches zulassen)

Es gibt die klassischen schrecklichen Compilerfehlermeldungen von Vorlagen-Meta-Dingen, wenn Sie etwas falsch machen, aber wenn es um Benutzerfreundlichkeit geht, ist dies

TEMPLOG_LOG(my_logger,sev_error,aud_support) << "logged in as " << user_name;

ist schwer zu schlagen.
Möglicherweise müssen Sie jedoch Ihre eigenen Protokollsenken erstellen (dort werden die Protokollnachrichten abgelegt), da die wenigen vorgefertigten (stderr, file, Windows-Protokollierung usw.) nicht besonders ausgefeilt sind. Da die Leistung ein Hauptziel ist, sind die Grundzüge des Ganzen etwas kompliziert (so wie sich die Formatierer von Protokollnachrichten mit Protokollsenken verheddern), aber das haben wir gemeistert (ich erinnere mich, dass ich es in einem Debugger durchgearbeitet habe, der dabei geholfen hat) und zwar einmal Verstanden, dass es nicht allzu schwer war, eigene Nachrichtenformatierer oder Protokollsenken zu schreiben.

zuverlässig (nicht auslaufen oder abstürzen!)

Wir haben es verwendet, ohne solche schwerwiegenden Probleme zu finden. Es gibt dort praktisch keine dynamische Speicherzuweisung, daher kann man sich kaum vorstellen, dass etwas falsch läuft. Natürlich haben wir es immer nur in einem Produkt auf den Prüfstand gestellt.

plattformübergreifend (mindestens Windows, MacOSX, Linux / Ubuntu)

Als wir es verwendeten, verwendeten wir es unter Win32, OSX und verschiedenen Linux-Distributionen, darunter Ubuntu.

Was Multithreading angeht: Wir haben dies nicht verwendet, aber soweit ich mich an die Architektur der Bibliothek erinnere, scheint es, als müssten Sie dies nur in Protokollsenken behandeln. ICBWT.

Sie können die Logog-Bibliothek unter http://www.logog.org in Betracht ziehen, die Ihrer Meinung nach Ihren Anforderungen entspricht. Einschränkung: Ich habe es geschrieben.

Siehe auch die Antworten anderer Personen unter /programming/696321/best-logging-framework-for-native-c .

Sie könnte dich interessieren Baical Tools gesetzt:

• Open Source und plattformübergreifende Bibliothek (Win, Linux, x86 / x64) für Protokolle, Traces und Telemetrie - P7
• Unglaublich schnell (für eingebettete Geräte) - 3 Millionen Protokolle pro Sekunde im Netzwerk, 5 Millionen in der modernen CPU. Ich kenne keine andere Bibliothek für die Protokollierung, die eine solche Geschwindigkeit und so detaillierte Informationen für jede Protokollmeldung bietet.
• Thread sicher
• Jede Tracenachricht enthält:
  • Textnachricht
  • Niveau
  • genaue Zeit (100ns)
  • Quelldatei, Funktionsname & Zeile
  • Modul-ID und Modulname
  • Thread-ID und Thread-Name
  • Prozessorkernindex
• Serveranwendung zum Empfangen und Anzeigen von Protokollen und Telemetrie
• Sie können Protokolle aus mehreren Quellen in Echtzeit sammeln, analysieren, durchsuchen und filtern