[[EDIT 2x] Myślę, że źle sformułowałem moje pierwotne pytanie, więc zgubiłem je poniżej i przepisałem dokładnie to, co próbuję uzyskać, dla przyszłych czytelników. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Nowe, błyszczące, jasne pytanie z lepszym sformułowaniem]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mam pętlę, która działa w ramach symulacji / gry. Ta pętla ma kilka miejsc, w których musi ustalić, ile czasu - w rzeczywistości - minęło, aby logika w tych specjalnych miejscach - w szczególności Rendering i Aktualizacja - mogła działać poprawnie. Ma możliwość bycia krokiem o ustalonym czasie (unfixed[update/render] jest fałszywy) lub nie.

Problem pojawia się, gdy debugowanie oparte na punkcie przerwania jest wykonywane w dowolnym momencie aplikacji, ponieważ wykorzystuje stoper do obliczenia, ile czasu minęło (w celu poruszania się fizyki i animacji z realistyczną prędkością, a nie w oparciu o liczbę klatki, które komputer może wyrzucić).

Wygląda (z grubsza) tak, używającwiele stoperów dla każdej „części” pętli aplikacji, która musi wiedzieć, ile czasu upłynęło od ostatniej „części”:

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( );

    }
}   

Kilka informacji o zmiennych:

updatestopwatch jestStoper na czas spędzony poza funkcją Update (),

renderstopwatch jestStoper na czas spędzony poza funkcją Render () i

gamestopwatch jestStoper za całkowity czas, który upłynął w samej symulacji / grze.

Problem pojawia się, gdy debuguję w dowolnym miejscu aplikacji. Ponieważ stopery mierzą w czasie rzeczywistym, Symulacja zostanie całkowicie odrzucona przez dowolny debugowanie na podstawie punktu przerwania, ponieważ stopery będą zliczać czas, niezależnie od tego, czy debuguję aplikację. Nie używam stoperów do mierzenia wydajności: używam ich do śledzenia czasu między ponownymi wystąpieniami aktualizacji, renderowania i innych zdarzeń, takich jak te przedstawione powyżej. Staje się to niezwykle frustrujące, gdy przerywam i analizuję i naprawiam błąd w Update (), ale wtedy czas Renderowania () jest tak całkowicie wyłączony, że jakiekolwiek wyświetlanie wyników symulacji jest mściwie kopane w twarz.

To powiedziawszy, gdy przestanę całkowicie debugować, to oczywiście nie jest problem, ale mam dużo pracy rozwojowej do wykonania i będę debugował przez długi czas, więc udawanie, że to nie jest niewygodne, nie zadziała , Niestety. = [

Spojrzałem na liczniki wydajności, ale nie wydaje mi się, żeby zawracałem sobie głowę tym, jak skłonić ich do pracy w kontekście tego, co próbuję zrobić: Renderowanie i aktualizacja mogą zawierać dowolną ilość dowolnego kodu (są specyficzne niezależnie od tego, jaka symulacja jest uruchomionawhile pętla), co oznacza, że ​​nie mogę stalePerformanceCounter.Increment() dla poszczególnych elementów pętli.

Będę wciąż wyszukiwał system.Diagnostics i inne przestrzenie nazw .NET, ale jak dotąd pokazałem spacje, jak po prostu „zignorować” czas spędzony w dołączonym debuggerze ...

Czy ktoś ma jakieś pomysły lub wgląd?

[[EDITS 5x] Poprawiono błędy ortograficzne i upewniono się, że formatowanie wszystkiego było poprawne. Przepraszam za to. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Oryginalne, mniej jasne pytanie]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mam stałą pętlę działającą w aplikacji C #, którą cały czas debuguję. Obecnie używam stopera, ale mógłbym użyć dowolnego innego mechanizmu do śledzenia upływu czasu. Mój problem zaczyna się, gdy robię takie rzeczy, jak używanie punktów przerwania gdzieś podczas tej pętli (ujęte w typowywhile (true) { ... }:

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

Czas mierzy się dobrze, ale mierzy rzeczywisty czas rzeczywisty - w tymkażdy czas spędziłem na debugowaniu. Co oznacza, że ​​po 17 sekundach będę się szturchaćupdatestopwatch.Reset(), jest to dołączane do mojej pętli i - przez co najmniej 1 powtórkę tej pętli - muszę uporać się z dodatkowym czasem spędzonym w czasie rzeczywistym na wszystkich moich obliczeniach.

Czy jest jakiś sposób, w jaki mogę podłączyć się do debuggera, aby wiedzieć, kiedy zamroził aplikację, więc mogę przeciwdziałać czasowi i odpowiednio go odjąć? W tym celu używam .NET i C #, ale wszystko, co jest związane z Visual Studio, może pomóc mi we właściwym kierunku.

[EDIT] Aby dostarczyć więcej informacji, używam kilku stoperów (do aktualizacji, renderowania i kilku innych zdarzeń w innej kolejce komunikatów). Jeśli ustawię punkt przerwania w aktualizacji () lub w dowolnej innej części aplikacji, stopery dokładnie zmierzą czas rzeczywisty spędzony między nimi. Obejmuje to czas spędzony na debugowaniu różnych, całkowicie niepowiązanych składników mojej aplikacji, które są nazywane poniżejUpdate() lubRender() lubInput() itd. Oczywiście Timing symulacji (kontrolowany przez parametr GameTime przekazywany do funkcji aktualizacji, renderowania itp.) nie będzie działał poprawnie, jeśli nawet procesor zajęłby tylko 13 ms na zakończenie funkcji aktualizacji, spędzam13 dodatkowych sekund debugowania (patrząc na zmienne, a następnie kontynuuj z symulacją); problem polega na tym, że zobaczę inne stopery, które nagle się rozliczą13 dodatkowych sekundy czasu. Jeśli to nadal nie ma sensu, znów zacznę dzwonić.