spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »289_29689«

Ja ich benutze SFML 1.6 und ich versuche schon seit 2 Monaten eine Lösung zu finden. Was wäre deiner Meinung nach die beste Lösung? Boost? Ich wäre sehr gerne Plattform unabhängig.

Kannst du nicht einfach auf SFML 2.0 umsteigen?

Zitat von »289_29689«

Mit andere Syntax mein ich die mit: sf::Thread Thread(void(Game::OnEvent)(),Game *theGame); Würde die überhaupt etwas bewirken?

Hab dir doch schon zweimal gesagt was das bewirkt

wenn du keine Lust hast von sfml 1.6 auf 2.0 umzusteigen dann könntest du eine kleine "Wrapperfunktion" für den Thread schreiben ala:

In deiner Main:



und deine Wrapper Funktion:




aber ich würde dir lieber raten auf sfml 2.0 umzusteigen oder etwas anderes zu benutzen (wie z.b. Boost).

Du könntest auch einfach von sf::Thread erben und die runmethode definieren. Hättest du dir die Tutorials auf der SFML Seite angeschaut, hättest du das Problem nach 10 Minuten gelöst

Nur weil du weißt was OOP, Threads und Zeiger sind, heißt es nicht, dass du damit umgehen kannst.

Threads müssen synchronisiert werden. Wenn dein Zeichnenthread gerade ein Objekt zeichnen will, dass der Eventthread gerade löscht kommen gemeine Fehler zustande.
Schon die Namen deiner Threads zeugen davon, dass du nicht weißt was du tust.
Wofür benötigst du die Nebenläufigkeit eigentlich? Läuft dein Spiel so langsam?

Ich schau mir grad eine Vorlesungsreihe vom MIT zu dem Thema an: http://ocw.mit.edu/courses/electrical-en…otes-and-video/

Vielleicht hilfts dir ja weiter

Zitat von »289_29689«

Dafür gibt es ja dann die Mutexes oder habe ich da etwas falsch verstanden?

Ja, dafür sind die da. Allerdings werden deine Threads mehr warten als arbeiten. Das wird dein Programm im Endeffekt langsamer machen.

Zitat von »289_29689«

Ich wusste nicht, dass SFML 1.6 das nicht kann. Ich werde auf Version 2.0 umsteigen.

Zitat von »NachoMan«

Du könntest auch einfach von sf::Thread erben und die runmethode definieren. Hättest du dir die Tutorials auf der SFML Seite angeschaut, hättest du das Problem nach 10 Minuten gelöst

du meinst mit void Run(){}. Da kann ich aber dann nur einen Thread starten.

Du müsstest ja auch mehrere Klassen erstellen. Für jeden Thread eine
Das ist auch sinnvoll, weil Threads sehr stark voneinander getrennt sein sollten. D.h. sie sollten einander nur über ein einziges Interface beeinflussen können um das Synchronisierne zu vereinfachen. Was auch die Erklärung dafür ist, dass die Namen deiner Threads verraten, dass du nicht weißt was du tust.

Zitat von »289_29689«

Zitat von »NachoMan«

Wofür benötigst du die Nebenläufigkeit eigentlich? Läuft dein Spiel so langsam?

Zitat

Als ich dann eine Klasse für Buttons geschrieben habe und das ganze mal
zum Debuggen gestartet habe, habe ich festgestellt, dass das
Event-Handling nicht lückenlos funktioniert. Damit meine ich, dass es
teilweise ein ziemliches Delay gab. (Ich habe auch sf::Input probiert,
ohne erfolg) Deshalb die Entscheidung zum Multithreading.

...

Selbst wenn ich mir die Threads sparen könnte möchte ich zumindest wissen warum es nicht funktioniert, denn früher oder später werde ich mal Threads brauchen.

Ich habe inzwischen gelesen, dass ich das Programm mal nicht im Debug Modus ausprobieren soll. Meistens wird auch das Bild nicht gerendert, also das Spiel stürzt einfach ab. Egal ob Release oder Debug. Ich glaube das liegt an meinem Laptop, der hat ziemliche Überhitzungsprobleme und dann noch eine Virtuelle Maschine(Ich programmiere in einer VM damit ich wenn irgendetwas nicht richtig funktioniert nicht wieder mein Hauptsystem neu aufsetzen muss(z.B. eine Bibliothek wird nicht richtig installiert etc.)) Wenn ich den Projektordner aus der VM auf meinen echten PC kopiere dann kann ich das Programm nicht starten. Es passiert einfach nichts. Auch sf:leep(1) habe ich schon im Programm.

Die Ursache für die Verzögerung ist doch die VM und deinem Laptop, nicht der Code. Es ist nicht verwunderlich, dass die Eingabe verzögert ist, egal wie schnell das Programm läuft.
Wenn dein Programm ohne VM nicht läuft solltest du erstmal dieses Problem lösen bevor du es mit Threads noch komplexer machst.

Wenn du nicht nicht allzu dumm anstellst dürfte es kein Problem sein ohne VM zu entwickeln.

Wenn ein Auto nicht fährt, weil keine Reifen montiert sind, installierst du doch auch keinen Raketenantrieb um es zu reparieren...

Eigentlich muss das nicht installiert werden. Du müsstest höchstens die dlls in den Ordner verschieben.
Kompiliere die SFML ausserhalb der VM einfach neu. Musst du ja sowieso mit SFML2.0.

Zitat von »289_29689«

Zitat

D.h. sie sollten einander nur über ein einziges Interface beeinflussen können um das Synchronisierne zu vereinfachen.

Wie könnte ein solches Interface aufgebaut sein?

Ein Beispiel für einen sinnvollen Thread ist das nebenläufige Laden von Resourcen(Images, Sounds usw.)
Bei größeren Spielen kannst du zuerst alle Grafiken für das Menü laden. In der Zeit, in der der Spieler das Menü bedient kannst du die restlichen Resourcen für die Level in einem Thread laden.

Achja, Ubuntu xD
Starte das Programm über das Terminal. Dann sollte er dir das Problem anzeigen