1. Foren
  2. Kommentare
  3. Games
  4. Alle Kommentare zum Artikel
  5. › Minecraft: Katzen, KI-Änderungen und…

Minecraft in Java...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Minecraft in Java...

    Autor: _Thunder_ 30.01.12 - 11:26

    Java mag ja ganz schön sein, da man es auf jedem OS nutzen kann, aber für ein Spiel ist es gänzlich ungeeignet, so rescourcenfressend wie es ist. Da bau ich einmal einen Shadermod ein und bekomm meinen i7 2700k so ordentlich zum laufen, wie er nichtmal bei Battlefield 3 läuft...

  2. Re: Minecraft in Java...

    Autor: Anonymer Nutzer 30.01.12 - 11:32

    IT News für Profis - Ich glaube du hast dich verirrt!

  3. Re: Minecraft in Java...

    Autor: ww 30.01.12 - 11:37

    Also tatsächlich ist Minecraft die einzige Java App, deren Performance und Plattformunabhängigkeit mich begeistern.

  4. Re: Minecraft in Java...

    Autor: Raketen angetriebene Granate 30.01.12 - 11:43

    Minecrafts Framerate könnte bei voller Auslastung eines Kernes in der Tat besser sein. Aber für mich ist die Hauptsache, dass es spielbar ist. Und das ist es.

    Auch braucht Mojang sich keine Gedanken über Inkompatibilitäten zwischen verschiedenen Plattformen machen. Das ist bei dem ehemaligen Ein-Mann-Projekt sicher entscheidend für den Erfolg des Spiels gewesen.

    Ich mag Java eigentlich auch nicht, aus der User-Perspektive. Für Entwickler bietet es allerdings Vorteile, die keine andere Software-Plattform bietet.

  5. Re: Minecraft in Java...

    Autor: Altruistischer Misanthrop 30.01.12 - 11:49

    Selten hat ein derart unqualifizierter (Troll)Beitrag das Licht der Welt erblickt. Es gibt AAA-Titel deren Backend komplett in Java programmiert wurde. Es scheitert garantiert nicht an einer Sprache.

    Natürlich ist Java an sich schonmal langsamer als nativer Code, aber im Allgemeinen scheitert es an den Programmierkenntnissen der Entwickler, nicht an der Sprache.

    Eine Sprache für die Inkompetenz von manchen Entwicklern verantwortlich zu machen grenzt schon an Arroganz.

    Aber is klar: PHP, JAVA und alle anderen "beliebten" bzw. verbreiteten Sprachen sind böse, eben weil sie beliebt und verbreitet sind.

  6. Re: Minecraft in Java...

    Autor: fuzzy 30.01.12 - 11:58

    Naja, die "Unabhängigkeit" wird dadurch erkauft, dass native Bibliotheken für alle Systeme beiliegen.

  7. Re: Minecraft in Java...

    Autor: Ritter 30.01.12 - 12:12

    Altruistischer Misanthrop, guter Beitrag, nur eine Korrektur:

    "Natürlich ist Java an sich schonmal langsamer als nativer Code"

    Seit bei Java 1.4 (oder 1.3?) der neue Just-in-Time (JIT) Compiler namens "Hotspot" eingeführt wurde, ist das nicht mehr so.

    Denn dieser Hotspot-Compiler optimiert den -- hier aus dem Minecraft-Spiel -- vorliegenden Java-Bytecode zur _Laufzeit_ in den Maschinencode der jeweiligen Plattform (und er heißt Hotspot, weil er beispielsweise besonders häufig durchlaufende Code-Stellen besonders optimiert). Deswegen kann der Hotspot Maschinencode-Optimierungen durchführen, die ein klassischer statischer Compiler (Pascal, C/C++) gar nicht erreichen kann, weil er ja zur Laufzeit nicht tätig ist.

    Das kann man nachlesen bei SUN/Oracle oder sonstwo, ist ein sehr spannendes und faszinierendes Kapitel.

    Jedenfalls ist es dadurch möglich, daß Java-Programme sogar schneller als statisch compilierte Programme ablaufen (Pascal, C/C++, Assembler).
    Natürlich hängt aber alles vom Programm und seinen Aufgaben ab. Beim bloßen Verschieben großer Byte-Mengen gibt es zur Laufzeit wohl kaum etwas zu optimieren, und da ist der größere Aufwand einer virtuellen Maschine wie der von Java dann tatsächlich "natürlich langsamer" als purer Maschinencode, der aus C/C++, Pascal, etc. compiliert wurde und der direkt auf dem Prozessor ohne Einsatz einer Virtuellen Maschine abläuft.

    Aber z.B. für graphische Byte-Verschiebungen nutzt man in Java entsprechende Bibliotheken des darunterliegen Betriebssystems.
    Bei Java2D geschieht dies schon automatisch (so wird z.B. das transofrmierte Zeichnen von Pixelbildern via Javas drawImage() automatisch an OpenGL oder DirectX weitergeben).
    Bei 3D-Sachen nutzt man die 3D-Highlevel-API Java3D oder andere, und bei Lowlevel wie im Falle von Minecraft dann Javas OpenGL-Bindungen.


    Aber generell ist dieser Satz ganz richtig:

    ", aber im Allgemeinen scheitert es an den Programmierkenntnissen der Entwickler, nicht an der Sprache. "

    Denn durch die Wahl der richtigen Algorithmen und Datenstrukturen (z.B. die sehr mächtigen Collections in Java) löst man normalerweise die wesentlichen Geschwindigkeits-Engpässe in seinem Programm.

  8. Re: Minecraft in Java...

    Autor: Ritter 30.01.12 - 12:16

    OpenGL-Bindungen im Falle von Minecraft.
    Diese übertragen OpenGL-Java-Aufrufe an den Treiber. Gibt es für jede Java-Plattform und ist alles OpenSource, daher auch relativ leicht an Plattformen anpaßbar, für die es zwar Java gibt, aber noch keine OpenGL-Bindung.

    Man ist nach wie vor maximal unabhängig -- insofern das geht, wenn man 3D-Hardware verwenden will. Sobald Oracle sich entscheidet, das SUN-Projekt Java-OpenGL (JOGL) in Java einzupflegen (vorbereitet ist alles), wandert diese plattform-abhängige Schicht eben in die Virtuelle Maschine von Java, genauso wie es mit Java2D geschah, das inzwischen ja 2D-Hardware-Operationen (über 3D...) direkt verwendet.

  9. Re: Minecraft in Java...

    Autor: _Thunder_ 30.01.12 - 12:18

    Gut, dann entschuldige ich mich hiermit für meine Unkenntnis und danke für die Aufklärung.

  10. Re: Minecraft in Java...

    Autor: fuzzy 30.01.12 - 12:33

    "Bindungen" D:
    jinput
    lwjgl
    OpenAL
    Jeweils in 32 und 64 Bit, jedenfalls für Windows. Unter Linux (und anderswo) wirds nicht anders aussehen. Nicht gerade, was ich unter Plattformunabhängigkeit verstehe.
    Klar, irgendwann wird das meiste in die VM integriert bzw da eben mitgeliefert.

  11. Re: Minecraft in Java...

    Autor: Altruistischer Misanthrop 30.01.12 - 12:34

    Ernsthaft? Also ich hab auf der Uni gelernt, dass Java (das dort fast in jeder LVA eingesetzt wurde und soweit ich weiß auch wird) immer um etwa 40% langsamer ist als C bzw. C++, einfach per Design, wegen der JVM.

    Dass sich diese 40% wieder kaum auswirken, weil die Flaschenhälse ganz wo anders sitzen (Speicherzugriffe etc.) ist eine andere Geschichte.

    Wir haben damals jedenfalls schon mit Java 1.5 gearbeitet und es so gelernt. Besonders da wir überall Java eingesetzt haben, würde mich jetzt wundern wenn wir da absoluten Blödsinn gelernt haben, was natürlich aber auch nicht auszuschließen ist.

  12. Re: Minecraft in Java...

    Autor: redwolf 30.01.12 - 12:48

    Für die 3d Darstellungen wird lwjgl http://lwjgl.org/ verwendet. Die 3D-Darstellung ist also nativ über JNI angebunden, was nochmal einen Performanceboost bringen sollte. Was in Java in 3D möglich ist, sieht man am jMonkey Projekt.

  13. Re: Minecraft in Java...

    Autor: burzum 30.01.12 - 15:06

    Altruistischer Misanthrop schrieb:
    --------------------------------------------------------------------------------
    > Selten hat ein derart unqualifizierter (Troll)Beitrag das Licht der Welt
    > erblickt. Es gibt AAA-Titel deren Backend komplett in Java programmiert
    > wurde. Es scheitert garantiert nicht an einer Sprache.

    Jetzt bin ich aber mal auf Beispiele solcher Titel gespannt mit Quellen zur Verwendung von Java in denen.

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

  14. Re: Minecraft in Java...

    Autor: Der schwarze Ritter 30.01.12 - 15:13

    Inzwischen ist es eigentlich Blödsinn. Java und auch C#/VB.NET sind inzwischen nicht mehr wirklich langsamer als nativer Code, da die JIT-Compiler verdammt gut sind. Beide Sprachen werden beispielsweise in Bereichen eingesetzt, die vor einigen Jahren noch eine absolute Native-Code-Domäne waren (Spieleentwicklung). Minecraft ist jetzt allerdings ein schlechtes Beispiel für guten Java-Code. Hier wurde mit den Resourcen massiv geschlampert und auch ein schlecht programmiertes Spiel in C++ läuft schlecht und lastet die CPU massiv aus. Das hat nichts mit der Sprache zu tun. Gut geschriebener managed Code steht nativem Code in nichts mehr nach. Im Gegenteil, bietet managed Code einige großartige Vorteile, die man nicht mehr missen möchte, wenn man sich etwas mehr damit beschäftigt.

  15. Re: Minecraft in Java...

    Autor: Anonymer Nutzer 30.01.12 - 15:27

    Irgendein Troll muss echt immer wieder die alte Java-C-Native-Diskussion anfangen. Und es finden sich immer wieder Halbwissende, die darauf einsteigen :-/ Aber aus Gründen des Fast-Feierabends mach ich heut auch mal mit.

    @Misanthrop:

    1. Vielleicht habt ihr mit 1.5 gearbeitet, aber das muss nicht heißen, dass euer Prof sich schon mit den besonderheiten neuerer Java-Versionen vertraut gemacht haben muss.

    2. 40% von was? Erstens ist es schon unseriös überhaupt eine Zahl zu nennen, da es immer auf die Anwendung ankommt. Zweitens kenne ich diese Zahl, die stammt aus den ANFANGSzeiten von Java. Da gab es noch keinen JIT-Compiler und dergleichen.

    3. Um der Übersetzungs- und Optimierungsdiskussion noch etwas hinzuzufügen: Im Multithreading-Bereich ist Java sogar besser als C, weil darauf optimiert.

  16. Re: Minecraft in Java...

    Autor: Altruistischer Misanthrop 30.01.12 - 15:48

    sepplhorst schrieb:
    --------------------------------------------------------------------------------
    > Irgendein Troll muss echt immer wieder die alte Java-C-Native-Diskussion
    > anfangen.

    Eigentlich war es nicht als Trollbeitrag gemeint. Ich habe mit JIT-Compilern eigentlich nichts zu tun und wusste nicht, dass diese bereits derart fortgeschritten sind. Ansonsten würde das Argument nämlich stimmen, dass gleich guter Code in Java einfach per Default langsamer sein müsste, eben weil er noch durch die JVM muss.

    Ich lass ja mit mir reden, es hat mich einfach nur interessiert.

  17. Statisch compilierter Maschinencode VS Virtuelle Maschine

    Autor: Ritter 30.01.12 - 15:49

    Altruistischer Misanthrop schrieb:
    --------------------------------------------------------------------------------
    > Ernsthaft? Also ich hab auf der Uni gelernt, dass Java (das dort fast in
    > jeder LVA eingesetzt wurde und soweit ich weiß auch wird) immer um etwa 40%
    > langsamer ist als C bzw. C++, einfach per Design, wegen der JVM.

    Ja, da hatten Ihre Professoren etwas Falsches gelehrt. :-)
    Zu dem Thema führte der damalige SUN-Ingenieur Jeff Kesselmann viel aus. Er hatte einerseits eine Leidenschaft für das Spieleprogrammieren und war -- soviel ich weiß -- in SUNs Hotspot-Mannschaft dabei. Außerdem war er sehr freundlich und hilfsbereit; wir standen damals im Kontakt. Den Schweden müßte Kesselmann noch kennen, als der Schwede sein Wurm online bastelte...

    Ich finde auf die Schnelle aber nur das Untenstehende; doch suchen Sie einfach im Internet nach mehr Hintergrundinformationen; es ist wirklich ein hochinteressantes Thema.
    Auch mich faszinierte es, als ich zum ersten Mal darüber hörte. Denn wie Sie dachte ich damals (und frisch von der Hochschule), daß es "natürlich nichts schnelleres als (compilierten) Maschinencode" geben könnte ... bis ich dann den Unterschied zwischen statisch compilierten Maschinencodeprogrammen als Ergebnis von C/C++ etc, und dem zur Laufzeit optimierten Maschinencode von Virtuellen Maschinen erfuhr. Seither programmiere ich eigentlich nur noch auf Virtuellen Maschinen wie der von Java; die Vorteile sind einfach überwältigend.


    http://www.javaperformancetuning.com/news/qotm042.shtml

    QUESTION: I read somehere that Java could theoretically run faster than a C program. Is there any truth to that? [..] Are there any practical examples which can show this?

    ANSWER: Yes. In an interesting discussion Jeff Kesselman (Sun engineer focused on games) had in his java.net blog, ( see the blog here), Jeff made the following points (my thanks to Jeff for allowing me to use his comments):

    Java code (or any run-time compiled code) has the potential to run FASTER then pre-compiled code because it can (and does) factor in knowledge of the operating environment. Some examples:

    * If you want C code on Win32 to run on multi-processor systems you need to compile for that and put in synchronization instructions that slows it down for single processor systems. The Hotspot JIT detects how many CPUs you have and generates code accordingly.

    * When you compile C code you need to state a minimal platform (P2, P3, etc). In doing so you lose access to all the extended instructions of more recent proessors. Hotspot again detects what kind of processor and generates code accordingly.

    * The list of run-time code improvements is almost endless. Inlining is good, but only so much that you don't overflow your cache. A precompiler has to guess at cache size -- a JIT knows it. Potentially polymorphic dispatch points in C++ CANNOT be inlined, they have to go through a jump table. In Hotspot they ARE inlined and then, if if the dispatch point actually gets *used* in a polymorphic way, that inlining is backed out.

    In general Java today is C++ equivalent in speed. There are some micro tasks that C will always do better. These involve random access into large byte array fields. Decoding MPEG streams is the classic example. Thats why we ship a JNI based codec with JMF. (Even in this extreme case though it only buys us about 15% speed improvement.)
    There are some tasks Java will almost always beat C at. Java allocation and deallocation is lightning fast compared to C. Our better optimization of loops and recursion also seem to, for some reason, result in a FFT that always ends up beating the best C counterpart.

    [..]

  18. Ein paar Java-Spiele...

    Autor: Ritter 30.01.12 - 16:08

    burzum schrieb:
    --------------------------------------------------------------------------------
    > Altruistischer Misanthrop schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Selten hat ein derart unqualifizierter (Troll)Beitrag das Licht der Welt
    > > erblickt. Es gibt AAA-Titel deren Backend komplett in Java programmiert
    > > wurde. Es scheitert garantiert nicht an einer Sprache.
    >
    > Jetzt bin ich aber mal auf Beispiele solcher Titel gespannt mit Quellen zur
    > Verwendung von Java in denen.

    Auf der folgenden Java-Indy-Webseite sind sowohl freie als auch kommerzielle Spiele gelistet, die ganz in Java programmiert sind:
    http://www.java-gaming.org/boards/games/60/view.html
    (Aber Achtung: die Qualität schwankt sehr! Von professionellen Indy-Spielen bis zu Lausig-gemachten-aber-lustige-Hobby-Spielen ist alles bunt gemischt)

    Und hier sind ein paar kommerzielle Spiele aufgelistet, die wenigstens teilweise Java verwenden:
    http://www.java-gaming.org/topics/list-of-commercial-games-using-java/3123/view.html



    1 mal bearbeitet, zuletzt am 30.01.12 16:08 durch Ritter.

  19. Re: Minecraft in Java...

    Autor: SoniX 30.01.12 - 17:00

    ww schrieb:
    --------------------------------------------------------------------------------
    > Also tatsächlich ist Minecraft die einzige Java App, deren Performance und
    > Plattformunabhängigkeit mich begeistern.

    Na da haben wirs wiedermal ^^

    Bei mir ruckelts wie Sau. Einfach unspielbar.

    Und dafür, dass es in so nem Look daherkommt und sowas von einfach gestrickt ist, halte ich das für unverzeihlich.

  20. Re: Minecraft in Java...

    Autor: Altruistischer Misanthrop 30.01.12 - 18:34

    versuch mal dem Programm mehr Ram zuzuweisen, stell die Weitsicht runter...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Software AG, Darmstadt
  2. Endress+Hauser Conducta GmbH+Co. KG, Gerlingen (bei Stuttgart)
  3. LS telcom AG, Lichtenau
  4. Hessisches Ministerium des Innern und für Sport, Wiesbaden (Home-Office möglich)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-47%) 21,00€
  2. 26,99€
  3. 10,99€
  4. 4,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de