Problem mit Frameunabhängigem programieren und FPS

Übersicht

BlitzBasic

Beginners-Corner

	HyDr0x Betreff: Problem mit Frameunabhängigem programieren und FPS	So, Dez 02, 2007 22:29 Antworten mit Zitat
Habe ein Problem, folgendes: Ich dachte Frameunabhängiges programieren wäre wenn man ein Programm immer gleich schnell laufen lassen kann. Also egal mit wieviel FPS. Nach 50 Millisekunden (was ungefähr 20 FPS entsprechen sollte) lasse ich alle Images neu Zeichnen. Der Rest läuft normal weiter. Das funktioniert auch ganz gut. Jetzt frage ich mich allerdings ob mein FPS Zähler nun noch korrekt funktioniert. Hier der Code: Code: [AUSKLAPPEN] [EINKLAPPEN] FPScount = FPScount + 1 If MilliSecs() > lastcheck+1000 fps = fpscount fpscount = 0 lastcheck = MilliSecs() End If vorlast=fps If z100 = 1 Then Text 0, 0, vorlast Der FPS Zähler läuft auch immer durch, ist also vom Timer der Bilder unabhängig wie der Rest vom Code der nichts mit Bilderzeichnen zu tun hat. Wie gesagt, ich frage mich ob der jetzt noch die korrekten FPS anzeigen kann. Kann mir jemand hier die Bestätigung das es funtzt oder nicht geben? PS: Nach einer kleinen Änderung meines Codes bin ich auf sagenhafte 200000 FPS gekommen. Da ich bezweifle das dieser Wert korrekt ist bitte ich um Hilfe ob mein FPS-Messer so korrekt funktioniert.

HyDr0x

Betreff: Problem mit Frameunabhängigem programieren und FPS

So, Dez 02, 2007 22:29
Antworten mit Zitat

Habe ein Problem, folgendes: Ich dachte Frameunabhängiges programieren wäre wenn man ein Programm immer gleich schnell laufen lassen kann. Also egal mit wieviel FPS.
Nach 50 Millisekunden (was ungefähr 20 FPS entsprechen sollte) lasse ich alle Images neu Zeichnen.
Der Rest läuft normal weiter. Das funktioniert auch ganz gut. Jetzt frage ich mich allerdings ob mein FPS Zähler nun noch korrekt funktioniert. Hier der Code:

Code: [AUSKLAPPEN]

FPScount = FPScount + 1
If MilliSecs() > lastcheck+1000
fps = fpscount
fpscount = 0
lastcheck = MilliSecs()
End If
vorlast=fps

If z100 = 1 Then Text 0, 0, vorlast

Der FPS Zähler läuft auch immer durch, ist also vom Timer der Bilder unabhängig wie der Rest vom Code der nichts mit Bilderzeichnen zu tun hat.
Wie gesagt, ich frage mich ob der jetzt noch die korrekten FPS anzeigen kann. Kann mir jemand hier die Bestätigung das es funtzt oder nicht geben?

PS: Nach einer kleinen Änderung meines Codes bin ich auf sagenhafte 200000 FPS gekommen. Da ich bezweifle das dieser Wert korrekt ist bitte ich um Hilfe ob mein FPS-Messer so korrekt funktioniert.

Zuletzt bearbeitet von HyDr0x am Mo, Dez 03, 2007 17:21, insgesamt 3-mal bearbeitet

	BigMaexle	So, Dez 02, 2007 23:27 Antworten mit Zitat
Code: [AUSKLAPPEN] [EINKLAPPEN] Anfang = MilliSecs () Repeat Frame = Frame +1 Aktuell = MilliSecs () If Aktuell - Anfang > 1000 Then Anfang=MilliSecs () FPS=Frame Frame=0 Print Fps EndIf Until KeyHit(1) (Ich hab AMD Athlon 3200+) Ich komm auf ca. 308.000 FPS Also sind 200.000 bei nem Starken PC und wenig Arbeit durchaus dirn
-------------------------------------- Ich bin unfreiwillig ein Mitglied dieser kapitalistischen Gesellschaft, wo jeder Geldgeile Unternehmer an mein Geld will und ich selbst bei meinen Entscheidungen so gut wie willenlos bin...... und ich bin glücklich drüber

BigMaexle

So, Dez 02, 2007 23:27
Antworten mit Zitat

Code: [AUSKLAPPEN]

Anfang = MilliSecs ()

Repeat

Frame = Frame +1

Aktuell = MilliSecs ()

If Aktuell - Anfang > 1000 Then
Anfang=MilliSecs ()
FPS=Frame
Frame=0
Print Fps
EndIf

Until KeyHit(1)

(Ich hab AMD Athlon 3200+)

Ich komm auf ca. 308.000 FPS
Also sind 200.000 bei nem Starken PC und wenig Arbeit durchaus dirn

--------------------------------------
Ich bin unfreiwillig ein Mitglied dieser kapitalistischen Gesellschaft, wo jeder Geldgeile Unternehmer an mein Geld will und ich selbst bei meinen Entscheidungen so gut wie willenlos bin...... und ich bin glücklich drüber

	Eingeproggt	So, Dez 02, 2007 23:47 Antworten mit Zitat
Da ich mir nicht vorstellen kann, dass mein Intel P4 HT mit 3,4GHz 10mal besser ist als eure, würd ich sagen, ihr habt euch verguckt Ich bring nämlich mit Maexles Code über 3,7Mio "Frames" zusammen. Aber eig sind das keine Frames sondern nur Schleifendurchläufe. Es wird ja nix angezeigt. mfG, Christoph.
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

So, Dez 02, 2007 23:47
Antworten mit Zitat

Da ich mir nicht vorstellen kann, dass mein Intel P4 HT mit 3,4GHz 10mal besser ist als eure, würd ich sagen, ihr habt euch verguckt Smile

Ich bring nämlich mit Maexles Code über 3,7Mio "Frames" zusammen. Aber eig sind das keine Frames sondern nur Schleifendurchläufe. Es wird ja nix angezeigt.

mfG, Christoph.

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	hectic Sieger des IS Talentwettbewerb 2006	Mo, Dez 03, 2007 0:03 Antworten mit Zitat
Boah, mom hoseaufmach Ich habe in keinem meiner Durchläfe weniger als 8 milionen Durchläufe. Aber wie gesagt, sind es nur Durchläfe und keine Frames. Der Grund warum ich nun antworte ist folgender. Frameunabhängiges Programmieren ist nicht, die Framezahl auf ein festen Wert zu setzen, sondern aufgrund veränderter FPS-Werte immer die gleiche Anzeigegeschwindigkeit zu erhalten. Es ist also genau das Gegenteil von dem, was du da machst. Dieses muss allerdings nicht unbedingt auch schlechter sein. Frameunabhängiges Programmieren wird meistens dann gemacht, wenn man ein Spiel hat, welches in seinem technischem Aufwand (Recourcen) sehr Hoch ist, und viele Frames pro Sekunde wichtig sind. Zum Beispiel Ego-Shooter. Die Spielbewegung wird anhand der letzten Framedauer skalliert. Frameabhängiges Programmieren wird meisten dann gemacht, wenn man ein Spiel hat, welches auch auf älteren Rechner gespielt werden kann und keine extrem hohen FPS notwendig sind. Also dann, wenn auch alte Rechner die benötigten FPS-Werte vermutlich liefern können. Zum Beispiel Jump&Run. https://www.blitzforum.de/foru...ce44b28b25
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

hectic

Sieger des IS Talentwettbewerb 2006

Mo, Dez 03, 2007 0:03
Antworten mit Zitat

Boah, mom *hoseaufmach* Ich habe in keinem meiner Durchläfe weniger als 8 milionen Durchläufe. Aber wie gesagt, sind es nur Durchläfe und keine Frames. Der Grund warum ich nun antworte ist folgender. Frameunabhängiges Programmieren ist nicht, die Framezahl auf ein festen Wert zu setzen, sondern aufgrund veränderter FPS-Werte immer die gleiche Anzeigegeschwindigkeit zu erhalten. Es ist also genau das Gegenteil von dem, was du da machst. Dieses muss allerdings nicht unbedingt auch schlechter sein.

Frameunabhängiges Programmieren wird meistens dann gemacht, wenn man ein Spiel hat, welches in seinem technischem Aufwand (Recourcen) sehr Hoch ist, und viele Frames pro Sekunde wichtig sind. Zum Beispiel Ego-Shooter. Die Spielbewegung wird anhand der letzten Framedauer skalliert.

Frameabhängiges Programmieren wird meisten dann gemacht, wenn man ein Spiel hat, welches auch auf älteren Rechner gespielt werden kann und keine extrem hohen FPS notwendig sind. Also dann, wenn auch alte Rechner die benötigten FPS-Werte vermutlich liefern können. Zum Beispiel Jump&Run.

https://www.blitzforum.de/foru...ce44b28b25

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

	BigMaexle	Mo, Dez 03, 2007 0:11 Antworten mit Zitat
Leute ich hab mich verguckt 3.080.000 Durchläufe Wer Zahlen lesen kann is klar im Vorteil
-------------------------------------- Ich bin unfreiwillig ein Mitglied dieser kapitalistischen Gesellschaft, wo jeder Geldgeile Unternehmer an mein Geld will und ich selbst bei meinen Entscheidungen so gut wie willenlos bin...... und ich bin glücklich drüber

BigMaexle

Mo, Dez 03, 2007 0:11
Antworten mit Zitat

Leute ich hab mich verguckt Laughing

3.080.000 Durchläufe

Wer Zahlen lesen kann is klar im Vorteil Embarassed

	HyDr0x Betreff: Re: Problem mit Frameunabhängigem programieren und FPS	Mo, Dez 03, 2007 7:33 Antworten mit Zitat
Sry Leute, habe mein Problem warscheinlich ein wenig schlecht erklärt. Wenn ich den Zähler einfach so durchrattern ließe und auf 200000 FPS gekommen wär hätt ich mich höchstens gewundert warum meine Kiste net mehr schafft . Zitat: Ich dachte Frameunabhängiges programieren wäre wenn man ein Programm immer gleich schnell laufen lassen kann. Also egal mit wieviel FPS. Jetzt frage ich mich warum dass, das Gegenteil ist von dem was du mir erklärt hast ... Zitat: Nach 50 Millisekunden (was ungefähr 20 FPS entsprechen sollte) lasse ich alle Images neu Zeichnen. Ich habe keine Ahnung was ihr für Images bei euren Tests genommen habt, aber entweder es müssen ganz ganz kleine und wenige gewesen sein oder ihr habt Rechner der nächsten Generation ... Jetzt noch ein Paar konzentrierte Hinweise darauf das ich nicht nur Images hab zeichnen lassen: Zitat: Der Rest läuft normal weiter. Das funktioniert auch ganz gut. Jetzt frage ich mich allerdings ob mein FPS Zähler nun noch korrekt funktioniert. Hier der Code: Zitat: Der FPS Zähler läuft auch immer durch, ist also vom Timer der Bilder unabhängig wie der Rest vom Code der nichts mit Bilderzeichnen zu tun hat. Zitat: Wie gesagt, ich frage mich ob der jetzt noch die korrekten FPS anzeigen kann. Kann mir jemand hier die Bestätigung das es funtzt oder nicht geben? Mit Bestätigung meinte ich ob mir jmd. ganz theoretisch, weil er z.B. auch schon Erfahrung auf dem Gebiet hat, sagen kann ob da ein FPS Zähler noch was bringt. Hatte insgeheim auf Hectic gehofft, da ich mit ihm schon früher in einem anderen Thread darüber geredet hatte ... Nun zum Abschluss des Threads zu dem ich nichts weiteres sage als die Lösung meines Problems, die mir gestern Abend im all abendlichen grübeln gekommen ist. Zitat: PS: Nach einer kleinen Änderung meines Codes bin ich auf sagenhafte 200000 FPS gekommen. Da ich bezweifle das dieser Wert korrekt ist bitte ich um Hilfe ob mein FPS-Messer so korrekt funktioniert. Die FPS die ich da gemessen habe waren die Durchläufe im Leerlauf, also in dem Moment wenn mein PC nur noch den Grundcode durchlaufen lässt ohne die Bilder oder sonstige Bildschirmausgabe. Eben die Zeit die mein PC schneller ist als 20 FPS und sozusagen im Moment nichts zu tun hat. Wenn ich die FPS in dem Durchgang messen lasse in dem die Bilder gezeichnet werden komme ich auf ca. 4000 FPS, was ja auch schon ganz gut ist . Das heisst: Mein game (oder Techdemogame ) läuft auf meinem PC mit 4000 FPS. Ich finde das für 2D schon ganz ordentlich, wenn diese Angabe stimmt. Deswegen, würde ich mich freuen, wenn mir jmd., ganz theoretisch, bestätigen könnte, dass es möglich ist, in einem frameunabhängig programierten Spiel die FPS mit dem oben genannten Code, zu messen. Edit Ich versteh die Welt net mehr, gestern als ich meinen PC schon ein wenig gestrietzt hatte brachte er in dem von mir vermuteten Leerlauf 240000 FPS Spitze. Jetzt, nachdem er nurn paar Minütchen an ist, sinds nur noch die Hälfte und selbst das noch nichteinmal. Höchstens 100000 FPS, und wenn ich nun aber nicht den von mir vermuteten Leerlauf messen lasse sinds unglaubliche 10000 FPS statt 4000 FPS. Ich lade den Code am besten mal hoch, denn ich weiß nicht mehr weiter. Ihr könnt mir ja dann sagen wie hoch eure Werte so sind. OMG wollte gerade die FPS im vermuteten Leerlauf anzeigen und die FPS im Nichtleerlauf, beide Werte waren GLEICH. Lasse ich einen von beiden Werten nicht anzeigen z.B. den wo ich denke das Bilder gezeichnet werden, also Nichtleerlauf dann schiesst der Wert des Leerlaufs wieder auf 100000 FPS. Deswegen werde ich in der Uploadversion nur eine von beiden Varianten nehmen und zwar die des Nichtleeraufs. Jetzt ist der Nichtleerlauf nur noch 1800 FPS Langsam hab ich das Gefühl, dass immer wenn ich das Programm mal neu starte er mir was andres anzeigt. EDIT: OK ich weiß warums keine 200000 FPS mehr sind, es lag am Debugmodus , der andre Wert ist noch gleich gewesen viell. ists nachm compillieren anners, akanns net mehr testen muss mich beeilen hab keine Zeit mehr. HIER DER LINK https://www.blitzforum.de/upload/file.php?id=2440

HyDr0x

Betreff: Re: Problem mit Frameunabhängigem programieren und FPS

Mo, Dez 03, 2007 7:33
Antworten mit Zitat

Sry Leute, habe mein Problem warscheinlich ein wenig schlecht erklärt. Wenn ich den Zähler einfach so durchrattern ließe und auf 200000 FPS gekommen wär hätt ich mich höchstens gewundert warum meine Kiste net mehr schafft Wink

.

Zitat:

Ich dachte Frameunabhängiges programieren wäre wenn man ein Programm immer gleich schnell laufen lassen kann. Also egal mit wieviel FPS.

Jetzt frage ich mich warum dass, das Gegenteil ist von dem was du mir erklärt hast ...

Zitat:

Nach 50 Millisekunden (was ungefähr 20 FPS entsprechen sollte) lasse ich alle Images neu Zeichnen.

Ich habe keine Ahnung was ihr für Images bei euren Tests genommen habt, aber entweder es müssen ganz ganz kleine und wenige gewesen sein oder ihr habt Rechner der nächsten Generation ...

Jetzt noch ein Paar konzentrierte Hinweise darauf das ich nicht nur Images hab zeichnen lassen:

Zitat:

Der Rest läuft normal weiter. Das funktioniert auch ganz gut. Jetzt frage ich mich allerdings ob mein FPS Zähler nun noch korrekt funktioniert. Hier der Code:

Zitat:

Der FPS Zähler läuft auch immer durch, ist also vom Timer der Bilder unabhängig wie der Rest vom Code der nichts mit Bilderzeichnen zu tun hat.

Zitat:

Wie gesagt, ich frage mich ob der jetzt noch die korrekten FPS anzeigen kann. Kann mir jemand hier die Bestätigung das es funtzt oder nicht geben?

Mit Bestätigung meinte ich ob mir jmd. ganz theoretisch, weil er z.B. auch schon Erfahrung auf dem Gebiet hat, sagen kann ob da ein FPS Zähler noch was bringt. Hatte insgeheim auf Hectic gehofft, da ich mit ihm schon früher in einem anderen Thread darüber geredet hatte ...

Nun zum Abschluss des Threads zu dem ich nichts weiteres sage als die Lösung meines Problems, die mir gestern Abend im all abendlichen grübeln gekommen ist.
Zitat:

PS: Nach einer kleinen Änderung meines Codes bin ich auf sagenhafte 200000 FPS gekommen. Da ich bezweifle das dieser Wert korrekt ist bitte ich um Hilfe ob mein FPS-Messer so korrekt funktioniert.

Die FPS die ich da gemessen habe waren die Durchläufe im Leerlauf, also in dem Moment wenn mein PC nur noch den Grundcode durchlaufen lässt ohne die Bilder oder sonstige Bildschirmausgabe. Eben die Zeit die mein PC schneller ist als 20 FPS und sozusagen im Moment nichts zu tun hat. Wenn ich die FPS in dem Durchgang messen lasse in dem die Bilder gezeichnet werden komme ich auf ca. 4000 FPS, was ja auch schon ganz gut ist Very Happy

.

Das heisst: Mein game (oder Techdemogame Very Happy

) läuft auf meinem PC mit 4000 FPS. Ich finde das für 2D schon ganz ordentlich, wenn diese Angabe stimmt. Deswegen, würde ich mich freuen, wenn mir jmd., ganz theoretisch, bestätigen könnte, dass es möglich ist, in einem frameunabhängig programierten Spiel die FPS mit dem oben genannten Code,
zu messen.

Edit Ich versteh die Welt net mehr, gestern als ich meinen PC schon ein wenig gestrietzt hatte brachte er in dem von mir vermuteten Leerlauf 240000 FPS Spitze. Jetzt, nachdem er nurn paar Minütchen an ist, sinds nur noch die Hälfte und selbst das noch nichteinmal. Höchstens 100000 FPS, und wenn ich nun aber nicht den von mir vermuteten Leerlauf messen lasse sinds unglaubliche 10000 FPS statt 4000 FPS. Ich lade den Code am besten mal hoch, denn ich weiß nicht mehr weiter. Ihr könnt mir ja dann sagen wie hoch eure Werte so sind.

OMG wollte gerade die FPS im vermuteten Leerlauf anzeigen und die FPS im Nichtleerlauf, beide Werte waren GLEICH. Lasse ich einen von beiden Werten nicht anzeigen z.B. den wo ich denke das Bilder gezeichnet werden, also Nichtleerlauf dann schiesst der Wert des Leerlaufs wieder auf 100000 FPS. Deswegen werde ich in der Uploadversion nur eine von beiden Varianten nehmen und zwar die des Nichtleeraufs.

Jetzt ist der Nichtleerlauf nur noch 1800 FPS Confused

Langsam hab ich das Gefühl, dass immer wenn ich das Programm mal neu starte er mir was andres anzeigt.

EDIT: OK ich weiß warums keine 200000 FPS mehr sind, es lag am Debugmodus Very Happy

, der andre Wert ist noch gleich gewesen viell. ists nachm compillieren anners, akanns net mehr testen muss mich beeilen hab keine Zeit mehr.

HIER DER LINK https://www.blitzforum.de/upload/file.php?id=2440

	hectic Sieger des IS Talentwettbewerb 2006	Mo, Dez 03, 2007 13:32 Antworten mit Zitat
Hmmm, OK. Ich könnte schwören, dass der Nachtragsatz ''Also egal mit wieviel FPS.'' da noch nicht stand, oder ich zum Zeitpunkt grad diesen überlesen hatte. Damit stimmt natürlich deine Aussage. Als Tipp kann ich dir noch geben: Es ergibt kein Sinn, ein Programm mit 4000 FPS zu durchlaufen. Für das beste halte ich eine Kombination aus auf Frameunabhängigem programmieren und einem Framelimiter. Schafft der Rechner die geforderten FPS nicht mehr, greift automatisch das frameunabhängige, und ist der Rechner schneller als nötig, so wird er einfach abgebremst. Und anders als ich noch vor ein paar Monaten beschrieben habe, sollte man immer Flip 0 nutzen, da Blitz sonst volle Auslastung dem Prozessor dranhängt. Diese ist schade, da nur mit Flip 1 es möglich ist, ein wirklich sanftes und perfektes Bild anzuzeigen. Um deine ursprüngliche Frage mal zu beantworten. Dein Code zeigt nahezu richtig die FPS an (bei mir ist es immer ein FPS zu viel bei deinem Code). Ich habe mal (weil es mal eine Disskusion darüber gab ''blaa, bla blaaa''), ein paar FPS-Umrechnemöglichkeiten ausprobiert und es hat sich folgendes für mich als bestes erwiesen: Code: [AUSKLAPPEN] [EINKLAPPEN] Text 20,20,fps:msc=MilliSecs() If msc>mts Then mts=msc+1001:fps=frm:frm=0 Else frm=frm+1 Falls du noch andere Möglichkeiten sehen willst, so hier die Codes von anderen Leuten: Code: [AUSKLAPPEN] [EINKLAPPEN] Graphics 400,300,0,2 SetBuffer BackBuffer() timer=CreateTimer(200) ;PRÄZISE mt2=MilliSecs() ;STEPTIGER'S ff#=0 time=MilliSecs() ;Hauptschleife While Not KeyHit(1) If KeyHit(57) Then w=1-w If w=1 Then Delay 10 ;STANDARDVERSION Text 20,20,fps:msc=MilliSecs() If msc>mts Then mts=msc+1001:fps=frm:frm=0 Else frm=frm+1 ; ;STANDARDVERSION DOPPELT SCHNELL ; msh=MilliSecs():Text 20,40,frh ; If msh>mth Then mth=msh+502:frh=zah:zah=0 Else zah=zah+2 ;PRÄZISE VERSION (TESTVERSION) Text 20,60,fps2 If MilliSecs()>mt2 Then mt2=mt2+1000:fps2=frame2:frame2=1 Else frame2=frame2+1 ; ;GETFPS ; frm=frm+1 ; Text 120,20,fps ; msc=MilliSecs() ; If msc>mts Then ; mts=msc+1001 ; fps=frm ; frm=-1 ; End If ;FREMDFUNKTION Framecounter_counter=Framecounter_counter+1 If Framecounter_time=0 Then Framecounter_time=MilliSecs() If Framecounter_time+1001<MilliSecs() Then Framecounter_framerate=Framecounter_counter Framecounter_counter=0 Framecounter_time=MilliSecs() EndIf Text 20,100,Framecounter_framerate ;ZEITNAHE VERSION fps1=1000.0/(MilliSecs()-ms1) ms1=MilliSecs() Text 20,120,fps1 ;STEPTIGER'S ff#=ff+1 Text 20,140,ff/(MilliSecs()-time)1000 WaitTimer (timer) Flip 0 Cls Wend End Mit SPACE kannst du den Rechner ''auslasten'', um zu sehen wie die FPS-Rechnungen darauf reagieren. Wie du bei einigen sehen kannst, sind die Werte etwas unterschiedlich. Beispiele: Während die ersten nach spätestens einer Sekunde die richtigen Werte liefern, liefert die ;ZEITNAHE VERSION* sofort ein Wert. Allerdings kann man beim testen in einem Spiel die stark schwankenden Werte nicht mehr lesen, daher bleibt die Version zumindest im Realtest nicht zu gebrauchen. Die Version von ;STEPTIGER'S zeigt sogar Nachkommastellen an, ist somit sehr ''genau'', doch wird hier der Wert immer nur angeglichen. Das bedeutet, wenn du zwischendurch SPACE drückst, so braucht die Version biszu zwei Minuten, bis sie mal richtige Werte anzeigt. Auch diese Version ist für den Realtest nicht zu gebrauchen. Die anderen unterscheiden sich lediglich von +/- 1 FPS, was ich versucht habe genau zu machen. Die erste sollte genau sein.^^ Die ;PRÄZISE VERSION sollte eventuelle (Steptiger's Behauptung) Problemberechnungen bei sehr großen Werten beheben. Es blieb aber dabei, dass es meiner Meinung nach keine Probleme mit der Rechnung gibt. Man kann auch unschwer erkennen, dass ;PRÄZISE und ;STEPTIGER'S jeweils eine Vorbereitungszeile vor dem Mainloop benötigen, was das schnelle Copy&Paste erschwert. Ich kopiere mir immer die zwei Teilen mal so schnell, um mal eben die FPS-Werte zu testen (mitlerweile habe ich aber Fraps installiert (auch gut)). Frage nur noch. Nutzt du deinen Code auch für die Geschwindigkeitsskallierung deiner Objekte? Rechnest du diese anhand deiner FPS-Werte um, oder hast du dafür eine andere Methode? Denn, die Geschwindigkeitsskallierung wird nicht mithilfe der FPS-Werte berechnet, sondern der Dauer der letzten Programmschleife. Man nimmt sich also eine Stelle frei im Code (zum Beispiel am Anfang einer Codeschleife), und speichert dort den aktuellen Millisekundenwert ab, beim nächsten Schleifendurchlauf wird die Differenz zwischen beiden in eine Variable gepackt. Diese Variable wird nun auf alle bewegenden Objekten drauf multipliziert.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

hectic

Sieger des IS Talentwettbewerb 2006

Mo, Dez 03, 2007 13:32
Antworten mit Zitat

Hmmm, OK. Ich könnte schwören, dass der Nachtragsatz ''Also egal mit wieviel FPS.'' da noch nicht stand, oder ich zum Zeitpunkt grad diesen überlesen hatte. Damit stimmt natürlich deine Aussage. Als Tipp kann ich dir noch geben: Es ergibt kein Sinn, ein Programm mit 4000 FPS zu durchlaufen. Für das beste halte ich eine Kombination aus auf Frameunabhängigem programmieren und einem Framelimiter. Schafft der Rechner die geforderten FPS nicht mehr, greift automatisch das frameunabhängige, und ist der Rechner schneller als nötig, so wird er einfach abgebremst. Und anders als ich noch vor ein paar Monaten beschrieben habe, sollte man immer Flip 0 nutzen, da Blitz sonst volle Auslastung dem Prozessor dranhängt. Diese ist schade, da nur mit Flip 1 es möglich ist, ein wirklich sanftes und perfektes Bild anzuzeigen.

Um deine ursprüngliche Frage mal zu beantworten. Dein Code zeigt nahezu richtig die FPS an (bei mir ist es immer ein FPS zu viel bei deinem Code). Ich habe mal (weil es mal eine Disskusion darüber gab ''blaa, bla blaaa''), ein paar FPS-Umrechnemöglichkeiten ausprobiert und es hat sich folgendes für mich als bestes erwiesen:

Code: [AUSKLAPPEN]

Text 20,20,fps:msc=MilliSecs()
If msc>mts Then mts=msc+1001:fps=frm:frm=0 Else frm=frm+1

Falls du noch andere Möglichkeiten sehen willst, so hier die Codes von anderen Leuten:

Code: [AUSKLAPPEN]

Graphics 400,300,0,2
SetBuffer BackBuffer()
timer=CreateTimer(200)

;PRÄZISE
mt2=MilliSecs()

;STEPTIGER'S
ff#=0
time=MilliSecs()

;Hauptschleife
While Not KeyHit(1)

If KeyHit(57) Then w=1-w
If w=1 Then Delay 10

;STANDARDVERSION
Text 20,20,fps:msc=MilliSecs()
If msc>mts Then mts=msc+1001:fps=frm:frm=0 Else frm=frm+1

; ;STANDARDVERSION DOPPELT SCHNELL
; msh=MilliSecs():Text 20,40,frh
; If msh>mth Then mth=msh+502:frh=zah:zah=0 Else zah=zah+2

;PRÄZISE VERSION (TESTVERSION)
Text 20,60,fps2
If MilliSecs()>mt2 Then mt2=mt2+1000:fps2=frame2:frame2=1 Else frame2=frame2+1

; ;GETFPS
; frm=frm+1
; Text 120,20,fps
; msc=MilliSecs()
; If msc>mts Then
;    mts=msc+1001
;    fps=frm
;    frm=-1
; End If

;FREMDFUNKTION
Framecounter_counter=Framecounter_counter+1
If Framecounter_time=0 Then Framecounter_time=MilliSecs()
If Framecounter_time+1001<MilliSecs() Then
   Framecounter_framerate=Framecounter_counter
   Framecounter_counter=0
   Framecounter_time=MilliSecs()
EndIf
Text 20,100,Framecounter_framerate

;ZEITNAHE VERSION
fps1=1000.0/(MilliSecs()-ms1)
ms1=MilliSecs()
Text 20,120,fps1

;STEPTIGER'S
ff#=ff+1
Text 20,140,ff/(MilliSecs()-time)*1000

WaitTimer (timer)
Flip 0
Cls
Wend
End

Mit SPACE kannst du den Rechner ''auslasten'', um zu sehen wie die FPS-Rechnungen darauf reagieren. Wie du bei einigen sehen kannst, sind die Werte etwas unterschiedlich. Beispiele: Während die ersten nach spätestens einer Sekunde die richtigen Werte liefern, liefert die ;ZEITNAHE VERSION sofort ein Wert. Allerdings kann man beim testen in einem Spiel die stark schwankenden Werte nicht mehr lesen, daher bleibt die Version zumindest im Realtest nicht zu gebrauchen. Die Version von ;STEPTIGER'S zeigt sogar Nachkommastellen an, ist somit sehr ''genau'', doch wird hier der Wert immer nur angeglichen. Das bedeutet, wenn du zwischendurch SPACE drückst, so braucht die Version biszu zwei Minuten, bis sie mal richtige Werte anzeigt. Auch diese Version ist für den Realtest nicht zu gebrauchen. Die anderen unterscheiden sich lediglich von +/- 1 FPS, was ich versucht habe genau zu machen. Die erste sollte genau sein.^^ Die ;PRÄZISE VERSION sollte eventuelle (Steptiger's Behauptung) Problemberechnungen bei sehr großen Werten beheben. Es blieb aber dabei, dass es meiner Meinung nach keine Probleme mit der Rechnung gibt. Man kann auch unschwer erkennen, dass ;PRÄZISE und ;STEPTIGER'S jeweils eine Vorbereitungszeile vor dem Mainloop benötigen, was das schnelle Copy&Paste erschwert. Ich kopiere mir immer die zwei Teilen mal so schnell, um mal eben die FPS-Werte zu testen (mitlerweile habe ich aber Fraps installiert (auch gut)).

Frage nur noch. Nutzt du deinen Code auch für die Geschwindigkeitsskallierung deiner Objekte? Rechnest du diese anhand deiner FPS-Werte um, oder hast du dafür eine andere Methode? Denn, die Geschwindigkeitsskallierung wird nicht mithilfe der FPS-Werte berechnet, sondern der Dauer der letzten Programmschleife. Man nimmt sich also eine Stelle frei im Code (zum Beispiel am Anfang einer Codeschleife), und speichert dort den aktuellen Millisekundenwert ab, beim nächsten Schleifendurchlauf wird die Differenz zwischen beiden in eine Variable gepackt. Diese Variable wird nun auf alle bewegenden Objekten drauf multipliziert.

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

	Foppele	Mo, Dez 03, 2007 15:33 Antworten mit Zitat
hectic hat Folgendes geschrieben: Diese Variable wird nun auf alle bewegenden Objekten drauf multipliziert. Jep, das kenn ich noch von C-lite, da gibts einen extra Befehl (timestep), das ist glaube ich die einzige richtige Möglichkeit, auf verschiedenen Rechnern eine gleichbleibende Spielgeschwindigkeit zu erreichen.

Foppele

Mo, Dez 03, 2007 15:33
Antworten mit Zitat

hectic hat Folgendes geschrieben:

Diese Variable wird nun auf alle bewegenden Objekten drauf multipliziert.

Jep, das kenn ich noch von C-lite, da gibts einen extra Befehl (timestep), das ist glaube ich die einzige richtige
Möglichkeit, auf verschiedenen Rechnern eine gleichbleibende Spielgeschwindigkeit zu erreichen.

	ozzi789	Mo, Dez 03, 2007 15:51 Antworten mit Zitat
Also ich hab mit dem alten frame zähler 5593673 (maximal) bekommen
0x2B \|\| ! 0x2B C# \| C++13 \| Java 7 \| PHP 5

ozzi789

Mo, Dez 03, 2007 15:51
Antworten mit Zitat

Also ich hab mit dem alten frame zähler 5593673 (maximal) bekommen Razz

0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

	HyDr0x	Mo, Dez 03, 2007 16:37 Antworten mit Zitat
hectic hat Folgendes geschrieben: Hmmm, OK. Ich könnte schwören, dass der Nachtragsatz ''Also egal mit wieviel FPS.'' da noch nicht stand, oder ich zum Zeitpunkt grad diesen überlesen hatte. Damit stimmt natürlich deine Aussage. Als Tipp kann ich dir noch geben: Es ergibt kein Sinn, ein Programm mit 4000 FPS zu durchlaufen. Ich bin zwar ein großer Freund des Editbuttons, aber die Methode etwas absichtlich in meinen Post einzufügen um meine Rhetorik zu Unterstützen praktiziere ich nicht. Wie gesagt es ist nur ne Techdemo um zu sehen wieviel Geschwindigkeit ich rausholen kann. Werde es aber warscheinlich nicht in dieser Form überall anwenden, da ich ohne Double Buffering arbeite. Was ich mich allerdings noch Frage ist warum Windows oder generell die Hardware, Frameunabhängiges Programieren ohne Timer im Fenstermodus nicht zulässt. Wird da der Windowsbuffer verwendet bzw. kontrolliert Windows da den Programmablauf? (ähnlich wie die Farbtiefe) hectic hat Folgendes geschrieben: Frage nur noch. Nutzt du deinen Code auch für die Geschwindigkeitsskallierung deiner Objekte? Rechnest du diese anhand deiner FPS-Werte um, oder hast du dafür eine andere Methode? Denn, die Geschwindigkeitsskallierung wird nicht mithilfe der FPS-Werte berechnet, sondern der Dauer der letzten Programmschleife. Man nimmt sich also eine Stelle frei im Code (zum Beispiel am Anfang einer Codeschleife), und speichert dort den aktuellen Millisekundenwert ab, beim nächsten Schleifendurchlauf wird die Differenz zwischen beiden in eine Variable gepackt. Diese Variable wird nun auf alle bewegenden Objekten drauf multipliziert. (Mein vorheriger Post war an dieser Stelle falsch) EDIT: Ich lasse am Anfang des Codes die Zeit mit Millisecs messen, dann lasse ich mit einer anderen Variable den Abstand messen. (Bei mir muss der Abstand größer als 50 Ms sein also 20 FPS kleiner ruckelts) Wenn der Abstand 0 oder kleiner ist dann wird eine andere Variable umgeschalten und der Code (also Objekte werden bewegt und gezeichnet) läuft einmal durch. Der Code der für die Eingabe oder andere Aufgaben (ausgenommen das Zeichnen und bewegen) zuständig ist wird immer durchlaufen (in meinem Falle mit einer Geschwindigkeit von 200000 FPS). Das heisst wenn ein REchner schneller läuft als die geforderten mindest FPS (hier 20 da 50 ms Abstand) ist er im "Leerlaufmodus", schafft ein Rechner die 20 FPS nicht, ruckelt das game ein wenig. Ich habe es schon mit Framelimitern probiert, es läuft immer gleichschnell. Also funktionierts nehme ich an (Download steht ja bereit zum Selbertesten). Ich denke aber das 20 FPS sowieso Minimum sind, und wenn es mein 2.53 Ghz mit 4000 FPS schafft müsste es doch auch ein Pentium 1 mit 166 Mhz schaffen und das reicht denke ich mal völlig aus . Ansonsten kann man die Zeitspanne ja auch noch erhöhen, dann könnte es allerdings wieder ruckeln, da das Programm ja dann unter 20 FPS läuft und da ruckelts ja meistens. Ich überlege mir gerade, ob ich, wenn der Rechner im Leerlauf ist und mit 200000 FPS durchrattert, ihn dann nicht andere Aufgaben zukommen lassen könnte, z.B. sehr Rechenintensive Sachen. Dann könnte er im Hintergrund irgendwas Laden. Ich werde auf jedenfall mit der Methode noch ein wenig rumspielen, schließlich ha ich jetzt 4000 FPS zum verpulvern ^^ und das ohne 3D. Kleiner Schlusssatz: Das game müsste somit auf jedem Rechner mit 20 trueFPS laufen. Edit: Mir ist gerade eingefallen, dass das was ich hier fabriziere kein echtes Frameunabhängiges programieren ist, da das Programm immer mit 20 FPS durchleuft und der Rest nur gefaked ist. Aber danke für den Tipp mit dem multiplizieren der Frames, ich werd versuchen des mal umzusetzten. Edit: Lasse die bewegenden Objekte jetzt mit dem von dir beschriebenen Multiplikator berechnen. Funtzt soweit ganz gut, nur die Sprungfunkton macht Probleme. Wenn ich da jetzt einen Frametimer reinbaue frage ich mich allerdings was da der große Unterschied zwischen meiner vorherigen Methode und der hier ist. Bei der vorherigen wurde eben nur alle 50 ms gezeichnet und nicht immer was theoretisch einem Timer von 20 FPS entspricht. (man könnte ihn nat. auch erhöhen) Mit dem frameunabhängigem Programieren lasse ich das Prog so schnell durchratter wie möglich (wenn ich keinen Timer verwende) und hab aber auch nicht mehr gewonnen als vorher, nur das die Bilder eben öfters gezeichnet werden wenn ich keinen Timer setzte, was das menschl. Auge aber auch nicht wirklich wahrnimmt. (ich zumindest sehe keinen Unterschied)

HyDr0x

Mo, Dez 03, 2007 16:37
Antworten mit Zitat

hectic hat Folgendes geschrieben:

Ich bin zwar ein großer Freund des Editbuttons, aber die Methode etwas absichtlich in meinen Post einzufügen um meine Rhetorik zu Unterstützen praktiziere ich nicht.
Wie gesagt es ist nur ne Techdemo um zu sehen wieviel Geschwindigkeit ich rausholen kann. Werde es aber warscheinlich nicht in dieser Form überall anwenden, da ich ohne Double Buffering arbeite.
Was ich mich allerdings noch Frage ist warum Windows oder generell die Hardware, Frameunabhängiges Programieren ohne Timer im Fenstermodus nicht zulässt. Wird da der Windowsbuffer verwendet bzw. kontrolliert Windows da den Programmablauf? (ähnlich wie die Farbtiefe)

hectic hat Folgendes geschrieben:

Frage nur noch. Nutzt du deinen Code auch für die Geschwindigkeitsskallierung deiner Objekte? Rechnest du diese anhand deiner FPS-Werte um, oder hast du dafür eine andere Methode? Denn, die Geschwindigkeitsskallierung wird nicht mithilfe der FPS-Werte berechnet, sondern der Dauer der letzten Programmschleife. Man nimmt sich also eine Stelle frei im Code (zum Beispiel am Anfang einer Codeschleife), und speichert dort den aktuellen Millisekundenwert ab, beim nächsten Schleifendurchlauf wird die Differenz zwischen beiden in eine Variable gepackt. Diese Variable wird nun auf alle bewegenden Objekten drauf multipliziert.

(Mein vorheriger Post war an dieser Stelle falsch) EDIT: Ich lasse am Anfang des Codes die Zeit mit Millisecs messen, dann lasse ich mit einer anderen Variable den Abstand messen. (Bei mir muss der Abstand größer als 50 Ms sein also 20 FPS kleiner ruckelts) Wenn der Abstand 0 oder kleiner ist dann wird eine andere Variable umgeschalten und der Code (also Objekte werden bewegt und gezeichnet) läuft einmal durch. Der Code der für die Eingabe oder andere Aufgaben (ausgenommen das Zeichnen und bewegen) zuständig ist wird immer durchlaufen (in meinem Falle mit einer Geschwindigkeit von 200000 FPS). Das heisst wenn ein REchner schneller läuft als die geforderten mindest FPS (hier 20 da 50 ms Abstand) ist er im "Leerlaufmodus", schafft ein Rechner die 20 FPS nicht, ruckelt das game ein wenig. Ich habe es schon mit Framelimitern probiert, es läuft immer gleichschnell. Also funktionierts nehme ich an (Download steht ja bereit zum Selbertesten). Ich denke aber das 20 FPS sowieso Minimum sind, und wenn es mein 2.53 Ghz mit 4000 FPS schafft müsste es doch auch ein Pentium 1 mit 166 Mhz schaffen und das reicht denke ich mal völlig aus Very Happy

. Ansonsten kann man die Zeitspanne ja auch noch erhöhen, dann könnte es allerdings wieder ruckeln, da das Programm ja dann unter 20 FPS läuft und da ruckelts ja meistens. Ich überlege mir gerade, ob ich, wenn der Rechner im Leerlauf ist und mit 200000 FPS durchrattert, ihn dann nicht andere Aufgaben zukommen lassen könnte, z.B. sehr Rechenintensive Sachen. Dann könnte er im Hintergrund irgendwas Laden. Ich werde auf jedenfall mit der Methode noch ein wenig rumspielen, schließlich ha ich jetzt 4000 FPS zum verpulvern ^^ und das ohne 3D.

Kleiner Schlusssatz: Das game müsste somit auf jedem Rechner mit 20 trueFPS laufen.

Edit: Mir ist gerade eingefallen, dass das was ich hier fabriziere kein echtes Frameunabhängiges programieren ist, da das Programm immer mit 20 FPS durchleuft und der Rest nur gefaked ist. Aber danke für den Tipp mit dem multiplizieren der Frames, ich werd versuchen des mal umzusetzten.

Edit: Lasse die bewegenden Objekte jetzt mit dem von dir beschriebenen Multiplikator berechnen. Funtzt soweit ganz gut, nur die Sprungfunkton macht Probleme.
Wenn ich da jetzt einen Frametimer reinbaue frage ich mich allerdings was da der große Unterschied zwischen meiner vorherigen Methode und der hier ist. Bei der vorherigen wurde eben nur alle 50 ms gezeichnet und nicht immer was theoretisch einem Timer von 20 FPS entspricht. (man könnte ihn nat. auch erhöhen) Mit dem frameunabhängigem Programieren lasse ich das Prog so schnell durchratter wie möglich (wenn ich keinen Timer verwende) und hab aber auch nicht mehr gewonnen als vorher, nur das die Bilder eben öfters gezeichnet werden wenn ich keinen Timer setzte, was das menschl. Auge aber auch nicht wirklich wahrnimmt. (ich zumindest sehe keinen Unterschied)

Übersicht

BlitzBasic

Beginners-Corner

Nach Oben

BlitzBasic Portal

Problem mit Frameunabhängigem programieren und FPS

Betreff: Problem mit Frameunabhängigem programieren und FPS

Betreff: Re: Problem mit Frameunabhängigem programieren und FPS