[JOGL 1.1.1a]Kleines Problem mit Text Overlays:

[Ulathar]

Ahoi Forum,

ich habe mal wieder ein Problem mit JOGL, was primär wohl daran liegt, dass ich mit OpenGL an sich noch auf einer "lerne ich gerade" Ebene bin.

Ich habe eine recht umfangreiche OpenGL bzw JOGL Scene, die auf einen AWTCanvas gerendert wird und in einem Swing GUI eingebettet dargestellt wird.
Soweit funktioniert das auch alles wunderbar.

Nun wollte ich die Scene um eine Art "TextOverlay" erweitern im sinne von FPS Counter und diverser anderer informationen (später auch 2D texturen für eine art Interface).

Auch das klappt bereits Teilweise, hier mal ein Codeausschnitt:

private void drawOverlay(GL gl, GLUT glut) {
		gl.glPushMatrix();
    	gl.glRasterPos3f(0, 0, 0);
		gl.glColor3f(0, 1, 0);
    	glut.glutBitmapString(GLUT.BITMAP_TIMES_ROMAN_10, "Ich bin ein Text");
    	gl.glPopMatrix();
    	
    	gl.glColor3d(1, 1, 0);
    	gl.glPushMatrix();
    	gl.glTranslated(-1, -1, 0);
    	gl.glScaled(.25, .25, .25);
    	glut.glutStrokeString(GLUT.STROKE_ROMAN, "Auch ich bin ein Text");
    	gl.glPopMatrix();
    }

Damit probiere ich gerade mit den Raster bzw Vector Textmöglichkeiten herum. Ich sehe beide Texte auch in meiner Scene, allerdings werden diese von meinem Trackball (also meiner Camera) beeinflusst, erfahren also ebenfalls wie die dargestellten objekte alle translationen und rotationen .

Wenn ich am anfang der Methode ein

gl.glLoadIdentiy()

sage, was meines Wissens nach eigendlich genau das vermeiden soll, sehe ich GARKEINEN text mehr .

Was ich konkret erreichen will:

ich will in der Scene quasi 2 ebenen haben.
1. die tatsächliche 3D-Szene die auf rotation und translation reagiert
2. eine 2D-Schicht die sich nie verändert, also immer z.b. in der linken oberen Ecke ist egal wo ich mich in der welt hinbewege.

Stehe da gerade aufm Schlauch und bin für jeden Tipp dankbar .


EDIT:
Achso falls es von bedeutung ist: die drawOverlay() calle ich in der display() function, wird also für jeden Frame aufgerufen. Das müsste denke ich korrekt sein...

EDIT2:
wo ich schon dabei bin:
Mein Trackball schaut zu beginn senkrecht auf den Ursprung (also auf 0,0), welcher in meinem Canvas aber nicht die untere linke ecke der Scene ist, sondern bereits ins Zentrum verschoben wurde.
Ergo erscheint mein Text derzeit ebenfalls im Zentrum des Bildes bei 0,0,0. Gibt es da nen einfachen weg den in die ecken zu bekommen? Das problem ist, dass der User die Fenstergröße nicht fix ist und zur Laufzeit verändert werden kann.

Achso und mit den Overlays soll NICHT interagiert werden müssen. sie dienen also wirklich rein als visuelle anzeige und sollen nicht klickbar, etc pp werden!

 

[Ulathar]

Hmm 40 Views und keiner ne Idee?
Kann auch noch mehr Code liefern falls das hilft...

 

[Marco13]

Vermutlich hat Fancy diesen Thread einfach nur übersehen
Ein KSKB hilft in solchen Fällen aber immer, um eher/schnell(er) eine Antwort zu bekommen...

 

[Ulathar]

Fancy? KSKB? Errr ich fürchte ich kann dir nicht ganz folgen .

Edit:
ah ok, ein kompilierbares beispiel. gut, das dürfte schwierig werden, da mein JOGL gerüst aus 11 klassen besteht und diverse renderer enthält für punkte, linien, polygone, etc (das tut auch alles wie es soll).
das problem ist "nur" das mit dem oben erwähten textoverlay um z.b. die FPS anzuzeigen.

 

[Marco13]

Hmja, Fancy ist der, der immer auf GL-Fragen antwortet.
Und ein KSKB... wäre halt schon gut, es muss ja nicht das ganze Programm sein, nur irgendwas, was compilieren und starten, und wo man dann das (un)erwünschte Verhalten erkennt...

 

[Guest2]

Moin,

gesehen hab ich die Frage gestern schon, nur war mir das glut* nicht "sexy" genug, um gestern noch drauf zu antworten.

Das, was Du scheinbar machen willst, ist ein HUD (heads up display). Dazu setz man normalerweise die Projektionsmatrix auf eine Parallel-Projektion und die Modelviewmatrix (erstmal) auf die Einheitsmatrix. Dann wird das HUD gezeichnet und anschließend die Matrizen wieder hergestellt (sofern noch benötigt).

In JOGL2 sähe das dann z.B. so aus (In JOGL1 war das imho GL2.GL_PROJECTION und GL2.GL_MODELVIEW):

        gl.glPushMatrix();
        gl.glLoadIdentity();

        gl.glMatrixMode(GLMatrixFunc.GL_PROJECTION);
        gl.glPushMatrix();
        gl.glLoadIdentity();
        gl.glOrthof(-1f, 1f, -1f, 1f, 0f, 1f);

        // draw HUD
        gl.glColor3f(0, 1, 0);
        gl.glBegin(GL.GL_TRIANGLES);
        gl.glVertex2f(0.0f, 1.0f);
        gl.glVertex2f(-1.0f, -1.0f);
        gl.glVertex2f(1.0f, -1.0f);
        gl.glEnd();

        gl.glPopMatrix();

        gl.glMatrixMode(GLMatrixFunc.GL_MODELVIEW);
        gl.glPopMatrix();

Für die "normalen" GL Koordinaten gilt dann immer das -1/1 "links/oben" ist. Bei der Positionierung mit glRaster ist das aber immer etwas unschön. Der Ursprung des Textes liegt da links/unten, sodass Du die Höhe des Textes wissen musst, um das links/oben ins Fenster heften zu können. Einfach geht das z.B. so:

   private int height;

    private void drawOverlay(final GL2 gl, final GLUT glut) {

// ...

        gl.glColor3f(0, 1, 0);
        gl.glWindowPos2f(0f, height - 10f);
        glut.glutBitmapString(GLUT.BITMAP_TIMES_ROMAN_10, "Ich bin ein Text");

// ...

    }


    @Override
    public void reshape(final GLAutoDrawable drawable, final int x, final int y, final int width, int height) {

        if (height <= 0)
            height = 1;

        this.height = height;

        final GL2 gl = drawable.getGL().getGL2();

        gl.glMatrixMode(GLMatrixFunc.GL_PROJECTION);
        gl.glLoadIdentity();
        glu.gluPerspective(45.0f, (float) width / (float) height, 1.0, 50.0);

        gl.glMatrixMode(GLMatrixFunc.GL_MODELVIEW);
        gl.glLoadIdentity();

    }

Gruß,
Fancy

 

[Ulathar]

Ah dank dir für die Antwort, werds mir mal ansehen und mich vermutlich noch mal melden .

Hast du evtl ein empfehlenswertes "Lesewerk" wo besonders die sache mit den Matrizen gut (oder anders formuliert: für dummies) erklärt wird?
Ich hab mir mein begrenztes OpenGL wissen bis dato über die NeHe GameDev tutorials angelesen und habe diese immer versucht in Java mittels JOGL umzusetzen. Das klappte da auch recht gut (der Code ist ja nahezug gleich).

Merke aber nun bei meinem "eigenen Projekt", dass komplett from Scratch geschrieben ist ohne sich an Tutorials lang zu hangeln, doch an jeder Ecke, dass ich das Prinzip das hinter den ganzen Matrizen und dem glLoadIdentity und vor allem MatrixModes steckt offensichtlich noch nicht 100%ig verstanden habe,
da es fast immer auf try & error hinausläuft.

Würd schon gern verstehen was genau da wieso abläuft (das würde dann vermutlich auch direkt erklären wieso ich mit oben erwähntem HUD solche Probleme habe).


Ach und wo ich dich gerade anner Strippe habe: würdest du JOGL2 gegenüber JOGL empfehlen? Abgesehen davon, dass es höllisch schwer is das überhaupt zu finden, bzw downzuloaden , erscheint mir ads noch in einem sehr unausgereifen Betastadium zu sein, gemessen an der frequenz der commits...
Das war auch der Grund wieso ich vor einigen Monaten mit JOGL 1.1.1a mein Projekt angefangen hatte, da ich da "weiß wies geht", zum teil jedenfalls .
Hatte testweise mal die Libs durch JOGL2 libs ersetzt, was aber extrem viele Fehler im Projekt verursacht hat und momentan fehlt mir die zeit und die Lust auf die entsprechenden API-Änderungen einzugehen. Evtl später wenn ich mit dem Projekt generell fertig bin (wollt dann auch evtl als Vergleich ne LWJGL lösung probieren ob das evtl performanter ist).

€dit:
eieiei dank dir vielmals, breits dein erster Codeausschnitt oben hat mein Problem gelöst.
ich hätte nach meinen pushMatrix jeweils nur 1x gl.glLoadidentity sagen müssen (habe das immer VOR dem push der matrix getan und mich gewundert wieso ich dann GARNIX mehr sehe ).
Jau wunderbar, mein HUD wird nun NICHT mehr durch meinen trackball rotiert/translatiert/etc. funzt nun wie gewünscht!

Macht es performancetechnisch einen Unterschied, ob ich

gl.glColor3f

oder

gl.glColor3i

verwende? letzteres würde mir nämlich lästige Umrechnungen von Java Color(int, int ,int) nach float in jedem zu rendernden Frame ersparen...

Nachtrag: hmm ok hat sich wohl erledigt, mit glColor3i sehe ich GARKEINEN text, mit Color3f hingegen schon auch color3d funktioniert oO.
komm ich also nich drum rum für jeden frame jedes mal Color.getRed() / 255, Color.getGreen() / 255 und Color.getBlue() / 255 berechnen zu lassen (die farben können sich mit jedem frame ändern daher kann ich mir die leider nicht einfach 1x umrechnen und speichern)?

Edit2:

gl.glColor3ub((byte)Settings.HUD_COLOR.getRed(), (byte)Settings.HUD_COLOR.getGreen(), (byte)Settings.HUD_COLOR.getBlue());

funktioniert, aber ob das soviel performanter ist... seltsam, dass der mit Color3i nicht will!

 

[Marco13]

glColor3i verwendet AFAIK den kompletten int-Bereich - ob das nun Integer.MAX_VALUE ist, oder aus legacy-Gründen doch nur Short.MAX_VALUE, weiß ich nicht, aber .. verwende am besten Color3ub, da weiß man, was man hat

 

[Ulathar]

also hälst du das casten der ints oben auf bytes für vertretbar in bezug auf die performance? (hab da wenig erfahrung mit).

und noch eine letzte frage die nicht mehr direkt mit dem thema zu tun hat:

unter c/c++ kann/muss man ja für eine OpenGL Scene diverse functions registrieren, darunter auch die glutIdleFunc();.
Gibt es dazu unter JOGL ein Pendant? Ich kann da nix finden, scheint nur die 4 aus dem GLEventListener interface zu geben (reshape, init, display und displaychanged).

Für einen ordentlichen FPS counter würd ich aber die "idle" funktion benötigen, oder habe ich hier einen Denkfehler?

 

[Fu3L]

Hast du evtl ein empfehlenswertes "Lesewerk" wo besonders die sache mit den Matrizen gut (oder anders formuliert: für dummies) erklärt wird?

Für Dummies wird schwer, weils generell kein einfaches Thema ist^^ Ich lese grade Real Time Rendering. (Was mir zuvor hier auch empfohlen wurde ) Also die Lineare Algebra übersteigt schon das, was man in der 13ten Klasse im Gymnasium so lernt, aber es ist verständlich. Was man noch nicht kennt, steht hinten im Anhang erläutert. Da das alles auf Englisch ist, wäre das aber ohne Grundlagen glaube ich unverständlich^^

Jedenfalls habe ich die ersten 120 Seiten durch und es sind bisher die Graphicspipeline und eben diese ganzen Transform-Matrizen erläutert worden (beginnt aber so langsam mit weiteren Techniken wie Licht und co). HUDs haben kein eigenes Kapitel, aber sollte man auch wohl hinbekommen mit den 1000 Seiten an Wissen^^ Is nur eben nicht billig das Buch und gutes Englisch ist ein Muss^^

Wenn du NUR die Mathematik lernen willst, brächte eine Amazon Suche dashier zu Tage: 3D-Grafik Programmierung: Alle mathematischen Grundlagen. Von einfachen Rasteralgorithmen bis hin zu Landscape Generation mitp Grafik: Amazon.de: Marius Apetri: Bücher. Ich kanns selbst nicht bewerten, aber die Rezensionen klingen nicht schlecht und ich war schon versucht mir das zu bestellen^^

 

[Marco13]

Das casten ist unproblematisch und praktisch umsonst. Intern rechnet Java ohenhin mintestens mit 'int', egal ob die Werte nun 'int' oder nur 'byte' sind. Das Umrechnen in float mit r/255.0f dagegen wäre ungünstig, weil Divisionen relativ teuer sind und es ja hier auch nicht notwendig ist: Die Grafikkarte muss aus diesem float nämlich früher oder später wieder einen byte-Wert zwischen 0 und 256 machen - also kann man auch gleich das byte verwenden. Aber selbst das /255 würde auf die performance nur in Extremfällen einen bemerkbaren Einfluß haben. Da gibt's in den allermeisten Fällen ganz andere Flaschenhälse.

Hmm... einen "vernünftigen" FPS-counter zu schreiben ist so eine Sache. Es gibt da zwei Muster, grob angedeutet:

void display()
{
    long before = System.nanoTime();

    // Alle GL-Befehle hier...

    long after = System.nanoTime();
    fps = berechneAus(before, after);
}

vs.

private long previous = -1;

void display()
{

    // Alle GL-Befehle hier...

    long current = System.nanoTime();
    if (previous != -1)
    {
        fps = berechneAus(previous, current);
    }
    previous = current;
}

Bei der ersten Variante wird gemessen, wie lange ein Durchlaufen der display-Methode braucht.
Bei der zweiten Variante wird gemessen, wie viel Zeit zwischen zwei vollständigen Durchläufen der display-Methode vergeht.

Oft sieht man die erste Variante, aber die ist IMHO (ganz subjektiv) kompletter Bogus: Damit wird gemessen, wie oft die display-Methode pro Sekunde ausfeführt werden KÖNNTE (wenn zwischendurch NICHTS anderes passieren würde).
Die zweite Variante ist IMHO eher das, was man wirklich messen will, nämlich genau wie oft die display-Methode pro Sekunde aufgerufen wird. Allerdings setzt diese Variante voraus, dass die display-Methode tatsächlich so oft wie möglich aufgerufen wird. Das würde in C++ mit der "glutIdleFunc" erreicht, wo man nur ein "glutPostRedisplay" reinschreiben würde.

In JOGL gibt's dafür die "Animator" Klasse. Die wird AFAIR schon bei den meisten Beispielen verwendet: Der Animator erfüllt quasi die Funktion von glutIdleFunc/glutPostRedisplay, und hat auch eine Methode setRunAsFastAsPossible und so. Kannst mal im Web nach Beispielen suchen, da findet man schnell was dazu. (Beachte, dass die Animator-Klasse zwischen JOGL und JOGL2 in ein anderes Package gewandert ist - aber die Verwendung bleibt praktisch gleich...)

 

[Ulathar]

Danke für den Tipp, ich werds mal bei zeiten in unserer Unibibo schauen ob die das evtl dort haben.
Gutes Englisch ist kein problem .

Wobei es mir nicht mal um die Mathematik geht die dahinter steckt sondern eher um die korrekte Anwendung der jeweiligen Matrizen und Modi. Die "tolle" JOGL Doku sagt bei denen nämlich immer so unglaublich aussagekräftige Dinge wie "entspricht der C implementierung" ^^.


€dit:

oh der marco is mir dazwischengerutscht.

Das Umrechnen in float mit r/255.0f dagegen wäre ungünstig, weil Divisionen relativ teuer sind

jo ich weiß, besonders mit Gleitkommazahlen, jedenfalls wenn diese von der CPU berechnet werden, deshalb wollte ich das ja vermeiden. aber wenn casts generell "wenig kosten" hat sich das direkt erledigt.

Bei der zweiten Variante wird gemessen, wie viel Zeit zwischen zwei vollständigen Durchläufen der display-Methode vergeht.

Genau das "Modell" wollte ich realisieren wozu ich besagte idle Funktion brauchen würde (jedenfalls dachte ich das). Werd mal n bischen damit rumprobieren und als Vergleich mal Fraps oder so drüberlegen (ohne zu wissen wie das intern die FPS ermittel). Mal schauen was für Zahlenwerte ich bekomme und ob die sich ähneln.

 

[Marco13]

Für die reine GL-Doku schau' ich gerne mal auf glPushMatrix ? DGL Wiki : Dort stehen die Befehle bequem auf deutsch erklärt, die Unterschiede zwischen Delphi und anderen Sprachen sind unbedeutend. Manche Befehle sind ähnlich "dünn" erklärt wie in der OpenGL-spec, aber manche sind ausführlicher und gut erklärt (speziell Kategorie:Exzellent ? DGL Wiki )

Aber noch nebenbei: Die ganzen Matrix-Sachen (glPushMatrix, glLoadIdentity usw) sind veraltet. Die stammen noch aus Zeiten von OpenGL 1.1, inzwischen sind wir bei OpenGL 4.x, und mit OpenGL 3.2 wurden diese Befehle (genauer: Die gesamte "Fixed Function Pipeline") als "deprecated" erklärt. Der Schritt von OpenGL <3.2 auf >= 3.2 kann eine Art Kulturschock sein (war es zumindest für mich...), ich wollte nur erwähnen, dass du dir vielleicht gar nicht mehr unbedingt die spezifischen Aspekte davon reinziehen musst, sondern dich (wenn du ein ein bißchen Frustrationsdurst verspürst) gleich die "moderne" Variante lernen könntest.... Fancy hat hier in einigen Threads JOGL-Start-Pakete zu GL 3.x verlinkt. Weitere Ansätze in Form von Snippets für C++ gibt's z.B. auf nopper.tv - Norbert Nopper's Homepage , aber nochmal: Ich fand es im ersten Moment ziemlich ... schwer zugänglich...

 

[Ulathar]

Noch ein Nachtrag zu deinem FPS Countervorschlag:

Ich benutze ebenfalls einen FPSAnimator, allerdings OHNE "runasfastaspossible" zwecks "schonung der hardware".
Übergebe atm als FPS Cap 60, ergo dürfte mein FPS counter zu keinem Zeitpunkt mehr als 60 anzeigen. Interessant wirds für mich eh eher dann, wenn ich mehrere hunderttausend, bis millionen Elemente in meiner Szene habe (geht um verarbeitung und visualisierung riesiger Punktwolken), da ich dort beim wandern durch die "welt" merke, dass selbst meine HD5850 da langsam an ihre Grenzen stößt .
Mir gehts also nicht darum zu sagen "woooah ich hab 300 fps" sondern eher um zu schauen ob und wenn ja wie stark sich Codeoptimierungen meinersets später auf eine bessere Performance auswirken wenn man eben nicht mehr an das FPS Cap gelangt, das man dem FPSAnimator übergeben hatte.

Ich mach mich gleich mal dran das umzusetzen und poste nacher mal meinen Ansatz (bin da für verbesserungen dann auch gerne offen).


Das mit den neuen Standards was OpenGL betrifft werd ich mir bei meinem "nächsten Projekt" zu gemüte führen. Ich muss mit dem Kram hier innerhalb der nächsten Woche quasi fertig werden und das wird mir dann doch zu zeitkritisch, vorerst gilt: Hauptsache es tut! (wie gesagt, ein Vergleich mit LWJGL steht auch noch auf meiner wishlist für die nahe Zukunft, aber auch erst wenn das eigendliche Projekt tut was und wie es soll).

 

[Ulathar]

So hier meine angekündigte Rückmeldung, der FPS Counter ist nun fertig und funktioniert 1A. Ich erhalte zwischen 60 und 62 FPS wenn ich den glutTeaCup in die Scene lade. Also minimal mehr als beim FPSAnimator angegebenen Cap von 60. Das dürfte auf "messungenauigkeiten" zurückzuführen sein.

Interessant ist, wie das "skaliert". Wenn ich <= 25.000 Elemente in die Szene lade halte ich die 60 FPS. Dann fallen sie rapide auf etwa 20 FPS (bei 75k Elementen).
Wenn ich dann rauf auf 5.000.000 Elemente gehe, bin ich runter auf 5 FPS .


Hier wie ich den FPS Counter implementiert habe, falls jemand mal für JOGL einen sucht (ich lasse teile aus dem Code raus, die nicht zum Counter gehören!):

public class Renderer implements GLEventListener {

	private int			frames			= 0;
	private int			fps				= 0;
	private long 		previousTime	= 0;
	private long 		currentTime 	= 0;
	private	long 		timeInterval	= 0;

    public void display(GLAutoDrawable gLDrawable) {
    	// hier allen kram machen der gezeichnet werden soll

        // update FPS
        frames++;
        
        //  get SystemTime in nanosec        
        currentTime = System.nanoTime();
        
        // time passed
        timeInterval = currentTime - previousTime;
       
        // check if one second has passed
        if(timeInterval > 1000000000) {
            //  calculate the number of frames per second
            fps = (int)(frames / (timeInterval / 1000000000));
            //  update time
            previousTime = currentTime;

            //  reset frame count
            frames = 0;
        }
}

Ich erhalte so einen FPS Counter der sich ca jede Sekunde updated. Scheint sehr gut zu funktionieren. Falls sich das noch optimieren lässt immer her mit Vorschlägen . Ansonsten mach ich das Topic mals als "erledigt" zu.

 

[Guest2]

Ach und wo ich dich gerade anner Strippe habe: würdest du JOGL2 gegenüber JOGL empfehlen? Abgesehen davon, dass es höllisch schwer is das überhaupt zu finden, bzw downzuloaden , erscheint mir ads noch in einem sehr unausgereifen Betastadium zu sein, gemessen an der frequenz der commits...

Also die offizielle URL von JOGL2 ist JogAmp.org - java graphics, audio, media and processing libraries. Leider schwankt die Qualität der dort angebotenen Builds teilweise deutlich. Das reicht von ab und an falsch gebauten JARS (die eigentliche JAR liegt in einem JAR) über falsche JARS (die eigentlich GZ sind) bis zu fehlenden nativen Bibliotheken. Eine vollständige Kombination aller Dateien zu finden / basteln ist in der Tat etwas nervig.

Das (imho hauptsächlich Sven Gothel) momentan intensiv an JOGL2 baut, finde sich eigentlich sehr positiv und bemerkenswert. Es scheint mir an sich auch relativ bugfrei zu sein, auch wenn mir die Entwicklung (zumindest für mich als außenstehenden) teilweise etwas chaotisch vorkommt (z.B. jogamp.org vs. com.jogamp das kann man doch eigentlich nicht übersehen?).

Der Vorteil von JOGL1 ist, das die JARS noch von SUN signiert wurden (allerdings nur noch bis zum 12.5.2012 gültig). Dadurch kommt es auch bei der Verwendung in Applets oder Webstart zu keinerlei Rückfragen an den Nutzer. Die JOGL2 JARS sind zwar auch signiert und werden von der JVM auch als korrekt signiert erkannt, jedoch kommt es immer zu einer Rückfrage an den Nutzer, da es sich eben nur um "normale" Zertifikate handelt.

Der Vorteil von JOGL2 ist definitiv das auch die neuen OpenGL Profile unterstützt werden. Nur so kommt man an die neuen Spielsachen.

Hatte testweise mal die Libs durch JOGL2 libs ersetzt, was aber extrem viele Fehler im Projekt verursacht hat und momentan fehlt mir die zeit und die Lust auf die entsprechenden API-Änderungen einzugehen. Evtl später wenn ich mit dem Projekt generell fertig bin (wollt dann auch evtl als Vergleich ne LWJGL lösung probieren ob das evtl performanter ist).

Einige Fehler kommen daher, dass einige Klassen nun in anderen Paketen liegen. Die Restlichen daher, dass nun verschiedene GL Profile unterstützt werden. Aus Deinem GL wird dann z.B. ein GL2.

LWJGL sollte nicht schneller sein. Beides sind lediglich Wrapper, die eine ähnliche Technik einsetzen. Lediglich die Art wie die C-Funktionen in JAVA als API zur Verfügung gestellt werden unterscheidet sich.

Gruß,
Fancy

 

[Guest2]

Da hier ja auch OpenGL >= 3.2 angesprochen wurde, noch als Nachtrag: Learning Modern 3D Graphics Programming

Bin zwar gerade selber erst drüber gestolpert, scheint mir aber auf den ersten Blick eine der ausführlichsten und technisch saubersten Seiten dazu zu sein.

Gruß,
Fancy

 

[Marco13]

Ja, das sieht sehr gut aus. Hätte ich vor 2 Jahren gebraucht

 

[Guest2]

Die Seite hätte mir damals wohl auch den einen oder anderen "verfluchten" Abend erspart. Eigentlich ist es erstaunlich, wie lange es das nun schon gibt und wie wenig "gute" Seiten es darüber gibt. Z.B. UBOs gibt’s seit 3.1 und trotzdem ist die Seite eine der wenigen, die das überhaupt erwähnen. Und zu den neuen 4.x Spielsachen gibt’s leider noch viel weniger (mehr als einzelne Blogeinträge hab ich dazu noch nicht gefunden).

Gruß,
Fancy

 

[Ulathar]

Hmm ja der Link sieht sehr interessant aus. Mal schauen wann ich Zeit finde das durchzuarbeiten, dürfte auch nich interessant werden, dass dann auf JOGL zu übertragen, da ich in C/C++ an der Uni leider nur die Grundlagen gelernt habe (Hauptsprache ist hier seit Jahren Java).