Hi...
Beim anschauen von ein paar Artikeln aus dem Wiki ist mir der Timebased Movement Artikel aufgefallen...

Wäre es nicht eigentlich Zeit ihn mal zu überarbeiten?
Zum einen finde ich das der Code nicht unbedingt das Gelbe vom Ei ist (insbesondere als Anfänger der von Flashs Tutorial auf den Artikel kommt, ist man wahrscheinlich danach verwirrt), zum anderen wäre es vielleicht an der Zeit zu klären ob eine absolute Genauigkeit per Hardware jetzt immer möglich ist, oder nicht, denn das ist nicht gerade vertrauenserweckend:

Außerdem meinte Magellan ja in diesem Topic das man von eienr Lösung mit GetTickCount absehen sollte, während das Wiki ja genau diese Möglichkeit vorschlägt.

cya,
Deathball

Ich für meinen Teil würde den Code aus dem Wiki folgendermaßen ersetzen:


Dann würde ich noch hinzufügen das man den Speedfactor mit sämtlichen Bewegungen/Bewegungsvektoren multipliziert.



Das ist imho eine verständlichere Variante, die eigentlich auch Anfänger die sich von Flashs Tutorial dorthin geklickt haben verstehen.
Interessieren würde mich jetzt allerdings ob ihr das genauso seht oder anderer Meinung seid...

cya,
Deathball

Sieht soweit gut aus.

Habe den Artikel überarbeitet. Werde evt. noch mehr machen. Aber nur zu, es ist ein Wiki bei dem jeder etwas ändern darf der möchte.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Ist es unter umständen nicht gescheiter mit timern (zb den sdl timern) oder eben anderen treads zu arbeiten, anstatt das ganze über rechnungen zu machen?

_________________
bester uo-shard: www.uosigena.de

Die Auflösung von Timern ist auch beschränkt, Threads sind nominell besser, denoch existiert dann das Problem der Synchronisierung.

wie meinst du das problem der synchronisierung?

_________________
bester uo-shard: www.uosigena.de

Wenn wir als Beispiel das Sonnensystem nehmen, dann hat die Erde ja einen Winkel.
Bei dem Code aus dem Wiki macht man einfach bei jedem Rendern:


Bei Threads hättest du einen Thread der ungefähr so aussieht:

Das Problem tritt bei dem Beispiel und der 32-Bit-Zahl weniger auf, aber spätestens bei grösseren Sachen besteht die Gefahr. Und zwar folgende:
Der Thread hat ein Teil des Winkel aktualliert, z.B. die ersten 16-Bit, die restlichen 16 sind noch alt. Dann unterbricht das OS und gibt die Zeit an den zweiten Thread bzw. deinem Rendercode, der dann aus Winkel absoluten Müll ausliest, weil absoluter Müll drinnen steht. Und genau das ist das Syncronisationsproblem.
Genaueres steht im Tutorial_Multithreading.

Auch ist mir beim Schreiben des Beispielcodes aufgefallen, dass der Code so immer noch Schwachsinn ist und man denoch bei sleep nen Zeitfaktor einbauen muss.

ahh ich weiss was du meinst, aber wenn das zeug 25-40 frames /s hat, dann sollte das kein problem mehr sein, zb bei partikeleffekten, denn ab 25 frames siehst du keinen unterschied mehr ob noch was geändert wurde oder nicht. ab dann läuft das spiel flüssig.

_________________
bester uo-shard: www.uosigena.de

Da bisher noch keiner was gegen meinen Code gesagt hat und Flo mich ermutigt hat werde ich demnächst den Code bei dem entsprechenden Abschnitt abändern...


der eigentliche Grund für den Post hat sich erledigt


cya,
Deathball