JMonkey Engine sinnvoll

[Tobiking2]

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.

[xaoC]

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.

[antijava]

[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).

[gary1195]

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 Grafikengine

Was 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.

[Gast]

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

[Gast]

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!

[Eisflamme]

Der GC löscht Referenzen? Hört, hört.

Ich glaube für das, was TE vorhat, ist JMonkey ausreichend.

[Gast]

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.

[Gregor]

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.

[Gast]

Gregor schrieb:

Ich meinte damit, dass er Referenzen auf diese Objekte halten kann, so dass der GC die Objekte nicht löschen kann.

Raffiniert.