Feste Spielgeschwindigkeit

Pikkolini

RedPuma schrieb:

Also zuerst ein Tipp zu Leserlichkeit, ich würde anstatt der Hexzahlen in dem Case-Statement auch die VK_* Definitionen einsetzen.

Danke für den Tip, das werde ich machen

RedPuma schrieb:

Zu deinem Problem: Das sich das Objekt sehr viel langsamer bewegt ist doch laut deinem Funktionsaufruf gewollt oder? Da rufst du nämlich die Funktion bei allen andern Keys außer VK_DOWN mit 10 anstatt 100 pps auf.

Das habe ich total übersehen
War halt schon was später und ich war müde, und hab mich dabei nurnoch auf den Code von der move-Funktion konzentriert.
Das Zittern sehe ich in der Form eines "Schweifes" immernoch. Also Die Kanten werden 2 mal gezeichnet. Eine die man immer sieht, die zweite um einen Pixel verschoben, welche flackert.
Ein Rundungsfehler kann natürlich die Ursache sein, aber ich weiß nicht genau wie C++ da rechnet.
Wenn ich als Auflösung den Wert 2.7936511484001459e-007 habe, rechnet das System dann so:
1 * 0,00000027936511484
oder so:
1 * 0,00000027936511484001459
Und da bei Microsoft ein long double das gleiche wie ein double ist, weiß ich auch nicht wie ich das genauer hinbekommen soll.

RedPuma

Öhm das mit der Genauigkeit bei Fließkommazahlen ist eine ganz eigene Geschichte, die sind nämlich in der "Mitte", also um 0 herum am genausten. Nach "Außen" werden die etwas ungenauer, ist aber egal weil du dich hier ja um die 0 rum befindest.

Ich hatte schonmal geschrieben dass durch die 1/frequency Rechnerrei und anschließende Multiplikation eventuell Rundungsfehler entstehen könnten. Du könntest mal ausprobieren den Frequency Wert direkt zu speichern und dann durch diesen zu teilen.

Andreas XXL

Hier eine Verdeutlichung des Problems einen Sprung ohne feste Anzahl an Rechenschritten zu berechnen.

Ein schneller Rechner schafft mehr Approximationsschritte (die kürzer sind) als ein langsammer Rechner.

Das Problem ist aber, dass bei einer guten Approximation einer Kurver durch Strecken, die Summe dieser Strecken größer ist als bei einer schlechteren Approximation.
Das hat zur Folge das die Sprunghöhe auf einem schnellen und langsammen Rechner nicht gleich ist, wenn der Scheitelpunkt der Kurver z.B durch Aufaddieren der Streckenabschnitte berechnet wird.

Bild:
http://img716.imageshack.us/img716/1867/approximation.jpg
(Das Bild ist nur eine Skizze und entspricht nicht den mathematisch exakten Höhenverhältnissen)

rapso

ja, wenn man sich ein wenig damit beschaeftigt, wird einem klar weshalb variable zeitschritte sehr instabil sein koennen (lernt man eigentlich auch im physik unterricht wenn man beschleunigung usw durcharbeitet).

und dass selbst feste zeitschritte oft nicht genug sind wird hier erklaert:
http://wiki.vdrift.net/Numerical_Integration

deswegen laeuft wohl jede physic engine mit festen zeitschritten (bzw mit maximalen schritweiten und einem guten solver).

hustbaer

Pikkolini schrieb:

Das Zittern sehe ich in der Form eines "Schweifes" immernoch. Also Die Kanten werden 2 mal gezeichnet. Eine die man immer sieht, die zweite um einen Pixel verschoben, welche flackert.

Kannst du deinen Code mal irgendwo hochladen?
Vielleicht liegt es auch einfach nur an der Art wie du zeichnest.

Pikkolini

@RedPuma
Du hast recht, direkt durch die Frequenz zu teilen geht auch und ist auch viel sinnvoller
Allerdngs behebt die Änderung das Problem überhaupt nicht.

@hustbaer
Das Objekt zeichne ich so:

glColor3ub(233,221,175);
glBegin(GL_QUADS);
	glVertex2d(x,			y);
	glVertex2d(x + width,	y);
	glVertex2d(x + width,	y + height);
	glVertex2d(x,			y + height);
glEnd();
glColor3ub(255,0,0);
glBegin(GL_LINE_STRIP);
	glVertex2d(x,			y);
	glVertex2d(x + width,	y);
	glVertex2d(x + width,	y + height);
	glVertex2d(x,			y + height);
	glVertex2d(x,			y);
glEnd();

Oder was meinst du?
Dabei fällt mir auch direkt eine Frage ein, und zwar wieso zeichnet GL_LINE_STRIP oder GL_LINES kein Viereck, sondern lassen eine Ecke immer aus. Also das ein Pixel an der Ecke fehlt.

@den Rest
Anscheindend ist es wirklich nicht sinnvoll, variable Zeitschritte zu nehmen. Also habe ich mich jett entschlossen 2 Threads zu machen.
Aber bevor ich mich da einarbeite, habe ich dazu noch eine Frage. Ist es möglich eine globale Klasseninstanz in 2 verschiedenen Threads zu "bearbeiten"?

hustbaer

Pikkolini schrieb:

@hustbaer
Das Objekt zeichne ich so:

glColor3ub(233,221,175);
glBegin(GL_QUADS);
	glVertex2d(x,			y);
	glVertex2d(x + width,	y);
	glVertex2d(x + width,	y + height);
	glVertex2d(x,			y + height);
glEnd();
glColor3ub(255,0,0);
glBegin(GL_LINE_STRIP);
	glVertex2d(x,			y);
	glVertex2d(x + width,	y);
	glVertex2d(x + width,	y + height);
	glVertex2d(x,			y + height);
	glVertex2d(x,			y);
glEnd();

Oder was meinst du?

Ich meine sind x, y, width, height Integers oder Floats, ist irgend ein Super-Sampling (Antialiasing) an oder nicht, ...?
Falls du ohne Antialiasing renderst, und die Koordinaten floats sind, probier einfach mal die Koordinaten vor dem Rendern auf Integer zu casten. Also...

int xi = x;
int yi = y;
int x2i = xi + width;
int y2i = yi + height;

glColor3ub(233,221,175);
glBegin(GL_QUADS);
	glVertex2d(xi, yi);
	glVertex2d(x2i,	yi);
	glVertex2d(x2i,	y2i);
	glVertex2d(x, y2i);
glEnd();
glColor3ub(255,0,0);
glBegin(GL_LINE_STRIP);
	glVertex2d(xi, yi);
	glVertex2d(x2i,	yi);
	glVertex2d(x2i,	y2i);
	glVertex2d(x, y2i);
	glVertex2d(xi, yi);
glEnd();

Also habe ich mich jett entschlossen 2 Threads zu machen.

Hihi, wie du meinst.

Aber bevor ich mich da einarbeite, habe ich dazu noch eine Frage. Ist es möglich eine globale Klasseninstanz in 2 verschiedenen Threads zu "bearbeiten"?

Ja, aber nicht ohne Synchronisierung. Wobei ich "globale Klasseninstanz" schonmal lustig finde, keine Ahnung was ich mir darunter genau vorstellen soll. Ich hab es einfach mal als "ein und das selbe Objekt in zwei Threads bearbeiten" interpretiert.

Pikkolini

Antialiasing ist nicht an. Wenn ich die Werte auf Integer caste, ruckelt das alles etwas.
Also wenn sich das Objekt bewegen soll steigt der x Wert nicht konstant sondern das ganze sieht so aus:
1 2 3 4 3 5 6 7 8 7 9
Das Objekt wird also immer "zurückgeworfen".

Naja ich arbeite mich mal heute in Thread ein. Mal schauen was ich dann später davon habe

hustbaer

Also zurück springen dürfte er NIE, sonst machste irgendwas echt falsch. Behaupte ich mal

Pikkolini

Ich habe jetzt mal ein paar Videos aufgenommen und analysiert, und springen tut er wirklich nicht, das ist nur eine optische Täuschung. Allerdings ist mir aufgefallen, dass wenn ich mit 60 fps aufnehme (mein Bildschirm hat 60 Hz), das Objekt sich zwar jede Sekunde wirklich einen Pixel bewegt, aber einige Bilder scharf und einige unscharf sind.
Woran liegt das eigentlich?

hustbaer

Daran dass du nicht auf Integers rundest, und vermutlich deine Texturen gleich gross sind wie der Platz den sie am Bildschirm einnehmen.

Entweder auf Integer runden, oder grössere Texturen verwenden.

Pikkolini

Ich verwende garkeine Texturen bei dem Zeichencode steht ja auch nichts von glTexCoord2f oder so.
Und wenn ich auf Inteher runde, ruckelt es mehr als das es zittert.

hustbaer

Hihi, OK, nicht weit genug mitgedacht.
Allerdings... wenn direkt die Kanten/Linien unscharf werden, dann muss fast irgend eine Art Antialiasing aktiv sein. Mir fällt auf jeden Fall nichts ein was sonst dazu führen könnte (dürfte) dass Kanten unscharf werden.

Wenn du es selbst nicht aktivierst, ... vielleicht die Default-Einstellung im Treiber?

Pikkolini

Ich habe jetzt mal Antialiasing mit glDisable(GL_LINE_SMOOTH) und GL_POLYGON_SMOOTH ausgeschaltet. Etwas anderes wie ARB Multisampling etc. existiert im Code gar nicht. Aber das wäre auch nicht der Sinn der Sache, wenn ich Antialiasing auschalten müsste.
Wie gesagt arbeite ich mich jetzt in Threads ein, und lasse die logischen Berechnung getrennt vom rendern mit festen Zeitschritten ablaufen. Aber was passiert dann eigentlich wenn der Computer nicht schnell genug ist, um z.B. alle 10 ms die logischen Schritte zu berechnen?

hustbaer

Pikkolini schrieb:

Ich habe jetzt mal Antialiasing mit glDisable(GL_LINE_SMOOTH) und GL_POLYGON_SMOOTH ausgeschaltet. Etwas anderes wie ARB Multisampling etc. existiert im Code gar nicht. Aber das wäre auch nicht der Sinn der Sache, wenn ich Antialiasing auschalten müsste.

Du hast erwähnt dass einige Bilder scharf und andere unscharf sind. Antialiasing macht "unscharfe" Bilder. Natürlich musst du es deswegen nicht ausschalten

Könnte natürlich auch sein dass einfach nur der Video-Codec schuld an den unscharfen Bildern ist.

Wie gesagt arbeite ich mich jetzt in Threads ein, und lasse die logischen Berechnung getrennt vom rendern mit festen Zeitschritten ablaufen.

Mach das ruhig, wird nur vermutlich nix bringen.

Aber was passiert dann eigentlich wenn der Computer nicht schnell genug ist, um z.B. alle 10 ms die logischen Schritte zu berechnen?

Na was soll passieren, dein Spiel läuft dann zu langsam.

Pikkolini

hustbaer schrieb:

Pikkolini schrieb:

Wie gesagt arbeite ich mich jetzt in Threads ein, und lasse die logischen Berechnung getrennt vom rendern mit festen Zeitschritten ablaufen.

Mach das ruhig, wird nur vermutlich nix bringen.

Ein paar Seiten vorher wurde in dies noch als beste Methode angepriesen und du willst mir jetzt sagen das bringt nichts?

Aber was passiert dann eigentlich wenn der Computer nicht schnell genug ist, um z.B. alle 10 ms die logischen Schritte zu berechnen?

Na was soll passieren, dein Spiel läuft dann zu langsam.

Hmm hast rechts das tuts ja eig immer, wenn der PC zu langsam ist.

hustbaer

Pikkolini schrieb:

hustbaer schrieb:

Pikkolini schrieb:

Wie gesagt arbeite ich mich jetzt in Threads ein, und lasse die logischen Berechnung getrennt vom rendern mit festen Zeitschritten ablaufen.

Mach das ruhig, wird nur vermutlich nix bringen.

Ein paar Seiten vorher wurde in dies noch als beste Methode angepriesen und du willst mir jetzt sagen das bringt nichts?

Nicht von mir.

Grundsätzlich ist die Methode schon gut, nur ich bin mir sicher dass du die Probleme die man damit Lösen kann einfach nicht hast.

Pikkolini

Also stehe ich hier vor einem unlösbaren Problem?
Aber mittlwerweile ist es mir fast egal, da ich endlich mal weiter kommen will.

hustbaer

Pikkolini schrieb:

Also stehe ich hier vor einem unlösbaren Problem?
Aber mittlwerweile ist es mir fast egal, da ich endlich mal weiter kommen will.

Ziemlich sicher nicht. Nur wie sollen wir dir sagen was du falsch machst wenn wir den Code nicht sehen?
Hab ja schon vorgeschlagen dass du den Code irgendwo uppen könntest, dann könnten wir drüber gucken. Wesentlich effizienter als zu raten und kleine Informationsstücke jedes mal umständlich nachfragen zu müssen.

Pikkolini

So ich habe jetzt mal den Sourcecode und die .exe hochgeladen.
Link