Hi,

ich bekomme es immer noch nicht hin..

Habe versucht das TimeBasedMovement aus dem Bomberman Tutorial zu verwenden, manchmal funktioniert es und manchmal funktioniert es nicht...

Meistens ruckelt es total und scheint viel zu große Sprünge zu machen und dann wie nach hinten zu laggen.

Hier die source:



Übrigens zeigt mir nen eingesetzter counter das die Geschwindigkeit der OnIdle Schleife auf ein zehntel reduziert wird wenn das Spiel gestartet wird (und es ist nur ein recht simpel umgesetztes Pong!)

Würde mich freuen wenn mir da jemand helfen kann.

Hallöle.
Also ich seh jetz auf die schnelle keinen fehler.
Aber du könntest ja mal dazuschreiben was du änderst damit es funzt und wie es sich verhält wenn du das TBM rausnimmst.

_________________
ghost-site.de

Also als Verbesserungsvorschlag fürs nächste Mal. Eine etwas genauere Beschreibung kann nie schaden vor allem da deine ein wenig wirr ist. Und Einrückungen im Code sind auch nicht zu verachten. Das ist nicht böse gemeint also versteh das bitte nicht falsch. Das sind aber alles Dinge die es uns einfacher machen dir eine Antwort zu geben. Und das ist ja dein erklärtes Ziel.

Bzw was meinst du damit, dass die Geschwindigkeit runter geht sobald ein Spiel gestartet wird? Erkläre das mal bitte für jemanden der deine Anwendung nicht kennt!

Aber wenn ich mir den Code so anschaue habe ich das Gefühl, dass deine Zeichenaktionen gar nicht in die Messungen mit einfließen. Gehen wir mal theoretisch an den Code.
- Du misst eine StartZeit.
- Du berechnest ein Delta anhand der Zeitwerte
- Du misst eine EndZeit

So gesehen mag das fast stimmt aber überlege mal welche Werte die StartZeit und die EndZeit zum Zeitpunkt der Berechnung haben. Die StartZeit wurde schon neu gemessen wärend die EndZeit noch "alt" ist. Somit beträgt deine gemessene Zeitspanne den Bereich den das Ende der Idle Methode bis zum Anfang der Idle Methode benötigt. Also zu gut Deutsch die Zeit die Windows zum Auslösen der Idle Methode benötigt. Deine Zeichnerei bleibt dabei vollkommen außen vor.

Zum Ändern genügt es, wenn du das Messen deiner StartZeit nach der Berechnung durchführst. Somit bekommst du für deine nächste Berechnung genau den Zeitbereich den du zum Zeichnen gebraucht hast. Du musst aber beachten, dass dadurch deine EndZeit wieder größer ist als die StartZeit. Sprich du musst das Vorzeichen davon nicht mehr umdrehen.

Ok, vielen Dank erstmal für deine Antwort. Ja ich sehe auch gerade das ich den Code schlecht formatiert habe, normalerweise mache ich das alleine damit ich durchsteige.

Das ganze ist ein Pong-Clone und ich zähle die OnIdle durchläufe, wenn ich nichts render also eigentlich garnichts in der Schleife ausgeführt wird ist sie 10 mal schneller als wenn ich rendere und ebend den Inhalt der Schleife ausführe.

Ich habe nun Start und End getauscht, das ganze sieht so aus:


Gerade lief es bei mir was ich als gutes Zeichen betrachte.

Vielen Dank für deine Hilfe.

OnIdle mit dem Rückgabeparameter Done auf False wird immer dann aufgerufen wenn deine Anwendung nicht zu tun hat. Wenn du also nichts zeichnest dann ist es doch logisch, dass es wesentlich schneller aufgerufen wird. Oder?

Hmmmm. An deinem Code hat sich rein gar nicht geändert außer, dass die Variablen vertauscht wurden. Das eigentliche Problem besteht aber doch weiterhin. Und zwar ist die Reihenfolge doch noch genau so wie ich es in meimen vorherigen Post beschrieben habe.

Um die ganze Sache mal abzukürzen hier mal der Code wie es eigentlich aussehen sollte.

Ah da hatte ich dich falsch verstanden.

Nun habe ich es wie folgt geändert:



Jedoch scheint das nichts zu ändern ausser das die Geschwindigkeit etwas runter geht. (Der Ball "lagt" immernoch daher ist mal etwas schneller und mal etwas langsamer und springt mir über die Kollisions-Abfrage hinweg)

Was gut sein könnte ist, dass die Round-Funktion mist rauswirft. Rundungsfehler können manchmal gaanz miese sachen machen. Sonst: Was ist DeltaT für ein Datentyp? Vielleicht ist der einfach zu ungenau, was vorallem bei dem PerformanceCounter heftig sein kann, da der ja wenn ich mich recht erinnere, ziehmlich genaue werte rauswirft.

(Außerdem noch ein Tipp: Nimm OpenGL, die Canvas-Funktionen sind zu lahm )

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also ich habe mal ein bisschen rumgespielt und bei dem Ball nur mal die X Werte durchgelassen bzw auch mal ein Sleep (30) eingefügt. Abgesehen davon, dass der Ball ziemlich schnell war konnte man sehen, dass die Bewegungen Gleichmäßig waren. Ich denke mal, dass das Problem da eher in deiner Kollision bzw den ganzen berechnungen liegt. Die schaue ich mir so jetzt aber mal nicht an.


Langsamer ja aber zu Lahm ist wohl eher Ansichtssache.

DeltaT ist ein single, habs gerade mal testweise auf double erweitert aber der Fehler bleibt.

Hm was könnte ich gegen Rundungsfehler machen? Habe das System im Rechnen igentlich immer für unfehlbar gehalten :S

Ja ich habe damit angefangen als ich noch kein OpenGl konnte, will es auch umschreiben, das kommt gleich nach OnIdle statt Timer und äh Internetfähigkeit

Sei froh das du nicht meine alte Source gesehen hast in der ich das Bild mit "canvast.lineto" in ner doppelten for to Schleife "geleert" hatte

EDIT:
@Lossy:
Ich habe bei mir gerade das selbe gemacht und der Ball ruckelt auch wenn ich nur die x Werte durchlasse. Und auch wnn ich den Inhalt der Kollision ausklammere.

ich würde die Zeit nur 1x pro frame messen, und immer die differenz zum vorherigen frame bilden. Außerdem würde ich DeltaT auf Zeiten zwischen 0 und 0.1 sec beschränken hier habe ich das ganze für gettickcount beschrieben, lässt sich jedoch leicht auf bessere counter umschreiben.

Addier mal:
4E-3
9E-1
9E-4
9E-2
4E-3
per Hand und du hast nur 2 Stellen zum Rechnen. An der Stelle wirst du merken, dass sogar simple Additionen Rechenfehler verursachen.

PS: Ich weiss das das Zahlenbeispiel doof ist

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Die Sache mit den Rundungsfehlern ist sogar noch viel Schlimmer:

Um den letzten Punkt zu beweisen, rechne man in 16 Stellen Genauigkeit:
1.0e20 + 17 -10 +130 - 1.0e20
Man permutiere die Reihenfolge der Summanden und erhält die Ergebnisse: 0, 120, 137, -10 und vielleicht noch ein paar mehr. (Das Beispiel ist aus M.Herrmann Numerische Mathematik. Hab ich mir nicht selbst aus den Fingern gesogen). Ein paar Beispiele für Katastrophen die aus solchen Rechnungen entstanden finden sich hier:
http://wwwzenger.informatik.tu-muenchen ... /bugs.html
Die Seite sollte man mal gelesen haben, wenn man mit Computern rechnet

Ihr überfordert mich!

Ich verstehe in keiner euren Rechnungn E, ich kenne nur x^e.. oder |E von |R

@The-Winner:
Ich messe die ja nur einmal pro frame, jeder durchlauf der OnIdle procedure sollte ja einer sein oder nicht?

Werde mir mal dein example angucken.

Edit:
Habs mal so umgeschrieben:

Die FPS Begrenzung habe ich rausgenommen da er dann garnix gemacht hat, aber CPU-Last ist zur Zeit eh mein kleineres Problem.

Das ganze bewirkt gerade das es eine extrem langsamme und ruckelige Bewegung gibt (durch die Geschwindigkeit ist es aber egal..) wenn ich die Berechnung für DeltaT wie früher mache und nur dein if DeltaT > 0.01 then.. reinpacke wird die Bewegung im verhältnis zu früher um einiges regelmäßiger aber auch um einiges langsamer.

das e bedeutet tatsaechlich soetwas wie hoch... In dem Fall naemlich 10hoch. So bedeutet 1.0e20, dass du 1.0 * 10^ 20 rechnest.

Zu den Rundungsfehlern. Klar kann das teilweise schon ganz "nette" Auswirkungen haben aber bei einem simplen Timebased Movement denke ich eher nicht, dass das groß ins Gewicht fällt. Und wenn dann auch nur weil die Berechnungen unnötig kompliziert sind. Von daher würde ich das Problem primär wo anders suchen wollen.

Eventuell sollten wir bzw. du mal eine andere Richtung einschlagen. Wäre es nicht besser, wenn du Testweise mal ein komplett leeres Projekt machst und dort einfach nur einmal testweise ein TimeBasedMovement implementierst. Und zwar für den Anfang nur erst einmal auf der X Achse. Immer von Links nach Rechts. Wenn das funktioniert kannst du einen Richtungsvektor mit einbauen. Und vor allem dann auch mal mit einem Sleep wärend des Zeichnens mal ein bisschen die Geschwindigkeit verändern auf, dass du testen kannst wie es sich bei unterschiedlichen Geschwindigkeiten verhält.

Das ganze würde ich aber so einfach wie möglich gestalten. Da denke ich liegt nämlich auch ein Problem. Ich habe deinen Code (außer das Timebased Movement) nur kurz überflogen aber was ich so gesehen habe sah viel zu komplex und nach viel zu vielen Berechnungen aus.

Ich sage damit nicht, dass du alles neu machen sollst. Ich will nur mal den unnötigen Balast beim Testen entfernen. Wobei wenn du das Movement mit einem Vektor hast dann hast du mehr oder weniger schon all das abgebildet was du in deiner Anwendung derzeit hast.


Gehört nicht ganz zum Thema ist meiner Meinung nach aber nicht ganz zu vernachlässigen.
Ich würde mir evtl auch ein bisschen etwas an den internen Strukturen überlegen. Du gehst an vielen Stellen davon aus, dass du nur genau so viele Objekte hast wie du dort im Code hast. Also im Speziellen die Methode Paint. Ein Ball und 2 Blöcke werden da rein gereicht. Das zieht sich überall komplett so durch. Die beste Möglichkeit dort etwas zu machen wäre es wenn du dynamischer arbeiten würdest. Also du hättest dann nicht für jedes Objekt eine eigene positions Variable sondern eine Liste in der du Objekte ablegst die eine Position haben. Beim Zeichnen würdest du durch die Liste gehen und alle Objekte dann zeichnen (Idealerweise würden das die Objekte selber machen da sie am Besten wissen was sie sind) und genau so bei der Kollision (Idealerweise würden das auch die Objekte machen). Dann musst du nicht alles mit allem vergleichen sondern gehst durch die Liste und vergleichst deinen Ball mit alle dem was sich dort befindet. So musst du nicht für alle Variablen das selbe machen sondern nur ein Mal. Das macht 1. den Code wesentlich übersichtlicher und 2. den Code nicht so Fehleranfällig, da du es mehr oder weniger nur ein Mal geschrieben hast und es sich auf alle Objekte ausdehnt.

Das aber nur mal als Anregung von mir. http://www.dsdt.info/tutorials/crashkurs/ In diesem Tutorial solltest du reichlich informationen finden. Besonders interessant sind die hinteren Seiten. Arrays und oder Objektorientierte Proggrammierung