PureBoard

Verfasst: **05.04.2008 16:17**

such mal nach dem von tobe erwähnten
> timeBeginPeriod_()
und nach HighRes Timer, ist schon des öfteren was drüber geschrieben worden.
schon vor drei jahren oder so hatte Danilo nen hochauflösenden timer via API veröffentlicht.

Verfasst: **05.04.2008 16:34**

@Andreas_S
damit hab ich es getestet:

Code: Alles auswählen

EnableExplicit
Define log$, time.q, tgtime.l, pbtime.l, n.l

Define Frequency.q
Procedure.q QueryPerformanceCounter()
  Shared Frequency
  Protected PerformanceCount.q
  QueryPerformanceCounter_(@PerformanceCount)
  ProcedureReturn PerformanceCount * 1000000 / Frequency
EndProcedure
;/
Procedure.q InitPerformanceCounter()
  Shared Frequency
  If QueryPerformanceFrequency_(@Frequency)
    ProcedureReturn QueryPerformanceCounter()
  EndIf
EndProcedure
;/
Procedure.l FastTiming(State)
  Static LPTIMECAPS.TIMECAPS
  If State
    timeGetDevCaps_(LPTIMECAPS,SizeOf(TIMECAPS))
    timeBeginPeriod_(LPTIMECAPS\wPeriodMin)
  Else
    timeEndPeriod_(LPTIMECAPS\wPeriodMin)
  EndIf
EndProcedure
;/
Procedure db(string$)
  Shared log$
  log$ + string$ + #LFCR$
  ;Debug string$
EndProcedure
;/
;FastTiming(1)
Delay(1)
tgtime.l = timeGetTime_()
time.q = InitPerformanceCounter()
pbtime.l = ElapsedMilliseconds()
For n = 0 To 10
  Delay(1)
  db("PBT: " + Str(ElapsedMilliseconds() - pbtime) + " ms")
  db("TGT: " + Str(timeGetTime_() - tgtime) + " ms")
  db("PCT: " + StrF((QueryPerformanceCounter() - time) / 1000, 1) + " ms")
Next n
;FastTiming(0)

MessageRequester("Delay Test",log$)

wenn man die beiden FastTiming() zeilen einschaltet dann funktioniert delay(1) mit ca 1ms.

Verfasst: **05.04.2008 16:39**

Danke!

Kann ich sicher immer wieder gut gebrauchen...

Verfasst: **06.04.2008 00:35**

tobe hat geschrieben:wenn man die beiden FastTiming() zeilen einschaltet dann funktioniert delay(1) mit ca 1ms.

Bei mir funktioniert beides gleich, kein unterschied feststellbar.

Bei mir hat das Delay(1) ungefähr 2 ms.

Übrigends:
Wenn ich daraus ein delay(0) mache, ergibt "PCT" 0.3 ms.
Hier gibs aber auch kein unterschied mit und ohne FastTiming()

MFG PMV

Verfasst: **06.04.2008 00:42**

vil. hast du irgendein "tolles" tool installiert...

Schaltet FastTiming(State) das für das ganze System ein?

Verfasst: **06.04.2008 01:40**

wo wir schon am raten sind, vielleicht liegt es auch an der prozessor- oder mother-generation...?

Verfasst: **06.04.2008 02:22**

@Andreas_S
msdn sagt: This function affects a global Windows setting.
also tippe ich mal auf ja, deshalb sollte man es auf jeden fall am ende auch wieder ausschalten.

@PMV
bei mir hat delay(0) immer ca 0,04ms, das war mir zu wenig für die cpu entlastung und delay(1) 15ms, mit fasttiming 2ms

@Kaeru Gaman
ich hatte vorher ein AMD und jetzt ein CoreDuo, beide 15ms bei delay(1)
auf einem Celeron braucht es nur 10ms.

aber hauptsache es hilft gemütlichen rechnern auf touren zu kommen und schnellen rechnern schadet es nicht

Verfasst: **06.04.2008 11:09**

Danke tobe!

Ich schätze mal das Windows eine Funktion hat das es die Zeitberechnung
mit der Prozessorgeschwindigkeit verbindet...

Verfasst: **06.04.2008 22:27**

Also ich hab grad noch mal den unterschied zwischen Delay(0) und
Delay(1) getestet. In einem einfachen Test-Programm

Code: Alles auswählen

Repeat
  i + 1
  i - 1
Forever

hat bei mir ein Delay(0) nichts gebracht, 100% Auslastung. Erst durch
Delay(1) war die Last wieder schön gering. Könnte natürlich auch an
dem Debugger liegen, der dabei mit lief, aber ist ja auch wurscht.

tobe hat geschrieben:aber hauptsache es hilft gemütlichen rechnern auf touren zu kommen und schnellen rechnern schadet es nicht

Du meinst das einschalten von FastTiming()? Na da bin ich anderer
Meinung, denn überall, wo es auf Echtzeit ankommt, ist mehr Leistung
nötig. Das Windows normal im ~16ms Tackt misst wird sicher seinen Grund
haben. Die wenigsten Programme brauchen eine genauere Messung, aber
du hast ja bestimmt schon mal getestet, wie viel das Einschalten von
FastTiming() wirklich kostet

Oder?

MFG PMV

Verfasst: **07.04.2008 22:08**

das delay(0) zu wenig für eine cpu entlastung ist hab ich ja vorhin schon geschrieben, hat nix mit dem debugger zu tun.
delay ist ja nur dazu gut um überschüssige zeit an an windows bzw andere prozesse abzugeben,
bestes beispiel ist bei FlipBuffers(), wenn die berechnung aller daten für zb ein spiel ca 5ms dauert, dann verbrutzelt FlipBuffers() bei einem 60hz screen 11ms lang sinnlos 100% cpu leistung.
wenn ich jetzt aber ein normales delay(1) bei mir einschiebe dauert es 15ms obwohl ich nur 11ms übrig hab und schon hab ich ein frame verloren, mit delay(0) könnte man zwar super timen aber es läuft so schnell das es auch 100% cpu leistung frisst. FastTiming() einschalten war da für mich die beste lösung.
mit "gemütlichen rechnern" meinte ich ja eigentlich ein gemütliches windows (15ms) so wie bei mir und "schnelle rechner" sind so wie bei dir mit 2ms delay.
warum bei dir delay(1) so funktioniert wie ich es mir gewünscht hätte, kann ich leider auch nicht genau sagen, aber es zeigt das immer unerwartete unterschiede zwischen systemen bestehen
das Einschalten von FastTiming() kostet nix

auf der msdn seite steht zwar das windows dadurch etwas mehr performance verbraucht, aber ich merk davon nix

hier noch die msdn seite:
http://msdn2.microsoft.com/en-us/librar ... S.85).aspx
hmm, der url tag mag mich nicht, egal

mfG
tobe

PureBoard

Ziel Schuss