3D Spiele mit Java - Diskussion

[Highchiller]

Hey Leute,

ich würde gern ein Spiel in 3D programmieren. Beim lesen und recherchieren bin auf unterschiedliche Ansätze gestoßen und hab mich immer wieder einiges gefragt, was ich nun gern mal los werden würde. Kurz vorweg, diese Diskussion erfindet das Rad nicht neu, aber alle Quellen die ich bisher dazu beziehen konnte sind bereits gut veraltet. Und grad in der Welt der Programme ist z.B. 2006 schon sehr alt.

Also. Wenn es darum geht ein ordentliches 3D-Game zu entwickeln braucht man eine Engine, wenn man nicht grad selbst eine schreiben will. Doch welche brauchbaren Engines gibt es für Java? Java3D, JMonkey, JOGL sind zwar alle schön und gut aber sie erinnern all zu oft an den klassischen Pixellook der alten Tage. Wieso bieten diese zum Beispiel keine halbwegs performante Grafik wie man sie von Unity oder gar CryEngine kennt. Klar das sind unends teure High-End engines, aber woran liegt es, dass es das für Java nicht gibt?

Wenn man sich für Spieleprogrammierung im 3D Bereich interessiert wird stets C oder C++ bevorzugt. Nur warum? Wenn man tiefer gräbt stellt man fest, dass Java, im Sinne der Performance, C++ nicht soweit nach steht. Wo ist also das Problem?

---------------------------------------------

Ich hab bereits viel Erfahrung mit Java und hab schon einige Spiele entwickelt. Einige 2D spielerein und auch ein 3D-Spiel. Aber alles in allem war das größtenteils nen Krampf. Damals hab ich schlicht Java3D benutzt. Ich hab auch einige Erfahrung im Umgang mit Blender. Was mir zu gute kommt wenn es darum geht gute Grafik zu erstellen. Mit C/C++ hab ich dagegen so gut wie gar keine Erfahrung. Ich kenn viel theoretisches und Aufgrund von guten Javakenntnissen kann ich C++-Code natürlich auch lesen und verstehen. Aber ich hab noch nie mit C++ programmiert.

Ich steh quasi vor der Frage. Lernst du jetzt lieber C++ ordentlich und fängst dann an dich mit deren 3D-Visualisierungen auseinander zu setzen oder arbeitest du dich besser in eine gute Java-Engine ein und progst damit?

Ich bevorzuge ja ganz stark Java. Schon allein weil es mich reizt auch mit Java was großes umzusetzen. Nur sind alle bisher erstellen "großen" Java-Titel nicht grad ein Augenschmaus.

---------------------------------------------

Was denkt ihr? Wo liegt das Problem mit Java? Gibt es durchaus grafisch ansehnliche Umsetzungen von Java-Spielen? Bevorzugt ihr eine bestimmte Engine? Gibt es eine Möglichkeit mit Java direkt auf der Graka zu rechnen (was heutzutage ja auch immer mehr in den Vordergrund rückt)?

Ich hät halt richtig bock auf son Wirtschaftssimulator á la "Schiene und Straße". Das hatte mir früher eigentlich sehr gefallen, falls das jemand kennt, aber auf Grund der Vergangenheit wurde da nie was großes draus.
Lässt sich sowas überhaupt mit Java umsetzen? Wenn nein, wieso nicht? Wenn ja, welche Engine, welche herangehensweise und so weiter...

Nun gut, ich hoffe ich bekomm viel zu lesen. Ach und ihr könnt ja mal abstimmen

Liebe Grüße
Highchiller

 

[Gucky]

Minecraft ist, soweit ich weiß, in Java programmiert worden. Dann zwar nativ übersetzt aber dennoch in Java und die Grafik ist nicht so schlecht. (sonst könnten die Blöcke nicht schräg von der Seite betrachtet werden)

Das Problem mit Java: es hat einen schlechten Ruf. Viele Viren werden über Java eingeschleust.
Und: Spiele sind sehr performancekritisch. Da werden Teile, die besonders viel Performance brauchen in Assembler nochmals optimiert. In Java ist das nur schwer möglich. Außerdem läuft immer die VM mit. Java ist, meines Wissens nach, 3 bis vier mal langsamer als C/C++, was für alle heutigen Spiele der Todesstoß wäre. Oder willst du dir einen Rechner mit 24 Gigahertz kaufen, um BioShock zu spielen?


Die MonkeyEngine ist zwar eine recht mächtige Engine aber halt von Leuten programmiert, die das hobbymäßig machen. Du hast auf der einen Seite Epic, die Millionen in ihre Engine stecken und auf der anderen Seite einen haufen Leute, die vielleicht allesamt überragende Programmierer sind aber da steht kein Geld hinter.


Ich rate dir: Wechsel zu C/C++.

 

[darkeye2]

Also aus meiner erfahrung heraus kann ich dir sagen, dass es mit java sehrwohl möglich ist, gute, performante spiele zu schreiben. Ein bekannter von mir hat ein recht unterhaltsammes spiel gemacht gehabt (multiplayer shooter).

Auch ich bin im moment dabei ein kleines 3D spiel zu entwickeln, hab momentan zwar gewisse probleme, die haben aber nix mit dem spiel selbst zutun.

Java ist geschwindigkeitstechnisch inzwischen sehr gut und wenn es um grafik oder sound geht, greift man ja ehe auf native mittel zurück (sprich OpenGL und OpenAL). Da du JOGL erwähnt hattest, das ist keine engine sondern eine java anbindung an OpenGL. LWJGL ist schon mehr an die Spieleentwicklung angelehnt, aber trotzdem nur ein "Werkzeug".

Die JMonkeyEngine hatte ich mir angeschaut, sieht auch ganz gut aus, kann aber nicht viel dazu sagen, da ich auch lerntechnischen Gründen eine eigene Engine schreiben möchte, die wird ganz simple sein, aber zum Lernen völlig ausreichend.

Meiner Meinung nach, musst du erstmal für dich folgende Frage klären, befor weiter darüber nachdenkst, was besser geeignet ist.
"Willst du eine eigene Engine schreiben oder reicht die die JME?"
Wenn die JME nicht deinen geschmack trifft, gibt es in java soweit ich weiß wenig alternativen. Also musst du eine eigenen Engine schreiben. Für eine richtige Engine müsstest du sehr viel zeit investieren.

Wenn du auf C++ umsteigst, stehen dir natürlich mehr fertige Engines zur verfügung.

 

[Highchiller]

Wenn ich man in Java Programmiert und dann für Grafik und Audio auf native Art implementiert, ist doch der große Vorteil der plattformübergreifenden Anwendung futsch. Was macht das dann für einen Sinn?

Soweit ich das verstehe, verwendet doch die JMonkeyEngine auch nur OpenGL und OpenAL, oder? Wieso dann den Umweg gehen?

Aber genau das meinte ich, der eine sagt Java ist heut zu tage gar nicht mehr soweit hinter C++, der andere meint, doch, bis zu 4 mal langsamer. Also was denn nun? Was ist up-to-date?

Und noch mal die Frage, kann man mit Java eigentlich direkt auf der Graka rechnen lassen? Das würde vieles enorm beschleunigen. In der Uni hat mir mal einer erklärt das er darüber seine Masterarbeit geschrieben hat und Java auf der Graka schon ziemlich der Horror wäre, aber möglich ist. Wenn das geht würde ich Java schon knapp hinter C++ ansiedeln.

 

[Gucky]

Naja. Knapp hinter C/C++? Auf der einen Seite hast du ein Programm, dass der Prozessor nimmt und direkt ausführt und auf der anderen Seite hast du ein Programm, dass deinen Code, zwar schon compiliert aber in Bytecode, nimmt und JIT in nativen Code umsetzt und ausführt. Man könnte ja mal einen Test machen. Man nimmt ein kleines Progrsmm, lässt es irgendwas berechnen und guckt, wie viel Zeit dabei drauf geht.

Zu dem Umweg: du kannst in Java auch direkt die WinAPI benutzen. Trotzdem benutzt du Swing, AWT oder JavaFX. Irgendwo benutzt auch Java die WinAPI oder die MacAPI oder was auch immer.

Zur Möglichkeit: in Java ist alles möglich, wenn du es dir vorstellen kannst. So auch auf der Graka rechnen. Aber dazu musst du auf die Hardware zugreifen, was entweder mit JNI/JNA oder native Methoden geht. Um dann den Zauber von Java zu erhalten musst du für jedes zu benutzende OS den nötigen nativen Code mitliefern.

 

[hauptDev]

Ich würde schon sagen, dass Java das kann! Die VM ist wirklich mittlerweile vernachlässigbar. Haut mich, wenn ich s*****e erzähle ;-)

Das große Problem ist doch eigentlich, dass C/C++ da so etabliert sind und deswegen die ganzen Engines schon extrem ausgereift und optimiert sind. Für Java sieht es da, was das Angebot angeht eher Mau aus. Aber man sieht an Minecraft (ljwgl) + entsprechenden "HighEnd"-Mods, wie das ganze Aussehen kann.

Wird das Potenzial denn dann überhaupt auch soweit ausgereizt in deinem Spiel, also ein Look wie ein Crysis 4!? Muss so viel Power sein?

Die größte Performance bestimmte letztlich der Programmierer mit seinen Algorithmen.

Edit: jetzt echt s******e wird zensiert?

 

[Sen-Mithrarin]

erstmal grundlegend : performance

klar kann man in java auch so einiges sehr gut umsetzen ... als beispiel würde ich dafür weniger minecraft nehmen ... da einfach zu schlecht umgesetzt ... sondern Jake2 ... ein klon von Quake2 der mit den original game-files läuft ... also ein kompletter re-write der engine ... und läuft bei mit wahnsinningen FPS da kommen einige native spiele nicht ran ... gut ... weil da aber auch viel leistung für bessere grafik drauf geht ... HL1 läuft bei mir auch mit teilweise über 600FPS ... und das obwohl ich schon filter vom garak-treiber aktiv habe ...

es ist also möglich ... aber nur wenn man performante anbindungen nutzt ... z.b. mit JOGL / LWJGL an OpenGL und dann dem den rest überlässt ...

oder ob man sich gleich ne native engine holt die dann mit DirectX noch mal n bissl mehr leistung rauskitzelt ? muss man halt wissen ob einem block-design gefällt oder man dann doch kanten-lose rundungen haben will

ich hab sogar schon gesehen das es jemand gepackt hat HL1 auf der Doom engine ans laufen zu bekommen ... sah natürlich noch grottiger aus ... aber es lief ...


das problem von java bei solchen dingen ist eher weniger die optimierbarkeit ... als mehr der zwang dazu das man native anbindungen nutzen muss wenn man leistung haben will ...
klar kann man vieles auf der GPU rechnen lassen wie es viele AAA-titel machen ... aber java rechnet dann ohne spezielle libs doch wieder auf der CPU ... was für grafik-berechnung mehr als nur killer ist ... denn wozu monster von graka haben wenn diese dann doch nur dazu "benutzt" wird ein vom cpu fertig gerendertes 2d bild auf den monitor zu klatschen ...


DAS ist eher das problem von java ... das halt zu viel auf CPU basis passiert ... weil eben ohne nötige libs die anbindung an die gpu fehlt ... und ob man jetzt nun opengl oder directx nutzt (gibt es eigentlich ne java-directx bridge ?) ist egal .. hauptsache man lagert das was auf die gpu gehört auch darauf aus

 

[Highchiller]

Also erst mal, natürlich soll es kein Game á la Crysis Grafik werden. Sondern nur ein Wirtschaftsimulator. Die Grafik die ich mir dazu vorstelle entspricht eher Banished, falls euch das was sagt. Hier ein Screen:


Was mich halt irritiert ist, dass es anscheinend niemand wirklich angeht. Java ist so auf den Handy und Webbrowser-Markt gedrängt worden, dass sich anscheinend keiner darum schert nen großes Java-basiertes Game zu entwickeln. Ich persönliche würde da Minecraft auch eher raus nehmen, schon allein weil Notch da einen sehr eleganten Weg an der High-End-Grafik vorbei beschritten hat.

Genau das denke ich auch. Die VM wird auf der CPU ausgeführt und ohne weiteres kommt man da nicht zwangsläufig raus. Grafik auf der CPU berechnen zu lassen ist heutzutage MEHR als tödlich. Und ich denke genau daher kommt das Problem, dass es kaum ansehnliche Java-Games gibt.

Normale Berechnungen, die nativ auf der CPU ausgeführt werden nehmen sich garantiert nichts (oder wenn überhaupt nur sehr wenig) im Vergleich zum Java-Code. Das würde auch erklären wieso der eine behauptet Java ist so schnell die C/C++ und der andere wieder sagt, das ist quatsch, Java ist deutlich langsamer.
Nur die GPU denkt dabei eventuell keiner.

 

[Gucky]

Ich hab grade mal einen Test gemacht. Das verblüffende Ergebnis: Das C++ Programm benötigte 2,744 Sekunden, um sämtliche Zahlen von 1 bis 1000000000 zu addieren und das Java Programm nur 1,225. Ich muss sagen, dass hat mich umgehauen.

Die Zeitmessung in C++ erfolgte mit std::clock(), falls das jemandem was bringt.

 

[darkeye2]

Erstmal zu der aussage "java verliert doch den größten vorteil, wenn man auf native mittel zurückgreift" ... Das stimmt so nicht ganz. Natürlich musst du auf native mittel zurückgreifen, da z.b. OpenGL nicht in java ist, aber z.b. jogl (java wrap für opengl) bringt native files für alle systeme mit (sogar android) das gleiche gilt für OpenAL. Somit schreibst du ein Programm, das OS unabhängig ist, da du erstens alles in java schreibst, und zweitens alle natives, die du nutzt, für alle Systeme verfügbar sind (alle gängigen).

Zum Thema geschwindigkeit:
Am anfang war es mal ein Problem, und seitem schreiben das die leute überral rein, obwohl sich sehr viel getan hat. Klar es ist eine VM dahinter, aber trotzdem erreicht man je nach anwendungsbereich so ziemlich die gleichen geschwindigkeiten wie in C.
Es gibt fälle, wo man in C deutlich schneller ist, aber das wird dadurch ausgeglichen, dass es auch bereiche gibt, die bei java intern besser umgesetzt sind, wodurch man durch die verwendeten algos doch wieder auf die gleiche Geschwindigkeit kommt.

Ich habe auch mal Tests gemacht gehabt, hab das noch irgendwo liegen, finde es aber grad nicht. Ich habe in java und in C die gleichen sachen machen lassen, und dabei die gesammtzeit und die einzelzeiten vergliechen. Da waren folgende sachen dabei: Sortieren von zahlen, faktobildung, datei einlesen, alle zeichen umkehren (a wird zu z, b zu y, ...) und wieder in die datei schreiben, mandelbrot zeichnen und die ersten 10000 primzahlen ermitteln. Am ende waren zwar die zwischenergebnisse unterschiedlich, aber die gesammtzeit war in etwa gleich, ich glaub java war minimal langsammer, aber wirklich nicht nennenswert.


Allgemein:
Wenn du dich mit Java auskennst, und in C gar nicht, dann bleib bei java, bis du dich in C gut genug auskennst, hast du dein spiel in java fertig. Der umstieg von java auf C ist nicht so einfach, vorallem weil man sich viel um die platformspeziefischen libs kümmern muss.

 

[Gucky]

Ich lerne grade C++ und muss sagen, dass der Unterschied gar nicht so groß ist.
C++ ist nur ungleich mächtiger als Java mit Zeigerarithmetik, Operatorenüberladung usw.
In die API oder wie es da heißt, standart lib kommt man Googles Hilfe irgendwie rein. Der größte Unterschied ist das GUI. Das ist mit C++ schwerer zu erstellen. In Java klickt man sich das GUI irgendwie zusammen und in C++ muss man sich erst mal ein Framework aussuchen. MFC, Qt und WxWidgets sind da nur drei Beispiele.

 

[darkeye2]

Gui Erstellung ist meiner Meinung nach recht einfach (wenn man erstmal drin ist), aber hast du schon mal ein mittelgroßes Projekt in C++ geschrieben, dass auf Windows und Mac laufen soll?

Natürlich ist C eine sehr mächtige Sprache, nutze es zwar hauptsächlich bei Mikrocontrollern, aber habe schon ein paar kleine bis mittelgroße Programme geschrieben gehabt, die eben auch auf verschiedenen OS laufen sollen, und da gibts einiges zu beachten.


Was den Übergang von Java zu C(++) angeht, so einfach ist es auch nicht, jemand, der nur Java kennt, hat z.b. noch nie Zeiger benutzt. Auch ist es gar nicht so einfach, Programme für mehrere OS zu schreiben. Es ist natürlich möglich umzusteigen, aber es braucht doch Zeit, und wenn man schon eine Sprache kann und das Vorhaben sich mit dieser Sprache auch umsetzten lässt, sehe ich keinen Grund dafür, Zeit zu investieren und einen weitere Sprache zu lernen.

 

[Highchiller]

Nu sollte man natürlich auch so ehrlich sein und zugeben, dass es nie schlecht sein kann mehrere Programmiersprachen zu beherrschen. Gerade bei solch Großen, wie Java und C++ macht es schon einen enormen Unterschied ob man nur Eine oder gleich Beide kann.

Aber zurück zur eigentlich Diskussion. Ich denke eben auch, dass Java längst nicht mehr langsam ist. Das war auch irgendwo Sinn und Zweck dieser Diskussion. Was mich in erster Linie abschreckt, ist die Tatsache, dass es keine Java-basierten Spiele gibt, welche mit guter Grafik aufwarten können. Das ist schlicht weg so. Und das bekannteste und größte Java-Spiel dürfte ganz klar Minecraft sein, aber das ist eben keine "gute" Grafik im herkömmlichen Sinne.

Und auf diese Art Neuland zu betreten ist nie leicht. Da fragt man sich stets, warum hat das noch keiner gemacht? Wenn doch Java längst so performant ist wie C++. Leider ist das auch gleichzeitig der vorgeschobene Grund von leuten die keine Ahnung haben... Ich hab schon tausend mal gelesen: "Java ist langsamer und schlechter, es hat ja seinen Grund wieso es keine AAA-Games auf Java-Basis gibt."

Aber wenn das mal einer hinterfragt wirds plötzlich still.

Ich bin beim recherchieren auf Projekte gestoßen wie OpenCL (Open Computation Language), welche als quelloffene Anbindung zur GPU dienen soll, sowie Aufgrundlage dessen, die zugehörige Java bindings JOCL und/oder JCuda. Gerade die Java Anbindungen befinden sich anscheinend noch in der Alpha Phase (Versionen 0.1.9 und 0.5.5). Für mich ein ausreichender Grund wieso sich noch keiner ernsthaft mit high-end Grafik auf Java-Basis beschäftigt hat.
Ich denke und hoffe es wird dazu noch deutlich mehr kommen.

Ich würd jetzt nicht sagen, dass ich von C und C++ gar keine Ahnung habe. Vieles aus der Theorie kenne ich natürlich und so unterschiedlich sind sich C++ und Java ja auch wieder nicht. Allerdings denke ich auch, gerade wenn man in Bereiche wie Grafikprogrammierung kommt wächst der Unterschied enorm an. Daher bleib ich wohl auch bei Java. C++ zu lernen wäre eigentlich kaum die Hürde. Aber es dann so gut zu beherrschen, dass man sich an wirklich gute Grafikprogrammierung wagen kann, halte ich für eine äußerst umfangreiche Aufgabe.

PS: Naja, die GUI klickt man sich in Java auch nicht grad irgendwie zusammen. Außer man verwendet eine Art GUI-Builder und sowas gibts doch garantiert auf für C/C++ Anwendungen.

 

[Ruzmanz]

Da fragt man sich stets, warum hat das noch keiner gemacht? Wenn doch Java längst so performant ist wie C++.

Evtl. musst du über den Tellerrand schauen. Du behauptest von dir selbst, dass du dich mit Java auskennst, kannst aber keine 3D-Engine für AAA-Games benennen. Für C++ fallen dir als Amateur sofort zwei ein ... Glaubst du ernsthaft die Unternehmen bekommen armselige 10 Millionen Euro für ein AAA-Spiel und planen das dann ein, um das Rad neu zu erfinden? Oder erhalten 300 Millionen und bestehen dann auf die 2 Jahre zusätzlichen Zeitaufwand, um eine aktuelle 3D-Engine in Java zu entwerfen. Woher nimmt das Unternehmen die Experten? Wer garantiert, dass die 3D-Engine funktioniert und damit das Spiel überhaupt realisiert werden kann? Im Gegensatz dazu hast sich z.B. die CryEngine bewährt. Es gibt einige gelungene Beispiele. An der Performance wird stetig gearbeitet. An der Portabilität wird gearbeitet. Im Gegensatz zu Java läuft diese z.B. auch auf der Wii, XBox 360, PS3. Es gibt Amateuere und Experten, die man rekrutieren kann. Durch das hohe Interesse schreitet die Entwicklung schneller voran.

Auf der anderen Seite entwicklen in Java ein paar Leute hautpsächlich hobbymäßig ein paar Engines und Spiele. Das ist unter anderem ein Grund, warum die so "alt" aussehen. Versuch doch mal das gepostete Bild in Blender nachzubauen. Auch ohne Programmieraufwand ist das ein haufen Arbeit.

PS: Wenn du in dem Bereich was machen willst, würde ich JMonkeyEngine nehmen.

 

[Highchiller]

Eventuell ist AAA-Game dabei etwas hoch gegriffen. Ich hab das nur erwähnt um zu verdeutlichen was gemeint ist. Ich meine, dass Banished (der Screen von oben) ein Ein-Mann-Projekt war und dennoch Meilenweit besser aussieht als alle Java-Games.

Klar ist das ne menge Arbeit, schon allein die Modelle in Blender zu erstellen. Das Hauptproblem liegt dennoch beim programmieren.

Wenn ich dich richtig verstehe meinst du also, es gibt keine ansprechende Grafik in Java-Spielen weil niemand unmengen Geld in eine ordentliche Engine stecken würde? Und genau da ist mein Problem. Wieso eigentlich nicht? Den Nachteil, dass Java nicht auf Konsolen läuft seh ich natürlich ein. Aber es gibt unmengen Engines die auch "nur" für den PC, dafür aber auf allen Plattformen entwickelt wurde.

Ich hät halt gedacht, daran hätte sich schon mal wer gewagt. Und um auch mal über den erwähnten Tellerrand zu schauen. Java ist längst nicht mehr die Programmiersprache die nur hobbymäßig genutzt wird. Auch hier fließen Milliardinvestitionen in die Taschen.

PS: Danke, und wieso? Weil sie als fertige Engine die beste tiefe bietet um Spiele zu programmieren? Im Endeffekt werd ich sicherlich auch in diese Richtung gehn. Mal sehen :toll:

 

[Unlikus]

Ich hab grade mal einen Test gemacht. Das verblüffende Ergebnis: Das C++ Programm benötigte 2,744 Sekunden, um sämtliche Zahlen von 1 bis 1000000000 zu addieren und das Java Programm nur 1,225. Ich muss sagen, dass hat mich umgehauen.

Die Zeitmessung in C++ erfolgte mit std::clock(), falls das jemandem was bringt.

Das liegt vermutlich daran, dass dein C++ Compiler sogut wie nichts optimiert hat.
Interessant wäre also welchen Compiler du benutzt hast und natürlich das OS.

 

[Gucky]

Windows 7 und den Microsoft Visual Studio 2012 Express Compiler. Der, der da bei war.

 

[Sen-Mithrarin]

noch mal zur performance

ich wollte mit meinem post das java hauptsächlich auf der cpu läuft nicht sagen das der dort ausgeführte code langsamer läuft als z.b. C ... eher im gegenteil : wie über mir erwähnt : java hat mitlerweile sehr gute JIT-optimizer die zur runtime versuchen komplexen java-bytecode relativ einfach, aber dennoch performant, in platform-abhängigen op-code direkt für die cpu umzusetzen ...

es gibt dabei welche die es teilwese davon abhängig machen wie oft eine bestimmte zeile ausgeführt wird ... andere sind auf bestimmte algorithmen ausgelegt ... und wieder andere ziehen einfach die VM unter den füßen weg und übersetzen erstmal pro-forma alles in native-code ... ggf mit etwas weniger optimierung


und genau DAS ist bei C-code dann doch wieder anders : hier bauen der compiler und linker fertigen code der dann zur runtime nicht, oder wenn dann nur sehr wenig, optimiert wird ... sondern einfach nur so läuft wie es letztenendes ausm linker gekommen ist


hier sehe ich einen deutlichen vorteil von java das halt, wenn entsprechend optimiert und mit JIT noch mal nachgerüttelt und in native-opcode übersetzt, von der performance her mit C code mithalten oder teilweise sogar überholen kann ...


was eben java wieder einen starken dämpfer aufsetzt ist wie gesagt das eben die meisten VMs direkt nur auf der CPU laufen ... auch alles graphische wie z.b. swing oder andere grafik-frameworks ...
und an dieser stelle braucht es einfach native-libs die die calls aus java in native umsetzen um halt z.b. grafik- und physik-berechnungen über bestimmte shader auf der GPU rechnen zu lassen ... allerdings erhöt sich hier wieder der call stack um zwischen einem java-objekt und speziellem GPU-opcode umzurechnen als wenn man code schreibt der schon recht optimiert auf bestimmte GPUs ist anstatt halt alles erst umrechnen zu müssen ... wo halt wieder CPU-zeit draufgeht ... und das ganze wieder bremst


macht eine hochleistungsengine in java sinn ? klar ... wenn sich mal jemand die mühe machen würde ... ob es dann überhaupt möglich ist sei mal dahin gestellt

auch muss man sich gedanken machen : wäre es sinnvoller einfach nur java-bindings für z.b. die cry-engine zu basteln ... oder ist es besser hier das rad neu zu erfinden ?

ich weis es nicht ... bin auch nur hobby-bastler ... aber trotzdem ne grafik-hure ... ich steh einfach auf games mit high-end grafik ... ABER : ich bin auch ein fan der ur-gesteine Quake, Unreal, Doom und Half-Life ... und spiele es mit begeisterung ... auch wenn die grafik heute mehr also nur minecraft-stil ist ... auch mit HD-packs oder kompletten remakes (wobei BlackMesa:Source schon wirklich ne sahne-perle ist) ... aber KANN man sowas auch mit java umsetzen ? mit sicherheit ... möglichkeiten dürfte es genug geben ... und wie gesagt : mit optimierungen und guten compilern sowie jit-runtimes dürfte man sicher hier und da noch etwas mehr rauskitzeln ... WENN man es schafft von der CPU auf die GPU zu kommen ...

 

[Highchiller]

Hey Sen-Mithrarin, schöner Beitrag, find ich gut.

Kurz vorweg. Wenn jemand oben abstimmt, dass es da "viel bessere Lösungen gibt" wärs schon cool wenn man auch schreibt was dies für Lösungen wären... :lol: aber so jemand ließt das hier dann vermutlich gar nich mehr

Wie dem auch sei.
Eines macht mich jetzt trotzdem stutzig. Rechnet nicht OpenGL auf der Graka? Und OpenAL entsprechend auf dem Sound-Chip oder eben der Soundkarte? Mittlerweile hat sich ja auch OpenCL etabliert, welches wiederum auf der Graka rechnet.
Das sind doch richtig gute Anwendungen die mittlerweile auch alle (OpenAL eigentlich auch?) Java-Bindings besitzen. Die Grundlage ist da schon gelegt würde ich sagen. Und zum Beispiel JME greift doch auch auf diese offenen Standards zurück und rechnet damit, zumindest die Grafikoberflächen und Shaderberechnungen etc., auf der Graka.
Fragt sich jetzt nur noch wieso dann JME nicht ganz so Bombe aussieht. Liegt das einfach daran, dass die Shader nicht so gut sind? Ich denke wir sind uns mittlerweile einig das die Power da ist und auch nutzbar vorliegt.

--------------------------------------------
Noch mal kurz ein Nachwort.
Ja, selbstverständlich kommt es immer aufs Spiel an und nicht auf die Grafik. Ist das Spiel Bombe kann es auch mit mäßiger Grafik was reißen. Andersrum kann ein Spiel Bomben Grafik haben aber an sich Schrott sein, wenns kein Spaß macht.
Allerdings bin ich auch ne Grafikhure und ich hab schon viel mit Blender gearbeitet (bisher aber nur aus künstlerischen Aspekten) und will einfach mehr Und die Grafik dieser Java-Generation ist nun mal sehr ernüchternd.

 

[darkeye2]

Die Antwort auf die Frage, wieso es in Java keine gescheiten Engines gibt, wurde oben schon beantwortet: GELD

Die meisten Spieleentwickler haben bereits jede menge Geld dafür investiert, das ganze in C(++) zu entwickeln. Nun exestiert alles schon, und wird mal etwas erneuert, mal etwas ausgetauscht oder hinzugefügt, aber es muss nicht von vorne angefangen werden. In Java gibt es noch keine Engine die wirklich den industriestandarts entspricht, also würde es jede menge Geld kosten.

Früher oder später wird es auch in Java Engines geben, die mit dennen in C mithalten können, oder sogar besser sind. Die bremse ist eben das keiner jetzt investieren will.

Die java bindings von OpenGl, OpenAL und OpenCL sind der erste schritt in diese richtung, die VM optimierung des Codes der nächste schritt. Jetzt fehlt nur noch jemand, der Geld in die Sache steckt. Es ist möglich, es gibt ansätze und die Vor- und Nachteile halten sich meiner Meinung nach in Waage.

Und es muss immer jemand der erste sein. Java und Gemeentwicklung hat einen schlechten Ruf, der sich hartnäckig hält, weil leute, die sich nicht auskennen in vielen Foren und Blogs schreiben, dass Java zu langsam ist, oder eben gar nicht mit der Graka kommunizieren kann, etc..

 

[Sen-Mithrarin]

ja, ist ja richtig das die bindings letzten-endes es auf die entsprechende hardware umleiten ...
und ob es überhaupt einen unterschied macht mit der VM (die wie gesagt mit mitlerweile sehr guter optimierung locker in der gleichen liga wie C++ spielt) noch eine eben drauf zu setzen die dann natürlich entsprechend über die CPU umgerechnet werden muss ... glaub ich eher weniger dran ... vor allem wenn durch den optimizer der code dann eh als CPU-opcode vorliegt und damit genau so performant läuft wie C++
es ist halt nur diese eine schicht mehr die man beachten muss

bei engines in C++ wird es durch den compiler direkt übersetzt ... bei java wäre hier halt noch die runtime-optimierung die den code erst nach und nach übersetzt ...

man müsste also eine java-engine in dem sinne erstmal "warmlaufen lassen" bis die optimizer ihre arbeit verrichtet haben

 

[Highchiller]

Na die Umfrage entwickelt sich ja wie erwartet, leider

Ich bin über ein Thema gestolpert, dass ich bisher nicht bedacht hatte und die Diskussion eventuell neu entfachen könnte. Die Garbage-Collection.

In games programming garbage collection is not an advantage. Even if the performance of Java is more or less in par with C++ for most tasks, and the JIT can even do very aggressive optimizations that beat those that can be done during the static analysis; the garbage collection can make the framerates drop at the worst moment.

Von fortran (Stack Overflow).

Ich hab diese Erfahrung selbst schon machen müssen und war in diesem Moment ziemlich machtlos gegenüber der Garbage-Collection. Allerdings ist das eine ganze Weile her.

Wie seht ihr das? Ist die Garbage-Collection, so praktisch sie auch ist, eher ein Nachteil für Game-Developer? Gibt es Möglichkeiten der Garbage-Collection unter die arme zu greifen um möglichst viel Kontrolle über den Aufwand des aufräumens zu behalten? Oder denkt ihr das ist alles quatsch, die Garbage-Collection ist schnell genug und bremst schon seit Java 4 nicht mehr die Programme aus XD

Und was mich auch interessieren würde. Weiß eventuell einer was im Java-Camp so geplant ist für kommende Versionen, hinsichtlich Performance?!
Mit Java7 kam ja die "mächtige" Neuerung mit dem Fork-und-Join-Framework der frischen Wind gebracht hat. Bringt Java8 weitere Neuerung für die Perfomance oder für Grafikoptimierung? Dazu konnte ich bisher nichts finden.

Grüße
Highchiller

 

[darkeye2]

Der GC ist durchaus eine hilfreiche sache, und ist inzwischen auch nicht mehr so störend, wie früher ... Aber da kann man auch abhilfe schaffen, es gibt etliche methoden, wie man den GC unterstützen kann, damit er seine arbeit besser erledigen kann.


Ob es nötig ist, da was zu machen sieht man aber erst, wenn man was zum testen hat. Also wenn du dein Spiel testest, und feststellst, das der GC die performance so runter zieht, dass du es nicht ausgleichen kannst, dann kannst du dir gedanken drüber machen, dem GC zu helfen.

Es gibt wahrscheinlich inzwischen viel mehr artikel zu dem Thema, aber von meiner liste kann ich dir die zwei empfehlen:
Infos zum GC und Vorschläge zur Performance steigerung (viele infos, schon ca. 2 jahre alt, aber fand es damals sehr informatiev)
Weitere Infos zum GC noch älter als der letzte Artikel, aber Zeigt ein paar andere Aspekte.

Ich würde dir empfehlen die Texte zu lesen und die Infos im Hinterkopf zu behalten, aber dir vorerst nicht zu viele Gedanken darum zu machen. Ich hatte nur ein einziges mal bis jetzt Probleme mit dem GC und die liesen sich nach etwas einlesen in die Materie, sehr einfach lösen.

 

[Highchiller]

Das klingt schon mal sehr gut vielen Dank!

 

[Highchiller]

Und ein letzter Antritt noch. Thema Sicherheit. Die wurde bisher nämlich gänzlich außer Acht gelassen. Das Java immer wieder mit Sicherheitslücken zu kämpfen hat hört man ja immer wieder. Grad der GC war oft Ziel von Attacken.

Wenn es darum geht ein kommerzielles Projekt auf Java-Basis zu vertreiben muss man sich entsprechend schützen. Wie sieht das heutzutage aus? Gibt es gute Möglichkeiten den KlarCode zu verschleiern? Einer ausführbaren Jar kann man in der Regel auf die Inhalte zugreifen und einsehen, das wäre natürlich tötlich für kommerzielle Projekte.

Wie sehen die Sicherheitsfunktionen in der kommenden Java 8 Version aus? Hat sich viel getan?
Welche ansätze gibt es sich gegen Raubkopien zu schützen speziell auf Java-Basis?

Vielleicht einige komische Fragen, aber auf dem Thema hab ich verblüffend rudimentäre Kenntnisse Also überrascht mich XD

 

[Gucky]

Den KlarCode nicht decompilierbar machen ist, meines Wissens nach, unmöglich aber es gibt Möglichkeiten ihn mit nur sehr geringem Performanceverlust unleserlich zu machen. Er wird dabei so stark verändert und durcheinandergewürfelt, dass selbst gestandene Programmierer sich die Harre raufen. Ich hab nur leider den Namen vergessen

Sicherheit: Oracle arbeitet kontinuierlich an weiteren Sicherheitsmechanismen. Aber es ist nie unmöglich diese zu knacken. Java hat zumindest den Ruf sehr unsicher zu sein. Selbst wenn dem so nicht mehr sein sollte, so ist der Ruf nur sehr schwer weg zu bekommen.

 

[Ruzmanz]

Die Performance leidet nicht darunter. Man tauscht einfach alle Bezeichner durch "a", "b", .., "aa", etc. aus und niemand wird den Code mehr verstehen. Das Stichwort heißt "Java Code Obfuscator".

Vielleicht einige komische Fragen, aber auf dem Thema hab ich verblüffend rudimentäre Kenntnisse Also überrascht mich XD

Es ist nicht die Aufgabe von Oracle für die "Sicherheit" deiner Anwendung zu sorgen. Wobei alles was du genannt hast, nicht in die Kategorie fällt.

 

[Highchiller]

Danke schon mal.

Ich hät mich auch dafür interessiert wie es momentan mit der allgemeinen Sicherheit von Java-Codes ausschaut. Wir haben ja auch festgestellt dass der Ruf, java wäre nicht performant, ebenfalls quatsch ist. Eventuell hat sich das bei Java auch geändert und ich surfe nur auf der Mainstream-Welle mit: "Java? Voll unsicher!" :lol:

Ok. Arbeiten denn Firmen die Java-Projekte schützen wollen auch auf diese, wie ich finde, simple Art des Obfuscators?

@Ruzmanz
Naja, dass die GC massive Sicherheitslücken aufwies (wer weiß obs heut auch noch so ist) ist ja wohl die Schuld von Oracle. Mit den Sicherheitslücken wollte ich auch nicht die Probleme andeuten, die der Coder selbst missachtet, sondern die schon auf Oracle zurück fallen.
Und der Ruf, dass Java nicht sicher sei, beruht ja sicherlich auch nicht auf der inkompetenz aller Java-Developer über die Jahre hindurch.

Daher ja meine Frage, was kann man tun? Welche Gefahren lauern gerade bei Java-Programmen und sind ein gefundenes Fressen für Hacker?

 

[Gucky]

Der Obfusfaktor benennt nicht nur die Variablen um sondern er verzweigt wild im Code herum, erstellt sinnlose Methoden, teilt Methoden in mehrere Teile auf und und und... Also er tut alles, um den Code unleserlich zu machen, ohne ihn unlaufbar zu machen.

 

[Ruzmanz]

Der Obfusfaktor benennt nicht nur die Variablen um sondern er verzweigt wild im Code herum, erstellt sinnlose Methoden, teilt Methoden in mehrere Teile auf und und und... Also er tut alles, um den Code unleserlich zu machen, ohne ihn unlaufbar zu machen.

Woher kommen die Infos? Selbst ausgedacht oder kannst du das belegen? Link mit einer Produktbeschreibung würde mir reichen.

Ok. Arbeiten denn Firmen die Java-Projekte schützen wollen auch auf diese, wie ich finde, simple Art des Obfuscators?

Google: Java Obfuscators

Und der Ruf, dass Java nicht sicher sei, beruht ja sicherlich auch nicht auf der inkompetenz aller Java-Developer über die Jahre hindurch.

Java-Code wurde bisher automatisch im Webbrowser ausgeführt. Damit der Webseitenbetreiber nicht auf deine privaten Dokumente zugreift oder dein System mistbraucht, wird dieser in einer Sandbox eingeschlossen. Wenn der Webseitenbetreiber die Sandbox umgehen oder manipulieren kann, dann fällt die Barriere und er kann alles auf deinem System machen was er will. (Der Ansatz kann nicht funktionieren, wie man an Adobe Flash, JavaScript und Java sehen kann)
Wird Java nicht automatisch geladen, dann besteht das Problem nicht. In diesem Fall kann der Anwender den Schadenscode selbst runterladen und manuell ausführen. Dabei spielt es keine Rolle, ob das nun in Java, C++ oder C programmiert wurde.

 

[Gucky]

@Ruzmanz
Die Infos sind aus diesen Forum. Nur weiß ich nicht mehr von wo.
Oder auch zu finden hier

meist unter Nutzung speziell
dafür entwickelter Tools

 

[Highchiller]

@Ruzmanz
Das der Webbrowser und entsprechende Anwendung für 3D-Spiele (unter denen diese Diskussion ja steht) eine eher untergeordnetere Rolle spielt, ist, so denke ich, klar.

Wenn ich deinen letzten Absatz richtig interpretiere, macht es also aus Sicherheitsgründen keinen Unterschied das Java in einer VM läuft im Vergleich zu nativem Code? Klingt äußerst fragwürdig.

 

[Gucky]

Die VM könnte Java in der Sandbox einsperren und nicht raus lassen. Das ist aber nicht gewollt. Schließlich möchte ich auch mal mit ganz lauteren Absichten eine Datei lesen und wieder speichern.

Deshalb würde ich schon sagen, dass der Schaden derselbe ist, der angerichtet werden kann. Nur da bei Java immer die VM mitläuft, wird Java früher bemerkt.

 

[Androbin]

Ehrlich gesagt verstehe ich nicht, was an der "JMonkeyEngine" so toll sein soll!

 

[Gucky]

Sie ist vollsändig OpenSource und in Java und kann so ziehmlich alles, was mir jetzt einfällt. Sie ist nicht die beste Engine und und auch nicht dir Schömste oder Mächtigste aber sie ist relativ gut und, wie gesagt, in Java.

 

[Highchiller]

@Androbin
Kennst du was besseres für Java? Dann immer her damit.