Suchergebnisse
Suchergebnisse 1-20 von insgesamt 23.
Funktioniert bestens, vielen Dank!
Hey, cool! Probier ich gleich mal aus, also wenn das klappt ist es echt die beste Lösung, da kann man ja sogar später noch über D3DTSS_COLORARG2 die Farbe mit Texturen mischen...
Hallo, kennt ihr eine Möglichkeit mit DirectX 9 Vertices farbig darzustellen ohne dabei Lighting zu verwenden oder die Farbe direkt in den VertexBuffer (D3DFVF_DIFFUSE) zu schreiben? Da ich die Farbe sehr oft ändern muss, würde es sich unnötig negativ auf die Performance auswirken in jedem Frame den Buffer neu zu beschreiben, da ich ja nur die Farbe ändern will, ebenso benötige ich keine Beleuchtung (die Vertices besitzen eh keine Normals) und möchte daher auch Lighting ausgeschaltet lassen da n...
Ich hab das Problem gelöst! Ich schreib die Funktion um und präsentier euch dann die Lösung...
Zitat von »dot« Ich denk am besten ist es, wenn du deine D3D Experimente mal ein paar Stunden ruhen lässt und dich ganz entspannt und unabhängig davon mit std::vector beschäftigst. ...hmmm... ok...denkst du denn, dass sich das Problem mit der vector-class lösen lässt? Zitat von »dot« Wenn dir jetzt jemand eine fertige Lösung präsentiert, würde dir das nicht wirklich helfen. Das sind einfach extrem wesentliche C++ Grundlagen, die du unbedingt verstanden haben solltest... Also ich dachte eher das...
sooo... jetzt wo Ferien sind, hab ich auch endlich wieder Zeit, mich mit DirectX zu befassen. An dem Problem mit den vielen Vertices komm ich nicht dran vorbei. Wenn ich euch jetzt sage "hier ist meine Funktion, die funktioniert nicht, was mach ich falsch?" können wir noch seeehr lange drüber diskutieren. Ob ein Objekt gezeichnet wird oder nicht hängt nicht alleine von der Objekt-Laden-Funktion ab, sondern auch noch von vielen anderen Faktoren. (ist das d3d-device richtig initialisiert, lösche i...
Hilft leider nicht viel... Warum schreibst du mit std::copy direkt in den VertexBuffer? Die Methode VertexBuffer->Unlock() schreibt doch schon in den VertexBuffer...oder? Mein Compiler gibt auf jeden Fall einige Fehler bei dem Code aus... Du benutzt wohl ne andere Version von DirectX? Trotztdem danke... Ich bin mir ziemlich sicher dass David das Problem leicht lösen könnte... Das ist ja vielleicht schon etwas in Vergessenheit geraten, aber eigentlich brauch ich die vector class nicht. Ich möchte...
hmmm... ok... nur mag mein Compiler den im Beispiel verwendeten Cast nicht. error C2664: 'IDirect3DVertexBuffer9::Lock': Konvertierung des Parameters 3 von 'BYTE **' in 'void **' nicht möglich Ohne Cast wird mal wieder nichts gezeichnet... Also bei mir sieht das jetzt so aus: C-/C++-Quelltext 1 2 3 4 5 VOID* pVertices; VertexBuffer->Lock(0, sizeof(Vertices_sortiert_VECTOR), (VOID**)&pVertices, 0 ); memcpy(pVertices, &Vertices_sortiert_VECTOR, sizeof(Vertices_sortiert_VECTOR)); VertexBuffer->Unlo...
Zitat von »TGGC« Man kann dem Lock daher nicht einfach irgendeine Speicherstelle geben, die zu einem std::vector gehoert. Der Lock schreibt dann irgendwo irgendwas in den std::vector, wenn der Vector sich z.b. mit der 73824 die Anzahl seiner Elemente abgelegt hat, so ist diese Information dann verloren. Damit kommt dieser im Normalfall nicht zurecht (was man in einen Vektor schreibt soll ja immer ueber dessen Funktionen gehen) und das endet im besten Fall in einem Absturz oder schlimmer in irge...
Zitat von »dot« Schau dir bitte mal an, was der dritte Parameter von Lock überhaupt macht... hab ich doch schon: Zitat von »lfp« In der msdn heißt es: VOID* pointer to a memory buffer containing the returned vertex data
Da euch meine .obj-Laden-Funktion scheinbar sehr verwirrt und es an einem gemeinsamen Code fehlt, über den wir diskutieren hab ich mal ne neue, übersichtlichere und vorallem kürzere Funktion geschrieben: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 void letstestsomevectorclass(LPDIRECT3DDEVICE9 D3DDevice){ vector <VERTEX> testvector; VERTEX testvertex; LPDIRECT3DVERTEXBUFFER9 testVertexBuffer; #define MyFVF (D3DFVF_XYZ | D3DFVF_DIF...
Zitat von »H5::« Zugriff auf das Interne Array des std::vector erhältst du über dessen data( ) ( s.o.) Methode. Das ist dann ein Pointer auf den Anfang des Arrays vom Typ des Inhalts (musst du dann eventuell noch casten). hmmm... das sieht jetzt so aus: C-/C++-Quelltext 1 VertexBuffer->Lock(0,0,(void**)(Vertices_sortiert_VECTOR.data()), D3DLOCK_NOSYSLOCK); Führt zu ner Zugriffsverletzung...
Zitat von »dot« &Vertices_sortiert_VECTOR ist ein Pointer auf den vector selbst und nicht dessen Inhalt... aber wenn ich stattdessen den ursprünglichen Array ( VERTEX Vertices_sortiert [10000] ) verwende, also VertexBuffer->Lock(0,0,(void**)(&Vertices_sortiert), D3DLOCK_NOSYSLOCK);, dann übergebe ich doch auch nur einen Pointer und es funktioniert Oder versteh ich das falsch? In der msdn heißt es: VOID* pointer to a memory buffer containing the returned vertex data Also müssen wir doch eh nur e...
so... also ich hab jetzt einige solcher tests gemacht: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 vector<VERTEX> testvector; VERTEX testvertex; testvertex.x = 1; testvertex.y = 2; testvertex.z = 3; testvertex.Color = RGB(100, 100, 100); testvector.push_back(testvertex); testvertex.x = testvector[0].x; naja... es macht leider keine Fehler Nach einigem nachdenken hab ich dann einfach mal den Vertex-Buffer weggelassen, also das Sperren und Entsperren. Und voila: Es gab keine Fehler mehr! Also: Quellcode...
Ich glaub ich hab jetzt eine Idee, wo der Fehler liegen könnte. Es scheint am Laden der Vertices zu liegen. Die Funktion lädt weniger als in der *.obj steht. Aber wenn das stimmt: warum macht das dann ohne vector-class keine Fehler? Ich schau mir das morgen nochmal genauer an.
Zitat von »Schrompf« ich hoffe mal dringend für Dich, dass Du im Debug-Build entwickelst und nicht mit dem Release-Build. naja... da der Fehler, wie du ja schon erwähnt hast, nur im Release so auftritt, und im Debug-Mode nur, wenn ich versuche, den Prozess zu beenden, habe ich den Release-Modus genommen, weil die Fehlermeldung da eindeutiger war und sofort aufgetaucht ist (im Debug gabs "nur" ne Zugriffsverletzung). Zitat von »Schrompf« ein std::vector hat ab Start eine Größe von 0. Das heißt, ...
So, hier die neue Version mit Benutzen der vector-class: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 13...
Zitat Punkt. Naja. Hast schon Recht... vielleicht wärs wirklich besser, wenn man von Anfang an davon ausgeht, nichts zu bekommen, was aber natürlich nicht ausschließt, dass man etwas von möglichen Einnahmen abbekommt. Oder einfacher gesagt: Das Ziel einer Zusammenarbeit sollte nicht Geld sein.
Oh, ihr scheint ja tatsächlich bereits die Lösung zu kennen. Ich schreib jetzt die Version um, so dass die vector-class verwendet wird und schick euch dann die Fehlermeldungen, die ich dabei ja schonmal bekommen hab. Ich geh dann auch nochmal auf die Fargen ein, da meine Funktion sicher unnötig kompliziert aussieht. Bis gleich...
04.06.2024, 11:41
Zum Seitenanfang
