JLI Spieleprogrammierung

[PeaceKiller]

[Fallen]

Oblivion ist der Nebenname, Morrowind der Hauptname Jonathan hat schon recht, auch wenn er es nicht eindeutig sagte.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Jonathan_Klein]

hm, heißt die Reihe nicht "The Elders Scrolls" oder so?
Ist ja auch egal, ich hatte die Illusion irgendwo gehört zu haben, der würde in nem seperaten Thread laden, aber wenn man zu schnell ist muss der halt doch manchmal Pause mache, also Ladebildschirm anzeigen.
Keine Ahnung, ist ja auch egal, auf jeden Fall scheint das eine elegante Lösung zu sein. Achja, Dungeon Siege benutzt das dann doch garantiert auch, die haben doch früher damit Werbung gemacht, dass man durch das ganze Spiel laufen kann, ohne einen einzigen Ladebildschirm zu sehen.
_________________
https://jonathank.de/games/

[PeaceKiller]

[Fallen]

Das Konzept dahinter kann ja auch eigentlich gar nicht so komplex sein.

zB denkt man sich die Welt besteht aus Quadranten (oder Kuben) am Anfang werden einfach alle 8 Quadranten um den Spielerquadrant herum geladen, bewegt sich der Spieler auf einen anderen Quadranten so wird im Hintergrund begonnen die neuen Angrenzenden Quadranten zu laden (max 5).

Solange das im Hintergrund geschieht und keine Teleports stattfinedn (min 2 Quadranten) so entsteht der Eindruck alles besteht aus einen Guss.

Sowas merkt man evtl recht gut an Gothic (2) benutzt man zB einen der teleportersteine später im Spiel wird die Welt um den neuen Spielerpunkt herum langsam wieder aufgebaut, man kann förmlich dabei zusehen wie die Texturen zugewiesen werden, nach dem "Ladeprozess" fängt das Spiel erst wieder an flüssig zu laufen.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[GreveN]

FarCry ist afaik auch ein schönes Beispiel für Multithreading, in dem Game muss der Performancezuwachs auf entsprechenden CPUs sogar richtig merklich gewesen sein.

Fallen:
Jupp, sowas Ähnliches habe ich mir auch mal überlegt. Man "tilet" quasi die die Tilemap nocheinmal.

Btw.: Multithreading soll soweit ich weiß fest mit in den Standard aufgenommen werden, es ist also damit zurechnen, dass sich da in Zukunft noch viel tun wird, bzw. die Nutzung einfacher wird.

[Fallen]

War FarCry nicht das Paradebeispiel für 64Bit? In der die GrafikkartenHersteller sowie die ProzessorHersteller gemeinsam den Code optimierten mit Crytek?

Was ist denn an Threads erstellen bisher so schwer?

Erstellen, ausführen, evtl "locken" und am ende beenden.

Fand das bisher schön simpel und vor allem funktionierend, oder hast du da etwas anderes im Sinn?
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[GreveN]

Ja, aber wenn du bisher auf externe Libs verzichten willst, die dir das Leben in der Hinsicht vereinfachen, dann bist du gezwungen direkt auf der jeweiligen Plattform-API zu arbeiten, was natürlich besonders unschön ist, wenn du nach Möglichkeit portabel bleiben und auf plattformspezifische Libs wie die WinAPI verzichten willst und nicht gerade Lust hast, dir den ganzen Mist für jede Plattform zu wrappen. Noch dazu würde das vielleicht helfen, dem (ungerechtfertigt) "schlechten Ruf" (z.B. schwierig in der Nutzung, unsicher, blabla...) entgegen zu wirken und Threads endlich "massentauglich" zu bekommen. Von daher, und weil es so wie ich es aufgefasst habe, keine direkte Sprachneuerung sein wird, stehe ich dem Ganzen optimistisch gegenüber.

[Dragon]

Threads sind nciht schwer, nur richtig und effektiv damit umzugehen um so mehr. Ich hab auch mal eine Thread-Klasse geschrieben. Ist nie richtig fertig geworden, weil ich die doch nicht gebrauch hatte.

[xardias]

Threading kann eine verdammt nützliche Sache sein. Jedoch sollte man bedenken dass es extrem schwierig Multi Threading Anwendungen zu schreiben. Wenn man nicht speziell synchronisiert muss man davon ausgehen dass zwischen jeder Codezeile ein andere Thread Variablen ändern könnte, das macht das ganze extrem Fehleranfällig, und man muss sehr vorsichtig sein.

Zumal Fehler die auf Threading zurückzuführen sind sehr schwer zu finden sind, da sie meist nicht direkt reproduzierbar sind, sondern teilweise mehr oder weniger zufällig passieren.

Auch wenn es schwierig ist, es lohnt sich damit zu beschäftigen. Ich habe Boost.Threads bisher noch nicht ausprobiert (da ich die eingebauten Threading Funktionen der Torque Engine verwende) aber ich habe bisher nur gutes davon gehört:
http://www.boost.org/doc/html/threads.html

[Otscho]

Frage: Dragon hat eine "komplette" Thread-Klasse gepostet. Kann man die schon verwenden ? Und wo muss der Code rein der dann gleichzeitig mit dem Rest ausgeführt wird?

Ich möcht das auch mal ausprobieren, hab allerdings noch keine richtige Erfahrung mit Multy-Threading gemacht, nur ein bisschen mit Java, is aber schon lange her und wahrscheinlich komplett anders.

[Kampfhund]

[Otscho]

Danke für die Tipps. Weil ich totaler Anfänger bin hab ich da nur noch ne Frage.

In der main.cpp

[Kampfhund]

Probier es einfach aus

Wenn mich nicht alles täuscht, dann müsste der code aber funktionieren.
Und ja, do (und alles andere danach auch) und newThread.run werden dann "gleichzeitig" ausgeführt.


Hier noch drei links:
http://www.codeworx.org/cpp_tuts_1_5.php
http://www.codeproject.com/threads/SynchronizedThreadNoMfc.asp
http://www.flipcode.com/articles/article_multithreading.shtml
_________________
Kochen ist ein NP-schweres Optimierungsproblem.

[Chriss]

Wenn du noch die Klammern dazu nimmst sollte es gehen