Hallo,

auf einigen Systemen kam es bei meinem Schachprogramm zu einem Problem mit der Zeitmessung für das Timebased Movement: So stoppte die Drehung, die das Feld im "Menu-Modus" macht, sobald der Mauszeiger über dem Programmfenster war. Inzwischen weiß ich dass Idle weiterhin aufgerufen (und das Bild gerendert) wird, nur die gemessene Zeit so kurz ist, dass sich praktisch nichts bewegt. Das Idle-Event schaut so aus:
Wie man sieht habe ich statt dem Hardwarecounter auch mal GetTickCount verwendet, da eine Idee war, dass der Fehler nur auf DualCores auftritt. Allerdings macht es nach meinem Ergebnis keinen Unterschied ob QPC oder TickCount.

Ich habe, da mir die o.g. Zeitmessung sowieso nicht zusagt eine zweite Methode ausprobiert:Diese verhält sich aber auch nicht anders, als die oben gezeigte. Ein zusätzliches Problem bei dieser Methode scheint zu sein, dass die OpenGL-Selektion nicht mehr funktioniert.

Ich habe daraufhin noch etwas mit der ersten Methode experimentiert, wobei mir aufgefallen ist, dass der Fehler manchmal behoben ist, wenn ich der Anwendung einen bestimmten Kern zuweise. Dann dreht sich das Feld manchmal normal, auch wenn der Zeiger über dem Feld ist - bewege ich ihn allerdings im Feld scheint das die Messung wieder zu beeinflussen, das Feld wird wieder langsamer.

Hat irgendjemand eine Idee was da schief laufen könnte?

Also ich habe das bei mir mit GetTickCount (bzw. Linux equivalenten) immer so gelöst, dass ich, wenn die differenz gleich 0 ist, den Frame geskippt und garnichts gemacht habe und auch die LastUpdate-Variable nicht verändert habe.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Naja, aber das ändert doch nichts daran, dass die Zeit falsch gemessen zu werden scheint, oder? Außerdem habe ich zumindest in der ersten variante ja keine LastUpdate-Variable. Was meinst du mit Frame skippen?

Mach nur eine Messung pro Frame, und nimm die Differenz zum vorherigen. Dann solltest du die Zeitdifferenz jedoch auf jeden Fall nach oben deckeln, ich nehm z.B. ganz gerne 100ms dafür. Eine Deckelung nach unter, z.B. bei 5ms kann auch sinnvoll sein um Rechenleistung zu sparen, da >200fps kaum sinnvoll sind.
Wir haben dazu aber schon einige Threads hier.

_________________

Ja, das wäre dann die zweite Variante - nur dass es bei der das selbe Messproblem gibt wie bei der ersten. Ein Framelimiter ist sowieso geplant, nur was soll ich machen wenn bei der Messung immer ~Null rauskommt?! Bisher bin ich der Meinung dass die Messung einfach falsch ist - auf anderen Systemen läufts ja richtig.
Was mir grade in den Sinn kommt - kann es sein dass EIST oder C1E da mit reinspielen? EDIT: Ne, ist vermutlich quatsch, GetTickCount geht ja auch nicht....

Du kannst dein Programm im Taskmanager auf einen Kern beschränken, das räumt zumindest diese Probleme aus.
Zeig mal deinen code wenn du nur einmal pro frame misst.

_________________

Ich habe ja bereits oben geschrieben, dass das Beschränken auf einen Kern nicht hilft (das Problem zumindest nicht vollständig behebt). Die zwei Zeitmess-varianten stehen doch oben?

ich seh da keine in der du nur einmal misst.
Ich mach das in etwa so:

_________________

Du misst effektiv nur die Zeit, die von QPCLastRender bis QPCNow vergeht, also die Zeit nach dem Rendern bis zum nächsten Rendern. Dass die so ganz grob 0 ist, erscheint mir logisch.
Probier mal statt

das:


Und für das seltsame FloatToStr-Konstrukt könntest du der Übersichtlichkeit halber auch FloatToStrF oder Format() mit %.2f verwenden.

MfG

Ahja bin ich doof, alles klar - jetzt geht's.^^ Jetzt tritt werden zwar die Selektionsmodelle nicht mehr angezeigt, wenn man auf ne Figur klickt, aber hinter den Fehler komme ich auch noch.^^
Vielen Dank!