multitex extension (ogl)



  • hast du das problem noch?
    wenn ja, funktionieren andere programme die multitexturing verwenden?



  • @treiber hab die allerneusten von nvidia drauf
    sind die extension aufrufe unter linux eigentlich dieselben?
    @rendercontext werd mal danach schaun... aber vorher gings ja d.h. ich hab source und bin auf ner backup cd und weiss, dass ichs früher von cd starten konnte
    jetzt gehts nicht mehr

    @basc ja ich hab das problrm noch und die andern benutzen kein multitex
    werd mal buch samples rauskramen und schaun obs da geht (glaubs aber ned)

    @TGGC ne danke. unsre teamengine unterstützt auch d3d9. ich hab den ogl part geschrieben und das frontend is in standard c++
    d3d is mir persönlich viel zu umständlich



  • sind die extension aufrufe unter linux eigentlich dieselben?

    Extensions laden unter Linux... *hihi*.
    Hab ich noch nie gebraucht.
    Wenn Microsoft mal neue Libs gegen die man linken könnte veröffentlichen würde, gäbe es das Problem unter Windows auch net.

    @TGGC: Was hast du in diesem Thread überhaupt zu melden? Wenn deine Antwort wenigsten hilfreich/vernünftig/begründet wäre. Aber naja, Helden brauch sowas anscheinend nicht..



  • @Sovok: Aber solch ein Multitexturing Problem hättest du mit DX nie. Vielleicht solltest du es nochmal überdenken mit dem "umständlich". Letzendlich gleicht sich das alles aus, da nur ein geringer Teil des Codes Api abhängig ist. Das zeigt ja letzendlich auch Eure Engine.

    @Kane: Gut das du mich erinnerst, sinnlose Posts müssen ja immer in einer Anti-MicroSoft Form geschriebenen werden.

    Bye, TGGC (Der Held ist zurück)



  • Hätte man unter Windows von Anfang an eine GL-1.5 Basis (wie es unter Linux und allen anderen Betriebssystemen der Fall ist), dann würde dieses sogenannte Problem gar nicht erst auftreten.

    Man sieht also: Problem geht von Windows aus, Windows = schlecht, Windows = Microsoft -> Folge: Microsoft = schlecht

    Bestechende Logik findet ihr nicht 😉

    cya
    liquid



  • LiquidAcid schrieb:

    Man sieht also: Problem geht von Windows aus, Windows = schlecht, Windows = Microsoft -> Folge: Microsoft = schlecht

    Du hast das Wort "Microsoft" benutzt -> Folge: Du = schlecht 🤡 👍



  • In diesem Falle keine bestechende Logik. Sry Nukem 😉

    cya
    liquid



  • LiquidAcid schrieb:

    In diesem Falle keine bestechende Logik.

    Tja, leider kein Einzelfall.

    Bye, TGGC (Der Held ist zurück)



  • TGGC schrieb:

    Wieder mal der Beweis, wieviel besser DX doch ist. Steig um!

    TGGC schrieb:

    Tja, leider kein Einzelfall.

    Endlich kommt die Einsicht.

    cya
    liquid



  • @TGGC:
    Der OpenGL-Support von MS ist keine geflame, sondern eine Tatsache.
    Das ist dir doch aufgefallen oder?



  • *räusper* will euch ja nich stören aber ich hab da immernoch son problem mit multitexturing 😉

    @kane hast du mal n kurzes codebeispiel wie du multitexturing unter linux initialisierst und verwendest?
    würd gern mal wissen ob ich das in der engine einfach kapseln kann



  • Und Linux ist es doch gerade toll, dass man dort nichts initialisieren muss. Einfach nur aktuelle Header einbinden und Defines gesetzt haben, dann hat man automatisch die Funktionen verfügbar. Den Mist über glGetProcAdress muss man dort gar nicht gehen.

    cya
    liquid



  • und wie heisst die funktion?
    das win teil is
    typedef void (APIENTRY * PFNGLMULTITEXCOORD2FARBPROC) (GLenum target, GLfloat s, GLfloat t);

    unter linux isses also kein zeiger sondern ne funktion... die frage is halt ob art der verwendung und parameter dieselben sind



  • @LiquidAcid:
    Glückwunsch zum ersten Schritt deiner Besserung. 😎

    @Kane:
    Kein Problem mit Extensions bei DX ist keine geflame, sondern eine Tatsache.
    Das ist dir doch aufgefallen oder?

    Bye, TGGC (Der Held ist zurück)



  • Unter Linux binde ich nur den Header ein. Die Funktionen habe ich dadurch automatisch. Wer sie gerne manuell laden möchte "glXGetProcAddress".

    Falls Multitexturing nicht mehr im String ist, kannst du trotzdem versuchen die Procs zu laden.

    Ich persönlich checke den String überhaupt nicht, sondern probier nur ob mit wglGetProcDings was == 0 zurück gibt.



  • Sovok schrieb:

    und wie heisst die funktion?
    das win teil is
    typedef void (APIENTRY * PFNGLMULTITEXCOORD2FARBPROC) (GLenum target, GLfloat s, GLfloat t);

    unter linux isses also kein zeiger sondern ne funktion... die frage is halt ob art der verwendung und parameter dieselben sind

    GLAPI void APIENTRY glMultiTexCoord2fARB (GLenum, GLfloat, GLfloat);
    

    es heisst alles genauso wie unter windows und es ist auch alles gleich.
    ist auch schliesslich der sinn der plattformunabhängigkeit 😉
    schaue dir doch mal die "glext.h" genau an.



  • mist kane war schneller, kommt davon wenn man so langsam schreibt und fünf dinge auf einmal macht. 😃



  • ahso "extension" bezieht sich nur auf grafikkarten
    dachte das wäre ne art plattformabhängige abspaltung von ogl



  • Sovok schrieb:

    ahso "extension" bezieht sich nur auf grafikkarten
    dachte das wäre ne art plattformabhängige abspaltung von ogl

    extension beziehen sich zum gröstensteils auf grafikkarten und sind plattformunabhängig (ausnahmen gibts es allerdins sind zb: GL_WIN_swap_hint).
    was definitiv plattformabhänig ist die initialisierung der extensionen.


Anmelden zum Antworten