''Da auf meine Anfrage nach dem geplanten Spiele-Typ für das Spielprojekt auf der Mailingliste leider kein Reply kam - starte ich diese Frage hier nun mal im Wiki (obwohl das ja eigentlich nicht der richtige Platz dafür ist)''

''Sorry - die Mailingliste vergammelt bei mir in einem extra-Ordner, in den ich aus Spam-Gründen nicht reinsehe. Ein Grund mehr, der Diskussion auf LugMailingListe zu folgen, und das zu ändern (siehe dort). -- ThomasBayen''

Was für Spiele hattet ihr euch überlegt in Java und mit OpenGL zu realisieren?

* Puzzle (z.B. Tetris)
* First-Person Shooter (z.B. wie Quake oder Unreal Tournament)
* Rollenspiel (z.B. wie Neverwinter Nights)
* Action-Adventure (z.B. wie Tomb Raider)
* Jump'nRun (z.B. Spyro the dragon, Rayman)

Um erste Erfahrungen in der Spieleprogrammierung zu sammeln bietet sich ein 3D-Puzzle an, denn dann kann man sich in OpenGL und auch in die Spieleprogrammierung hineinfinden.
Die anderen Kategorien enthalten schon zum Teil recht komplexe Softwarestrukturen und mathematische Hintergründe - ich bin (falls ihr das möchtet) natürlich gerne bereit darüber zu informieren und einen Überblick zu geben, da ich dabei schon in die eine oder andere Programmierfalle getappt bin.
Bei einem Puzzle stellt sich allerdings die Frage: Was für eines? Es sollte ja sowohl optisch als auch spielerisch ansprechend sein um den "Linux Spielemarkt" aufzumischen ;)

----

Das ist ja gespenstisch... ich hatte gerade einen langen Absatz hierzu auf JavaGrafik geschrieben... Ich hoffe, was dort steht, beantwortet Deine Fragen einstweilen. Deine Hilfe nehmen wir natürlich sehr gerne an. :-) Vielleicht sollte man diesen Absatz auf diese Seite hier umlagern?!? -- ThomasBayen

----

Was mich persönlich angeht, möchte ich erstmal alle zugrundeliegenden Technologien stückweise lösen und dann erst das echte Spiel anfangen, wenn ich weiß, das ich alle Fertigkeiten dazu beherrsche. Leider ist aber ein wichtiger Punkt, den man nur durch die echte Applikation herausfinden kann, die Performance. Unsere Welt besteht ja aus recht vielen Polygonen mit Textur. Eine erste Version ohne Texturen kam auf meinem (zugegeben rechenschwachen) Thin Client auf 3-4 fps, die ich mit Drawlists und einigen Optimierungen auf Kosten der Klassen-Eleganz auf über 5 gepusht habe... Auf der Grundlage brauche ich über Texturen gar nicht nachzudenken. :-( Wie würdest Du da rangehen? -- ThomasBayen

----

Um wieviele Polygone handelt es sich denn? Sind es wirklich Polygone? Am besten wäre es Polyone aus Dreiecken aufzubauen, denn darauf sind die Grafikroutinen optimiert. Es gibt mehrere Optimierungsstrategien - leider fallen bei Java die meisten weg :( Darum ist dein Ansatz mit den DisplayLists schon sehr gut - du könntest nun noch dafür sorgen dass die Vertices möglichst oft im Vertexbuffer der Grafikkarte liegen wenn sie gebraucht werden. Jeder Vertex das zur Grafikkarte geschickt wird, wird dort in einen Puffer eingetragen. Dieser fasst irgendwas zwischen 8 und 64 Vertices. Wenn nun Dreiecke gezeichnet werden deren Eckpunkte bereits im Puffer liegen kann die Grafikkarte sich die Matrixmultiplikation sparen und das Dreieck sehr schnell zeichnen.
Dies ist aber schon eine fortgeschrittenere Optimierung - eine die viel mehr Performance bringt ist es die Dreiecke nach Renderer-Zustand zu sortieren. Also möglichst viele Dreiecke an einem Stück zeichnen ohne dass man Methoden wie glBindTexture, glEnable oder glDisable aufrufen muss. Dies sind aber wirklich Optimierungen die man erst dann macht, wenn man sicher ist auch nur dass zu zeichnen was wirklich sichtbar ist.

Um die Anzahl an sichtbaren Dreiecken zu reduzieren gibt es mehrere Ansätze:
* '''Spatial data structures (BSP-Bäume, Octrees)''' - mit diesen Strukturen kann man sehr schnell ermitteln welche Geometrieelemente sich in einem bestimmten räumlichen Bereich befinden. Lässt man diese Strukturen auf den View-Frustum (die Sichtpyramide) los, dann nennt man das View frustum culling - es werden dann nur die Dreiecke an die Grafikkarte geschickt die auch sichtbar sind. Diese Strukturen sind auch unentbehrlich wenn es um Kollisionsabfragen geht.
* '''Terrain-culling''' - dies ist eine Technik die davon ausgeht, dass es ein Gelände ohne Höhlen gibt - d.h. alles was sich hinter einer Bergkette befindet ist unsichtbar. Ich habe dies bisher nicht implementiert, aber davon im Buch "Real Time Rendering" gelesen. Die Technik liest sich sehr rechenintensiv.
* '''Level-of-detail (LOD)''' - hierbei werden Objekte die weiter entfernt sind auch durch weniger Dreiecke dargestellt. Da Objekte die weit weg sind klein sind, tragen sie auch wenig zum Detailgrad des Gesamtbildes bei. Aus diesem Grund genügt es für diese Objekte reduziertere Modelle zu verwenden. Man kann diese reduzierten Objekte gut automatisch berechnen, muss sie also nicht per Hand erstellen.
* '''Backface culling''' - dies ist die einfachste und einzige von OpenGL nativ unterstützte Technik. Sie besagt einfach, dass alle Dreiecke deren Rückseite nach vorne zeigt nicht gezeichnet werden. OpenGL ermittelt die Seite eines Dreiecks über deren Windung: Im Uhrzeigersinn=vorne, gegen den Uhrzeigersinn=hinten (oder umgekehrt *g*).

Kannst du evtl. noch ein paar Eckdaten deines Programms nennen? Z.B. auf welcher Auflösung läuft es bei dir? Hast du Hardwarebeschleunigung aktiviert? -- StefanGaffga

: Wie ich sagte, gibt es im Grunde genommen noch kein Programm, höchstens eine Technologiestudie ;-). Ich würde das Programm gerne als Fenster auf einer normalen Oberfläche, also mit 1024x768 oder 1280x1024 in 24 Bit laufen lassen, brauche aber nicht wirklich eine so hohe Auflösung und bestimmt nicht so viele Farben. Ich benötige für den strategischen Überblick mindestens 40x40 angezeigte sechseckige(?) Felder, was nach meinen bisherigen Überlegungen 9600 Dreiecke ergibt. Das, was KaiEhlers erreichen will, kommt wohl mit weniger Feldern aus, enthält aber dafür wohl mehr Details und vor allem mehr bewegliche Figuren. Die fps-Rate, die ich angegeben habe, gilt für meinen Thin Client bei Ausgabe übers Netzwerk. Ich benutze das als langsamstes mögliches Szenario, auf dem mein Programm möglichst noch laufen soll. -- ThomasBayen