PureBoard

SetFrameRate() und die Methode von Kaeru Gaman haben änliche bzw.
sogar gleiche Resultate. Bei beiden wird eine gewisse Zeit gewartet,
bevor es weiter geht und wenn der PC zu langsam ist, um diesen
Intervall zu schaffen, läuft das Spiel auch merklich langsamer. Außerdem
wird bei beidem wohl viel CPU-Power durch das "nichts tun" vergeudet.

Ich finde das normale "Timebased-Movemend" ist sicher immer noch am
besten
... man könnte aber auch Kaeru Gamans Idee nutzen und den Takt-
Intervall dynamisch berechnen lassen. Natürlich muss man dazu dann
auch den Multiplikator entsprechend anpassen.

MFG PMV

nicht ganz...

Kaeru Gaman hat geschrieben:...dann sieht das gerüst so aus:

ich schrieb "gerüst".

mir ging es hier um eine effektive methode der synchronisierung.

dass in selche schleifen irgendein Delay() rein sollte,
um die CPU zu entlasten (wenn möglich), ist eigentlich selbstverständlich.

klar wäre es auch ne schicke möglichkeit, wenn man eine angepasste wartezeit wählt.


grundsätzlich ist es zwar vielleicht ganz nett, sich ne ein "Timebased-Movemend",
aber dabei scheinen die meisten zu vergessen, dass bewegung bei weitem nicht das einzige ist, was in intervallen berechnet werden muss.
nehmen wir als beispiel mal ein RTS, dann erwirtschaften z.b. die arbeitseinheiten eine bestimmte menge rohstoffe, gebäude werden gebaut, usw. usf.

meistens richtet man doch das innenleben eines games so ein,
dass es auf einer bestimmten mindestkonfiguration einen bestimmten takt halten kann.

ich fände es absolut widersinnig, wenn ich ein game mit 237FPS durchblasen lasse,
nur um dann am ende noch ungenauigkeiten zu bekommen, weil die floats nicht genau genug rechnen können für 1/237 sec....

mal ganz abgesehen davon, dass vielleicht nur deshalb die performance hinterherhinkt,
weil ich hunderte von divisionen durchführen muss, um dieses "Timebased-Movemend" anwenden zu können....

meistens richtet man doch das innenleben eines games so ein,
dass es auf einer bestimmten mindestkonfiguration einen bestimmten takt halten kann.

Richtige Zeitberechnung geht von keinem Takt aus, sondern von der
verstrichenden Zeit, logisch ... wenn man das also konsequent durch
zieht, wird selbst der langsamste Rechner die richtige Geschwindigkeit
haben. Natürlich bringt es nix, wenn das Spiel mit nicht mals 5 Sekunden
pro Frame ... vor sich hin kricht. Das interessiert den Programmierer
aber nicht. ... Allerdings kann man natürlich erahnen, was nötig sein wird,
selbst ohne praktische Tests.

Natürlich können PCs auch zu schnell sein. Wenn nicht heute, dann wird
es vielleicht morgen so weit sein. Deswegen sollte man in diesem Fall
natürlich auch entsprechende Bremsen ein bauen, damit es nicht, wie es
heute schon lange bei einigen Klassikern der fall ist, dass Spiel davon
rennt.

MFG PMV

schau dir doch mal professionelle spiele an...

z.b. bei Civ4, da laufen die animationen und bewegungen in der framerate der grafik-engine,
und irgendwelche veränderungen der tile-belegung etc. finden nur im sekunden-takt statt.

es ist doch logisch, dass wenn man mehrere aufwendige engines in nem game hat,
dass man dann die logik-engine nicht mit der framerate prügelt,
sondern ihr nen langsameren takt gibt.

PMV hat geschrieben:Richtige Zeitberechnung geht von keinem Takt aus, sondern von der
verstrichenden Zeit, logisch ...

...richtige programmierer denken nach bevor sie lachen.

PMV hat geschrieben:wenn man das also konsequent durch
zieht, wird selbst der langsamste Rechner die richtige Geschwindigkeit
haben. Natürlich bringt es nix, wenn das Spiel mit nicht mals 5 Sekunden
pro Frame ... vor sich hin kricht. Das interessiert den Programmierer
aber nicht. ... Allerdings kann man natürlich erahnen, was nötig sein wird,
selbst ohne praktische Tests.

natürlich interessiert das den programmierer.
sonst sagt sein verleger ihm nämlich: wenn sie ein spiel schreiben, das hardware braucht, die erst in fünf jahren erschwinglich ist, dann kommen sie in fünf jahren mit ihrem spiel wieder.

aber is ok, mach du nur.
für irgendnen furz-ballergame reicht auch so ne primitive zeit ermittlung, die siebenunddreißig divisionen braucht anstatt sich ihre zeit von vorn herein einzuteilen.

Ich lache immer und überall, wann es mir gefällt
Wenn du nen schlechten Tag hast, lass es nicht an mir aus -.-

... Ob jede Engine im Spiel ihren eigenen Takt hat oder nicht hat nichts
damit zu tun, ob ein Spiel auf alten Rechnern noch vernünftig läuft oder
nicht. Natürlich muss der Programmierer dafür sorgen, das sein
Programm/ Spiel optimiert ist und schnellst möglich läuft. Aber davon
abgesehen ist es bei vernünftiger Zeitberechnung uninteressant, ob ein
PC zu schnell oder zu langsam ist. Mehr wollt ich nicht sagen ...

In der heutigen Zeit, wo alles mit Threads arbeiten muss, damit alle
Kerne ausgeschöpft werden können ... ist klar, das sich nur die
Grafikengine nach der Framerate richtet

MFG PMV

PMV hat geschrieben:Natürlich muss der Programmierer dafür sorgen, das sein
Programm/ Spiel optimiert ist und schnellst möglich läuft.

Kein Spieleprogrammierer der Geld verdienen will, optimiert sein Produkt wirklich richtig. Nach Möglichkeit wird ein Spiel schnellstens aus dem Boden gestampft, denn alles was lang dauert kostet Geld. Wenn das Spiel innerhalb der festgelegten Hardwarekonfiguration rennt, ist alles andere egal, sofern es nur schnell geht. Es gibt viele gute Games an denen zu lange entwickelt wurde, weil sie dadurch meist alt wirkten, floppten sie auch oft. Mittlerweile ist es sogar üblich, die Kunden des Produktes als Betatester zu mißbrauchen. Gerade die Highlights kommen oft unfertig auf den Markt.

Schon klar, trotzdem ist der Programmierer dafür verantwortlich. Nix
anderes hab ich geschrieben

MFG PMV