"Unglaubwürdigkeitsproblem" bei Frameratenberechnung

xindon

Aber wenn FPS ebenfalls von der delta time abhängen und jeden Frame aktualisiert werden, ist das doch wohl egal, wie man Geschwindigkeiten letztendlich berechnet

rapso

das hatten wir alles schonmal http://www.c-plusplus.net/forum/viewtopic-var-t-is-21275

hustbaer

@xindon:
Ich weiss immer noch nicht was der Einwand sollte. Wenn ich die Framerate will muss ich von der delta time ausgehen. Die kann ich messen, und dann wie ich lustig bin (gemittlet oder auch nicht) eine Framerate daraus berechnen.

Aber warum in aller Welt sollte ich wenn ich dann eben beides habe gerade die Framerate verwenden um irgendwelche Bewegungen zu steuern? Und schon garnicht wenn ich die Framerate gemittelt habe, die delta time aber noch "roh" ist?
Verstehe ich nicht wie man darauf kommen könnte das so zu machen. Klar wäre es Blödsinn, aber eben weil es so offensichtlich Blödsinn wäre verstehe ich den Hinweis darauf nicht...

xindon

hustbaer schrieb:

Aber warum in aller Welt sollte ich wenn ich dann eben beides habe gerade die Framerate verwenden um irgendwelche Bewegungen zu steuern? Und schon garnicht wenn ich die Framerate gemittelt habe, die delta time aber noch "roh" ist?
Verstehe ich nicht wie man darauf kommen könnte das so zu machen. Klar wäre es Blödsinn, aber eben weil es so offensichtlich Blödsinn wäre verstehe ich den Hinweis darauf nicht...

Inzwischen ist mir auch klar, was du willst und das es sinnvoller ist, aber ich möcht dir grad noch erklären, wie ich konstante Bewegungen realisiert hab.

Nehmen wir an, ich verteile meinen Figuren feste Geschwindigkeiten, die ich bei 60fps für richtig halte.
Wenn das Programm jetzt mit 90fps läuft, kann man ja mit deinen beiden Frameraten einen Faktor ausrechnen (60/90) und dann multipliziert man die Bewegungsgeschwindigkeit mit diesem Faktor...

rapso

xindon schrieb:

hustbaer schrieb:

Aber warum in aller Welt sollte ich wenn ich dann eben beides habe gerade die Framerate verwenden um irgendwelche Bewegungen zu steuern? Und schon garnicht wenn ich die Framerate gemittelt habe, die delta time aber noch "roh" ist?
Verstehe ich nicht wie man darauf kommen könnte das so zu machen. Klar wäre es Blödsinn, aber eben weil es so offensichtlich Blödsinn wäre verstehe ich den Hinweis darauf nicht...

Wenn das Programm jetzt mit 90fps läuft, kann man ja mit deinen beiden Frameraten einen Faktor ausrechnen (60/90) und dann multipliziert man die Bewegungsgeschwindigkeit mit diesem Faktor...

das heisst, je nach framerate werden sie verschiedene kurven laufen und verschieden oft "nachdenken"? *hehe*

xindon

rapso schrieb:

das heisst, je nach framerate werden sie verschiedene kurven laufen und verschieden oft "nachdenken"? *hehe*

Versteh ich jetzt nicht, was du damit meinst?

rapso

xindon schrieb:

rapso schrieb:

das heisst, je nach framerate werden sie verschiedene kurven laufen und verschieden oft "nachdenken"? *hehe*

Versteh ich jetzt nicht, was du damit meinst?

was daran faellt dir schwer zu verstehen?

xindon

kurven laufen? nachdenken?

und wer ist überhaupt "sie" ?

rapso

xindon schrieb:

kurven laufen? nachdenken?

Prädikat?

xindon schrieb:

und wer ist überhaupt "sie" ?

xindon schrieb:

...meinen Figuren...

xindon

och man ich gebs gleich auf...

ich nehme mal an, mit "sie" sind die Figuren gemeint, aber warum sollten sie Kurven laufen? und über was sollen sie denn nachdenken?

rapso

xindon schrieb:

ich nehme mal an, mit "sie" sind die Figuren gemeint, aber warum sollten sie Kurven laufen?

weil es ziemlich langweilig waere nur geradeaus zu laufen, irgendwann muessen sie abbiegen/kurven laufen.

und über was sollen sie denn nachdenken?

die handlungen die sie durchfuehren.

xindon

Sag mal willst du jetzt auf einen Fehler/Bug in meiner Berechnung raus oder willst du mich einfach nur verscheissern? :p

rapso

xindon schrieb:

Sag mal willst du jetzt auf einen Fehler/Bug in meiner Berechnung raus oder willst du mich einfach nur verscheissern? :p

raffst du das echt nicht dass deine simple idee nur bei linearer bewegung richtig laufen kann?

xindon

rapso schrieb:

xindon schrieb:

Sag mal willst du jetzt auf einen Fehler/Bug in meiner Berechnung raus oder willst du mich einfach nur verscheissern? :p

raffst du das echt nicht dass deine simple idee nur bei linearer bewegung richtig laufen kann?

Ja was ist denn bitte eine lineare Bewegung? Wenn meine Objekte eine Position und einen Bewegungsvektor haben. Die Länge des Bewegungsvektors multipliziere ich mit dem oben genannten Faktor.. was soll da schief gehen?

rapso

xindon schrieb:

rapso schrieb:

xindon schrieb:

Sag mal willst du jetzt auf einen Fehler/Bug in meiner Berechnung raus oder willst du mich einfach nur verscheissern? :p

raffst du das echt nicht dass deine simple idee nur bei linearer bewegung richtig laufen kann?

lineare Bewegung?Position und Bewegungsvektor

xindon schrieb:

was soll da schief gehen?

rapso schrieb:

...nur bei linearer bewegung richtig laufen kann?

nicht lineare bewegung

xindon

Tut mir leid, es is schon spät und seit ich vorhin meine Matrix Klasse geschrieben hab, bin ich leicht matschig im Kopf (grr die ganzen Indizes)..

Du willst mir also sagen, dass ich das so nicht machen kann, wenn die Bewegungsgeschwindigkeit nicht konstant ist. Naja is mir jetzt auch egal, ich geh schlafen :p sorry, dass ich dich genervt hab

rapso

xindon schrieb:

Tut mir leid, es is schon spät und seit ich vorhin meine Matrix Klasse geschrieben hab, bin ich leicht matschig im Kopf (grr die ganzen Indizes)..

Du willst mir also sagen, dass ich das so nicht machen kann, wenn die Bewegungsgeschwindigkeit nicht konstant ist. Naja is mir jetzt auch egal, ich geh schlafen :p sorry, dass ich dich genervt hab

ja, sobald geschwindigkeit, richtung sich aendern, oder logic berechnet wird, ist diese interpolation ungenau und kann von pc zu pc ein anderes spiel erzeugen. bei jemandem mit 100fps kann es sein dass homing-missiles immer treffen, bei jemandem mit 15fps koennten sie in eine umlaufbahn um das ziel einschwenken.

xindon

Ja aber das ist ja dann immer so, wenn man Bewegungen von der Zeit abhängig macht.

Bei deinem Beispiel mit der Homing Missile könnte man der Rakete ja auch einen kleinen Radius verpassen, bei dem sie schon hochgeht..

rapso

xindon schrieb:

Ja aber das ist ja dann immer so, wenn man Bewegungen von der Zeit abhängig macht.

nein, wenn die bewegung immer fuer gleiche zeitabstaende berechnet wird, ist es auf jedem rechner gleich (falls die hardware nicht ungenauigkeiten hat)

Bei deinem Beispiel mit der Homing Missile könnte man der Rakete ja auch einen kleinen Radius verpassen, bei dem sie schon hochgeht..

das ist doch nicht der punkt. worauf es ankommt ist doch dass ein spiel fuer jeden gleich spielbar ist.

Kahino

Ich weiß, der Thread ruhte jetzt schon so ein Paar Tage, doch kam ich bis jetzt einfach nicht dazu mal wieder vorbei zu schauen 0o.

Was die Glaubwürdigkeit der Frames angeht.
Das mit den 50 000 bzw 150 000 FPS trifft ausschließlich bei der Winapi zu.

Ich habe jetzt mal Testweise versucht EXAKT DIE SELBE Frameratenberechnung bei einer simplen DirectX-Anwendung zu verwenden.
Der Aufbau der Spielschleife ist nahezu identisch zu meinem Winapi Versuch,
nur dass in der Schleife jetzt natürlich auch immer der Hintergrund gelöscht wird
und BeginScene() bzw EndScene() und Present aufgerufen wird,
mal abgesehen davon, dass ich die Framerate jetzt nicht mehr mit Textout auf den Bildschirm bringe.
Und die Framerate bewegt ist immer um die 60 FPS, sinkt zwischendurch zwar kurz auf Werte zwischen 50 und 60, doch so kleine Schwankungen sind ja normal.
Aber wie kommt es, dass die Werte nicht höher sind?
Da passiert doch nichts außer den Hintergrund in jedem Frame zu löschen und Text auszugeben.
Sicherlich gibt es da die Bildwiederholrate und so, doch diese DirectX-Beispiele aus dem SDK haben bei mir auch oft Werte zwischen 400-500.
Naja, ist ja jetzt auch erst mal egal.

Und falls du noch einmal hier vorbeischauen solltest @raspo:

In dem von dir angegebenen Thread sprachst du von Logigtiks.
Ich war zwar noch nicht so weit, als dass ich mir darüber schon Gedanken
gemacht hätte, doch wäre mein Ansatz wohl auch gewesen die Bewegung von der Framerate abhängig zu machen, doch dein Ansatz gefällt mir besser.
Und als Beispiel gabst du folgenden code an:

int LastTick=GetTickCount(); 
    while(!g_bQuit) 
    { 
        while(LastTick<GetTickCount()) 
        { 
            g_pAktualModule->LogicTick(); 
            LastTick+=TICKTIME; 
            if(LastTick+10000<GetTickCount()) 
                LastTick=GetTickCount()+TICKTIME; 
        } 
        Render(); 
        if(PeekMessage(&msg,hWnd,0,0,PM_NOREMOVE)!=0) 
        { 
            g_bQuit = !((bool)(PeekMessage(&msg,hWnd,0,0,PM_REMOVE))); 
            TranslateMessage(&msg); 
            DispatchMessage(&msg); 
        } 
    }

Und dazu hätte ich dann jetzt noch ein Paar Fragen.
Erstens, ist das hier deine Aktuelle Version davon?
Denn du schriebst später:

DAS kann nicht nur, DAS ist so für den logictick, schliesslich rechnet man mit der abstrakten zeit, die das framework vorgibt und nicht mit z.B. GetTickCount oder sowat (siehe mein code snipple in früheren post)

In diesem Codeschnipsel findet sich jedoch GetTickCount, anfangs dachte ich mir, dass du meinst, GetTicCount würde intern bei der Logikberechnung nicht vorkommen, doch dann verstehe ich speziell in diesem Zusammenhang den Verweis auf diesen Codeschnipsel nicht (da man hier ja nicht das interne Zeug deienr Logikberechnung sieht).
Naja, vielleicht war das ja auch nur ein Missverständnis, doch dies war jetzt nicht das Hauptproblem weswegen ich hier jetzt nachfrage.

Nun gut, zu Beginn deiner Spielschleife startest du die "Logigschleife", die so lange wiederholt wird bis LastTick größer ist als der Wert von GetTickCount.
Bei jedem Durchlauf wird hier ein LogigTick ausgeführt, welcher intern das nötige Zeug vorberechnet und die Animatoren einstellt(?).
Doch auch wenn dieses System mit der Framerate herzlich wenig zu tun hat, wird hierbei ein schneller Rechner weniger Ticks Pro Zeiteinheit durchführen als ein langsamer Rechner, einfach weil die LastTick-Variable bei einem Schnellen Rechner schneller erhöt wird, als sich der Wert von GetTickCount vergößert(bei jedem Durchlauf der Logikschleife liefert GetTickCount ja einen neuen Wert).
Nungut, dass der schnellere Rechner wirklich weniger durchführt muss nicht sein, so befindet sich ein langsamer Rechner zwar länger in der Logigschleife, doch dauert es somit natürlich auch länger bis ein Logigtick aufgerufen wird.
Doch betrachtet man Rechner die unterschiedlich schnell sind, doch beide schnell genug "selbstständig" einen höheren LastTickwert zu erhalten als GetTickCount zurückgibt, ist eine unterschiedliche Logigtickaufrufzahl ja klar und dieses indirekte Schleifenende bei einem zu großen Unterschied ( langsame Rechner) heißt auch nicht unbedingt, dass die Proportionen gewahrt sind.
Sicherlich, ein schneller Rechner der die Logigschleife mit den geringeren Logiktickaufrufen beendet die Logigschleife schneller und kommt somit auch schneller wieder beim nächsten Durchlauf der Spielschleife wieder hinein, doch ob dies das Selbe ist? Das wage ich zu bezweifeln.
Ok, du hast da einen Mechanismus eingebaut der die Logigschleife indirekt beendet sollte der Unterschied zwischen LastTick und GetTickCount zu groß sein (bei einem sehr langsamen Rechner).
Aber dennoch sind es nur spezialfälle an denen ein langsamer Rechner und ein schneller Rechner mit dieser Berechnung die selbe Anzahl an Logigticks pro Zeiteinheit hinbekommen.

Nächste Frage, nehmen wir hier einfach mal an das zuvor erwähnte Problem hätte ich nicht angesprochen.
Also die Logigschleife wird beendet und das Rendern beginnt.
Im Animator herrscht nun eine Warteschlange von Zeichenoperatoren.
Doch das Problem ist, die Spielschleife hat doch nur eine einzige Zeichnung pro Spielschleifendurchlauf frei, zeichnet man mehrmals sieht man das Bildchen auch mehrmals auf dem Bildschirm, abhängig von der Geschwindigkeit auch nur ein Paar Überlagerungen, doch auch nicht nett.
Gedacht ist das Zeig sicherlich so, dass die Animatoren natürlch mehr Frames zur Verfügung haben um das Zeug zu zeichnen, doch da man eigentlich in jedem Frame wieder in die Logigschleife kommt, werden die Animatoren auch immer wieder neu eingestellt, was die ganze Einstellerei wieder nutzlos macht.

Könnte zwar noch ein Paar Sachen schreiben, doch ich offe genug geschrieben zu haben damit du mein Verständnisproblem erkennst, wenn du dieses System schon Jahre benutzt und keine Ungereimtheiten festgestellt hast, wird es wohl auch funktionieren :D, ich würde nur gerne wissen wie.

Vielleicht hilft auch die Information was denn "TICKTIME" für einen Wert enthält.

Ist TICKTIME gar so klein, dass dieser Wert niemals in der Lage wäre LastTick auf einen höheren Wert zu bringen als GetTickCount zurückgibt?
Und die Geschwindigkeit des Rechners somit nur noch beeinflusst wie lange es dauert bis der Differenzbetrag zu groß ist? Und somit diese Indirekte Abbruchbedingung in Kraft tritt (if(LastTick+10000<GetTickCount())
LastTick=GetTickCount()+TICKTIME;
)? Und somit auch die Möglichkeit gegeben ist, dass die Startbedingung bei der Logigschleife mal tatsächlich nicht gegeben ist und die Animatoren dadurch einen Sinn machen?

...

Wenn dem so ist, dann würde ich dennoch gerne wissen, weshalb pro Zeiteinheit somit immer die selbe Anzahl an Logigticks durchgeführt wird, egal wie schnell der Rechner ist.
Würde dieses System dann nämlich auch gerne selbst verwenden

&quot;Unglaubwürdigkeitsproblem&quot; bei Frameratenberechnung

"Unglaubwürdigkeitsproblem" bei Frameratenberechnung