JMonkey Engine sinnvoll
-
Gregor schrieb:
Im Prinzip kann man so programmieren, dass der GC in zeitkritischen Abschnitten nicht aktiv wird. Man darf dann halt einfach keine Objekte in diesen Abschnitten freigeben.
IMHO würde das GC ad absurdum führen. Ich will mich doch dank GC gerade nicht darum kümmern müssen wann, wie und wo ich irgendwelche Objekte freigeben will oder kann.
-
Morle schrieb:
Gregor schrieb:
Im Prinzip kann man so programmieren, dass der GC in zeitkritischen Abschnitten nicht aktiv wird. Man darf dann halt einfach keine Objekte in diesen Abschnitten freigeben.
IMHO würde das GC ad absurdum führen. Ich will mich doch dank GC gerade nicht darum kümmern müssen wann, wie und wo ich irgendwelche Objekte freigeben will oder kann.
Es gibt jenseits des GC noch viele weitere Gruende, Java zu verwenden. Wenn einen der GC in einem bestimmten Kontext stoert, dann programmiert man halt so, dass er dort nicht eingreift. Also man erstellt die benoetigten Objekte vorher und loescht die Referenzen spaeter. Die Hauptaufgabe des GC ist das Speichermanagement. Vor allem sollen keine Speicherlecks entstehen. Dafuer sorgt der GC auch in dem Fall. Aber man passt halt auf, dass in dem kritischen Codebereich kein Speichermanagement notwendig ist, sondern nur rund um diesen Bereich herum.
...aber ehrlich gesagt glaube ich, dass das nichtmal notwendig ist.
-
In einem Spiel, wo man eigentlich durchgehend auf eine bestimmte Frametime limitiert ist, ist das nicht so einfach einen nicht zeitkritischen Abschnitt zu finden.
Meine Aussage mit den Pausen bezog sich aber auch nur auf den GC den Java als default einsetzt. Da ist dokumentiert, dass dieser auf Durchsatz getrimmt ist und daher die Programmausführung während des kompletten Durchlaufs stoppt um möglichst effizient arbeiten zu können. Java bringt aber auch andere GCs mit, die für reaktive Systeme geeignet sind, und explizit ausgewählt werden können. Diese kommen zwar auch nicht ganz ohne Pausen aus, versuchen diese aber kurz zu halten und möglichst viel neben der normalen Ausführung zu erledigen.
-
Ich würde sagen, in der Spieleprogrammierung sollte man soweit wie möglich eh so eine Art Pool für Objekte bereithalten. Es sollte eigentlich fast immer Wege geben, für die normalen Anforderungen abschätzen zu können, um wie viele Objekte es sich handelt, oder wenigstens vernünftige Schätzungen abzugeben.
Anschließend wird man diesen Pool nicht mehr ändern, dieser verwaltet nur noch die vorhandenen Objekte, und gibt bei Anforderung einfach das erstbeste "deaktivierte" oder "freie" Objekt zurück (was auch immer das konkret bedeutet).
Da sollte die Garbage Collection nicht eingreifen. Ich implementiere es jedenfalls in der Art, innerhalb meiner GameLoop BEWUSST keine De-/ bzw. Allozierung anzutriggern.Im Idealfall weißt du vorher genau, wie viel Instanzen von XYZ so in deiner Gameloop rumhampeln.
-
[quote="Java_dave"]...
Und um das auch auf Linux rauszubringen möchte ich es mit Java schreiben.
...quote]1. Ein Spiel sollte so schnell wie möglich ablaufen, also würde ich nicht zu Java greifen, weil es eben keine nativen Anwendungen erstellt, sondern von der JVM interpretiert wird.
2. Kannst du auch C/C++ verwenden, z.B. kannst du dann OpenGL verwenden. Gibt Spiele wie Warsow, die das machen (in C).
-
antijava schrieb:
1. Ein Spiel sollte so schnell wie möglich ablaufen, also würde ich nicht zu Java greifen, weil es eben keine nativen Anwendungen erstellt, sondern von der JVM interpretiert wird.
2. Kannst du auch C/C++ verwenden, z.B. kannst du dann OpenGL verwenden. Gibt Spiele wie Warsow, die das machen (in C).1. der Bytecode wird kurz nach dem start durch den jit-Compiler in Maschinencode übersetzt und ist dann sehr schnell.
2. Er möchte ein Spiel Programmieren und keine GrafikengineWas xaoC schreibt ist eine wichtige Sache du solltest an Ressourcen denken obwohl Java möchte das du nicht daran denkst,
denn durch unbedachten Umgang mit Ressourcen kannst du die Leistungsfähigkeit deines Programms stark einschränken.
-
M. A. n. übertreibt ihr es mit den Nachteilen des GCs. Als ich mal Minecraft angetestet habe, habe ich keine Aussetzer bemerkt. Klar: Minecraft ist grafisch nicht anspruchsvoll, aber dennoch sind da viele tausende oder gar Millionen von Objekten im Speicher die verwaltet werden wollen...
L. G.
Steffo
-
Gregor schrieb:
Also man erstellt die benoetigten Objekte vorher und loescht die Referenzen spaeter.
Du musst gar nichts löschen, das macht alles der GC!
-
Der GC löscht Referenzen? Hört, hört.
Ich glaube für das, was TE vorhat, ist JMonkey ausreichend.
-
Eisflamme schrieb:
Der GC löscht Referenzen? Hört, hört.
Was verstehst du darunter? Ich hatte das so verstanden, dass man Referenzen auf null setzen muss, damit der GC den Speicher aufräumt, was natürlich Quatsch ist.
-
Steffo schrieb:
Gregor schrieb:
Also man erstellt die benoetigten Objekte vorher und loescht die Referenzen spaeter.
Du musst gar nichts löschen, das macht alles der GC!
Ich meinte damit, dass er Referenzen auf diese Objekte halten kann, so dass der GC die Objekte nicht löschen kann.
-
Gregor schrieb:
Ich meinte damit, dass er Referenzen auf diese Objekte halten kann, so dass der GC die Objekte nicht löschen kann.
Raffiniert.
