# LWJGL oder OpenGL (C++)



## Pommes9485 (25. Nov 2012)

Guten Tag,

mein Kumpel und ich schreiben momentan ein Spiel und mir sind jetzt langsam die Grenzen von LWJGL klar geworden, da zuviele Polygone im FPS Einsturz enden.

Noch lässt sich alles relativ einfach in C++ umschreiben, aber die Frage ist jetzt halt :
Ist OpenGL VIEL Effizienter unter C++ als LWJGL unter Java ?

Vor allem runde Objekte sind "anstregend" und wir wollen am Ende kein Baustein Spiel haben...


----------



## trääät (25. Nov 2012)

LWJGL kann intern auch über OpenGL rendern ... siehe Minecraft ...
das problem dürfte hier eher der java-code an sich sein der zur großen performance-bremse wird ...
wobei ich grundsätzlich schon sagen würde das es performance-plus gibt wenn man es direkt in C++ schreibt als über java und dann native-libs ...


----------



## Guest2 (25. Nov 2012)

Moin,

der Grafikteil von LWJGL ist nur ein relativ dünner Wrapper um das native OpenGL, einen Geschwindigkeitsunterschied gibt es da höchstens akademisch. Ob C++ oder Java schneller ist, hängt imho von den Fähigkeiten des Entwicklers ab. Einige schreiben schnelleren C++ Code andere schnelleren Java Code.

Wenn ich hier raten müsste, dann das es im Code von Pommes Sequenzen aus glBegin, glVertex3f und glEnd gibt. Das wäre ein Fehler. Hier wird beschrieben wie Vertices auf die Grafikkarte geschoben werden.

(Wenn es nicht daran liegt, dann würden ein paar Details helfen das Problem einzukreisen.)

Viele Grüße,
Fancy


----------



## Helgon (25. Nov 2012)

Ich hab auch mit OpenGL angefangen, bin dann aber auf DirectX also C++ umgestiegen und finde es irgendwie "sauberer" und besserer abgepackt (vorallem eben seit dem großen Update der DirectX 11 API) - nur mal dazu.

Aber punkte performance. Ich arbeite mich grad durch alle möglichen Themen durch und da gibt es jedes mal so viele verdammte Möglichkeiten etwas anzugehen und alles wirkt sich anders auf die Performance aus.

Nehmen wir GemometryShader, bis 20 Vertices ist es ok, ab 27-40 Vertices haste 50% Einbuse, davor aber der heillige Gral der Tesselation

Oder wie oft man den BlendState, RasterSate oder irgendwelche DepthStencils ändert.. je weniger desto besser, oder wie man welche Objekte rendert.. von front to back um hardware basierte z-depth-tests durch zu führen oder wenn mans genau anders rum macht weil man blending verwendet usw usw.. 

oder hat man einen dynamischen vertex buffer der über die cpu arbeitet oder implementiert man es über hlsl sodass es die gpu abwickelt..

oder lädt man daten von der gpu in die cpu oder sonst was sodass es zu nem bottleneck kommt.. alles wirkt sich auf die performance aus

bin selber kein profi was das angeht, aber ich merk selbst, dass "wie man es schreibt" einen viel größeren einfluss auf die performance hat als alles andere (zumindest auf unserem niveau)

Grüße


----------



## Kr0e (25. Nov 2012)

C++ bietet Vorteile was Puffer angeht, da es wirkliche Pointer gibt. Ich gebe Fancy recht, der
ggf. entstehende Unterschied hängt vom Programmierer ab.

Ein Beispiel:

Java hat einen GC. Das ist in erster Linie gut, aber leider bietet Java nur Heap-Alloc an. Ergo jeder Vektor, jede Matrix, jedes Array landet erstmal auf dem Heap und muss dort auch wieder entsorgt werden.

Ja, ich weiß, es gibt Libs mit denen man Javaobjekte auf dem Stack anlegen lassen kann, aber viele wissen das nicht/nutzen es nicht.

C# bietet hier eine sehr schöne Zwischenlösung, dort gibt es structs und ref/out. Sowas hab ich in Java immer schon vermisst.

Man muss also wissen wie man performanten Code schreibt, sowohl in der einen, als auch in der anderen Sprache.


Tendentiell kann man sagen, dass C++ natürlich mehr Potential hat, man muss eben wissen, wie man es rausholt. Dafür ist das Arbeiten in C++ etwas unproduktiver , zumindest hab ich es so immer empfunden.


Fazit: Bleib bei dem was dir liegt. Auf Teufel komm raus ein Programm in C++ übersetzen wird erstmal nichts bringen. VBO und VAO sind hier relevante Stichworte um aus OpenGL das allerletzte rauszuholen.


Ich persönlich würde vermutlich auf C++ setzen, allein schon wegen den zahlreichen Tools/Libs/Engines die es gibt. Aber das ist Geschmackssache...


----------



## Titanpharao (26. Nov 2012)

Würde auch mal sagen, das es stark an deinem Code liegt und sich mit OpenGL C++ nicht wirklich bessern würde.

Hat damals mit der JME ~15 Millionen Polygone auf dem Bildschirm was etwa 10x soviel ist wie bei Crysis 2 (Startsequenz auf die Stadt^^) ist ... und 60 oder 30 fps. Auf jeden fall absolut akzeptabel.

Frage ist doch, was du für "Krasse" Models benutzt, das ein Designer Model was primär für 3DS Max render vorgesehen ist, nicht in ein Spiel gehört da es allein schon mehrere Millionen Polygone hat.

Sonst NIO Buffer und VBO wie schon erwähnt .... sollte eigentlich nicht wirklich einbrechen :S


----------



## Marco13 (26. Nov 2012)

Ich fand neben seiner schieren Existenz den Wiki-Eintrag As Fast As Cee ganz unterhaltsam. Ansonsten kannst du mal einen Blick auf Bytonic Software werfen, und davon ausgehen, dass das ganze mit Java 7 nochmal (ggf. deutlich) schneller geworden ist. (Die C-Version bleibt für immer so schnell wie sie jetzt ist - so viel dazu  )


----------



## Kr0e (26. Nov 2012)

Man kann schon nicht wegdiskutieren, dass Managed-Code Nachteile hat. Garbage-Collection finde ich persönlich überflüssig, auch schon deshalb weil ich in Java mal erlebt habe, dass es ein OutOfMEmory Error gab, weil ich zu oft neuen Speicher alloziiert habe und der alte nicht schnell genug gelöscht wurde.
Ja ich weiß, mann kann mit irgendwelchen JVM Tricks den GC stark konfigurieren, aber alles im allem... Warum der ganze Hickhack wenn man RAII & Destructor nutzt. Grad C++11 bietet was Return-By-Reference angeht sehr schöne neue Verbesserungen.

Aber man sollte definitiv nicht wegen ein paar Prozent Gewinn etwas nhemen, was einem nicht liegt. Vorallem sind mit ein paar Prozent viele Optimierungen und dreckiges Insiderwissen nötig.

Auch hat Java so seine Probleme was nativen Speicher angeht. Habe damals einen Videoplay mit ffmpeg und Píxel Puffer Object in Java geschrieben. Bei Full HD 90 % Auslastung. Laut Profiler ging die gesamte Zeit fürs kopieren der Puffer drauf, also wenn man FFmpeg einen Puffer zum befüllen gibt. Eine in C++ geschriebene Variante brachte 6- 8% Auslastung. Das ist kein Beweis, dass C++ besser ist, sondern einfach dass gewisse Tools eben für gewisse Sprachen ausgelegt sind, mehr nichtz


----------

