Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Java als Ausgangsbasis für ein Cross-Platform Framework zu verwenden, halte ich persönlich für keine gute Idee. Im Speziellen hat man bereits ein Problem bei iOS, ganz allgemein kommen noch die nicht vollständig standardkonformen Implementierungen von Java hinzu (z.B. Dalvik). LibGDX war ursprünglich für Android gedacht und das ist auch nicht zu übersehen. Diese ursprüngliche Fixierung auf Android hat nun ihre Konsequenzen. Warum nicht den umgekehrten Weg gehen? Anstatt auf allen Nicht-Androids eine VM mitzuliefern, damit der Java-Code läuft, wäre es besser, mithilfe des NDKs auf Android nativen Code ausführen (z.B. C++).
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Zitat
Anscheinend kennst du konkrete Fälle, in denen Dalvik nicht kompatibel mit dem Standard ist und in denen man die Nachwirkungen der Android-Fixierung im Falle der LibGDX spürt.
Zitat
C++ als Alternative zu nennen finde ich allerdings nicht besonders gut. Es hätte zwar den Vorteil, dass auf anderen Geräten keine VM notwendig wäre, allerdings wären die Nutzer der Engine dann dazu gezwungen, C++ und dessen Eigenheiten zu nutzen.
Zitat
Dazu gehört beispielsweise, dass man für jede Plattform exportieren müsste, was heißt, dass man für jede Plattform den Compiler bei sich auf dem Rechner haben muss und ggf. noch weitere notwendigen Tools. So wäre es möglich, dass die Engine ein Tool mitliefert, welches die Paketierung nach dem Kompilieren für die gewünschte Plattform übernimmt (der ggf. notwendige Code, um den Javacode auf der jeweiligen Plattform zu starten, dürfte unabhängig vom Java-Bytecode sein und müsste deswegen nicht jedes Mal neu gebaut werden.)
Zitat
Wichtig in dem Zusammenhang wäre aber auch zu wissen, welche Beweggründe es seitens des Threaderstellers für Java gab.
Zitat
Anscheinend kennst du konkrete Fälle, in denen Dalvik nicht kompatibel mit dem Standard ist und in denen man die Nachwirkungen der Android-Fixierung im Falle der LibGDX spürt.
Dass Dalvik nicht gleich Java SE/EE ist, ist ein ganz anderes Problem als das, was ich damit eigentlich ansprechen wollte. Meine Zeit mit LibGDX liegt 2-3 Jahre zurück, damals war es noch Android-only. Da die Crossplatform-Capability aber nicht von Anfang an berücksichtigt wurde, musste sie quasi dazugefrickelt werden, im Falle iOS mit einem externen Framework (Xamarin). Das sind bereits 2 Abhängigkeiten, die man in fremde Hände legt. Windows RT scheint überhaupt noch nicht unterstützt zu sein. Bzgl Dalvik: Diese VM hat stellenweise ganz eigene APIs, die in Java nicht vorkommen (diverse Container-Klassen und natürlich die plattform-spezifischen), umgekehrt fehlt u.a. AWT mitsamt allen Utility Klassen (z.B. Point2D). Wer seine Apps primär für Android schreibt und das nicht berücksichtigt, wird bei der Portierung mit einigen ClassNotFoundExceptions zu kämpfen haben. Aber das sind eigentlich Kleinigkeiten. Zu RoboVM: Wer garantiert mir, dass der generierte Code zuverlässig funktioniert? Die Probleme bei der Portierung beginnen ja bereits bei den unterschiedlichen Compilern.
Zitat
Dazu gehört beispielsweise, dass man für jede Plattform exportieren müsste, was heißt, dass man für jede Plattform den Compiler bei sich auf dem Rechner haben muss und ggf. noch weitere notwendigen Tools. So wäre es möglich, dass die Engine ein Tool mitliefert, welches die Paketierung nach dem Kompilieren für die gewünschte Plattform übernimmt (der ggf. notwendige Code, um den Javacode auf der jeweiligen Plattform zu starten, dürfte unabhängig vom Java-Bytecode sein und müsste deswegen nicht jedes Mal neu gebaut werden.)
Das muss man sowieso. iOS-Apps lassen sich nur mit Xcode erstellen, Windows RT Apps nur mit Visual Studio (ohne das jetzt bestätigen zu können). Für Android braucht man die ADT. Ein Game-Studio hat deshalb auch alle Betriebssysteme im Haus versammelt, das sind Peanuts in der Anschaffung. Typischerweise verwendet man PCs mit Windows (Linux als Zweitsystem) mit einem Mac mini als Build-Rechner. Bei uns in der Firma ist es umgekehrt: Wir haben einen Windows-Build-Rechner und arbeiten selbst auf iMacs. Wenn man sich mit einem JAR-Bundle für die Desktop-Betriebssysteme zufrieden gibt, dann stimmt der Einwand natürlich. Aber wenn man heutzutage von Cross-Platform spricht, dann lassen sich die mobilen Plattformen kaum mehr ignorieren. Welche Tools den Build-Prozess dann schließlich erleichtern, hängt mehr vom Umfang der Engine selbst ab.
Zitat
Wichtig in dem Zusammenhang wäre aber auch zu wissen, welche Beweggründe es seitens des Threaderstellers für Java gab.
Wenn ich das richtig verstanden habe, dann war der Grund für Java die Tatsache, dass LibGDX (als Basis der Engine) darauf basiert. In diesem Fall führt wahrscheinlich auch kein Weg mehr dran vorbei.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Chromanoid« (31.07.2013, 00:43)
Die Frage ist einfach in welcher Sprache man programmieren will.
Zitat
welche Beweggründe es seitens des Threaderstellers für Java gab.
Zitat
Im Speziellen hat man bereits ein Problem bei iOS
Zitat
die nicht vollständig standardkonformen Implementierungen von Java hinzu (z.B. Dalvik)
Werbeanzeige