PureBoard

Kaeru Gaman hat geschrieben: außerdem bin ich der ansicht, wenn du besseres timing benutzen willst,
dann wird es auch langsam zeit sich mit getrennten threads zu beschäftigen,
etcpp

Jo, wer was wirklich wasserdichtes haben will muss sich zumindest mit Time Based Movement/Animation auseinandersetzen und jeweils 1 Thread für Anzeige und Berechnung sind auch nicht zu verachten. Ist halt nur etwas Overkill für jemanden der nen Pongclone oder ähnliches machen will.

Ich meinte ja nur bzw. wollte darauf hinweisen, dass der Code nur dann funktioniert, wenn FlipBuffers() NICHT wartet. Und dass ist zum Beispiel im Fenstermodus nicht möglich, jedefalls wartet FlipBuffers bei mir, egal, was ich als Parameter angebe.

Lebostein hat geschrieben:Ich meinte ja nur bzw. wollte darauf hinweisen, dass der Code nur dann funktioniert, wenn FlipBuffers() NICHT wartet. Und dass ist zum Beispiel im Fenstermodus nicht möglich, jedefalls wartet FlipBuffers bei mir, egal, was ich als Parameter angebe.

aber das STIMMT DOCH GARNICHT!
der ist auf 30FpS ausgelegt und funktioniert einwandfrei mit einem wartenden FlipBuffers.

@Lebo
Bei WindowEvent() wird aber nicht gewartet. Und wenn ich bei einer Fensteranwendung Windowed nutze, sollte man meiner Meinung nach in der Regel kein WaitWindowEvent() verwenden (Wobei ich aber dazu sagen muß, daß ich die neueren Möglichkeiten mit WaitWindo.. noch nicht getestet habe), auch wenn hier dann einige gerne wegen der Prozessorauslastung heulen. Zur Not gibts ja noch Delay().

@X

WaitWindowEvent(Timer) hat zwei Belange in diesem kontext:
1. du musst die berechnete Wartezeit dann halt hier angeben und kein Delay benutzen
2. wenn ein Event auftritt, wird nicht gewartet, also innerhalb eines Games recht oft, wenn Maus gedrückt wird etc.
damit wird deine ganze timerberechnung über den haufen geworfen.

@Kearu

1. Das ist Grundsätzlich ok, allerdings wobei ich aber von Spielen ausgeh, für was anderes lohnt sich Windowed eher selten... ich bin der absoluten Überzeugung, daß ein Game alle Reourcen haben sollte, die zur Verfügung stehen, deswegen würde ich da auch kein Delay verwenden. Daher auch kein WaitWindoEvent(1). Wobei ich wie erwähnt nicht beurteilen kann, ob es überhaupt bremsen würde, muß ich erst mal richtig ausstesten.
2. Warum wird meine Timerberechnung aufgehoben?

2. du berechnest einen ms-wert, der gewartet werden soll,
um der warteschleife von FlipBuffers nicht das ganze warten zu überlassen,
weil das zu 100% CPU-Last führt.
diesen ms-wert packst du in ein Delay, was diese zwischenzeit anderen prozessen zur verfügung stellt.
(immer in timeslices eingeteilt, deswegen der grenzwert von 16ms)

wenn du jetzt deinen wartewert in WaitWindowEvent() einsetzt,
übernimmt WWE die aufgabe von Delay, mit einer einschränkung:
wenn ein Event vorliegt, wartet es überhaupt nicht.

d.h. wenn trotzdem genauso wenig zeit in der hauptschleife verbraucht wird,
wird die gesamte wartezeit in FlipBuffers verbraten, und dein ganzer Timer-Aufwand wird zwecklos.


... btw. fällt mir grad auf, dass das Delay ja am Ende der Schleife steht,
und die aktuell übrig gebliebene zeit warten soll.
damit du also WWE überhaupt verwenden kannst, müßtest du deine struktur ändern,
und das Event auch am ende der schleife abfangen, um es im nächsten durchlauf zu verarbeiten.

Ah, ich hab eine ganz andere Vorgehensweise. Man sollte eher hin gehn und die Anwendung zu 100 % auslasten (ich geh von Spielen aus), dabei wird der Zeitunterschied von Frame zu Frame gemessen, also kann es unter Umständen mit 100 FPS aber Problemlos auch mit 223 Fps usw. laufen. Über den gemessenen Zeitabstand kann ich dann die Position der Objekte usw. berechnen lassen. Bei der Methode kann man dann auch Problemlos Delay() einbauen, wobei ich davon ja eh nichts halte. Da kann man natürlich auch WaitWindowEvent(irgendwas) nutzen, sofern man es nötig hält.
Ich halte jedoch nicht sonderlich viel davon, bei Games eine FPS-Begrenzung einzubauen oder mit einer Methode die Frames in relativ gleich große Abstände zu pressen. Das kann ganz schön nach hinten los gehn, wenn die Anwendung auf einmal unerwartet viel mehr Berechnen muß, oder diese auf Kisten läuft, die eh schon an den Grenzen stößt.
Trotzdem hab ich selbst mal etwas programmiert, bei dem ich die Bildausgabe zeitgesteuert ablaufen lies (zb 100 FPS in genau 10 ms Abständen), die eigentliche Schleife aber je nach eingestelten Frames einige 1000 bis 100000 mal mehr durchlaufen wurde. Der Vorteil dabei war, daß die Programmverarbeitung nicht mehr nur innerhalb der eingestellten FPS ab lief. Stellte man die FPS zu hoch ein, war natürlich die Schleife für den Programmablauf auch nicht mehr schneller, automatisch aber gleich schnell. Wenn durch irgendwelche größeren Berechnungen die Performance dann in die Knie ging, war das auch kein Problem, weil die grafische Darstellung ja zeitgesteuert war.

Das bedeutet jedoch, dass, falls mal richtig viel auf dem Bildschirm los ist und ich jede Menge droped frames habe, da ja einige der Stufen (z.B. Fahrzeug fährt und schießt) übersprungen werden, möglicherweise der Player schon tot ist und gar nicht weiß warum. Dann doch lieber alles darstellen und ein verlangsamen der Performance in Kauf nehmen. Das kennt man doch vom GameBoy (bei mächtigen Explosionen bei Mega Man fuhr das Spiel ganz schön in der Geschwindigkeit zurück).

Grundsätzlich muss ich Dir da recht geben und so wie Du es beschreibst, wird es normal auch bei Echtzeitstrategiegames gehandhabt (zB C&C). Jedoch bei Shootern eher wieder nicht, da wird in der Regel in kauf genommen, daß man getroffen wird/stirbt oder sonstwas und es unter Umständen erst später erfährt (zB Counter Strike).