Programmieren auf verschiedenen Bildschirmauflösungen

[Kaeru Gaman]

hä? wie was umrechnen? o_O

klärt vielleicht mal, über was präzise ihr überhaupt diskutieren wollt.

hier laufen grad 2D und 3D und Gadgets und Screenwidth/15 durcheinander wie kraut und rüben.
versteht doch kein A... mehr.

[#NULL]

>>es hat mich nur mal so interessiert wie das die professionellen entwickler immer lösen.
ich würde sagen, allgemein ist es immer so gelöst, wie man es am ende auch sieht. also ob sich alles mit-skaliert (auch in der größe), oder ob nur die positionen angepaßt werden, und es aber zum beispiel bei höherer auflösung kleiner aussieht. letzteres ist eigentlich nicht so schwer. und beim skalieren baust du dir einfach eine prozedur, die dir die positionen und größen mit realtiven werten berechnet, und du zeichnest deine buttons dann an diese vorberechneten positionen. ob du dabei deine bilder direkt skalieren willst, oder ob du fertige grafiken unterschiedlicher größe nimmst, hängt auch davon ab, ob du 2 verschieden auflösungen unterstützen willst, oder 8 verschiedene (.. bzw wie viele bilder du hast).

[ZeHa]

@ Kaeru: Es ging eigentlich (von meiner Seite aus) nur drum, daß man die Koordinaten und Größen berechnen*) muß, wenn man mit unterschiedlichen Auflösungen arbeiten will und immer alles möglichst "gleich" aussehen soll (was ja der Original-Poster gern haben wollte), und daß es da egal ist, ob das nun Gadgets auf einem Window sind oder Bilder auf einem DirectX-2D-Screen - an den Berechnungen kommt man halt nicht vorbei. Wenn man jedoch in 3D arbeitet, sieht das ganze anders aus, hier weiß der Rasterer, was zu tun ist und stellt alle Objekte immer in der korrekten Größe dar.

Was DarkDragon allerdings meinte, daß man sich das Berechnen beim 2D sparen kann, weiß ich bis jetzt auch noch nicht... aber er könnte es ja einfach mal erklären

*) und das Berechnen habe ich halt Umrechnen genannt, weil ich davor bereits erklärt hab, wie ich vorgehe, wenn ich sowas machen muß, und da rechne ich eben meine Soll-Werte auflösungsangepaßt in die endgültigen Ist-Werte um.

[Kaeru Gaman]

yo Zeha, so isses glei verständlicher..

das ist grundsätzlich richtig, obwohl, wie ich bereits sagte,
bei den meisten games auf ein skalieren der bedienelemente verzichtet wird.
also dort muss man dann garnichts umrechnen,
sondern hat nur relativkoordinaten zu den rändern/ecken des screens.

in punkto 3D muss ich dir widersprechen.
natürlich hast du recht, dass die darstellung von 3D-objekten
vom renderer auf die jeweilige auflösung umgerechnet wird,
allerdings sind bedienelemente/anzeigeelemente meistens 2D-objekte,
die nachträglich oben drauf aufgebracht werden(*), also ist die
umrechnung/koordinaten-bearbeitung dieselbe wie bei nem 2D-game.

(*) in PB: nach dem RenderWorld die DisplayTransparentSprite-befehle für die 2D-elemente.

[ZeHa]

Da hast Du natürlich auch wieder Recht

Naja zum Thema "da wird gar nix vergrößert", das ist auch korrekt, aber hierbei muß man sich dann wenigstens die Position errechnen - es sei denn, Du plazierst alles in der Mitte und läßt bei steigender Auflösung den Rand drumherum "wachsen". Wenn Du aber wenigstens eine einigermaßen gleichmäßige Aufteilung haben willst, dann mußt Du sozusagen das Raster vergrößern und z.B. die Bedienelemente in ihren einzelnen Rasterbereichen zentrieren oder sowas.

[DarkDragon]

Was DarkDragon allerdings meinte, daß man sich das Berechnen beim 2D sparen kann, weiß ich bis jetzt auch noch nicht... aber er könnte es ja einfach mal erklären

Generell im 2D kann man es sich spaaren, da man mit einer Projektionsmatrix so ziemlich alles ganz einfach manipulieren kann.

Hier z.B.

Code: Alles auswählen

void cRenderingContext::set2DMode(bool state, int swidth, int sheight) {
    if(state) {
        // Falls 2D: TiefenBuffer ausschalten
        glDisable(GL_DEPTH_TEST);
        glDisable(GL_LIGHTING);

        // Orthogonalsichtweise einschalten:
        glMatrixMode(GL_PROJECTION);
        glLoadIdentity();
        glOrtho(0.0, (double) swidth, (double) (height - sheight), (double) height, -1.0, 1.0);
        glMatrixMode(GL_MODELVIEW);
    } else {
        // Falls nicht 2D: TiefenBuffer anschalten
        glEnable(GL_DEPTH_TEST);
        glEnable(GL_LIGHTING);

        // Perspektivisch verzerrte Sicht:
        setCamera(camX * -1.0, camY * -1.0, camZ * -1.0);
    }
}

Diese Zeile ist wichtig:

Code: Alles auswählen

glOrtho(0.0, (double) swidth, (double) (height - sheight), (double) height, -1.0, 1.0);

swidth, sheight = 2D Bildschirmauflösung.
width, height = Normale Bildschirmauflösung.

Sicher gibt es einen weg das selbe zumindest in ähnlicher Weise mit dem PureBasic 2D Screen anzustellen. Z.B. indem man alles zuerst auf ein Sprite malt und dann großskaliert/kleinskaliert. Das ist aber schon overkilled meiner Meinung nach.

Mein swidth, sheight kommt etwa _PB_Screen_Width und _PB_Screen_Height nahe und width, height kommt etwa _PB_Screen_RealWidth und _PB_Screen_RealHeight hier nahe:

...
-----------------------------------------------------------------------
Sprite
------

_PB_Screen_Width ; width of the current buffer selected with UseBuffer()
_PB_Screen_Height ; height of the current buffer selected with UseBuffer()
_PB_Screen_Depth ; depth (in bpp) of the current buffer selected with UseBuffer()

_PB_Screen_RealWidth ; width of the back buffer
_PB_Screen_RealHeight ; height of the back buffer
_PB_Screen_Window ; ScreenID() (HWND)
_PB_Screen_Windowed
...

http://www.purebasic.fr/english/viewtop ... 503#129503

Bei mir wird halt nichts zuerst auf einen dritten Buffer gerendert sondern direkt mit der resultierenden Matrix multipliziert.

[EDIT]
Hier mal die Befehlsbeschreibung zu glOrtho:
http://wiki.delphigl.com/index.php/GlOrtho

Dürfte nun für alle klar sein.

[EDIT2]
Das ganze geht auch mit DirectX sicherlich.