RPG-Spiel und Performance

[Inanis]

Guten Tag allerseits und gleich mal ein erfolgreiches neues Jahr 2007 an alle.

Bin ein rechter Newbie in der Spieleprogrammierung und dachte mir, ich koennte hier mal anfragen ob ihr vielleicht wisst was ich da falsch mache, bzw. was ich verbessern koennte.

Ich moechte ein Rollenspiel im Stil von Diablo, Baldurs Gate ... (von der Bedienung und der Darstellung her) programmieren und stosse
gerade an die Grenzen der Performance. DoubleBuffering bzw. Pageflipping wird per BufferStrategy im Vollbildmodus genutzt und das
Spiel stellt sich bei mir auf etwa 15 FPS ein. Habe einen 2800 Mhz AMD-Proc. mit ner GeForce FX 5200 und einem Gigabyte Ram.
Die Tiles der Map werden aus einem File geladen. Hab zum Testen halt mal irgendwas genommen.
Die 15 FPS sind allerdings der beste Fall und es ruckelt ab und an ganz gewaltig.

Java/Javac-Version 1.6.0
Betriebssystem: Linux

Das Problem: Ich muss wenn sich der Spieler bewegt natuerlich alles neu zeichnen, weil der Spieler sich in der Mitte des Screens befindet.
Natuerlich kann man eine Abfrage starten, ob sich der Spieler ueberhaupt bewegt hat, aber das braechte ja nichts, wenn er sich bewegt.
Was also tun um an etwa 30 FPS zu gelangen? Immerhin muessen da ja spaeter noch einige andere Frames drauf.
Habs auch schon mit groesseren Tiles versucht welche in world.png zu finden sind aber da sieht es genau so schlimm aus.

Hoffe ihr koennt mir ein wenig weiter helfen.
Ich benutze, wie man leicht sieht, bisher noch einiges an Code von Dr. Andrew Davison aus dem Buch "Killer Game Programming in Java"
( http://fivedots.coe.psu.ac.th/~ad/jg/ )
Vermutlich habe ich was nicht richtig verstanden oder mache sonst irgendwelche Fehler.

Hab auch hier im Forum schon gegraben, aber das half mir leider nicht bei meiner Fehlersuche fuer meine Performance. Vielleicht unterlieft mir
allerdings auch bei der Suche ein Fehler. Dafuer moechte ich mich freilich entschuldigen.

Vielen Dank schon einmal!

Hier der Url:
Sources

 

[nocxsville]

Ich hab mir mal ein paar deiner Quellen angesehen und muss dir ganz ehrlich sagen, dass es kein Wunder ist das die Performance so schlecht ist. Alleine das Grundgerüst der Anwendung lässt jeden architekturbewussten Programmierer Schaudern.

Ich will dir wirklich nicht zu nahe treten, aber les dir erstmal die Grundzüge / Eigenschaften und -heiten objektorientierter Programmiersprachen durch bevor du dich an ein so gewaltiges Projekt wie ein RPG machst.

Gruß,
nocxsville.

 

[Inanis]

Tag Noxville,

dankeschoen fuer die schnelle Antwort. Ich kann sehr wohl mit Kritik umgehen und weiss auch selbst, dass ich viel zu lernen habe nur brachte
mich deine Kritik irgendwie keinen Schritt weiter. Auch nicht in Richtung einer besseren Struktur des Ganzen. Es waere sehr nett, wenn du
etwas konkreter formulieren koenntest, was genau dich als professionellerer Javaprogrammierer abstoesst. Dann koennte ich daraus lernen.
Natuerlich habe ich mich auch mit OOPs beschaeftigt, sonst wuerde ich ja nicht versuchen ein Javaprogramm zu schreiben. Leider, wie du
bereits bemerkt hast, bin ich ein Newbie in dieser Angelegenheit und waere froh darueber, wenn mir erfahrenere Programmierer wie du mitteilen
wuerden, was ihnen nicht gefaellt, wenn sie sich schon die Muehe machen und sich meine Sourcen ansehen.

Vielen Dank

 

[0xdeadbeef]

Mach doch da mal ein Jar oder wenigstens ein Zip d'raus. Die 'zig Dateien einzeln runterzuladen kann man ja keinem Menschen zumuten.
Auf den ersten Blick wird aber schon wieder eine beliebig kleine Sleep-Zeit benutzt, was zumindest auf einem XP-System die Systemzeit verstellen kann und in aller Regel nicht funktioniert. Alles unterhalb von 10ms sollte man in einer Schleife verbraten, anstatt die JVM und das OS mit superkurzen Sleep-Anfragen in Verlegenheit zu bringen.
Ansonsten ist halt BufferStrategy und Timing per Wait/Sleep tendeziell ein Problem. Wenn per VSync umgeschaltet wird, kann die Warterei per Wait/Sleep dazu führen, daß für den Vsync nochmal ein ganzer Refrehzyklus gewartet wird. Optimalerweise zwingt man den Refresh auf einen Wert (z.B. 60Hz) und macht das Timing ganz vom VSync abhängig. Hat natürlich auch seine Nachteile, aber einen Tod muß man sterben.

 

[Inanis]

Entschuldigung:
zip ist nun vorhanden

 

[nocxsville]

Hi Inanis,
werde ich dir ausführlich erläutern sobald ich zu hause bin

P.S.: Ich schreib dir dann eine PM.

Gruß,
nocxsville.

 

[0xdeadbeef]

Auf den zweiten Blick:
Es ist sehr auffällig, daß das Spiel um so langsamer wird, je weiter man nach rechts oder unten läuft und um so schneller, je näher man der Startposition wieder kommt. Ohne reingeschaut zu haben, vermute ich, daß da ein Bug in der "drawWorld"-Methode ist.
Abgesehen davon solltest Du nur das Zeichnen, was unbedingt notwendig ist. Den ganzen Bildschirm vor jedem Redraw zu löschen, ist für die Füße, weil ja eigentlich fast alles wieder von der Worldmap übermalt wird.
Es wäre sicher auch günstiger, die "mapTileList" (und "mapIMages") in einem Array abzuspeichern und nicht in einer Liste oder zumindest mit einem Iterator durch die Liste zu gehen, statt jedesmal per "get" das entsprechende Element von vorne zu suchen.
Gerade in der "drawWorld"-Methode sollte man natürlich auch alle Dinge, die man außerhalb der Schleife berechnen kann, auch dort berechnen. Beziehungsweise: was man einmal per Schleife berechnen kann, sollte man auch nur einmal per Schleife berechnen. Der ganze Algorithmus erscheint mir auf den ersten Blick eh etwas merkwürdig- würde das ganz anders aufziehen.
Es sieht zumindest so aus, als wüdest Du jedes "Tile" einzelen daraufhin untersuchen, ob es auf dem Bildschirm zu sehen ist, oder nicht. Das ist aber natürlich die langsamstmögliche Methode. Stattdessen Mußt Du ja nur wissen, welches Tile links oben dargestellt werden soll. Das sollte durch zwei Modulo-Operationen herauszufunden sein. Dann braucht man nur noch eine veschachtelte Schleife von diesem Tile X bzw. Y nach X+Width bzw. Y+Height, die ganz ohne Abfragen auskommt. Wobei Width/Height die Bildschirmbreite in Tiles sind. Mehr zu zeichnen bzw. zu untersuchen ist ja für die Füße.

 

[Inanis]

Mit dem Bildschirm komplett erst weiseln hast du freilich recht. Das hab ich bisher noch nicht raus gehauen, da meine Welt halt bisher
recht klein is. Da koennte man natuerlich auch ne Abfrage reinwerfen, obs der Spieler sieht oder nicht. Haus jetzt auch raus, danke.
Ich zeichne an "Welt" nur das, was der Spieler sehen kann. Das ist in der World.class geloest.

Das Problem an einem Array ist, dass es erst einmal fest ist. Eine Liste laesst sich wesentlich guenstiger erweitern aber eben dummerweise
viel teurer einen Index nutzen. Da aber das durchlaufen wesentlich haeufiger passiert als was zu loeschen, behaeltstt du vermutlich auch hierbei recht. Doch sollte ich vielleicht ne Liste benutzen und sowas wie tmp = tmp.next nutzen ...


Wow ... *auf die Stirn klatsch* Mit dem Untersuchen hast du freilich recht...
Hab das erst mal fuer alles moegliche schreiben wollen und da wusste ich ja noch
nicht wie gross Objekte werden koennen... in diesem Fall voelliger Bloedsinn. Danke!

 

[LoN_Nemesis]

Das Problem an einem Array ist, dass es erst einmal fest ist. Eine Liste laesst sich wesentlich guenstiger erweitern aber eben dummerweise
viel teurer einen Index nutzen. Da aber das durchlaufen wesentlich haeufiger passiert als was zu loeschen, behaeltstt du vermutlich auch hierbei recht.

Klingt geradezu prädestiniert für eine ArrayList (bzw Vector). Verhält sich wie eine Liste, also hat einfache Methoden zum hinzufügen etc von Elementen und so. Intern ist es aber nichts anderes als ein Array, also eine .get(index) Operation ist O(1).

 

[Inanis]

lol im ernst?
.... ok ... ich hatte naemlich zuvor eine ArrayList, bin aber gerade daran das zu aendern
*schluchz* aber im Fall einer Map, ist das wirklich sinnvoller, solange diese nicht zur Laufzeit
geaendert werden soll.
Fuer meine Monster und Gegenstaende, moechte ich allerdings eine ArrayList<Monster> oder sowas in die Richtung benutzen.
Dass sie mit O(1) laeuft wusste ich nicht. Vielen Dank fuer die Info.

 

[Wildcard]

Klingt geradezu prädestiniert für eine ArrayList (bzw Vector). Verhält sich wie eine Liste, also hat einfache Methoden zum hinzufügen etc von Elementen und so. Intern ist es aber nichts anderes als ein Array, also eine .get(index) Operation ist O(1).

Nö, eben nicht. Beim linearen durchlaufen der Elemente und beim Einfügen ist die LinkedList wesentlich besser. Nur wahlfreier Zugriff ist dann wieder deutlich langsamer.

 

[LoN_Nemesis]

Klingt geradezu prädestiniert für eine ArrayList (bzw Vector). Verhält sich wie eine Liste, also hat einfache Methoden zum hinzufügen etc von Elementen und so. Intern ist es aber nichts anderes als ein Array, also eine .get(index) Operation ist O(1).

Nö, eben nicht. Beim linearen durchlaufen der Elemente und beim Einfügen ist die LinkedList wesentlich besser. Nur wahlfreier Zugriff ist dann wieder deutlich langsamer.

Warum soll die LinkedList besser beim linearen Durchlaufen sein? Man muss halt bei einer ArrayList über die Indizes gehen. Und das Einfügen in einer ArrayList ist auch nur dann ein Problem, wenn das Array vergrößert werden muss. Wenn man ständig Elemente hinzufügt und löscht und die Größe dabei stark variiert, dann ist sie ungeeignet, aber das scheint ja nicht der Fall zu sein.

 

[Wildcard]

Und das Einfügen in einer ArrayList ist auch nur dann ein Problem, wenn das Array vergrößert werden muss.

Nein, wenn du zB etwas in die Mitte, oder am Anfang einfügst, müssen alle nachfolgenden Elemente verschoben werden.
Bei der LinkedList werden nur 2 Zeiger verbogen.

 

[LoN_Nemesis]

Ok aber standardmässig wird es ja am Ende eingefügt, wenn man von einer unsortierten Liste ausgeht ist es kein Problem.

 

[Inanis]

Dasselbe Problem hat man beim Löschen, wesshalb WildCard auch hierbei Recht behaelt.

So ... jetzt hab ich mal ne "neuere" Version online gestellt.
Hab jetzt statt der ArrayList ein 2D-Array genommen, da die Map ohnehin statisch ist.
Ausserdem habe ich noch ein paar andere Fehler in der World.java beseitigt.

FPS stellt sich mittlerweile bis auf ca. 18 ein, was natuerlich immer noch viel zu langsam ist.
Vor allem kommen ja noch die Graphiken von Gegenstaenden, Baeumen (sollte man die lieber gleich auf MapTiles hauen?)
und Monster/NPCs dazu, welche pro Screen wohl noch einmal durchschnittlich etwa 80 Sprites sein können.
(wenn zu viele Dinge uebereinander liegen, lasse ich die untersten nicht mehr zeichnen, aber das dauert eh noch)

Werd mich jetzt mal dran machen, die Sleep-BufferStrategy-Geschichte auszumerzen. Als ich Sleep mal rausgehauen und
VSync per setDisplayMode auf die des Screens eingestellt hatte, lief das ganze noch wesentlich langsamer und hat geruckelt.
Im Moment habe ich das temporaer so geloest, dass keine Sleep-Times von unter 15 ms aufkommen sollten.

Werde das spaeter wohl auch noch so machen, dass nichts geaendert wird, wenn sich der Spieler nicht bewegt, aber
es muss ja trotzdem auch laufen, wenn er sich dazu entscheidet mal die Oertlichkeit zu wechseln.

Wuerde mich ueber weitere Anregungen und Hilfestellungen freuen, falls euch was dazu einfaellt.

 

[Wildcard]

Kannst du bitte ein jar draus machen.
Ich würde gerne sehen ob das derzeitige Ergebnis interessant genug ist mich mal in den Quelltext einzulesen :wink:

 

[LoN_Nemesis]

Also ein 2D Array hat ja mal genau die gleichen Nachteile wie eine ArrayList. Wenn du wirklich so oft löschst oder anfügst dann eben eine LinkedList.

Und zu der sleep Geschichte: Wie vorher bereits von jemanden angesprochen, solltest du zu kleine sleep Zeiten in Java vermeiden. 15 sollte ok sein, aber 20 sollte auch noch reichen, das sind im Idealfall ja immer noch 50 FPS.

P.S.: .jar fände ich auch sehr komfortabel

 

[Inanis]

Werd mein Array NUR fuer die Karte benutzen, welche sich nicht aendert. Da langt ein Array und da ist natuerlich auch eine ArrayList tauglich.
Allerdings werde ich wahrscheinlich keine ArrayList fuer Monster und Gegenstaende benutzen sondern eher sowas wie ne LinkedList.
Das "List" in ArrayList hat mich wohl etwas verwirrt. Weiss nicht, wo genau die Unterschiede liegen und ich werds mir wohl mal reinziehen.

Werd mir mal Jogl naeher ansehen sobald ich Zeit dazu finde. Andere welche groessere Flaechen in ihren Spielen zu aendern haben, machen
das wohl auch oder benutzen eben was gleichwertiges.
Was haltet ihr davon?

Mein Spiel lief bei den 18 FPS uebrigens auf 1024x768, hatte ich noch vergessen mit anzugeben.

So long

Wollte euch grad noch ein Jar bescheren. Hat jedoch leider nicht funktioniert.
Bisher benutzte ich keine Jars mit Packages, benutze auch keine IDE sondern
mache alles auf Konsole.

jarr cfvm Game.jar try1.mf try1
jarva -jar Game.jar

(try1 ist der Name des Verzeichnisses, da is auch Image/ mit drin und alles scheint geadded zu werden)
try1.mf
Main-Class: try1.Game
Leerzeile

Er findet den Image-Path nicht, obwohl er auch mit im jar is. Kann mich grad leider nicht damit
auseinandersetzen weil mir die Zeit fehlt.

Hab wieder etwas gelesen:
Bisher benutze ich
int transparency = im.getColorModel().getTransparency();
wobei ich allerdings hier im Forum gelesen habe, dass man fuer Sprites besser Transparency.BITMASK benutzt.
Waere natuerlich sinnvoll, wenn ich nur Sprites verwende, welche eben nur ganz sichtbare Teile oder eben nur ganz
transparente Teile haben.
getTransparency() liefert mir allerdings bloederweise TRANSLUCENT. Hab grad nachgeprueft und in den Bildern
gibts tatsaechlich solche Pixel.
Da dachte ich mir, ich setze einfach auf transparency einfach auf 2 also auf BITMASK, falls es TRANSLUCENT ist,
aber da wirds so richtig langsam. Kann man das denn irgendwie erzwingen?
Grund: Falls einmal andere Leute Graphiken supporten moechte ich nicht alle halbtransparenten Pixel per Hand raussortieren,
die soll einfach das Programm entweder komplett transparent machen oder eben komplett sichtbar.
Die Tiles sind allerdings alles OPAQUE so wie es sich gehoert.

 

[LoN_Nemesis]

Ok für eine Karte macht ein Array Sinn,da würde ich auch einfach ein 2D Array nehmen und keine ArrayList. Sorry hatte ich falsch verstanden.

Zu der Sache mit Jogl: Das kommt darauf an, in welcher Form deine Grafiken vorliegen. Wenn es einfach nur Bilder irgendwie im .bmp, png, gif o.a. Format sind, dann wird dir das nicht viel helfen. Denn üblicherweise benutzt man dann 3D Modelle statt einfacher Sprites. Das sieht natürlich besser aus, ist aber auch deutlich mehr Arbeit.

Ansonsten kann ich dir eine IDE wie Eclipse nur SEHR an Herz legen. Kaum Einarbeitungszeit und nach allerspätestens einer Woche wirst du nicht mehr ohne wollen. Nimmt einem einfach sehr viel Arbeit ab.

 

[Inanis]

hehe, ja das glaube ich dir,

kenne einige die auf Eclipse schwoeren und ich selbst habe auch vor es mir zu installieren. Zuvor moechte ich allerdings zumindest
in etwa verstehen, was Eclipse denn so macht wenn es jar-files, Projekte etc. anlegt. Also behalte ich mir vorerst noch die Konsole
vor.

 

[MarcoBehnke]

Ich glaube das Problem mit Bildern in Jars ist, dass Du sie nicht mit Pfad ansprechen darfst/brauchst.... Einfach nur den Namen, dann müsste er die Bilder finden.

 

[Inanis]

Danke Marco fuer die Antwort. Hat leider auch nicht geklappt.
Allerdings bin ich insgesamt "einen Schritt weiter" gekommen.

Das Spiel laeuft naemlich unter Windows bei VSync-Geschwindigkeit also feinst moeglich was die FPS anbelangt.
Tja ... aber ich will ja grad Java benutzen, weil ich eben Plattformunabhaengig sein moechte. Irgendwie beisst sich
das gerade. Zumindest bekomme ich keine so schoene Performance hin wenns um Linux geht.
Habs auch schon mit dem Switch -Dsun.java2d.opengl=True versucht, allerdings eben ohne jar.
ergo java -Dsun.java2d.opengl=True try1/Game
Gemeckert hat er nicht, also schien es mir funktioniert zu haben.
Trotzdem lief es nicht schneller. OpenGl hab ich auf meiner Box installiert und mein Driver sollte es auch unterstuetzen.
Werd mich dahingehend also noch mal um die Sache kuemmern.

glxgear ruckelt sogar
the journey goes on ...

Werd mir heut abend nen neuen kernel backen und die neuesten driver dazu.
Halte euch auf dem Laufenden. Eventuell gibts ja auch andere, die daran interessiert sind.

 

[Guest]

Sodala ...

hab mir jetzt nen frischen Kernel gebacken und nen neuen Driver installiert.
Jetzt schaffe ich wie bei Windows ca die Hz-Rate des Bildschirms (75).

Hab zum Spass einfach mal das Vierfache von allen Tiles hingeklatscht.
Also pro Durchgang einfach jeweils viermal an jede Stelle dasselbe Tile
zeichnen lassen um zu sehen, wie schnell es damit noch laufen wuerde.
Es ist immerhin noch bei 22 FPS und so viele Tiles, werde ich ja mit
Sicherheit nie fuer einen Screen brauchen.
Das Ganze noch bei ner Aufloesung von 1024x768 und 32 Bit kann sich
doch sehen lassen. (klar es gibt langsamere Kisten aber 800x600 muesste
ja auch langen)

Wird alles doppelt gezeichnet, so hat man noch ca. 41 FPS auf meiner Kiste. (da is der Bildschirm dann
quasi mit Items, Monstern und Spielern voll)
Wird alles doppelt gezeichnet und alles (!) wird als TRANSLUCENT behandelt, so sinds etwa 24 FPS. (braucht man freilich auch nicht)
Das waren immer Tiles der groesse 32x32, also recht winzig. Dachte mir schon, dass groessere effektiver sein wuerden
und habs mal bei 64x64 versucht. Voila, so kamen auch bei doppel gezeichneten Tiles (OPAQUE) 75 FPS raus.
Bei doppelten TRANSLUCENT werdens da aber auch nicht mehr als ca. 28 FPS.

Last but not Least muss man anmerken, dass die Kartengroesse nur 76x85 Tiles betrug,
was allerdings immerhin schon einmal mehr als 33 Bildschirmen der Aufloesung 1024x768 entspricht.
Ausserdem glaube ich nicht, dass die Performance grossartig in die Knie geht, wenn man die Karte noch
vergroessert.
Glaubt ihr nicht? Ich auch nicht, also ran:
perl -e 'for($i = 0; $i < 1000; $i++) { print "01"x500; print "\n" }' >> world.txt (also 1000x1000 als Kartengroesse (werden ja "01" also 2 Chars ausgegeben)
Das laeuft dann immer noch mit VSync-rate also wieder ca. 75 FPS bei doppelten Tiles OPAQUE und 64x64
Bei noch groesseren Maps spielt der Java-Heap nicht mehr recht mit. Das waere allerdings eh Verschwendung von Speicherplatz.

Hoffe, das hat euch nicht all zu sehr gelangweilt. Den einen oder anderen interessierts ja vielleicht.

Hier gings natuerlich grad auch nur um die eingeschraenkte Graphik. Was die Kollisiondetection sagen wird und
wie es sich bei wesentlich mehreren verschiedenen Graphiken verhaelt, bleibt noch zu erkunden.


Jetzt fuehle ich mich dazu ermutigt endlich mit dem eigentlichen Spiel loszulegen
wobei ich erst einmal die naechsten zwei-drei Monate leider weniger Zeit dafuer
haben werde.

 

[Inanis]

Achja ... das war natuerlich grad von mir sry.

Ausserdem hab ich vergessen beim 1000x1000-Beispiel die Groesse in Bildschirmen mit anzugeben.
Klar, koennte jeder selbst, aber da ich eh grad was schreib.

Es sind ca. 5208 Bildschirme der Aufloesung 1024x768

Ob jemals so eine grosse Map als ein Stueck existieren wird, bleibt freilich fraglich. Werde
alles wohl in verschiedene Areas gliedern, was selbstverstaendlich bei vielen anderen Berechnungen
nur von Vorteil sein kann.

Ich bedanke mich grad noch bei allen die mir geholfen haben, insbesondere bei:

nocsville fuer seine PNs
Wildcard fuer seine nuetzlichen Posts die hier im Forum verstreut herumliegen

 

[Wildcard]

Wildcard fuer seine nuetzlichen Posts die hier im Forum verstreut herumliegen

lol :lol:

Viel Glück noch bei deinem Projekt. Ist in jedem Fall eine interessante Sache bei der man viel lernen kann.
Sei doch so nett und halt uns mit einem jar ab und an auf dem laufenden. Würde mich interessieren was da rauskommt :wink:

 

[Guest]

Und das Einfügen in einer ArrayList ist auch nur dann ein Problem, wenn das Array vergrößert werden muss.

Nein, wenn du zB etwas in die Mitte, oder am Anfang einfügst, müssen alle nachfolgenden Elemente verschoben werden.
Bei der LinkedList werden nur 2 Zeiger verbogen.

[Info by Beni: diesen Post bitte nicht löschen, dient als Anschauungsmaterial]

 

[Inanis]

Rehi ...
nach "langer" Zeit melde ich mich nun auch mal wieder und ja, mit meinem Projekt geht es voran, wenn auch etwas
schleppend, da ich einfach keine Zeit hatte.
Bald stehen aber die Semesterferien ins Haus und inzwischen hat sich zumindest ein wenig was getan.

Das Ganze habe ich nun in Client und Server aufgeteilt wobei der Server in C und der Client in Java geschrieben wurde.
Im Moment kann man quasi nur Chatten und nen Punkt auf der Oberflaeche bewegen.
Die Collisiondetection existiert auch schon, ist aber noch nicht mit in den Server eingepflegt.

Der Ganze Spass kommt also ins Rollen.
Den Server-Code ruecke ich vorerst noch nicht heraus (is ja eh in C) aber der Javaclient wird auf alle
Faelle Open-Source sein.
Sobald es etwas neues gibt, melde ich mich wieder.
Dann koennte es gut sein, dass ihr bereits mit anderen "Punkten" (natuerlich vorerst) auf ner Map rumtollen und chatten koennt. (naja zugegeben, das klingt nicht besonders verlockend, aber immerhin gibts ja auch Code zum kritisieren)

btw.: Wer Lust verspuert ein niedliches Fantasy-Online-RPG mit Graphiken zu bestuecken der melde sich.
(Erfahrung mit Photoshop/Gimp und einem oder mehreren 3D-Modelling-Programmen waeren hoechst erwuenscht)

so long

*wave*

 

[Vampir2005]

Hi
gugg dir mal das Spiel Chrome an das ist ein Ego Shooter in Java
geschrieben.
Beschäftige mich selber schon eiige zeit mit Java; aber das was die machen ist abgefahren.

 

[Inanis]

Tag allerseits,

ich habe jetzt damit begonnen mich ernsthafter mit der Thematik zu befassen und mich entschieden auf
Java zu verzichten.
Warum kein Java?
Java ist eine wirklich schöne Programmiersprache aber es gibt einfach schnellere Schnittstellen.
Wie Vampir schon angedeutet hat gibt es natürlich auch in Java geschriebene erstklassige Spiele.
Den Kampf um die Performance bewältigt man allerdings mit anderen Sprachen (wie C++ oder D)
einfach schneller und besser. Chrome ist im Übrigen von DirectX abhängig, was die Plattformunabhängigkeit
von Java wieder zerstört.

Mein Projekt werde ich nun in C++ (Client) und C (Server) angehen.
(zumindest bis ich einmal dazu komme mir D anzusehen)
Benutzt wird derzeit freeglut und OpenGL, womit ich wieder Plattformunabhängig bin.
(naja zumindest Linux, Mac OS und Windows und ein paar andere Unixen auf PCs (man schreibt nicht Unixe!) )
Früher oder später wird freeglut allerdings durch mehr eigenen Code ersetzt werden und
das Spiel bleibt Plattformunabhängig. (naja wenn es dann mal eines ist )
(So viel Arbeit ist die Plattformunabhängigkeit nämlich auch wieder nicht, für die, die das noch nie versucht haben.)

Derzeit kann ich Landschaften aus Hightmaps rendern und mit Texturen bestücken.
Das Ergebnis kann sich sehen lassen und es ist auch sehr performant (bei 1.045.506 Polygonen)
und das obwohl ich noch nicht optimiert habe.
(das passiert sobald ich hier fertig geschrieben habe)

So das heisst jetzt allerdings auch, dass ich hier wohl die Zelte abbrechen und weiterziehen werde.
Vielen Dank noch mal an alle und vielleicht sieht man sich ja mal wieder.

PS: An alle die sich jetzt Sorgen machen, ob sie nun doch lieber mit anderen Programmiersprachen anstatt
Java ihr Spiel verwirklichen sollen kann ich nur sagen: Macht es mit Java! Erst wenn ihr euch selbst sicher seid,
dass ihr was anderes braucht, solltet ihr euch davon entfernen. Das heisst, bis dahin lest ihr einfach genug und
macht euch ein paar Wochen Gedanken drüber.

Viel Spass am Gerät!

 

[ice-breaker]

Oh man, frei nach dem Motto ich habe gravierende Fehler gemacht daran ist Java Schuld? :roll: :lol:
Dir ist schon bewusst, dass Java auf Grund seines JIT-Compilers öfters eine bessere Geschwindigkeit erreicht als C++ oder D?
Und OpenGL hättest du auch in Java haben können, da gibt es viele nette Projekte, dir du auch hätten beweisen können, dass es keine Gründe mehr gibt für Spieleprogrammierung auf C++ zu wechseln.
Ich habe das Gefühl du gehst das alles falsch an, auch mit deine rAussage eine Map darstellen die 5000 Bildschirme füllen kann, es wird immer nur dynamisch das erzeugt was man sieht + außenrum noch ein minimaler Bereich, und dann kann man Maps erstellen die unendlich groß sind (solange die Map-Infos in den Ram passen^^)

 

[noobydoop]

Wat iss n "Pervormanz"?

Un wass meinstä mid hilväställonk?

sopper ide anzonstän.

Die Wits mid Joe Gades isss ächd lostik!

 

[Inanis]

Tag nochmal

@ice-breaker:
Wie kommst du drauf, dass es am stuemperhaften Programmieren liegen muss, wenn man die Sprache wechselt?

Kennst du das Buch "Java-Killer-Game-Programming"?
Dort versucht der Autor recht viel aus Java herauszuholen aber es ist einfach nicht gut genug.
Nicht mal wenn man den Code vom Autor mal laufen lässt. Natürlich kann ich nicht beurteilen, ob der
Autor nicht selbst "gravierende Fehler" macht. Für mich als Java-Laie (1.5 Jahre Java) sah es jedoch recht gut aus.
(OpenGL unterstützt versteht sich)


JIT:
Wenn ich will, kann ich auch ASM-Code mit einbinden um laufzeitkritischen Code zu optimieren. Ob und wie
man das löst, sind wieder ganz andere Geschichten.
Ausserdem würde mich interessieren wo du gelesen hast, dass Java dadurch _öfters_ eine bessere Geschwindigkeit
hat wie C++ und D.
Nebenbei bemerkt spricht man heute eher von HotSpot-Technologie als vom JIT-Compiler, auch wenn das Just In Time abläuft. (Tipp: Einfach mal die White-Papers von Sun zum Thema lesen.)

http://de.wikipedia.org/wiki/Hotspot-Optimierung
Man beachte, dass reichlich C++ für die Optimierung verwendung findet.

Bei Java haben sich einfach eine Menge cleverer Leute überlegt, wie man das Ganze performant bekommt und
dafür entsprechenden Code programmiert. Das heisst aber nicht, dass ihre Ideen nicht noch schneller in C++
Verwendung finden könnten. (ist ja nicht so, dass sich Compiler-Bauer darüber keine Gedanken machen)


Klar gibts OpenGL auch für Java, wie für viele weitere Sprachen aber letztendlich entscheidet man sich eben.


Test-Map:
Bei der Test-Map wurde natürlich auch nur das gezeichnet was man sieht (+Rand). Sie befand sich aber tatsaechlich schon als Ganzes geladen im Speicher. Nur vergiss nicht, dass es sich um einen der ersten Tests handelte. Man implementiert für gewöhnlich ein Feature nach dem anderen. Zumindest mache ich es so und würde dies auch weiterempfehlen.
Soviel zum "falschen" Herangehen.
Nebenbei bemerkt ist ständiges Nachladen von der Platte nicht unbedingt empfehlenswert und man sollte auch bedenken, dass ein paar mB Ram heutzutage gar nichts mehr sind. (und fuer diesen Map-Typ braucht man nun wirklich nicht viel)

Ich glaube allerdings, dass wir uns in diesem Punkt ziemlich einig sind und dass nur ein Missverstaendnis vorlag.
Sollte ich mich irren, freu ich mich auf weitere Kritik.


Ich bin recht experimentierfreudig und habe auch nichts dagegen mir Assembler reinzuziehen oder per Shaderlanguages "direkt" auf die GPU zuzugreifen. Vielleicht eine Eigenschaft die mich zu C++ bringt aber
sicher auch eine die mich für D offener macht.
Java ist nach wie vor eine hervorragende Sprache und das habe ich auch nicht bestritten. Nach meinem
jetzigen Stand der Kenntnisse jedoch ist C++ besser für meine Belange geeignet. Sollte ich falsch liegen,
werde ich damit gerne "auf die Fresse fallen" und dazulernen.

Danke für die Kritik!

so long

 

[ice-breaker]

Es werden mitlerweile atemberaubende 3d-Spiele in Flash genaut und du versucht mir zu erzählen, dass Java nicht reicht?
Schau dir mal die jMonkexEngine (der Anfang ist nen bissel ironisch gemeint, das interessante kommte später) an und du willst mir sagen, dass ein Autor der ein Buch geschrieben hat, welches mitlerweile verlatet ist dich überzeugt das man aus Java nix rausholen kann? Da ist der Gegenbeweiß.
Ich habe mir das Buch Killergame-Programming auch angesehen, es wird eine mitlerweile sehr alte Version von JOGL verwendet, was erwartest du? Zudem legt der Autor in seinem buch mehr auf Verständlichkeit als Performance.

Neija sieh dir mal die jMonkeyengine an, da siehst du dann dass sogar 3dSpiele ohne Probleme möglich sind

 

[Inanis]

Ich wäre hocherfreut wenn du dich etwas genauer ausdrücken könntest was du mit "atemberaubend" meinst.
Ansonsten kann Flash garantiert nicht im mindesten das leisten was ich gerne an Performance und Spieltiefe hätte.
(im Übrigen sage ich nicht, dass mein Projekt jemals was tolles werden wird aber alleine schon die Technik interessiert
mich)
Vielleicht ein Beispiel?

Dankeschön für das Video der JMonkey-Engine. Leider beeindruckt es mich überhaupt nicht. Gerade weil es 1. von 2007
zu sein scheint und damit recht aktuell und 2. weil ich vermute, dass die da wohl Spiele gezeigt hatten die das möglichst
beste dieser Engine aufzeigen sollen.
Da gabs weder beeindruckende Graphik noch ansonsten wirklich Rechenlastiges zu erblicken. Vielleicht solltest du dich
mal umsehen was modern in sachen performanter Engine ist.
Um ein Beispiel zu nennen könnte man auf Crysis verweisen.
Btw. fand ich Vampir's Beispiel wesentlich effektiver, wenn auch nicht hinreichend.

Zudem möchte ich mich nicht mit den Finessen eines erfahreneren Programmierteams messen, weder in
Java noch in C++. Die JMonkey-Engine kannte ich im Übrigen schon, das Video hingegen noch nicht.
Dennoch zeigt diese Video ein paar nette Beispiele die sicherlich vielen Leuten das geben dürften, wonach sie suchen.

Das Buch war nur der Versuch ein konkretes Beispiel zu liefern und es sollte ohnehin nicht für geniale Performance
sprechen, als aufzuzeigen was zumindest ein Mensch der ein Buch über Game-programming in Java geschrieben hat,
bis ca. zum Jahr 2005 darüber gedacht hat.
Er hat mich also nicht überzeugt sondern ist eine weitere Erfahrung. Nebenbei bemerkt sollte man sich vielleicht andere
Software aus dem Jahr 2005 ansehen wenn man schon über ein "so altes" Buch redet.
Ein weiteres Indiz wären die Leute der Demoszene. Zumindest habe ich bisher noch nicht mitbekommen, dass da ein
Java-Hype herrscht und für gewöhnlich stürzt sich da stets ein nicht zu verachtender Teil auf bessere Performance.

Performance-Tests die ich kenne:
D vs. Java
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=dlang&lang2=java
C++ vs. Java
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=java

Vielleicht sollten wir das Ganze über PM weiterbetreiben?
Mich würde beispielsweise interessieren was du bereits an Spielen/3D-Software programmiert hast
und woher du die Performance-Vergleiche zwischen Java und C++/D hast.