Ziel Schuss
-
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
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.
> 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.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
@Andreas_S
damit hab ich es getestet:
wenn man die beiden FastTiming() zeilen einschaltet dann funktioniert delay(1) mit ca 1ms.
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$)
PureBasic 4.40 (Windows - x86)
Bei mir funktioniert beides gleich, kein unterschied feststellbar.tobe hat geschrieben:wenn man die beiden FastTiming() zeilen einschaltet dann funktioniert delay(1) mit ca 1ms.
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
-
- Beiträge: 17389
- Registriert: 10.11.2004 03: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
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

PureBasic 4.40 (Windows - x86)
Also ich hab grad noch mal den unterschied zwischen Delay(0) und
Delay(1) getestet. In einem einfachen Test-Programm
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.
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
Delay(1) getestet. In einem einfachen Test-Programm
Code: Alles auswählen
Repeat
i + 1
i - 1
Forever
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.
Du meinst das einschalten von FastTiming()? Na da bin ich anderertobe hat geschrieben:aber hauptsache es hilft gemütlichen rechnern auf touren zu kommen und schnellen rechnern schadet es nicht
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

MFG PMV
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
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
PureBasic 4.40 (Windows - x86)