Goto/Gosub - Alternative?

Übersicht

BlitzBasic

Beginners-Corner

Gehe zu Seite Zurück 1, 2

	TimBo	Mi, Okt 28, 2009 20:27 Antworten mit Zitat
und warum hat dann mein Kernometer 1% bei jedem Kern, wenn ich ein programm mit WaitTimer(timer) Flip(1) sowas starte ? Greez TimBo
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10 Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

TimBo

Mi, Okt 28, 2009 20:27
Antworten mit Zitat

und warum hat dann mein Kernometer 1% bei jedem Kern, wenn ich ein programm mit

WaitTimer(timer)
Flip(1)

sowas starte ?

Greez
TimBo

mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10
Stolzer Gewinner des BCC 25 & BCC 31
hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

	hectic Sieger des IS Talentwettbewerb 2006	Mi, Okt 28, 2009 20:31 Antworten mit Zitat
Weil du dann eine superdolle Grafikkarte hast die so per Treiber konfiguriert wurde, dass sie generell Flip 0 macht, egal was du da eingibtst. Das kommt dann besser bei den FPS-Fetischisten an. Letztendlich ist es schon ein kleiner Betrug der vor allem in früheren Grafikkarten gerne gemacht wurde.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

hectic

Sieger des IS Talentwettbewerb 2006

Mi, Okt 28, 2009 20:31
Antworten mit Zitat

Weil du dann eine superdolle Grafikkarte hast die so per Treiber konfiguriert wurde, dass sie generell Flip 0 macht, egal was du da eingibtst. Das kommt dann besser bei den FPS-Fetischisten an. Wink

Letztendlich ist es schon ein kleiner Betrug der vor allem in früheren Grafikkarten gerne gemacht wurde.

Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

	TimBo	Mi, Okt 28, 2009 20:34 Antworten mit Zitat
ok gebe mich geschlagen.. dann benutze ich wieder Flip(0) , obwohl das bei meinem jetzigen Projekt dann so abgehackt aussieht. Ich weiß nicht, Flip(1) sieht "runder" aus. Grüße TimBo
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10 Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

TimBo

Mi, Okt 28, 2009 20:34
Antworten mit Zitat

ok gebe mich geschlagen.. Very Happy

dann benutze ich wieder Flip(0) , obwohl das bei meinem jetzigen Projekt dann so abgehackt aussieht. Ich weiß nicht, Flip(1) sieht "runder" aus.

Grüße
TimBo

	Nicdel	Mi, Okt 28, 2009 20:38 Antworten mit Zitat
Generell ist die Methode von TimBo in B3D am besten geeignet. Auch wenn ich nur selten damit arbeite. Meine unsinnvolle Methode ist zwei Schleifen hintereinander zu machen, eine für's Menü, eine für's Spiel. @TimBo: Wenn du Flip 1 verwendest kannst du dann aber auch den Timer weglassen. Der nützt dann auch nichts mehr. Was meinst du mit abgehackt?
Desktop: Intel Pentium 4 2650 Mhz, 2 GB RAM, ATI Radeon HD 3850 512 MB, Windows XP Notebook: Intel Core i7 720 QM 1.6 Ghz, 4 GB DDR3 RAM, nVidia 230M GT, Windows 7

Nicdel

Mi, Okt 28, 2009 20:38
Antworten mit Zitat

Generell ist die Methode von TimBo in B3D am besten geeignet. Auch wenn ich nur selten damit arbeite. Meine unsinnvolle Methode ist zwei Schleifen hintereinander zu machen, eine für's Menü, eine für's Spiel.

@TimBo: Wenn du Flip 1 verwendest kannst du dann aber auch den Timer weglassen. Der nützt dann auch nichts mehr. Was meinst du mit abgehackt?

Desktop: Intel Pentium 4 2650 Mhz, 2 GB RAM, ATI Radeon HD 3850 512 MB, Windows XP
Notebook: Intel Core i7 720 QM 1.6 Ghz, 4 GB DDR3 RAM, nVidia 230M GT, Windows 7

	TimBo	Mi, Okt 28, 2009 20:41 Antworten mit Zitat
ja so ein streifen der von unten nach oben geht. Und jetzt weiß ich auch warum. Wenn ich mit Flip(1) arbeite , dann ist die FPS 60. Wenn ich den Timer auf 60 schalte , zeigt mir der FPS Counter 62FPS an. 62 FPS mag mein Flat nicht und es kommt zu den überschneidungen. die FPS habe ich mit BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] ;Hectics FPS Counter ms=MilliSecs():Text 0,20,fps If ms>mt mt=ms+502:fps=frame:frame=0 Else frame=frame+2 ermittelt Greez TimBo
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10 Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

TimBo

Mi, Okt 28, 2009 20:41
Antworten mit Zitat

ja so ein streifen der von unten nach oben geht.
Und jetzt weiß ich auch warum.

Wenn ich mit Flip(1) arbeite , dann ist die FPS 60.
Wenn ich den Timer auf 60 schalte , zeigt mir der FPS Counter 62FPS an.
62 FPS mag mein Flat nicht und es kommt zu den überschneidungen.

die FPS habe ich mit
BlitzBasic: [AUSKLAPPEN]

;Hectics FPS Counter
ms=MilliSecs():Text 0,20,fps 
If ms>mt mt=ms+502:fps=frame:frame=0 Else frame=frame+2

ermittelt

Greez
TimBo

	Nicdel	Mi, Okt 28, 2009 20:42 Antworten mit Zitat
Das stimmt. Ein Timer, der mit CreateTimer(60) erstellt wurde macht eigentlich 62.5 FPS.
Desktop: Intel Pentium 4 2650 Mhz, 2 GB RAM, ATI Radeon HD 3850 512 MB, Windows XP Notebook: Intel Core i7 720 QM 1.6 Ghz, 4 GB DDR3 RAM, nVidia 230M GT, Windows 7

Nicdel

Mi, Okt 28, 2009 20:42
Antworten mit Zitat

Das stimmt. Ein Timer, der mit CreateTimer

(60) erstellt wurde macht eigentlich 62.5 FPS.

Desktop: Intel Pentium 4 2650 Mhz, 2 GB RAM, ATI Radeon HD 3850 512 MB, Windows XP
Notebook: Intel Core i7 720 QM 1.6 Ghz, 4 GB DDR3 RAM, nVidia 230M GT, Windows 7

	TimBo	Mi, Okt 28, 2009 20:46 Antworten mit Zitat
Hi man die guten alten Zeiten: Zitat von Hectic: aus dem Topic: Speed Test Okt 08, 2007 , https://www.blitzforum.de/foru...hlight=fps Zitat: Alle Bildschirme haben irgendwie unterschiedliche Bildwiederholfrequenz. Wenn nun deine Vorgaben mit einem kleinen gemeinsamen Teiler harmoniert, so erscheinen in Dissharmonierter Frequenz eben so tolle zu sehende ''Balken'' die dann von Oben nach Unten oder umgekehrt erscheinen. Beispiel: Dein Programm ist auf 60 FPS gestellt, doch ein Monitor macht 60.1 Hz, dann wandert ein Balken alle 10 Sekunden langsam den Bildschirm entlang. Dieser Balken ist aber nur als horizontaler Bewegung als Asyncronisation zu erkennen. Also über den Balken ist ein neueres Bild als unter dem Balken und umgekehrt. Rätzelslösung ist einen FPS-Wert anzugeben, der möglichst mit keiner gängigen Bildfrequenz harmoniert (auch nicht annährend). Gängige Frequenzbereichen sind 60, 72, 75, 76, 80, 85, 100, 150... und sicherlich noch ein paar, die mir grad nicht so geläufig sind. Wie man aber auch unschwer erkennen kann, wird es recht eng mit einer passenden Vorgabe. Genau diese Balken kommen bei Flip (1) nicht mehr ... mit Flip(0) schaffe ich es nicht den Timer so zu schalten , dass diese doofen Balken weg sind. Greez TimBo
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10 Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

TimBo

Mi, Okt 28, 2009 20:46
Antworten mit Zitat

Hi

man die guten alten Zeiten:

Zitat von Hectic:
aus dem Topic: Speed Test Okt 08, 2007 ,
https://www.blitzforum.de/foru...hlight=fps

Zitat:

Alle Bildschirme haben irgendwie unterschiedliche Bildwiederholfrequenz. Wenn nun deine Vorgaben mit einem kleinen gemeinsamen Teiler harmoniert, so erscheinen in Dissharmonierter Frequenz eben so tolle zu sehende ''Balken'' die dann von Oben nach Unten oder umgekehrt erscheinen. Beispiel: Dein Programm ist auf 60 FPS gestellt, doch ein Monitor macht 60.1 Hz, dann wandert ein Balken alle 10 Sekunden langsam den Bildschirm entlang. Dieser Balken ist aber nur als horizontaler Bewegung als Asyncronisation zu erkennen. Also über den Balken ist ein neueres Bild als unter dem Balken und umgekehrt. Rätzelslösung ist einen FPS-Wert anzugeben, der möglichst mit keiner gängigen Bildfrequenz harmoniert (auch nicht annährend). Gängige Frequenzbereichen sind 60, 72, 75, 76, 80, 85, 100, 150... und sicherlich noch ein paar, die mir grad nicht so geläufig sind. Wie man aber auch unschwer erkennen kann, wird es recht eng mit einer passenden Vorgabe.

Genau diese Balken kommen bei Flip (1) nicht mehr ... mit Flip(0) schaffe ich es nicht den Timer so zu schalten , dass diese doofen Balken weg sind.

Greez
TimBo

	Noobody	Mi, Okt 28, 2009 21:11 Antworten mit Zitat
TimBo: Lies mal den Hilfeeintrag zu Flip durch. Dass es bei Flip 1 keinen Balken gibt, liegt schlicht daran, dass Flip dann wartet, bis das aktuelle Bild komplett aufgebaut ist und dann erst das neue Bild anzeigt. Selbst wenn du einen Timer hättest, der perfekt die gleiche Framerate wie dein Bildschirm hat, kommt es zu diesem Balken (auch Image-Tearing genannt) - der Balken bleibt dann einfach an Ort und Stelle. Im Grunde genommen ist Flip 1 einfach ein VWait mit folgendem Flip 0 Da man Flip 1 nicht per Timer nachbasteln kann, muss man sich dann einfach entscheiden - entweder, man lastet den Kern, auf dem das Programm läuft, komplett mit Flip 1 aus und hat dafür einen sanften Bildübergang oder man benutzt einen Timer mit Flip 0 und nimmt dafür das Image-Tearing in Kauf, sorgt aber für akzeptable Prozessorauslastung. Für die meisten Spiele würde ich Methode 2 ans Herz legen, da Programme einen sehr schlechten Eindruck machen, wenn sie für ein simples Tetris das System komplett auslasten. In grösseren Projekten könnte man Flip 1 immerhin optional machen, für die, die beim Spielen auf Bildqualität setzen
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Mi, Okt 28, 2009 21:11
Antworten mit Zitat

TimBo: Lies mal den Hilfeeintrag zu Flip

durch.

Dass es bei Flip 1 keinen Balken gibt, liegt schlicht daran, dass Flip dann wartet, bis das aktuelle Bild komplett aufgebaut ist und dann erst das neue Bild anzeigt. Selbst wenn du einen Timer hättest, der perfekt die gleiche Framerate wie dein Bildschirm hat, kommt es zu diesem Balken (auch Image-Tearing genannt) - der Balken bleibt dann einfach an Ort und Stelle. Im Grunde genommen ist Flip 1 einfach ein VWait

mit folgendem Flip 0 Razz

Da man Flip 1 nicht per Timer nachbasteln kann, muss man sich dann einfach entscheiden - entweder, man lastet den Kern, auf dem das Programm läuft, komplett mit Flip 1 aus und hat dafür einen sanften Bildübergang oder man benutzt einen Timer mit Flip 0 und nimmt dafür das Image-Tearing in Kauf, sorgt aber für akzeptable Prozessorauslastung.

Für die meisten Spiele würde ich Methode 2 ans Herz legen, da Programme einen sehr schlechten Eindruck machen, wenn sie für ein simples Tetris das System komplett auslasten. In grösseren Projekten könnte man Flip 1 immerhin optional machen, für die, die beim Spielen auf Bildqualität setzen Razz

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	TimBo	Mi, Okt 28, 2009 21:14 Antworten mit Zitat
Das mit der Synchronisation war mir bewusst, nur das man das NICHT mit dem Timer nachbauen kann nicht. Aber ist irgendwie logisch. Muss man also abwägen Danke Noobody Grüße TImBo
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10 Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht.

TimBo

Mi, Okt 28, 2009 21:14
Antworten mit Zitat

Das mit der Synchronisation war mir bewusst, nur das man das NICHT mit dem Timer nachbauen kann nicht.
Aber ist irgendwie logisch.

Muss man also abwägen Smile

Danke Noobody

Grüße
TImBo

	hectic Sieger des IS Talentwettbewerb 2006	Mi, Okt 28, 2009 21:48 Antworten mit Zitat
Also, wenn es bei dir einen sichtbaren Unterschied zwischen Flip 0 und Flip 1 gibt, dann entspricht meine vorherige Aussage nicht mehr. Dieses Ausschalten auf Seiten der Grafikkarte wurde gerne gemacht, um eben hohe FPS-Zahlen zu erhalten um sich so bessere Verkäufe der Grafikkarten zu erhoffen. Später haben die Leute den Schwindel bemerkt, und die Treiber wurden dann eben angepasst. Das sah dann so aus, dass jeder selbst entscheiden konnte: [] Programmspezifisch [] Vertikale Synhronisation immer an [] Vertikale Synhronisation immer aus - - - Meine Aussage von 2007 muß ich allerdings ändern. Generell halte ich es mitlerweile für nicht mehr sinnvoll, den Timer auf ein möglichst asynchronen Wert zu stellen. Das kommt schon daher, dass heute fast schon jeder einen Flachbildschirm hat, und diese sollten tatsächlich absolut genau 60 FPS machen. Das war bei damaligen CRTs eben nicht so. Die besten Ergebnise erhält man natürlich nach wie for mit Flip 1, wenn da nun leider nicht die hohe Prozessorauslastung wäre. Auch ein Timer - der bei Blitz3D - leider etwas ungenau ist, ist nicht unbedingt die beste visuele Lösung möglich. Weil der Timer dann bei eingestellten 60 FPS tatsächlich 62.5 FPS macht. Eventuell etwas besser das Ergebnis wenn man den Timer auf 58 FPS einstellt. Aber noch besser, wenn man sich einen eigenen Timer mit Delay erstellt und auf 60 FPS laufen lässt. Aber auch hier gibt es ein Problem. Einige Prozessoren (konnte ich leider selbst noch nicht bestätigen) können ein Delay nicht so gut verarbeiten, was zur Folge hat, dass dann bestimmte Prozessoren wieder auf Volllast arbeiten. Also wieder das gleiche Problem wie mit Flip 1. Es bleibt also nichts anderes übrig, als bei Blitz3D den hauseigenen Timer zu benutzen. Oder man lässt den User nach dem Programmstart selbst entscheiden --> ( [VWait] / [Timer] / [Timer experimental] ). Edit1: Achja, selbst wenn man versucht einen Timer vor Flip 1 zu schalten, scheitert der Versuch. Meine Überlegung war: Wenn ein Programm zum Beispiel 300 FPS erreichen könnte, dann muß zu lange auf VWait gewartet werden. Also müsste es besser zu lösen sein, wenn man zuvor einen Prozessorschonenden Timer vorstellt, der so eingestellt ist, dass er kurz vor dem Zeilensprung das Programm weiter führen lässt, aber gleich nach dem Timer eben Flip 1 wartet. Aber egal wie wenige MilliSekunden man da ran geht, die hohe Prozessorauslastung geht maximal auf 50% runter (in Relation ohne Timer). Aber der Zeitraum dazwischen ist dann schon so Eng, dass man dann schon öfers Droped Frames verursacht. Das heisst, der Zeilensprung wurde überflogen und ein ganzes Frame hingt nun das Programm hinterher. Und das sieht dann wirklich beknackt aus. Außerdem habe ich diese Tests nur unter Idealbedingungen ausgeführt. Also ohne Schwankungen die sonst in einem Spiel so auftauchen.

hectic

Sieger des IS Talentwettbewerb 2006

Mi, Okt 28, 2009 21:48
Antworten mit Zitat

Also, wenn es bei dir einen sichtbaren Unterschied zwischen Flip 0 und Flip 1 gibt, dann entspricht meine vorherige Aussage nicht mehr. Dieses Ausschalten auf Seiten der Grafikkarte wurde gerne gemacht, um eben hohe FPS-Zahlen zu erhalten um sich so bessere Verkäufe der Grafikkarten zu erhoffen. Später haben die Leute den Schwindel bemerkt, und die Treiber wurden dann eben angepasst. Das sah dann so aus, dass jeder selbst entscheiden konnte:

[] Programmspezifisch
[] Vertikale Synhronisation immer an
[] Vertikale Synhronisation immer aus

- - -

Meine Aussage von 2007 muß ich allerdings ändern. Generell halte ich es mitlerweile für nicht mehr sinnvoll, den Timer auf ein möglichst asynchronen Wert zu stellen. Das kommt schon daher, dass heute fast schon jeder einen Flachbildschirm hat, und diese sollten tatsächlich absolut genau 60 FPS machen. Das war bei damaligen CRTs eben nicht so.

Die besten Ergebnise erhält man natürlich nach wie for mit Flip 1, wenn da nun leider nicht die hohe Prozessorauslastung wäre. Auch ein Timer - der bei Blitz3D - leider etwas ungenau ist, ist nicht unbedingt die beste visuele Lösung möglich. Weil der Timer dann bei eingestellten 60 FPS tatsächlich 62.5 FPS macht. Eventuell etwas besser das Ergebnis wenn man den Timer auf 58 FPS einstellt. Aber noch besser, wenn man sich einen eigenen Timer mit Delay erstellt und auf 60 FPS laufen lässt. Aber auch hier gibt es ein Problem. Einige Prozessoren (konnte ich leider selbst noch nicht bestätigen) können ein Delay nicht so gut verarbeiten, was zur Folge hat, dass dann bestimmte Prozessoren wieder auf Volllast arbeiten. Also wieder das gleiche Problem wie mit Flip 1.

Es bleibt also nichts anderes übrig, als bei Blitz3D den hauseigenen Timer zu benutzen. Oder man lässt den User nach dem Programmstart selbst entscheiden --> ( [VWait] / [Timer] / [Timer experimental] ).

Edit1: Achja, selbst wenn man versucht einen Timer vor Flip 1 zu schalten, scheitert der Versuch. Meine Überlegung war: Wenn ein Programm zum Beispiel 300 FPS erreichen könnte, dann muß zu lange auf VWait gewartet werden. Also müsste es besser zu lösen sein, wenn man zuvor einen Prozessorschonenden Timer vorstellt, der so eingestellt ist, dass er kurz vor dem Zeilensprung das Programm weiter führen lässt, aber gleich nach dem Timer eben Flip 1 wartet. Aber egal wie wenige MilliSekunden man da ran geht, die hohe Prozessorauslastung geht maximal auf 50% runter (in Relation ohne Timer). Aber der Zeitraum dazwischen ist dann schon so Eng, dass man dann schon öfers Droped Frames verursacht. Das heisst, der Zeilensprung wurde überflogen und ein ganzes Frame hingt nun das Programm hinterher. Und das sieht dann wirklich beknackt aus. Außerdem habe ich diese Tests nur unter Idealbedingungen ausgeführt. Also ohne Schwankungen die sonst in einem Spiel so auftauchen.

	BIG BUG	Mi, Okt 28, 2009 23:43 Antworten mit Zitat
Das Problem mit 2 unterschiedlichen Takten(z.B. CreateTimer und VSync) ist, dass diese nicht synchron laufen und damit kein wirklich brauchbares Ergebnis erzielt werden kann. Ich habe mal probiert mit Delay eine eigene Routine zu basteln, die immer bis kurz vor den VSync wartet um somit dieses lästige Problem mit der Prozesserauslastung zu reduzieren: Code: [AUSKLAPPEN] [EINKLAPPEN] Const vSync = 1 Global gFlipStartTime, gFlipRefreshWait Graphics 800, 600, 32, 2 SetBuffer BackBuffer() CalcRefreshRate() xDir# = 2 Repeat Cls Color 0,0,0 Rect 0,0, GraphicsWidth(), GraphicsHeight() ;FPS fps_fpscnt% = fps_fpscnt% + 1 fps_new_sec% = MilliSecs() If (fps_new_sec% => fps_old_sec% + 1000) fps_fps% = fps_fpscnt% fps_fpscnt% = 0 fps_old_sec% = fps_new_sec% EndIf Color 255,0,0 Rect xPos#, 0, 50, GraphicsHeight() xPos# = xPos# + xDir# If xPos# > GraphicsWidth() - 50 Or xPos# < 0 Then xDir# = -xDir# Color 255,255,255 Text 10, 0, fps_fps% Text 10, 20, gFlipRefreshWait MyFlip(vSync) Until KeyHit(1) Function CalcRefreshRate() Local startTime Local cSubstract = 2 Local cAccuracy = 10 Delay(100);wait some time For i = 0 To cAccuracy If i = 1 Then startTime = MilliSecs() Cls Flip vSync Next gFlipRefreshWait = (MilliSecs() - startTime) / cAccuracy - cSubstract ;set 60 fps if VSync disabled If gFlipRefreshWait <= 0 Then gFlipRefreshWait = 16 End Function Function MyFlip(vSync) Local waitTime ;calc waittime waitTime = gFlipRefreshWait - (MilliSecs() - gFlipStartTime) If waitTime > 0 And gFlipStartTime > 0 Then Delay(waitTime) Flip vSync gFlipStartTime = MilliSecs() End Function Das Ganze kann man hier und da zwar noch besser machen, die CPU-Auslastung wird hier aber schon ganz gut reduziert. Dennoch wird es mit BB-Mitteln immer einen gewissen Restverlust geben. P.S. Das VSync-Prozessorauslastungs-Problem tritt übrigens nicht bei allen Grafikkarten/Treibern auf, kann also sein dass es bei Timbo hier tatsächlich funktioniert.
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Mi, Okt 28, 2009 23:43
Antworten mit Zitat

Das Problem mit 2 unterschiedlichen Takten(z.B. CreateTimer und VSync) ist, dass diese nicht synchron laufen und damit kein wirklich brauchbares Ergebnis erzielt werden kann.

Ich habe mal probiert mit Delay eine eigene Routine zu basteln, die immer bis kurz vor den VSync wartet um somit dieses lästige Problem mit der Prozesserauslastung zu reduzieren:

Code: [AUSKLAPPEN]

Const vSync = 1

Global gFlipStartTime, gFlipRefreshWait

Graphics 800, 600, 32, 2

SetBuffer BackBuffer()

CalcRefreshRate()

xDir# = 2

Repeat

Cls

Color 0,0,0
Rect 0,0, GraphicsWidth(), GraphicsHeight()

;FPS
fps_fpscnt% = fps_fpscnt% + 1
fps_new_sec% = MilliSecs()
If (fps_new_sec% => fps_old_sec% + 1000)
   fps_fps% = fps_fpscnt%
   fps_fpscnt% = 0
   fps_old_sec% = fps_new_sec%
EndIf

Color 255,0,0
Rect xPos#, 0, 50, GraphicsHeight()

xPos# = xPos# + xDir#
If xPos# > GraphicsWidth() - 50 Or xPos# < 0 Then xDir# = -xDir#

Color 255,255,255
Text 10, 0, fps_fps%
Text 10, 20, gFlipRefreshWait

MyFlip(vSync)

Until KeyHit(1)

Function CalcRefreshRate()

Local startTime
Local cSubstract = 2
Local cAccuracy = 10

Delay(100);wait some time

For i = 0 To cAccuracy

   If i = 1 Then startTime = MilliSecs()

   Cls
   Flip vSync

Next

gFlipRefreshWait = (MilliSecs() - startTime) / cAccuracy - cSubstract

;set 60 fps if VSync disabled
If gFlipRefreshWait <= 0 Then gFlipRefreshWait = 16

End Function

Function MyFlip(vSync)

Local waitTime

;calc waittime
waitTime = gFlipRefreshWait - (MilliSecs() - gFlipStartTime)
If waitTime > 0 And gFlipStartTime > 0 Then Delay(waitTime)

Flip vSync

gFlipStartTime = MilliSecs()

End Function

Das Ganze kann man hier und da zwar noch besser machen, die CPU-Auslastung wird hier aber schon ganz gut reduziert. Dennoch wird es mit BB-Mitteln immer einen gewissen Restverlust geben.

P.S. Das VSync-Prozessorauslastungs-Problem tritt übrigens nicht bei allen Grafikkarten/Treibern auf, kann also sein dass es bei Timbo hier tatsächlich funktioniert.

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

Gehe zu Seite Zurück 1, 2

Übersicht

BlitzBasic

Beginners-Corner

Nach Oben

BlitzBasic Portal

Goto/Gosub - Alternative?