[[2x BEARBEITEN] Ich glaube, ich habe meine ursprüngliche Frage falsch formuliert, also habe ich sie für zukünftige Leser weiter unten untersucht und genau das umgeschrieben, worauf ich abzielen möchte. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Neue, glänzende, klare Frage mit besserer Formulierung]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ich habe eine Schleife, die für ein Simulations- / Spiel-Framework ausgeführt wird. Diese Schleife enthält mehrere Stellen, an denen ermittelt werden muss, wie viel Zeit - in Wirklichkeit - vergangen ist, damit die Logik an diesen speziellen Stellen - insbesondere beim Rendern und Aktualisieren - ordnungsgemäß funktioniert. Es besteht die Möglichkeit, ein fester Zeitschritt zu sein (unfixed[update/render] ist falsch) oder nicht.

Das Problem tritt auf, wenn das Breakpoint-basierte Debugging an einer beliebigen Stelle in der Anwendung ausgeführt wird, da mithilfe einer Stoppuhr ermittelt wird, wie viel Echtzeit verstrichen ist (zum Zweck der Bewegung von Physik und Animation mit realistischer Geschwindigkeit und nicht auf der Basis von wie vielen Frames, die der Computer ausgeben kann).

Es sieht (ungefähr) so aus, mitmehrere Stoppuhren für jeden 'Teil' der Anwendungsschleife, der wissen muss, wie viel Zeit vergangen ist, seit dieser 'Teil' zuletzt aufgetreten ist:

while ( RunningTheSimulation ) {
    /* ... Events and other fun awesome stuff */

    TimeSpan updatedifference = new TimeSpan( updatestopwatch.ElapsedTicks );

    if ( unfixedupdate || updatedifference > updateinterval ) {

        Time = new GameTime( updatedifference,
                                    new TimeSpan( gamestopwatch.ElapsedTicks ) );
        Update( Time );
        ++updatecount;
        updatestopwatch.Reset( );
        updatestopwatch.Start( );
    }

    TimeSpan renderdifference = new TimeSpan( renderstopwatch.ElapsedTicks );

    if ( unfixedrender || renderdifference > renderinterval ) {

        Time = new GameTime( renderdifference,
                                 new TimeSpan( gamestopwatch.ElapsedTicks ) );
        Render( Time );
        ++rendercount;
        renderstopwatch.Reset( );
        renderstopwatch.Start( );

    }
}   

Einige Infos zu den Variablen:

updatestopwatch ist einStoppuhr für die Zeit außerhalb der Update () - Funktion,

renderstopwatch ist einStoppuhr für die Zeit außerhalb der Render () - Funktion und

gamestopwatch ist einStoppuhr für die gesamte verstrichene Zeit der Simulation / des Spiels.

Das Problem tritt auf, wenn ich irgendwo in der Anwendung debugge. Da die Stoppuhren in Echtzeit messen, wird die Simulation durch jede Art von Breakpoint-basiertem Debugging vollständig außer Kraft gesetzt, da die Stoppuhren die Zeit weiterhin zählen, unabhängig davon, ob ich die Anwendung debugge oder nicht. Ich verwende die Stoppuhren nicht, um die Leistung zu messen: Ich verwende sie, um die Zeit zwischen dem erneuten Auftreten von Aktualisierungen, Rendern und anderen Ereignissen wie den oben gezeigten zu verfolgen. Das wird extrem frustrierend, wenn ich einen Fehler in Update () anhalte und analysiere und behebe, aber dann ist die Render () -Zeit so komplett verrutscht, dass jede Anzeige der Simulationsergebnisse rachsüchtig ins Gesicht tritt.

Das heißt, wenn ich das Debuggen vollständig beende, ist das natürlich kein Problem, aber ich habe noch viel Entwicklungsarbeit zu erledigen, und ich werde lange Zeit debuggen. Nur so zu tun, als ob dies nicht unpraktisch wäre, wird nicht funktionieren , Unglücklicherweise. = [

Ich habe mir Leistungsindikatoren angeschaut, aber ich kann mich nicht wirklich darum kümmern, wie ich sie im Kontext meines Versuchs zum Laufen bringen kann: Rendern und Aktualisieren kann eine beliebige Menge beliebigen Codes enthalten (sie sind spezifisch) zu welcher Simulation auch immer läuftwhile Schleife), was bedeutet, ich kann nicht stetig tunPerformanceCounter.Increment() für die einzelnen Komponenten der Schleife.

Ich werde weiterhin in System.Diagnostics und anderen .NET-Namespaces stöbern, aber bisher habe ich Lücken gefunden, wie man die im angehängten Debugger verbrachte Zeit einfach "ignoriert" ...

Hat jemand irgendwelche Ideen oder Einsichten?

5x BEARBEITEN Korrektur von Rechtschreibfehlern und Überprüfung der korrekten Formatierung. Das tut mir leid. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Ursprüngliche, weniger klare Frage]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ich habe eine konstante Schleife in einer C # -Anwendung, die ich die ganze Zeit debuggen. Ich benutze derzeit eine Stoppuhr, aber ich könnte jeden anderen Mechanismus verwenden, um die Zeit zu verfolgen. Mein Problem beginnt, wenn ich in dieser Schleife irgendwo Haltepunkte verwende (eingeschlossen in einem Typical)while (true) { ... }:

if ( unfixedupdate || updatedifference > updateinterval ) 
{
    Time = new GameTime( updatedifference, 
                        new TimeSpan( gamestopwatch.ElapsedTicks ) );
    Update( Time );
    ++updatecount;
    updatestopwatch.Reset( );
    updatestopwatch.Start( );
}

Die Zeit misst sich gut, aber sie misst die tatsächliche Echtzeit - einschließlichirgendein Zeit, die ich mit dem Debuggen verbracht habe. Das heißt, wenn ich nachher 17 Sekunden lang herumstöbereupdatestopwatch.Reset()Dies wird auf meine Schleife aufgeschlüsselt und - für mindestens 1 Wiederholung dieser Schleife - muss ich mich mit der zusätzlichen Zeit auseinandersetzen, die ich in Echtzeit verbracht habe, um all meine Berechnungen zu berücksichtigen.

Kann ich mich in den Debugger einklinken, um zu erfahren, wann er die Anwendung einfriert, damit ich die Zeit gegenmessen und sie entsprechend subtrahieren kann? Wie bereits erwähnt, verwende ich .NET und C #, aber alles, was mit Visual Studio zu tun hat, kann mir dabei helfen, die richtige Richtung einzuschlagen.

[BEARBEITEN] Um weitere Informationen bereitzustellen, verwende ich mehrere Stoppuhren (zum Aktualisieren, Rendern und für einige andere Ereignisse, die sich alle in einer anderen Nachrichtenwarteschlange befinden). Wenn ich in Update () oder in einem anderen Teil der Anwendung einen Haltepunkt festlege, messen die Stoppuhren die zwischen diesen verbrachte Echtzeit genau. Dies schließt die Zeit ein, die ich mit dem Debuggen verschiedener völlig unabhängiger Komponenten meiner Anwendung verbringe, die als nachgeordnet bezeichnet werdenUpdate() oderRender() oderInput() usw. Offensichtlich funktioniert das Timing der Simulation (gesteuert durch den GameTime-Parameter, der an die Funktionen "Update", "Render" usw. übergeben wird) nicht richtig, selbst wenn die CPU nur 13 ms benötigt hat, um die Update-Funktion zu beenden13 zusätzliche Sekunden Debugging (Variablen betrachten und dann mit der Simulation fortfahren); Das Problem ist, dass ich die anderen Stoppuhren plötzlich sehen werde13 extra Sekunden Zeit. Wenn es immer noch keinen Sinn ergibt, melde ich mich wieder.