Hurra, 100 % Auslastung

Übersicht BlitzBasic FAQ und Tutorials

Gehe zu Seite 1, 2  Weiter

Neue Antwort erstellen

Abrexxes

Betreff: Hurra, 100 % Auslastung

BeitragMi, Sep 19, 2007 16:31
Antworten mit Zitat
Benutzer-Profile anzeigen
Im ersten Augenblick ist man vielleicht stolz darauf wenn das eigene PacMan Game 100% der System Power braucht. Das aber viele aktuelle Vollpreisspiele nicht 100% benötigen (CPU Power) oder zb ein Vergleichbares Spiel auf dem Commodore64 bereits mit 1Mhz (einem !) liefen stört auch noch die wenigsten. Aber ist das normal?

Die Antwort darauf lautet eindeutig "Ja". Es ist normal wenn :

Arrow Der Programmierer keine Ahnung vom Programmieren hat
Arrow Das System zu alt ist und nicht die nötige Power besitzt
Arrow Die neuste Programmiertechnik das System überfordert
Arrow Der PC nicht vernünftig konfiguriert ist
Arrow Nicht genügend Resourcen zur Verfügung stehen (andere Programme)

Das der Anwender dummerweise X aktive Tasks offen hat kann vorkommen, aber dann ist nur der PC an sich ausgelastet, das bedeutet nicht dass das eigene Programm 100% braucht.

Zugegeben, wir als Programmierer können gegen die Punkte 2,3,4 und 5 nicht viel machen. Der User muss sein System in Ordnung halten sonst läuft nichts ordentlich. Bei 1 müssen wir uns aber die Frage stellen ob unser Spiel wirklich 100% eines DualCore PCs braucht wenn es um einen PacMan geht der nicht viel anders aussieht als ein Amiga Klon der mit 7,14 Mhz glücklich wäre. Dabei sollten wir berücksichtigen dass :

Arrow Games wie BIOSHOCK auf solchen System laufen, es ist also eine Frage des Verhältnisses
Arrow Blitzbasic nicht die schnellste Sprache ist, man also bei sehr vielen Objekten nun mal nichts machen kann was aber immer noch keine 100% rechtfertigen würde bei einem PacMan
Arrow Man 1000 Jahre optimieren könnte, ein "Optimal" gibt es daher leider nicht.

Wieso soll ein Spiel nur das benutzen was es braucht ?

Arrow Ein PC der unter Volllast läuft hat immer eine kürzere Lebenszeit. Die Bausteine (vor allem die CPU) sind gegen Hitze empfindlich. Je wärmer sie werden desto schneller werden sie zerstört. Das gilt nicht nur wenn der Ventilator ausfällt, sondern auch im normalen Betrieb da sich JEDE Temperatur zur Lebenszeit addiert. So hält zb eine CPU die immer bei 55 Grad läuft deutlich länger als eine die 60 Grad aushalten muss, auch wenn beides keine zu hohe Temperatur ist.

Arrow Der Stromverbrauch ist auf maximum, so kann zb ein System das eigentlich nur 95 Watt bräuchte um unser Game abzuspielen plötzlich 265 Watt brauchen (!), und das nur weil wir nicht programmieren können. Je stärker das System desto mehr verschwenden wir dann das Geld des Anwenders.

Arrow Ein PC kann viele Aufgaben gleichzeitig erledigen, zb im Hintergrund etwas laden oder das Netzwerk bedienen. Wenn nun unser Programm 100% braucht bricht das System zusammen, und falls im Netzwerk aktiv sogar eventuell das gesamte Netzwerk. Wirklich keine Werbung für unsere Programmier Künste.

Die Aussage "Ich nutze 100% weil es nun mal geht" ist daher nicht nur dumm, sondern zeigt das wir weder von gescheitem Programmieren eine Ahnung haben noch wissen wir wie ein PC arbeitet.

Wo sehe ich was mein Programm braucht ?

Bei denn meisten System reicht im Betrieb ein [CTRL]+[ALT]+[DEL]. In dem System Fenster können wir sehen wie viel % jedes Programm braucht. Dabei gilt 99% als Auslastung da circa 1% immer dem System gehört, ansonsten stürzt der Rechner sofort ab oder friert ein. Hier kann man auch sehen das unser Programm NICHT die Mutter aller Dinge ist sondern Windows noch viele andere Sachen machen muss.

Wie viel soll mein Programm brauchen ?

Das ist eine schwere Frage die jeder selbst beantworten muss. Man sollte einfach sein Programm so gut wie möglich optimieren, denn Verbrauch immer im Blick haben und realistisch sein. Blitz ist nicht schnell und 2D sogar noch langsamer. Wer aber immer das Tempo im Auge behält sieht was viel Power kostet und ob er das optimieren kann.

Wieso soll ich das tun ?

Entweder wollt Ihr programmieren oder murksen. Für Murkser ist hier kein Platz, der Sinn eines Programmierers ist es Programme zu schaffen die dem User nutzen oder Ihn erfreuen, nicht sein System zu ruinieren oder sein Geld zu verschwenden durch unsinnigen Code. Ich persönlich sehe solche Software als Schadsoftware an, und genau wie ein Virus oder Trojaner fliegt es vom System. Fertig. Wer davon nichts wissen will sollte sich nach einem Gamemaker umsehen und das programmieren aufgeben.

Bevor wir Anfangen noch 2 Dinge. Ein Programm KANN das maximum brauchen, es muss aber wie gesagt im Verhältnis zu dem stehen was geboten wird. Grundsätzlich gibt es in Blitz drei Dinge die viel Zeit benötigen :

Arrow 2D,(wenn viele kleine Bilder gezeichnet werden zb. Tilemaps) da das verwendete DIRECTDRAW von DX7 nun mal langsam ist und die Grafikkarte nahezu nicht benutzt wird
Arrow Viele Objekte, da Blitz nun mal nicht so schnell rechnen kann wie zb C++ oder Blitzmax
Arrow Aufwendige 3D Objekte, da auch hier noch das alte DX7 am Werk ist das Limits hat die weit von dem entfernt sind was aktuelle DX9 Karten mit der DX9 Schnittstelle anfangen können. Dabei spielen Shader etc von DX9 übrigens keine Rolle, das liegt grundsätzlich an denn verschiedenen Optimierungen der DX Schnittstellen.

Kapitel 1 : Die verbotenen 99 des Todes

Schauen wie uns das hier mal an :

Code: [AUSKLAPPEN]

While Not KeyHit (1) ; ESC
Print "Test"
Wend


Rein logisch ist das korrekt. Der PC soll solange kein Escape gedrückt wird "Test" ausgeben. Doch ist es normal das dies hier 99% eines 3Ghz PCs benötigt? Der C64 kann das auch mit 1Mhz. Wo also liegen die Unterschiede? Nun, sieh liegen leider in dem was wir NICHT sehen. Rein objektiv sehen wir 23 mal TEXT in einem Fenster. Das der PC das aber in Wirklichkeit ein paar hundert mal pro Sekunde macht sehen wir nicht da Text immer wieder am selben Platz steht. Hier wäre der arme C64 zwar langsamer , aber auch er würde es so schnell machen das wir es nicht bemerken. Doch was passiert im Ablauf?

Der PC tut was man im sagt, er ist nicht vernünftig und auch nicht intelligent sondern rechnet "nur". Da wir im hier nicht sagen wie schnell er das tun soll macht er es so schnell es nur geht mit aller Kraft die er hat.

Wären wir ein Transportunternehmen hätten wir zu unserem Fahrer gesagt er soll so schnell wie möglich von A nach B fahren. Da unser Fahrer wenig Hirn hat tut er das mit Bleifuss. Das Resultat, drei Unfälle, beschädigter Motor, übermüdeter Fahrer, 3 mal mehr Sprit verbraucht....aber die Ware kommt an. Ist das Intelligent?

Kapitel 2 : Die Rache des Delay

Code: [AUSKLAPPEN]

While Not KeyHit (1) ; ESC
Print "Test"
Delay 10
Wend


Auf den ersten Blick, perfekt. Das hier verbraucht nahezu 0%. Auf den zweiten Blick Müll. Wäre dies wieder unser Unternehmen, hätten wird dem Fahrer gesagt das er eine Pause machen darf von 10 Minuten an einer Tankstelle. Er wäre also nicht mehr übermüdet, am Rest hätten wir aber nichts geändert. Wir haben aber in diesem Fall Glück das auf der Strasse nichts los ist wenn er keine Pause hat und mit seinem Bleifuss unterwegs. Sorgen wir also mal für Betrieb auf der Strasse.

Ich weise darauf hin das diese For_Next Schleifen nicht fähr sind. Es bedeutet das der PC in diesem Fall 60 Millionen (!) Schleifen pro Sekunde rechnen soll

Code: [AUSKLAPPEN]

While Not KeyHit (1) ; ESC
Print "Test"
For i = 0 To 1000
   For n = 0 To 1000
      ;For m = 0 To 1000 <--für Leute mit Ultra schnellen DUAL Cores !
      ;Next
   Next
Next
Delay 10
Wend


Was ist denn das? Da bannt sich schon wieder der eine oder andere Unfall an, und der Spritverbrauch steigt auch, und das nur wegen dieser beiden Schleifen? Was tun wir jetzt? Sollten wir die Pause verlängern? Kürzen? Und wenn dann noch mehr los ist? Kurz, DELAY ist hier Blödsinn. Wer es so macht zeigt zwar das er eingesehen hat das es ein Problem gibt, aber verstanden worum es eigentlich geht hat er nicht. So kann er nur dem Programm PAUSEN verordnen, aber effektiv ist das nicht da dies sich auf jeder Maschine anders verhält (je nach Tempo) und die CPU selbst gegen diesen Murks machtlos ist. Ihr bleibt nichts übrig als dieses "Stop And Go" mitzumachen. Mehr dazu später.

Das einzige Intelligente ist ein Weg wo der Fahrer SELBST bestimmen kann wann er was machen muss und wann nicht. Wir sagen also nur, "Du hast 24 Stunden für von A nach B". Wenn die Strecke nun kurz ist (starker PC) kann der Fahrer sich Tempo und Pausen selbst einteilen. Bei längeren Strecken muss er halt etwas Gas geben (schwächere CPU). Aber er kann frei entscheiden was er macht und wählt die optimale Lösung. Sehen wir uns das mal an.

Kapitel 3 : Showdown am CPU Sockel

Wir lassen Print nun weg (da es das Resultat verfälscht) und vergleichen folgende 2 Codes.

Code: [AUSKLAPPEN]

Global timer =CreateTimer(30)
While Not KeyHit (1) ; ESC
For i = 0 To 1000
   For n = 0 To 1000
      For m = 0 To 2 ;<--für Leute mit Ultra schnellen DUAL Cores !
      Next
   Next
Next
WaitTimer timer
Wend


Code: [AUSKLAPPEN]

While Not KeyHit (1) ; ESC
For i = 0 To 1000
   For n = 0 To 1000
      For m = 0 To 2 ;<--für Leute mit Ultra schnellen DUAL Cores !
      Next
   Next
Next
Delay 10
Wend


Zugeben, beides funktioniert, ob aber die zweite Lösung an die erste rankommt hängt von eurem System ab.

Beim zweiten Code könnte man nun den Delay Wert so lange anpassen bis eine optimale Auslastung vorhanden ist. Dann habt Ihr nichts anderes gemacht als von einer genau definierten Aufgabe die Zeit auszupendeln die euer System braucht und schenkt quasi der CPU die Zeit mit Delay. Wie schnell das ganze sein soll könnt Ihr gar nicht ermitteln, nur solange rumspielen bis es korrekt läuft und wenig Zeit verbraucht.

Doch in einem "Echten" Programm ist nun mal die Zeit für einen Durchlauf IMMER eine andere, auch sind alle Systeme nicht gleich schnell. Im Vergleich zu der ersten Methode kommt Ihr als zu 99% schlechter weg oder seit allerhöchstens gleich auf. Diese Beispiele hier taugen leider ausser zum Testen zu gar nichts. Aber was passiert wenn nun ein PC langsamer ist? Irgendwann fängt er an zu stottern obwohl er noch genügend Zeit hätte um korrekt zu arbeiten, aber ER MUSS ja Pause machen, auch wenn er eigentlich keine Zeit mehr dazu hat. Und wenn das System schneller ist...nun dann rennt er wieder so schnell es geht MIT PAUSE. Also, keine Lösung. Aber es geht noch schlimmer.

Code: [AUSKLAPPEN]

Graphics 640,480,0,2
SetBuffer BackBuffer()

While Not KeyHit (1) ; ESC
;
; Ihrgend was Frame unabhängiges
;
Delay 5
Flip
Wend
End


Wer so arbeitet dem kann man nur noch Gratulieren. Er hat jeden Fehler zu diesem Thema begangen denn man mit Blitzbasic nur realisieren kann. Jeden!
Zusätzlich das er das gesamte Multitasking des Systems ad absurdum führt zwingt er auch noch das Programm nach einer erzwungenen Pause auf den Monitor zu warten. Dieses System führt unweigerlich zum Genickschuss. Spätestens dann wenn ein PC nicht genug Ressourcen mehr frei hat für die erzwungene Pause (nicht für das Programm) weil ein andere Programm im Hintergrund was tut oder der PC halt schwächer ist. (Das Thema wieso man keine 500 Frames ausrechnen soll da ein Monitor eh nur 60 oder 75 anzeigt behandele ich hier nicht)
Die älteren unter euch wissen vielleicht noch wie unter Win98se manchmal ein Spiel zu ruckeln anfing wenn eine Email ankam, genau das selbe Problem. Das System (OS) konnte das Multitasking noch nicht so gut verwalten wie das heute 2000 oder XP können. Mit Delay tun wir nichts anderes als solche Stollpersteine wieder einbauen die einschlagen wenn das System DURCH DELAY an seine Grenze stösst. Denn dann ist DELAY keine Hilfe mehr sondern ein Problem.

Der zweite Weg :

Code: [AUSKLAPPEN]

timer = createtimer (60)
Graphics 640,480,0,2
SetBuffer BackBuffer()

While Not KeyHit (1) ; ESC
;
; Ihrgend was Frame unabhängiges
;
Waittimer timer
Flip 0
Wend
End


Hier sagen wir zuerst mal das er nur 60 Bilder pro Sekunde berechnen soll, alle anderen kann er sich sparen, dann soll er selbst feststellen wie viel Zeit übrig bliebt und die SELBST nutzen. Wenn die Zeit abgelaufen ist soll er SOFORT weitermachen. Egal welches System, egal wie viel zu berechnen ist. Der PC kann sich so die Zeit perfekt einteilen, verwalten und nutzen. Mehr ist dazu nicht zu sagen.

Natürlich könnt Ihr einen eigenen Timer schreiben. Doch dies ist der einzige korrekte Weg der garantiert das eure Software überall bei optimaler Lastverteilung läuft. Und das auch noch in 10 Jahren ohne wieder Ressourcen zu verschwenden oder Systeme auszubremsen.

Fazit: Keiner kann wissen wie viel Zeit auf einem System bei einem Programm übrig bleibt um diese zu "Verschenken". Nutzt also DELAY nicht als "Ressourcen Erzeuger" sondern nur wofür es gedacht ist. Haltet eure Ressourcen sauber. Die Systeme und Nutzer eurer Software danken es euch.

Have Fun.
  • Zuletzt bearbeitet von Abrexxes am Do, Sep 20, 2007 11:06, insgesamt 5-mal bearbeitet

ZaP

BeitragMi, Sep 19, 2007 17:24
Antworten mit Zitat
Benutzer-Profile anzeigen
Super Sache!

Die CPU (bzw. ältere Modelle) sind/waren aber immer voll ausgelastet, deswegen ja der leerlaufprozess.

Naja, seit SpeedStep und PowerNow! ja nichtmehr. Vielleicht sollte man noch was über die Delta-Zeit schreiben, falls mal jemand unter die 60 FPS kommt und der Spielablauf konstant bleiben soll.
Starfare: Worklog, Website (download)
 

Cyderic

BeitragMi, Jan 07, 2009 12:56
Antworten mit Zitat
Benutzer-Profile anzeigen
Vielen Dank für den Beitrag hat mir geholfen
(hab zuerst, weil ichs nicht besser wusste, auch Delay genommen - jetzt weiss ich es besser Smile )

Abrexxes

BeitragMi, Jan 07, 2009 22:04
Antworten mit Zitat
Benutzer-Profile anzeigen
Danke für das Lob. Ein "Held" weniger. Wink
 

chi

BeitragDo, Jan 08, 2009 1:33
Antworten mit Zitat
Benutzer-Profile anzeigen
Ist ja alles schön und gut... Allerdings komme ich bei Flip(1) (bzw. vwait:flip 0) nicht um einen Delay herum, weil mit Waittimer() trotzdem fast 100% Cpu benötigt werden.

So in etwa mache ich es... (Pseudocode)

Code: [AUSKLAPPEN]

xdelay=10

repeat

   start=millisecs()

   ;loop code

   if xdelay>10 then xdelay=10 elseif xdelay < 1 then xdelay=0

   delay(xdelay):flip1

   xdelay=26-(millisecs()-start)

until keyhit(1)
end


Meine richtige Routine zum Berechnen des Delays ist natürlich etwas umfangreicher, aber denn Sinn dahinter erkennt man. Jeder Loopdurchgang wird auf 16ms beschränkt. Dauert ein Loop länger
als 16ms, zB. 19ms wird als Delay nicht 10ms zurückgegeben, sondern eben nur 7ms (26-19) usw...

Sollte meine Routine vollkommen Schwachsinnig sein (vom Sinn her), gebt mir bitte Bescheid. Allerdings habe ich diese Art schon in manchen Programmen von mir angewendet und bis jetzt noch keine negativen
Erfahrungen gemacht Wink

Aber nochmal... der oben angeführte Code ist nur zur Veranschaulichung und würde so natürlich nicht richtig funktionieren!


cheers, chi

hectic

Sieger des IS Talentwettbewerb 2006

BeitragDo, Jan 08, 2009 12:55
Antworten mit Zitat
Benutzer-Profile anzeigen
Du sollst ja auch Flip 0 machen. Denn sobald ''Flip'' bzw. ''Flip 1'' angewendet wird, benötigt das Programm gleich 100%. Der Grund dazu ist mir allerdings schleierhaft. Es nützt auch nichts mit Delay oder WaitTimer das Warten auf VSync im Vorwege auf das notwendigste zu reduzieren.

Will man aber unbedingt fliessende Bewegungen alá ''Flip 1'', so kann man auch gleich auf WaitTimer oder Delay verzichten, da im Normalfall (außer ein Superuser hat es Treibermäßig ausgeschaltet) dann eh auf die Bildschirmfrequenz syncronisiert wird.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D
 

Krischan

BeitragDo, Jan 08, 2009 13:36
Antworten mit Zitat
Benutzer-Profile anzeigen
Dieser Code hält die CPU auch kühl, solange die Anzeige für "Time left" > 0 ist, also bei konstant 60FPS. Ist ursprünglich ein Code von sswift, den ich ein wenig erweitert habe, damit man auch steuern kann und was sieht:

Code: [AUSKLAPPEN]
Const MAX_FPS = 30

Graphics3D 1024,768,32,2

Min_Frame_Time  = Floor(1000.0/Float(MAX_FPS))
Current_Time   = MilliSecs()
Game_Start_Time = Current_Time

; Pivot und Kamera
cam=CreateCamera()
piv=CreatePivot()

; Dummys erstellen
For i=1 To 1000
    dummy=CreateCube(piv)
    ScaleEntity dummy,0.25,0.25,0.25
    TurnEntity dummy,Rnd(0,360),Rnd(0,360),Rnd(0,360)
    MoveEntity dummy,0,0,10
    PointEntity dummy,piv
Next

leftold=MilliSecs()

While Not KeyHit(1)
   
    TurnEntity piv,0.1,0.1,0.1
   
   Time_Old      = Current_Time                           ; Store the time the last frame began.                     
   Current_Time    = MilliSecs()                           ; Store the time at the start of this frame.
   Time_Delta       = Current_Time - Time_Old                  ; Calculate how long the last frame took.
   Time_Delta_Sec# = Float(Time_Delta)/1000.0
   
    mxs#=MouseXSpeed()
    mys#=MouseYSpeed()
    RotateEntity cam,EntityPitch(cam)+(mys#/5),EntityYaw(cam)-(mxs#/5),0
    MoveMouse GraphicsWidth()/2,GraphicsHeight()/2
    If KeyDown(200) Then MoveEntity cam,0,0,0.1
    If KeyDown(208) Then MoveEntity cam,0,0,-0.1
    If KeyDown(205) Then MoveEntity cam,0.1,0,0
    If KeyDown(203) Then MoveEntity cam,0.1,0,0
   
   UpdateWorld                                          ; Handle collisions.
   RenderWorld                                          ; Render the current 3D view to the back buffer.
   
    If MilliSecs()-leftold>100 Then newleft=time_left : leftold=MilliSecs()
   
    Text 0, 0,"Tris.......: "+TrisRendered()
    Text 0,15,"Time left..: "+newleft+"ms"
   
    Flip 0                                              ; Swap the back buffer with the front buffer.
   
   Time_Passed = MilliSecs() - Time_Old                     ; Calculate how long this frame took to render including the flip.
   Time_Left   = Min_Frame_Time-Time_Passed                  ; Calculate the amount of additional time we should wait to stay below MAX_FPS.
   Delay(Time_Left)                                    ; Delay for that amount of time.
   
Wend

End


Einfach mal die Anzahl der Würfel erhöhen, nebenbei den Task Manager im Auge behalten und dann mal rückwärts aus der Würfelkugel herausfliegen, so dass alles gerendert werden muss. Ihr werdet feststellen, dass die CPU-Auslastung mit steigender angeforderter Leistung bis 100% zunimmt, also dynamisch an die Komplexität der Szene angepasst ist.

An diesem Beispiel kann man auch schön sehen, dass nicht nur die Anzahl der Tris entscheidend für den Leistungshunger sondern eher die Anzahl der Surfaces / Entities dafür verantwortlich zeichnet (einfach mal createcube durch createsphere ersetzen, macht bei 16er Spheres nicht so den Unterschied obwohl 10000x mehr Tris gerendert werden müssen).
 

chi

BeitragDo, Jan 08, 2009 15:12
Antworten mit Zitat
Benutzer-Profile anzeigen
hectic hat Folgendes geschrieben:
Will man aber unbedingt fließende Bewegungen alá ''Flip 1'', so kann man auch gleich auf WaitTimer oder Delay verzichten, da im Normalfall (außer ein Superuser hat es Treibermäßig ausgeschaltet) dann eh auf die Bildschirmfrequenz synchronisiert wird.

und genau das trifft z.b. auf meine grafikkarte (ati x700 64mb) nicht zu... wenn ich die standardeinstellungen lade, steht meine vsync einstellung auf "Aus - falls nicht von Anwendung festgelegt." (neueste treiber + ati ccc).

außerdem macht es meines erachtens dann sehr wohl sinn, im zusammenhang mit Flip1 nicht auf delay zu verzichten, weil man eben nur mit diesem befehl die cpu-auslastung runterschrauben kann...

unter http://lunamedia.heim.at/bfbeta/BasefieldTC.zip könnt ihr euch ein beispiel anschauen... ist mit flip1 gemacht und braucht auf meinem system max. 40% cpu (tm forever braucht bei mir genau so viel). darüber hinaus wird das bild immer synchronisiert, nur wenn hardwaremässig vsync komplett ausgeschaltet ist, gibts unter options einen kleinen fix... dieses system hab ich auch schon auf einigen pc´s getestet und bin bis jetzt noch nicht eingefahren Wink

flip0 war für mich nie ne option, schon allein wegen der tatsache, dass bei schneller kameradrehung das bild extrem unsanft angezeigt wird... vsync off eben

cheers, chi

hectic

Sieger des IS Talentwettbewerb 2006

BeitragDo, Jan 08, 2009 15:57
Antworten mit Zitat
Benutzer-Profile anzeigen
Das Problem bei ''Flip 1'' ist einfach, dass es nahezu unmöglich ist es mit Delay auf alle Eventualitäten vorzubereiten. Soll heissen: Einmal hat man das Problem ''Flip 1'' immer 100% Leistung benötigt (Vorrausgesetzt, es wartet ein ganzen Syncronisationszyklus). Das liegt vielleicht daran, dass das Abfangen des Monitorsignales äußerst zeitnah geschehen muß. Hat man nun das Signal verpasst, so wartet dann Flip eine ganze Weile bis das nähste Signal kommt. Und hier auch schon das zweite Problem. Schafft ein Rechner nicht immer die volle FPS, so wird immer gleich die FPS um ganze 50% reduziert. Das sehr starke Einbrechen der FPS macht sich dann für bestimmte User so negativ bemerkbar, dass diese das Programm sicherlich nie mehr ausführen werden.

Um wirklich das beste aus allem zu haben, könnte man folgendes machen.

- Immer ein Standard-Delay von etwa 4 setzen, damit jeder Rechner zu jeder Zeit immer genügend Zeit auch für andere Dinge hat.
- Programmschleife dessen Zeit messen und ein Delay so ansetzen, dass ein VSync unmittelbar bevorsteht und gleich danach auch ''Flip 1'' ausführen. Dieser muß dann nicht mehr so lange auf das Signal warten und verpulvert auch keine unnötige Recourcen.
- Sollte die Programmschleife länger als ein vorberechnetes VSync dauern. Also das VSync ist schon vorbei, dann unmittelbar ''Flip 0'' ausführen. Das zuvor festgelegte ''Delay 4'' sorgt dafür, dass der Rechner nicht ''abraucht'' und Zeit für andere Dinge bekommt. Ab diesem Zeitpunkt ist aber schluß mit schönen fliessenden Bewegungen.

Problem bei der Sache sind aber die ganzen ''Idioten'' die treiberseitig ihr VSync ausgeschaltet haben. Ohne Wissen tun die meisten dass, damit sie sich an ihren FPS bei CS und anderen Spielen aufgeilen können. Was aber 400 FPS bringen wissen diese Leute dann auch nicht so genau, glauben es aber zu wissen.

Und so kommen wir dann auch zum nächsten. Man muß eine Vorabprüfung machen, die feststellt ob der User eventuell VSync generell ausgeschaltet hat und wenn ja, dann einfach auf 60, 100 FPS oder was auch immer festlegen.

Der einfachste Weg ist aber immer noch einfach ''WaitTimer'' einsetzen und gut. Bei einfachen Spielen braucht man dann auch nicht frameunabhängig programmieren und kann direkt alles einhacken und gut ist.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

Valnar

BeitragDo, Jan 08, 2009 17:52
Antworten mit Zitat
Benutzer-Profile anzeigen
hectic hat Folgendes geschrieben:
Um wirklich das beste aus allem zu haben, könnte man folgendes machen.

- Immer ein Standard-Delay von etwa 4 setzen, damit jeder Rechner zu jeder Zeit immer genügend Zeit auch für andere Dinge hat.
- Programmschleife dessen Zeit messen und ein Delay so ansetzen, dass ein VSync unmittelbar bevorsteht und gleich danach auch ''Flip 1'' ausführen. Dieser muß dann nicht mehr so lange auf das Signal warten und verpulvert auch keine unnötige Recourcen.
- Sollte die Programmschleife länger als ein vorberechnetes VSync dauern. Also das VSync ist schon vorbei, dann unmittelbar ''Flip 0'' ausführen. Das zuvor festgelegte ''Delay 4'' sorgt dafür, dass der Rechner nicht ''abraucht'' und Zeit für andere Dinge bekommt. Ab diesem Zeitpunkt ist aber schluß mit schönen fliessenden Bewegungen.

Das hört sich interessant an, kannst du mal so eine Function Programmieren?
Interssiert mich mal wie das im Endeffekt aussehen soll Very Happy

Abrexxes

BeitragDo, Jan 08, 2009 17:59
Antworten mit Zitat
Benutzer-Profile anzeigen
hectic, bei DELAY macht Blitz nichts anderes als eine Entlosschleife zu fahren bis die Zeirt verstrichen ist. Das System wird so unnötig belastet und Multitasking ist ab absurdum. Delay sollte man daher NIE verwenden, auch wenn es die eine SPU "kühl" hält kann das auf einer anderen anders aussehen.

FLIP(1) wartet auf denn Monitor. Rein technisch gesehen hat dein PC als keine 1000ms mehr po Sekunde sonder 1000/(Hz Monitor), der Rest geht einfach denn Bach runter da auch wieder Entlosschleife = 100%

An alle ausser hecitc: Sucht bitte keine 1000 Möglichkeiten wie man es dich hin kriegen könnte sondern macht es richtig. Wink

cu

FireballFlame

BeitragDo, Jan 08, 2009 19:05
Antworten mit Zitat
Benutzer-Profile anzeigen
Abrexxes hat Folgendes geschrieben:
hectic, bei DELAY macht Blitz nichts anderes als eine Entlosschleife zu fahren bis die Zeirt verstrichen ist. Das System wird so unnötig belastet und Multitasking ist ab absurdum.

Huh? Ich hatte immer gedacht, Code: [AUSKLAPPEN]
c=CreateTimer(60)
Repeat
   ; ...
   WaitTimer(c)
Forever
und Code: [AUSKLAPPEN]
Repeat
   x=MilliSecs()
   ; ...
   Delay 1000/60-(MilliSecs()-x)
Forever
wären dasselbe - jedenfalls zeigt bei mir der Taskmanager bei beidem 0% Auslastung an?

Abrexxes hat Folgendes geschrieben:
Delay sollte man daher NIE verwenden, auch wenn es die eine SPU "kühl" hält kann das auf einer anderen anders aussehen.

Was ist eine SPU?
PC: Intel Core i7 @ 4x2.93GHz | 6 GB RAM | Nvidia GeForce GT 440 | Desktop 2x1280x1024px | Windows 7 Professional 64bit
Laptop: Intel Core i7 @ 4x2.00GHz | 8 GB RAM | Nvidia GeForce GT 540M | Desktop 1366x768px | Windows 7 Home Premium 64bit

Abrexxes

BeitragDo, Jan 08, 2009 19:10
Antworten mit Zitat
Benutzer-Profile anzeigen
Dann mach das mal auf einem Pentium 100, dann wird es dir vielleicht klar.

Eine SPU ist übrigens eine CPU die falsch geschrieben wurde. Wink

Edit: Ach macht doch was Ihr wollt. Gäbe es nicht Leute wie Cyderic könnte es mir manchmal leid tun für die Zeit die ich in solche Texte investiere. Over&Out

biggicekey

BeitragDo, Jan 08, 2009 20:15
Antworten mit Zitat
Benutzer-Profile anzeigen
also ich habe noch kein argument gehört welches gegen flip 0 und waittimer spricht.

das sollte doch auch dem letzten auffallen. Idea
#45 www.icekeyunlimited.de www.starcrusade.de
Gewinner BCC#17 !!! mit dotkiller
Nothing more to register - you've cleaned us out![/size]

hectic

Sieger des IS Talentwettbewerb 2006

BeitragDo, Jan 08, 2009 20:34
Antworten mit Zitat
Benutzer-Profile anzeigen
Gut, ich gebe mich geschlagen. Auch schon deshalb, weil ich selber gegen Delay war. Mein oben genannter Vorschlag war eine Idee sowohl ein sauberes Bild über VSync als auch eine geringe Prozessorauslastung zu erreichen. Das Delay auf bestimmten Rechnern hohe Auslastung verursacht habe ich nicht gewusst. Dann bleibe ich weiterhin auf WaitTimer, wie bisher alle meine Codes des letzten Jahres.

@biggicekey, das Argument ist, dass ohne VSync eben jegliche Bewegungen und Hintergrundverschiebungen horizontal visuel abgeschnitten werden. Das heisst, dass wechseln der beiden Puffer erfolg zu jeder Zeit und somit auch zu Zeiten, wo der Bildaufbau vom Bildschirm gerade irgendwo aber nicht am Ende (unten) des Bildschirmes ist. Das bedeutet, dass unterhalb eines Pufferwechsels ein neueres Bild auf dem Bildschirm gezeichnet wird. Objekte und Hintergrundbilder wirken ''abgeschnitten'' oder werden ''unruhig'' bewegt. Allerdings muß ich dazu sagen, dass immer mehr Spiele auf VSync verzichten und anscheinend fällt es nur denn Leuten auf, die explizit darauf achten. Eventuell können auch neuere Flachbildschirme das selbst interpolieren und zeigen immer ein gesamtes Bild an.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D
 

Krischan

BeitragFr, Jan 09, 2009 9:28
Antworten mit Zitat
Benutzer-Profile anzeigen
Noch einen Nachtrag, damit man nicht immer den Taskmanager im Auge behalten muss, zur CPU-%-Messung gibt es eine ältere DLL, die das Ingame messen kann (funzt hier auf meinem C2D T7500 aber noch sehr gut):

https://www.blitzforum.de/foru...php?t=1224

Ich verwende die im Mainloop so (jede Sekunde eine Messung):

Code: [AUSKLAPPEN]
If MilliSecs()-time>1000 Then
time=MilliSecs()
percent%=CallDLL ("blitzcpu.dll","_CPUPercent")
EndIf


percent kann man dann als Wert oder Balken ausgeben.

ozzi789

BeitragFr, Jan 09, 2009 18:36
Antworten mit Zitat
Benutzer-Profile anzeigen
@Krischan

bei mir funkt gar nix (hab beide samples ausprobiert)
bekomm immer 0
vlt liegt es an calldll?

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

Krischan

BeitragFr, Jan 09, 2009 20:17
Antworten mit Zitat
Benutzer-Profile anzeigen
Bei mir geht das (ich hab B3D 1.99). Liegt die DLL auch im selben Verzeichnis wie die BB Source-Datei? Alternativ kann man dazu auch ein decls File basteln, da CallDLL noch aus BB-Urzeiten stammt (hab das Ding aber nicht geproggt, nur der Vollständigkeit halber erwähnt).

ozzi789

BeitragSa, Jan 10, 2009 1:21
Antworten mit Zitat
Benutzer-Profile anzeigen
jep alles dort wo es hingehört, eine decls wär natürlich toll! Smile
(habs auch mit 1.99 probiert, vlt liegts an der quad Cpu..)
mfg
0x2B || ! 0x2B
C# | C++13 | Java 7 | PHP 5

Abrexxes

BeitragSa, Jan 10, 2009 1:33
Antworten mit Zitat
Benutzer-Profile anzeigen
Vielleicht braucht dein Prog auch nur 0.00000X % Wink

cu

Gehe zu Seite 1, 2  Weiter

Neue Antwort erstellen


Übersicht BlitzBasic FAQ und Tutorials

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group