Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Framebased rendering

Werbeanzeige

Black-Panther

Alter Hase

  • »Black-Panther« ist der Autor dieses Themas

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

1

07.02.2007, 18:44

Framebased rendering

Hi!

Hab mir gerade gedacht, dass es in meinem Fall besser wäre framebased rendering zu betreiben... Wollte das gerade umstellen... doch es funktioniert mir noch zu schlecht... Weiß allerdings nicht genau, woran es liegt... es ruckelt irgendwie:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

//while(true): MessageLoop


          ogTimer Timer;
        Timer.Start();

        //Startzeit messen

        if(fFixedFrameRate > 0.f)
            fTime = fFramePeriod;
        else 
            fTime = og_g_Clock.GetPredictedFrameTime();

//Hier werden die WM verarbeitet sowie die Render und Move funktion aufgerufen

        
        //Bildbuffer sichtbar machen

        ogDirect3D::Instance().Present();

        //Fixe Framerate einstellen?

        Timer.Stop();
        float fTimeForThisFrame = Timer.GetDuration<float>();
        if(fFixedFrameRate > 0.f && fFramePeriod > fTimeForThisFrame)
        {
            ::Sleep(static_cast<DWORD>((fFramePeriod - fTimeForThisFrame) * 1000.f));
        }


Also... der Timer misst mir die Zeit, die der Schleifendurchgang benötigt, daraufhin, wird dir restliche Zeit (bis zur fFramePeriod) mit einem Sleep verbracht ;)
Da es eben so ein bisschen stockt, meine Frage, kann es sein, dass die auflösung der Sleep funktion in ms zu gering ist?
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

Firefly

Alter Hase

Beiträge: 484

Wohnort: Irgendwoundnirgendwo

  • Private Nachricht senden

2

07.02.2007, 20:40

willst du eine Framebremse einbauen?

chriss

Alter Hase

Beiträge: 624

  • Private Nachricht senden

3

07.02.2007, 21:45

Tuts eventuell auch ein Timer für deine Zwecke?

Black-Panther

Alter Hase

  • »Black-Panther« ist der Autor dieses Themas

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

4

07.02.2007, 23:09

@FireFly
So in der Art... Will halt von timebased auf framebased Rendering umsteigen

@chriss
Definitiv nicht! ^^
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

Chase

Alter Hase

Beiträge: 753

Wohnort: Nagaoka / Darmstadt / Düsseldorf

Beruf: fauler Studi

  • Private Nachricht senden

5

08.02.2007, 09:07

Die Sleep Genauigkeit haengt wohl vom Betriebssystem ab. MSDN schreibt nur If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time.

Ich hab gelesen, dass ein Sleep(1) theoretisch 50ms statt 1ms dauern kann, also das koennte tatsaechlich das Problem sein!
Schreib dir doch zum Testen mal ein haessliches while-Konstrukt dann wirst du sehen ob das Ruckeln weg ist.
"Have you tried turning it off and on again?"

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

6

08.02.2007, 09:18

Wenn ich sowas seh'. Welcher (sorry) Trottel versucht denn Frames zu verschenken? Das machen Anfänger und Leute die keine Ahnung haben. Framebremsen haben nichts im Quellcode verloren!
Vielmehr solltest du die Bewegung der Objekte in Abhängigkeit der Frames bringen und nicht versuchen selbige auf eine fixe Zahl runterzuschrauben.
@D13_Dreinig

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

7

08.02.2007, 10:49

Zitat von »"David_pb"«

Wenn ich sowas seh'. Welcher (sorry) Trottel versucht denn Frames zu verschenken? Das machen Anfänger und Leute die keine Ahnung haben. Framebremsen haben nichts im Quellcode verloren!
Vielmehr solltest du die Bewegung der Objekte in Abhängigkeit der Frames bringen und nicht versuchen selbige auf eine fixe Zahl runterzuschrauben.

Geht's noch?
Angenommen mein Spiel macht nur 25 Logik-Updates pro Sekunde, also 40 ms pro Update, und ich bin schon nach 5 ms mit meinem Update fertig und habe auch schon mein Frame gerendert - dann kann ich die restlichen 35 ms anderen Programmen zur Verfügung stellen, indem ich meine CPU-Zeit z.B. durch Sleep so lange abtrete. Da man nie genau wissen kann, ob man wirklich genau nach der gewünschten Zeit wieder an die Reihe kommt, sollte man lieber etwas weniger Zeit abwarten, z.B. 25 ms statt die eigentlichen 35 ms.
Am sichersten ist es wohl, wenn man einfach ein Sleep(0) macht und bei der Rückkehr wieder prüft, ob es mittlerweile Zeit für ein neues Logik-Update ist. Falls nicht, dann wieder Sleep(0), so lange, bis genug Zeit vergangen ist.
Öfter zu rendern als Updates zu machen bringt nur dann was, wenn ich irgendwelche Komponenten habe, die nur von der reinen physikalischen Zeit abhängen und nicht von der Logik-Zeit, oder wenn ich zwischen zwei Logik-Zuständen interpolieren will.
Also halt dich mal zurück mit solchen erniedrigenden Kommentaren.
David Scherfgens Website | Konzentrationstest Polizei

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

8

08.02.2007, 11:46

Zitat von »"David Scherfgen"«

Zitat von »"David_pb"«

Wenn ich sowas seh'. Welcher (sorry) Trottel versucht denn Frames zu verschenken? Das machen Anfänger und Leute die keine Ahnung haben. Framebremsen haben nichts im Quellcode verloren!
Vielmehr solltest du die Bewegung der Objekte in Abhängigkeit der Frames bringen und nicht versuchen selbige auf eine fixe Zahl runterzuschrauben.

Geht's noch?
Angenommen mein Spiel macht nur 25 Logik-Updates pro Sekunde, also 40 ms pro Update, und ich bin schon nach 5 ms mit meinem Update fertig und habe auch schon mein Frame gerendert - dann kann ich die restlichen 35 ms anderen Programmen zur Verfügung stellen, indem ich meine CPU-Zeit z.B. durch Sleep so lange abtrete. Da man nie genau wissen kann, ob man wirklich genau nach der gewünschten Zeit wieder an die Reihe kommt, sollte man lieber etwas weniger Zeit abwarten, z.B. 25 ms statt die eigentlichen 35 ms.
Am sichersten ist es wohl, wenn man einfach ein Sleep(0) macht und bei der Rückkehr wieder prüft, ob es mittlerweile Zeit für ein neues Logik-Update ist. Falls nicht, dann wieder Sleep(0), so lange, bis genug Zeit vergangen ist.
Öfter zu rendern als Updates zu machen bringt nur dann was, wenn ich irgendwelche Komponenten habe, die nur von der reinen physikalischen Zeit abhängen und nicht von der Logik-Zeit, oder wenn ich zwischen zwei Logik-Zuständen interpolieren will.
Also halt dich mal zurück mit solchen erniedrigenden Kommentaren.


Man bremst Frames nicht aus! Man sollte lieber einen Faktor ermitteln anhand dessen sich die Objekte bewegen. Läuft das Programm im Vollbildmodus (davon geh ich hier mal aus) dann bekommt es sowiso höchste Priorität.

Ps: Nochmals sorry wegen dem Ton :)
@D13_Dreinig

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

9

08.02.2007, 12:12

Zitat von »"David_pb"«

Man bremst Frames nicht aus! Man sollte lieber einen Faktor ermitteln anhand dessen sich die Objekte bewegen.

Nein, es ist besser, die Logik-Updates in kleinen konstanten Schritten durchzuführen. Ich weiß, dass ich das in meinem Buch nicht so mache. Bei den Beispielen dort geht es auch ohne, aber spätestens wenn du eine Physik-Engine integrieren willst, bekommst du Probleme, vor allem wegen der Kollisionserkennung. Du wirst jedes Mal ein anderes Ergebnis bekommen, weil die Zeitschritte nicht immer gleich sind.
Alle professionellen Spiele gehen, soweit ich das weiß, nach dem Schema mit den konstanten Logik-Schritten vor (und ich bin auch vor einiger Zeit darauf umgestiegen ;)).

Zitat von »"David_pb"«

Läuft das Programm im Vollbildmodus (davon geh ich hier mal aus) dann bekommt es sowiso höchste Priorität.

Selbst wenn das stimmen würde (woran ich zweifle), wäre das kein Grund dafür, die CPU zu 100% auszulasten, wenn es gar nicht nötig ist.
David Scherfgens Website | Konzentrationstest Polizei

Black-Panther

Alter Hase

  • »Black-Panther« ist der Autor dieses Themas

Beiträge: 1 443

Wohnort: Innsbruck

  • Private Nachricht senden

10

08.02.2007, 13:14

Also der Grund für meine "FRAMEBREMSE" ist ein Thread, der dynamisch während der Laufzeit Resourcen lädt. Immer wenn das passiert und ich timebased-rendere kommt es zu kurzem ruckeln (wegn Framerateschwankungen (trotz dass ich den fTime-Wert ziemlich gut mittle); und das wäre nicht nötig, da ich mit 800 fps rendere... wenn ichs auf 30fps runterschraub, dann bekommt der Thread leicht die Zeit die er braucht, und das ruckeln bleibt aus (soweit meine theoretische Idee!).

Zur Lösung (@David)
Meinst du praktisch in einer while(true) immer einen Sleep(0) und dann die vergangene Zeit (für den Sleep) messen, sobald es "genug" ist, aus der Schleife raus.. Hab ich das richtig verstanden?
stillalive studios
Drone Swarm (32.000 Dronen gleichzeitig steuern!)
facebook, twitter

Werbeanzeige