2D Spiel mit verschiedenen Auflösungen aber gleichem Bildausschnitt?

[Friedhelm]

Ich versuche gerade eine Lösung für die im Titel beschriebene Aufgabe zu finden.

Folgendes Problem:

Ich habe eine Screenauflösung von 640x480 und platziere einen Sprite auf 640,480 - Sprite.Width,Sprite.Height. Damit erscheint der Sprite rechts unten auf dem Screen.

Wenn ich jetzt auf 1280x960 umschalte, dann ist der Sprite nicht mehr rechts unten sondern in der Mitte des Screens.


Bei CallOfDuty (Menü-HUD) haben die Macher das so gelösst, dass man alle Elemente immer in der Standart-Auflösung 640x480 platziert... aber egal welche Auflösung man einstellt, die HUD Objekte immer an der selben Stelle platziert sind und auch die HUD-Sprites in der Größe angepasst werden.

Sprich, egal welche Auflösung man einstellt, es sieht immer gleich aus... nur eben Pixliger, oder weniger Pixliger.

Wie gehe ich das richtig an?


Muss ich mir eine Funktion erstellen, die alle Objekte durch diese Funktion schleust (Position, Move, Resize), und dann x,y,width,height mit einer Ratio Multipliziert (Standart-Auflösung*tatsächliche Aufösung)?

Ich arbeite mit LWJGL... gibt es evtl. einen Befehl der für mich das automatisch erledigt?

 

[Evil-Devil]

Du benötigst in dem Falle eine Funktion die deine Screenkoordinaten auf die Fensterkoordinaten umrechnet. Du sagst ja selbst, dass deine Spielwelt immer in 640*480 dargestellt wird. Wenn man nun eine höhere Auflösung bzw. ein größeres Fenster hat, dann muss man das entsprechend umrechnen lassen.

Hab in nem Buch dazu ein Beispiel und im Netz gibt es sicher auch so einiges. Mal schauen...

//edit: Mit glOrtho geht das unter anderem, wobei effektiv nur für 2D. Die Top, Bottom, Left, Right Werte werden auf die Fensterdimension gemappt. Du hättest mit glOrtho(0, 640, 0, 480, zNear, zFar) immer 640 x 480 als Spielfeld. Deine Sprites wären aber entsprechend aufm Schirm skaliert :/

 

[Friedhelm]

Hab in nem Buch dazu ein Beispiel und im Netz gibt es sicher auch so einiges. Mal schauen...

Wäre cool wenn Du den entscheidenen Code hier posten würdest, dann hätten alle die das brauchen (neben mir) gleich ne Referenz.

 

[Evil-Devil]

Wäre cool, wenn Du den entscheidenen Code hier posten würdest, dann hätten alle die dannach Suchen gleich ne Referenz.

Joar, kann ich machen. Das wird nur erst nach Feierabend (18:00+) sein 😉

 

[Friedhelm]

Ja, keine Panik, eilt nicht 🙂 Hauptsache es wird geliefert 😀

 

[Guest2]

Moin,

wenn Du doch OpenGL nutzt, ist der richtige Weg einfach die ProjectionMatrix passend einzustellen. Normalerweise mit glOrtho.

Z.B.: glOrtho(-1, 1, -1, 1, -1, 1);

Die Positionierung der Objekte erfolgt dann immer (x und y) von -1 bis +1, unabhängig der absoluten Auflösung.

Gruß,
Fancy

Edit: zu langsam...

 

[Friedhelm]

//edit: Du hättest mit glOrtho(0, 640, 0, 480, zNear, zFar) immer 640 x 480 als Spielfeld. Deine Sprites wären aber entsprechend aufm Schirm skaliert :/

Das die Sprites skaliert werden ist gewünscht.

ich nutze glOrtho(0, 640, 480, 0, zNear, zFar)... kannst Du erklären warum mit glOrtho(0, 640, 0, 480, zNear, zFar) alles gleich bleibt? Ich würds gerne genau wissen wollen 🙂

 

[Friedhelm]

Z.B.: glOrtho(-1, 1, -1, 1, -1, 1);

Die Positionierung der Objekte erfolgt dann immer (x und y) von -1 bis +1, unabhängig der absoluten Auflösung.

Das hab ich schon irgendwann mal in einem SourceCode gesehen... habe mich gefragt was das soll 🙂
Ich werd das mal probieren... bin gespannt wie sich das auswirkt.

Aber habe ich nicht das Problem, das die Bildschirmmitte wieder 0,0 ist, weil ich möchte gerne das links oben 0,0 ist (sorry, aber ich komme vom C64er Grafik-System 😀 ).

 

[Evil-Devil]

Das die Sprites skaliert werden ist gewünscht.

ich nutze glOrtho(0, 640, 480, 0, zNear, zFar)... kannst Du erklären warum mit glOrtho(0, 640, 0, 480, zNear, zFar) alles gleich bleibt? Ich würds gerne genau wissen wollen 🙂

Weil glOrtho die Angaben immer auf das jeweilige Fenster projeziert. Die Matrix im Hintergrund wird auf den glOrtho Angaben neu berechnet und fortan zur Darstellung verwendet. Damit hast auf einfache Art und Weise dir deine eigene AspectRatio geschaffen 😉

 

[Friedhelm]

Weil glOrtho die Angaben immer auf das jeweilige Fenster projeziert. Die Matrix im Hintergrund wird auf den glOrtho Angaben neu berechnet und fortan zur Darstellung verwendet. Damit hast auf einfache Art und Weise dir deine eigene AspectRatio geschaffen 😉

Das wäre gut. Nur ... wenn ich GL11.glOrtho(-1, 1, -1, 1, -1, 1) verwende... ist alls weg. Ich sehe nichts mehr auf dem Bildschirm.

 

[Guest2]

Ist Dir bekannt was ein Frustum ist? Und wie das mit den Clipping Plane zusammenhängt?

Mit glOrtho stellst Du die Projektion eben auf eine orthogonale Projektion ein und setzt die clipping planes entsprechend der übergebenen Parameter.

Positionierst Du nun Deine Objekte außerhalb der clipping planes, also außerhalb des Frustums, damit also auch außerhalb des sichtbaren Bereiches, sind Deine Objekte eben nicht mehr zu sehen.

Die Koordinaten innerhalb von OpenGL haben normalerweise nun mal nichts mit den Koordinaten auf dem Fenster zu tun – das wird alles abstrahiert. Oft normalisiert.

Gruß,
Fancy

 

[Guest2]

Oder konkret (in JoGL, hab gerade kein LWJGL hier):

    @Override
    public void display(final GLAutoDrawable drawable) {

        gl.glClear(GL.GL_COLOR_BUFFER_BIT);

        gl.glColor3f(1.0f, 0.0f, 0.0f);

        gl.glBegin(GL.GL_TRIANGLES);
        gl.glVertex2f(-1, -1);
        gl.glVertex2f(+1, -1);
        gl.glVertex2f(+0, +1);
        gl.glEnd();

    }


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

        if (height <= 0)
            height = 1;

        gl.glMatrixMode(GL.GL_PROJECTION);
        gl.glLoadIdentity();
        gl.glOrtho(-1, 1, -1, 1, -1, 1);
        gl.glMatrixMode(GL.GL_MODELVIEW);
        gl.glLoadIdentity();

    }

Ergibt ein Dreieck mit den Ecken unten links, unten rechts und oben mitte. Unabhängig der Auflösung.

Gruß,
Fancy

 

[Evil-Devil]

Bei der [1,-1] Geschichte müsste man die Skalierung letzten Endes ja selbst berechnen. Ich glaube nicht das dies der TE wirklich will 😉


Btw@guest2: registriere dich doch mal und bist du auf DGL auch vertreten?

 

[Marco13]

Btw@guest2: registriere dich doch mal

Vergiß es 😛ueh: 😉

 

[Guest2]

Das mit den Koordinaten ist ja so eine Sache, für Friedhelm ist es ja scheinbar "intuitiv richtiger" wenn oben links (0,0) und unten rechtes (640,480) ist. Für mich ist es intuitiver wenn (0,0) die Mitte ist und entsprechend (-1,-1) unten links bzw. (+1,+1) oben rechts.

Da er ja bereits in einem früheren Thread andeutete auch was mit 3D machen zu wollen, kann es imho auch nicht schaden sich auch in 2D langsam an das "normale" OpenGL Koordinatensystem zu gewöhnen.

[..] bist du auf DGL auch vertreten?

Ne, das D bei DGL steht ja hauptsächlich für Delphi und meine Delphi Tage sind schon lange vorbei. 😉
Aber ich mag deren Seiten um mal schnell ne Erklärung verlinken zu können.

Btw@guest2: registriere dich doch mal [..]

Vergiß es 😛ueh: 😉

😀 (ja, schwierige Sache 😉)

Gruß,
Fancy

 

[Friedhelm]

Das mit den Koordinaten ist ja so eine Sache, für Friedhelm ist es ja scheinbar "intuitiv richtiger" wenn oben links (0,0) und unten rechtes (640,480) ist. Für mich ist es intuitiver wenn (0,0) die Mitte ist und entsprechend (-1,-1) unten links bzw. (+1,+1) oben rechts.

Gruß,
Fancy

Ja, am Anfang war der Mittelpunkt auch bei 0,0 bis ich ihne auf links oben gesetzt habe 🙂

Ich weiß nicht warum, aber mir kommt es komisch vor mit negativen Werten für einen Spritepositon zu arbeiten. Was sind eigentlich die Nachteile wenn 0,0 in der Mitte ist, bzw. was die Vorteile wenn 0,0 links oben ist?

 

[Evil-Devil]

@DGL: Mit Delphi arbeiten die wenigsten dort noch. Viele sind auf C/C++ und Java umgestiegen. Oder halt das was sie gerade im Beruf benötigen

@Koordinaten: AFAIK hat OGL doch sein System mit 0/0 Links Unten. So steht es jedenfalls in jedem Lehrbuch. Das 0/0 in der Mitte liegt ist eigentlich nur beim 3D Koordinaten System. Wobei ich es da auch praktisch finde. Nur für ein HUD im 2D Modus gefällt mir 0/0 unten Links Unten auch besser. Wobei es bei einem Fenstersystem mit [1,-1] wieder gut ist um Elemente einfach skalieren zu können ^^

 

[Guest2]

@DGL: Mit Delphi arbeiten die wenigsten dort noch. Viele sind auf C/C++ und Java umgestiegen. Oder halt das was sie gerade im Beruf benötigen

Oh, gut zu wissen. Als ich vor längerer Zeit ein wenig dort im Forum gelesen habe, war das halt noch überwiegend Delphi und seit dem hab ich das da nicht mehr wirklich verfolgt.

@Koordinaten: AFAIK hat OGL doch sein System mit 0/0 Links Unten. So steht es jedenfalls in jedem Lehrbuch. Das 0/0 in der Mitte liegt ist eigentlich nur beim 3D Koordinaten System. Wobei ich es da auch praktisch finde. Nur für ein HUD im 2D Modus gefällt mir 0/0 unten Links Unten auch besser. Wobei es bei einem Fenstersystem mit [1,-1] wieder gut ist um Elemente einfach skalieren zu können ^^

Ja, hätte ich vermutlich genauer schreiben müssen. Auf Pixelebene, z.B. bei Texturen ist (0,0) tatsächlich unten links. Ich bin jetzt naiv auch einfach davon ausgegangen, dass Friedhelm seine Spites einfach als texturierte Quads darstellt. Dann wäre das mit der Parallelprojektion aus dem glOrtho eben einfach ein verkaptes 2D aus dem eigentlichen 3D gewesen.

Nichtsdestotrotz, wenn man [0,1] haben will, ist das ja dasselbe in grün: glOrtho(0, 1, 0, 1, -1, 1) 😉

Ich weiß nicht warum, aber mir kommt es komisch vor mit negativen Werten für einen Spritepositon zu arbeiten. Was sind eigentlich die Nachteile wenn 0,0 in der Mitte ist, bzw. was die Vorteile wenn 0,0 links oben ist?

Der wesentliche Vorteil ist, ist das der Augpunkt auf (0,0) (bzw. (0,0,0)) liegt. Das macht viele spätere Berechnungen einfach einfacher. Solange Du einfach nur ein paar Sprites darstellst, macht das wohl keinen besonderen Unterschied. Aber die Möglichkeiten mit OpenGL sind vielfältig und die Ansprüche steigen oft mit dem eigenen Können. Und spätestens dann merkst Du das (0,0,0) wesentlich unkrampfiger ist. 😉

Gruß,
Fancy

 

[Friedhelm]

Also ich habe es mit GL11.glOrtho(-1, 1, -1, 1, -1, 1); probiert.

Nur wenn die Sprites genau auf 0,0 liegen, dann sehe ich ein Mega-Sprite über den ganze Screen. Sprich, das Sprite ist so nah, dass man es nicht erkennen kann und alle Sprites die nicht auf 0,0 liegen, sind ausserhalb des Screens.

Was nun? Ist ja auch ganz klar... denn ich positioniere die Sprites ja mit Werten > 1 (450,200), und ich definiere ja mit GL11.glOrtho(-1, 1, -1, 1, -1, 1), dass der Screen nur 1,1 Pixel breit ist.

Also irgendwie scheint da ein Denkfehler oder das funktioniert nur mit JOGL, aber nicht mit LWJGL!


Hier meine GL Init:

[Java]

GL11.glPushAttrib(GL11.GL_ENABLE_BIT|GL11.GL_TRANSFORM_BIT|GL11.GL_HINT_BIT|GL11.GL_COLOR_BUFFER_BIT|GL11.GL_SCISSOR_BIT|GL11.GL_LINE_BIT|GL11.GL_TEXTURE_BIT);
GL11.glMatrixMode(GL11.GL_PROJECTION); // Select The Projection Matrix
GL11.glPushMatrix();
GL11.glLoadIdentity(); // Reset The Projection Matrix

GL11.glOrtho(-1, 1, -1, 1, -1, 1);

GL11.glMatrixMode(GL11.GL_MODELVIEW);
GL11.glPushMatrix();
GL11.glLoadIdentity(); // Reset The Projection Matrix
GL11.glEnable(GL11.GL_TEXTURE_2D); // Enable Texture Mapping
GL11.glEnable(GL11.GL_BLEND);
GL11.glEnable(GL11.GL_LINE_SMOOTH);
GL11.glDisable(GL11.GL_DEPTH_TEST); // Enables Depth Testing
GL11.glDisable(GL11.GL_LIGHTING);
GL11.glBlendFunc(GL11.GL_SRC_ALPHA,GL11.GL_ONE_MINUS_SRC_ALPHA);
GL11.glHint(GL11.GL_LINE_SMOOTH_HINT, GL11.GL_NICEST);
[/Java]

 

[Guest2]

Was nun? Ist ja auch ganz klar... denn ich positioniere die Sprites ja mit Werten > 1 (450,200), und ich definiere ja mit GL11.glOrtho(-1, 1, -1, 1, -1, 1), dass der Screen nur 1,1 Pixel breit ist.

Nein, du definierst nicht, dass das was Du darstellen willst 1x1 Pixel groß ist, sondern Du definierst das Du einen sichtbaren Bereich aus dem Intervall [-1, +1] haben willst. Das sind Gleitkommazahlen.

Beispiel:

    @Override
    public void display(final GLAutoDrawable drawable) {

        gl.glClear(GL.GL_COLOR_BUFFER_BIT);

        gl.glColor3f(1.0f, 0.0f, 0.0f);

        gl.glBegin(GL.GL_QUADS);
        gl.glVertex2f(-0.5f, -1.0f);
        gl.glVertex2f(+0.5f, -1.0f);
        gl.glVertex2f(+0.5f, -0.75f);
        gl.glVertex2f(-0.5f, -0.75f);
        gl.glEnd();

    }


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

        if (height <= 0)
            height = 1;

        gl.glMatrixMode(GL.GL_PROJECTION);
        gl.glLoadIdentity();
        gl.glOrtho(-1, 1, -1, 1, -1, 1);
        gl.glMatrixMode(GL.GL_MODELVIEW);
        gl.glLoadIdentity();

    }

Das ist ein "Block" unten in der Mitte. Egal wie die Auflösung ist, der Block ist immer an derselben Stelle. Die Koordinaten des Bildschirms haben nun mal nichts mit den Koordinaten von OpenGL zu tun.

Der Bereich [0, 640] x [0, 480] ist dann vollkommen willkürlich. Genauso kannst Du eben den sichtbaren Bereich auch auf [-1, +1] x [-1, +1] festlegen.


Als texturierter Block sähe das dann so aus:

    @Override
    public void display(final GLAutoDrawable drawable) {

        gl.glClear(GL.GL_COLOR_BUFFER_BIT);

        gl.glBindTexture(GL.GL_TEXTURE_2D, textureID);
        gl.glBegin(GL.GL_QUADS);
        gl.glTexCoord2f(0, 0);
        gl.glVertex2f(-0.5f, -1.0f);
        gl.glTexCoord2f(1, 0);
        gl.glVertex2f(+0.5f, -1.0f);
        gl.glTexCoord2f(1, 1);
        gl.glVertex2f(+0.5f, -0.75f);
        gl.glTexCoord2f(0, 1);
        gl.glVertex2f(-0.5f, -0.75f);
        gl.glEnd();
        gl.glBindTexture(GL.GL_TEXTURE_2D, 0);

    }

Du siehst, dann kommt ein weiteres Koordinatensystem ins Spiel. Die Texturkoordinaten bewegen sich in [0, 1] x [0, 1].

Es gibt in OpenGL für gewöhnlich eine ganze Reihe von verschiedenen Koordinatensystemen. Und alle spielen "irgendwie" zusammen, lassen sich aber auch (fast) beliebig neu definieren. Man muss dann nur auch dafür sorge tragen, das alles in sich zueinander konsistent bleibt.


Gruß,
Fancy

 

[Friedhelm]

Das scheint aber mit LWJGL nicht zu klappen, denn die Funktionen:

@Override
public void display(final GLAutoDrawable drawable)

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


... kennt LWJGL nicht.

Ich bekomms jedenfalls nicht hin. Ich habe alle Sprites auf Mitte 0,0 Koordinaten umgestellt. Doch wenn ich auf gl.glOrtho(-1, 1, -1, 1, -1, 1) umstelle, dann sind alle Objekte auf dem Bildschirm verschwunden.

 

[Friedhelm]

So, jetzt hab ich's :lol:

Der hinweis das die Objekte immer an der selben Stelle sind egal welche Auflösung man einstellt hat mich darauf gebracht 🙂

Ich hatte die Sprites immer abhängig von der eingestellten Auflösung platziert Sprite.y = Screen.Height - 100.

Sowas ist natürlich tödlich 😀


Aber... nun habe ich das Problem, egal welche Auflösung ich einstelle:

//Screen screen = new Screen("Game",640, 480, true, true, false);
//Screen screen = new Screen("Game",1024, 576, true, true, false);
//Screen screen = new Screen("Game",1920, 1080, true, true, false);

und ich (bei GL11.glOrtho(-512, 512, 288, -288, -1, 1); immer gleich belasse,
die Objekte haben immer die gleiche Größe (also bei 1920 sehen die Objekte immer noch so pixelig aus).

Ich denke ich muss da irgendwie was eigenes basteln. Meine Theorie ist, dass ich die fixe View Auflösung von 640x480 mit der tatsächlich eingestellten Screen-Auflösung 1920x1080 auf die Positionen jedes Sprites transformieren muss. Erst dann erhalte ich was ich eigentlich möchte.

Sprich:

ratio.x = 1920/640;
ratio.y = 1080/480;

Sprite.x *= ratio.x;
Sprite.y *= ratio.y

Dann kann ich auch GL11.glOrtho(-Screen.width/2, Screen.width/2, -Screen.height/2, -Screen.height/2, -1, 1); verwenden und die Sprites werden mit höherer Auflösung auch hochauflösender, behalten aber ihre Position bei.

 

[Evil-Devil]

Naja, du könntest deine Bilder in einer höheren Auflösung erzeugen oder einfach erzwingen das man nur ein 640*480 Fenster erzeugen darf.

 

[Guest2]

Das scheint aber mit LWJGL nicht zu klappen, denn die Funktionen:

@Override
public void display(final GLAutoDrawable drawable)

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


... kennt LWJGL nicht.

Natürlich nicht, das ist ja auch JoGL! Bei LWJGL musst Du Deine entsprechenden Methoden nehmen, bzw. dich um das reshape selber kümmern. LWJGL ist nun mal kein JoGL.

Ich denke ich muss da irgendwie was eigenes basteln. Meine Theorie ist, dass ich die fixe View Auflösung von 640x480 mit der tatsächlich eingestellten Screen-Auflösung 1920x1080 auf die Positionen jedes Sprites transformieren muss. Erst dann erhalte ich was ich eigentlich möchte.

Ich denke ehr nicht.

Dann kann ich auch GL11.glOrtho(-Screen.width/2, Screen.width/2, -Screen.height/2, -Screen.height/2, -1, 1); verwenden und die Sprites werden mit höherer Auflösung auch hochauflösender, behalten aber ihre Position bei.

Das Koordinatensystem innerhalb von OpenGL ist unabhängig der tatsächlichen Auflösung. Setzt Du etwas Auflösungsabhängiges in glOrtho ein, verlierst Du diesen Vorteil.


Auf die schnelle in LWJGL hingerotzt:

import org.lwjgl.LWJGLException;
import org.lwjgl.input.Keyboard;
import org.lwjgl.opengl.Display;
import org.lwjgl.opengl.DisplayMode;
import org.lwjgl.opengl.GL11;


public class Foo {

    private boolean     done;
    private DisplayMode mode;


    public static void main(final String args[]) {

        new Foo().run();
    }


    public void run() {

        try {

            Display.create();
            resize(640, 480);

            done = false;
            while (!done) {

                mainloop();
                render();
                Display.update();

            }

            Display.destroy();

        } catch (final Exception e) {

            e.printStackTrace();
            System.exit(0);

        }
    }


    private void render() {

        GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
        GL11.glColor3f(1.0f, 0.0f, 0.0f);

        GL11.glBegin(GL11.GL_QUADS);
        GL11.glVertex2f(-0.5f, -1.0f);
        GL11.glVertex2f(+0.5f, -1.0f);
        GL11.glVertex2f(+0.5f, -0.75f);
        GL11.glVertex2f(-0.5f, -0.75f);
        GL11.glEnd();

    }


    private void resize(final int width, final int height) throws LWJGLException {

        final DisplayMode modes[] = Display.getAvailableDisplayModes();
        for (final DisplayMode mode : modes)
            if (mode.getWidth() == width && mode.getHeight() == height && mode.getBitsPerPixel() == 32) {
                this.mode = mode;
                break;
            }

        Display.setDisplayMode(mode);

        GL11.glViewport(0, 0, width, height);
        GL11.glMatrixMode(GL11.GL_PROJECTION);
        GL11.glLoadIdentity();
        GL11.glOrtho(-1, 1, -1, 1, -1, 1);
        GL11.glMatrixMode(GL11.GL_MODELVIEW);
        GL11.glLoadIdentity();

    }


    private void mainloop() throws LWJGLException {

        if (Keyboard.isKeyDown(Keyboard.KEY_ESCAPE))
            done = true;

        if (Display.isCloseRequested())
            done = true;

        if (Keyboard.isKeyDown(Keyboard.KEY_1))
            resize(640, 480);

        if (Keyboard.isKeyDown(Keyboard.KEY_2))
            resize(800, 600);

        if (Keyboard.isKeyDown(Keyboard.KEY_3))
            resize(1024, 768);

    }

}

1, 2, 3 wechseln die Auflösung. Das ist jetzt zur Übersicht im Fenster, das Fenster wird dabei dann logischerweise größer, aber die Verhältnisse zueinander bleiben exakt gleich. Im Vollbild ist es exakt dasselbe, nur wird das "Fenster" dann nicht größer, sondern die Pixel "feiner".


Gruß,
Fancy

 

[Friedhelm]

Danke. Spock würde sagen "Faszinierend!" :toll:

Was mir aufgefallen ist, dass ich kein GL11.glViewport(0, 0, width, height); benutzt habe.

Was ich nicht verstehe ist, dass wenn ich 1920x1080 einstelle, das das untere Rechteck dann dunkelrot wird und die Maus sich nur noch träge bewegt.

Bei 1600x900 ist noch alles ok.

 

[Friedhelm]

So, ich habe das jetzt in mein Programm integriert... und hey, es sieht gut aus (auch bei 1920x1080 🙂

Sehr gut sogar.

Noch eine Frage, wenn 0,0 (x,y) in der Mitte vom Bildschirm liegt und man von der Mitte aus sich bewegt:

ist x positiv wenn man sich nach rechts bewegt
ist x negativ wenn man sich nach links bewegt
ist y positiv wenn man sich nach oben bewegt
ist y negativ wenn man sich nach unten bewegt

also:

-1 +1
-1 -1

 

[Guest2]

ist x positiv wenn man sich nach rechts bewegt
ist x negativ wenn man sich nach links bewegt
ist y positiv wenn man sich nach oben bewegt
ist y negativ wenn man sich nach unten bewegt

Ja.

Wobei Du Bewegungen vornehmlich über glTranslate realisieren solltest. Wenn sich mehrere Objekte unterschiedlich bewegen, ist vermutlich der Einsatz von glPushMatrix und glPopMatrix sinnvoll.

Zum Verständnis wie das mit dem positionieren funktioniert ist vermutlich dieses Tutorial sinnvoll.

Gruß,
Fancy

 

[Friedhelm]

Danke!