framerate-unabhängige GameLoop

[PMV]

Was für dich absurt klingt, scheinen andere schon umgesetzt zu haben.
Oder was verbirgt sich hinter Optionen wie "GPU/CPU Syncronisation"
mit einem Schieberegler mit mehreren Stufen? Definitiv mehr als an/ aus.

Aber davon mal abgesehen, nur weil etwas 100% syncron ist, ist dadurch
die Parallelisierbarkeit nicht ausgeschlossen. Denk an den doppelten Screenpuffer.
Wenn es sich herrausstellt, dass ich tatsächlich so unschöne Microrukler im
Spiel hab, dann muss ich halt mit der selben Logik arbeiten, wie es beim
fertigen Bild passiert. Erst berechnen, dann kopieren, dann nächste berechnen
und gleichzeitig aus den kopierten Daten das Bild rendern.

MFG PMV

[AND51]

@ ZeHa

Interessanterweise habt ihr beide (AND51 und 7x7) eure Postings begonnen mit "ich programmiere keine Spiele, ABER". Ich selber programmiere schon seit Jahren Spiele und weiß, daß da manche Dinge einfach nicht so funktionieren, wie man sich das vielleicht naiverweise vorstellen mag.

solang ich davon keine vernünftige Implementierung sehe, die a) vom Code her sauber ist und b) tatsächlich nennenswerte Vorteile bietet in Performance oder was auch immer, bleibe ich bei meiner sequentiellen Variante, da ich mir aufgrund meiner eigenen Erfahrungen sicher bin, daß das die vernünftigere Entscheidung ist.

Alles klar, Meister. Wieso proklamierst du nicht gleich, dass du der King bist und nur mal wissen wolltest, ob wir deinen genialen Gedanken teilen? Die ganzen 5 Seiten hier hab ich keinen gesehen, dem du auch nur das kleinste bisschen zustimmst oder dessen Antwort du zumindest respektierst. Hätte ich gewusst, dass der einzige Sinn dieses Threads darin liegt, festzustellen, ob wir das gleiche denken wie du, hätte ich meine gaaanzen Beiträge sehr kurz fassen können: "Nein."

solang ich davon keine vernünftige Implementierung sehe

Die wirst du auch nie kriegen. Denn du hast hier ja auch keine vernünftige Implementierung abgeliefert, die hinreichend detailliert ist, damit auch "nicht-Spieleprogrammierer" wie ich deine Brillianz nachvollziehen können. Dein Hallo-Welt-Beispiel von Seite 1 beweist mir nichts mehr, als dass du die Syntax korrekt beherrschst.

Die render() Routine hat ein Delay(16) in der Schleife. So erreicht render() eine konstante Framerate!

Achso, Dein Renderer braucht null Millisekunden? Kannst Du mir den Code mal geben, sowas wollte ich schon immer mal haben

Nein, den Code behalte ich lieber. Ein gestandener Spieleprogrammierer wie du hat es nicht nötig, bei "mir" abzuschauen.

Mal im Ernst: Du zeigst hier deine volle Intoleranz gegenüber nicht so erfahrenen Programmierern im Spiele-Bereich. Ich habe versucht meinen Beitrag so simpel wie möglich zu halten und sogar mehrmals ausdrücklich gesagt, dass ich kein Experte auf dem Gebiet bin (wer lesen kann...). Ist doch klar, dass ich nicht an jede letzte Kleinigkeit denke. Bei diesem Diskussionsverlauf war ja zu erwarten, dass du mich selbst beim kleinsten Schnitzer schon auseinander nimmst. Kommentare dieser Art kannst du dir sparen, mein Freund. Dieser signalisiert mir, dass du meine weitere Anwesenheit in diesem Thread (oh, ich habe schon wieder das böse Wort gesagt!) nicht länger wünschst.



Das beste zum Schluss:

• Interessanterweise habt ihr beide (AND51 und 7x7) eure Postings begonnen mit "ich programmiere keine Spiele, ABER".

  Tut mir leid. Ich muss irgendwo das Schild am Eingang übersehen haben: "Geschlossene Gesellschaft - Nur Spieleprogrammierer".
  Bitte sorge doch dafür, dass ich es nächstes Mal nicht übersehe, ja?

[ZeHa]

Schon wieder beleidigte Leberwurst?

Die ganzen 5 Seiten hier hab ich keinen gesehen, dem du auch nur das kleinste bisschen zustimmst oder dessen Antwort du zumindest respektierst.

Dann hast Du nicht richtig gelesen.

Hätte ich gewusst, dass der einzige Sinn dieses Threads darin liegt, festzustellen, ob wir das gleiche denken wie du

In meinem Thread geht es um eine Optimierung der "anerkannten" Standard-GameLoop. Hab ich auch schonmal gesagt. Und daß man das Multithreading-Gedöns auch mal in einen anderen Thread verschieben könnte (und daß ich die Diskussion darüber sogar "respektiere"), habe ich auch gesagt.

Denn du hast hier ja auch keine vernünftige Implementierung abgeliefert

Das ist meine Implementierung. Das eigentliche Spiel steckt nunmal in den Funktionen render(), update() und controls().

Du zeigst hier deine volle Intoleranz gegenüber nicht so erfahrenen Programmierern im Spiele-Bereich.

Ich habe mehrfach versucht, anhand von einfachen Beispielen und Erklärungen zu verdeutlichen, warum Multithreading nur in manchen, aber nicht allen Fällen sinnvoll ist. Diese Fälle habe ich auch erklärt.

Ich habe versucht meinen Beitrag so simpel wie möglich zu halten und sogar mehrmals ausdrücklich gesagt, dass ich kein Experte auf dem Gebiet bin (wer lesen kann...)

Hab ich gelesen! Und sogar zitiert. Aber das interpretierst Du dann ja leider als "Nicht-Spieleprogrammierer sollen draußen bleiben".

Lies Dir doch nochmal Deine eigenen Beiträge durch, in denen Du mich teilweise hinstellst, als hätte ich noch nicht einmal verstanden, was ein Thread überhaupt ist. Genialer Meister.

[NicTheQuick]

Ich würde vorschlagen, dass ihr euch alle mal in die Thematik der Multithreading-Programmierung einliest bevor ihr wild herum spekuliert, ob es gut oder schlecht ist und wie man die Threads am besten miteinander verbindet. Mir scheint ihr habt da alle keine Ahnung von. Tut mir Leid das jetzt sagen zu müssen, aber so ist es leider. Studiert jemand von euch Informatik und hat Vorlesungen zur nebenläufigen Programmierung gehört und schon verteilte System programmiert?

Ihr könnt hier jetzt wild weiter 'rum spinnen, aber ich glaube da wird nichts vernünftiges bei heraus kommen. Ein paar haben schon begriffen, wo die Vorteile liegen und würden sie wohl richtig einsetzen. Leider fehlen euch noch viele Techniken, die bereits existieren und die die Threadkommunikation sicher machen. Ein bisschen Einlesen hilft. Da gibt es tonnenweise Material im Internet. Das Auslagern von Eingabe, Berechnung und Ausgabe in verschiedene Threads ist durchaus sinnvoll. Soviel ist sicher.

[DarkDragon]

Das Auslagern von Eingabe, Berechnung und Ausgabe in verschiedene Threads ist durchaus sinnvoll. Soviel ist sicher.

Ja, aber das alleinige auslagern in einen Thread löst das Problem um das es in diesem Thema geht nicht. Jeder weitere Threads muss auch auf die Zeit achten und das gilt es hier ja zu vermeiden bei einer "framerate-unabhängigen GameLoop".

[ZeHa]

Ja ich bin Informatiker und programmiere auf Arbeit schon seit Jahren multithreaded stuff, blabla. Meiner Meinung nach geht es eher darum, ob das Thema Multithreading in diesem Kontext überhaupt sinnvoll ist. Jeder weiß, wie die Spiele ungefähr aussehen, die sich hier im Forum so tummeln, und das sind in 100 von 100 Fällen Spiele, die weder Multithreading noch "Techniken, die die Threadkommunikation sicher machen" nötig haben. Du fängst jetzt schon an, von "verteilten Systemen" zu reden.

Wo soll das ganze Multithreading-Gefasel denn hier noch hinführen? PMV (der hier weniger emotional mitdiskutiert) hat doch trotz Thread-Befürwortung auch schon gesagt, daß der Code möglicherweise unnötig komplex würde. Als Beispiele wurden hier auch schon Dinge wie Crysis o.ä. genannt. Während hier im Forum reihenweise Pacman- und Waponez-Clones entstehen.

Kennt hier jemand das Sprichwort mit den Kanonen und den Spatzen?

PS: Zudem möchte ich (speziell AND51) nochmal drauf hinweisen, daß ich am Ende lediglich gesagt habe, daß ich persönlich bei meiner single-threaded Version bleibe, solange mich keiner mit einer Implementierung eines besseren belehrt. Damit respektiere ich sehr wohl eure Ideen und sage auch nicht, daß sie definitiv Müll sind, ich sage nur daß ich mir (aufgrund meiner persönlichen Erfahrungen! und sogar mit Erläuterung!) im Moment nicht vorstellen kann, daß das unterm Strich die bessere Alternative ist.

[DarkDragon]

[Witz]Ich frag mich wo die Starvation für dieses Thema hier im Forum bleibt ... . [/Witz]

[EDIT]
Ich wusste aber, dass NicTheQuick sich dazu äußern wird und dass er auf der Seite der Threads steht. Er hat nämlich exakt sowas mal gemacht in einem der älteren Foren wo Rob noch dabei war. Jedoch auch ohne jegliches Timing soweit ich mich erinnern kann.

[NicTheQuick]

Ich wusste aber, dass NicTheQuick sich dazu äußern wird und dass er auf der Seite der Threads steht. Er hat nämlich exakt sowas mal gemacht in einem der älteren Foren wo Rob noch dabei war. Jedoch auch ohne jegliches Timing soweit ich mich erinnern kann.

Du kannst dich daran noch erinnern?

Ja, aber das alleinige auslagern in einen Thread löst das Problem um das es in diesem Thema geht nicht. Jeder weitere Threads muss auch auf die Zeit achten und das gilt es hier ja zu vermeiden bei einer "framerate-unabhängigen GameLoop".

Hm... Aber framerate-unabhängig bedeutet doch auch, dass die Spiellogik immer gleich schnell läuft und die FPS erst mal egal sind. Aber da wart ihr doch sogar schon im Verlauf dieses Threads (Haha, Wortspiel).

Kennt hier jemand das Sprichwort mit den Kanonen und den Spatzen?

Ähm... Ja... Kenne ich. Das trifft hier auch eindeutig zu.

Ich dachte nur ich erwähne, dass es schon genügend Problemlösungen im Threadbereich gibt. Wahrscheinlich gibt es sogar extra Paper für Game-Loops und deren Modularisierung und Verteilung in Threads.
Und ja, verteilte System sind etwas weit her gegriffen. Aber im entferntesten Sinne könnte man es ja mit einem Netzwerkspiel vergleichen, dass auf Server und Clients konsistent und schnell bleiben muss, auch wenn plötzlich ein Client abschmiert.

[7x7]

@ZeHa:
Es ist ja in Ordnung, wenn du bei deiner Single-Threadet-Programmierung bleibst, solange alles schnell genug auf
deiner 5GHz-Maschine läuft.

[ZeHa]

Noch einer, der nicht richtig lesen kann