multitex extension (ogl)
-
versuchs mal mit Treiber neu installieren
-
glGetString(..) funzt nur nach dem erstellen des rendercontext.
-
Wieder mal der Beweis, wieviel besser DX doch ist. Steig um!
Bye, TGGC (Der Held ist zurück)
-
TGGC schrieb:
Wieder mal der Beweis, wieviel besser DX doch ist. Steig um!
du hast recht.
-
Ich sehe den Beweis nicht, hilf mir mal auf die Sprünge. Bin halt kein Held wie du TGGC.
cya
liquid
-
LiquidAcid schrieb:
Ich sehe den Beweis nicht, hilf mir mal auf die Sprünge. Bin halt kein Held wie du TGGC.
mensch ist doch ein eindeutig wo der beweis ist
-
hast du das problem noch?
wenn ja, funktionieren andere programme die multitexturing verwenden?
-
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
