Suchergebnisse
Suchergebnisse 1-20 von insgesamt 47.
@ unsigned long Der Vertexbuffer ist eine "Highmap", es gibt ein Feld mit den Abweichungswerten, über eine ROAM Algorithmus berechne ich wenns not tut einen neuen Indexbuffer und verwende den statisch. Ich sagte ja "eben genannten" das schließt Geomipmapping nicht unweigerlich mit ein, was denke ich jetzt aber mit den statischen Indexbuffern auch gehen würde. Zitat Ich möchte mal wissen wie das geht. Das wäre so als ob man Turbolader mit Kompressor verbindet Geklärt? So geht das.
Die OpenGL Funktion glTexImage2D hat auch zwei Parameter dafür, muss man dann eben selbst die nächst höhere 2er Potenz berechnen. Dann einsetzen, fertig. Irgentwas (DX/OpenGL) wirst du schon verwenden müssen, das komplett selbst zu schreiben halte ich für abwegig.
Ich glaube die große Frage war nicht wie LOD, sondern wann. @drakon in beiden Fällen lässt sich nur das nötige laden. In der Regel gibt es inzwischen sehr viel Speicher und Ladezeiten sind immer nervend. Also Variante 1. Allerdings wäre es Interessant, ob es Highpolys mit 40000 Dreiecken sind, dann ist der Speicherverbrauch enorm. Wenn es nur um eins zwei MB geht ist es besser die zu Speichern, andernfalls sie doch lieber zu berechnen. Dabei muss dann aber auch der Arbeitsspeicher groß genug sei...
Wenn du sehr auf Speichersparen bei GeoMipmapping setzt, kannst du auch einen Vertexbuffer nehmen und mehrere Indexbuffer, die verschieden viele Vertizen verwenden. Die anderen nicht genutzten werden dann zwar immer noch als Daten überall hin mitgenommen, aber nicht mehr Transformiert und gerendert, was dann eben doch schneller geht als volles Detail. Ich verwende ein Hybrid aus ROAM und eben genannten.
Ja das meine ich, aber so etwas habe ich noch nie probiert. D3DXCreateTextureFromFileEx hat zwei Parameter (Width, Height), die man mit Default füllt. Im Hilfetext steht, dass wenn das Device keine ungeraden Texturen unterstützt wird automatisch auf nächste 2er Potenz gestreckt. Ich weiß jetzt aber nicht, ob ein leerer Teil angefügt wird, oder wirklich gestreckt, außerdem müsste man an dieser Stelle auch selbst Werte angeben können und so die Texturgröße beeinflussen (höhere Performenc-Kosten). ...
Ok in Zukunft passe ich da mehr auf. Aber man hat die Möglichkeit, dies besser auszunutzen (da OpenGL Systemnäher ist). Aber ich mach meine Freunde auch immer so runter, wenn sie mit einem Kommentar aus so einer Zeitschrift auftauchen. Ich gebe dir somit vollkommen recht, dieses Kommentar war nicht gut. Zu 3. Es ist gebräuchlich das Laden und die Positionsverwaltung zu trennen - da eine Textur mehrfach an unterschiedlichen Stellen auftreten können - weitere Sprites hinzukommen ... (und man eben ...
Sorry, wo ist mein Fehler? Ich frage jetzt wirklich aus interresse. Jedes OpenGL Programm, welches ich gesehen habe war schneller als alle die ich in DX gesehen habe (und damit meine ich die, die das Haargenau gleiche Ergebnis haben!!)
Wer sagt denn, dass ID3DXSprite so schnell sein soll? Na gut DX10 ist jetzt schon ganz gut, aber OpenGL ist in jedem Falle schneller als DX9. Zitat Und wie sollte ich dann überhaupt eine Art Textur-/Spritemanager realisieren? Ok, was genau?? Textur und Sprites sollte man gesondert behandel, ein Texturmanager lädt und optimiert beim Rendern vielleicht, das sie nicht so oft gesetzt werden. Spritemanager sind da ja eher für Transformationen und massig kleiner 2D Flächen gedacht. 1. Hintergründe Ein...
Wie der Titel schon sagt hat der Befehl "SetPixelShader" bei mir keine Wirkung. Der Shader ist korrekt assembliert und das Set.. liefert auch keinen Fehler. Der Shader wird jedoch einfach nicht durchgeführt (der Vertexshader an gleicher Stelle wird es). Ich habe den Shader auf: ps_1_4 mov r0, v0 reduziert, und eigentlich müsste das jetzt ja grau-weiß sein. Auf dem Bildschirm erscheint die Sache aber dennoch mit Textur! // egal wie der Shader aussieht, es kommt immer das selbe Ergebnis
Noch ein Nachtrag zu Geschwindigkeiten. Einzelne Operatoren auszutauschen bringt nur bedingt etwas und eigentlich auch nur, wenn man davon ausgehen muss, dass die betreffende Stelle sehr oft durchgeführt wird. Beispiel: eine Multiplikation ist meist schneller als eine Division (bei float). Daher ist for(i->10000) y=x/1.6; langsamer als f = 1/1.6; for(i->10000) y=x*f; (Multiplikation mit dem Kehrwert) Abfragen brauchen in etwa gleich viel Leistung wie die Arithmetik, oder weniger. Logische Operat...
Nein, das hat leider keine Wirkung. Ich hab das Gefühl, etwas mit den Texturstages selbst stimmt nicht.
Wenn du den Quelltext von oben ein wenig anders strukturierst und kapselst wird er auch schon wesentlich optimaler. 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 bool Field::CheckDir(int x, int y, int xrichtung, int yrichtung) { // Feldgrenzen absichern if(x+3*xrichtung < 0 || x+3*xrichtung > width) return false; if(y+3*yrichtung < 0 || y+3*yrichtung > height) return false; // Die Viererreihe testen if (slot[x][y] != 0 && slot[x][y] == slot[x+xrichtung][y+yrichtung] &...
Ich muss diesen Thread leider noch einmal aufwärmen. Wahrscheinlich ist der Fehler genau so banal wie der andere. Von den Texturen die ich setze wird immer nur die 1. verwendet, auch wenn ich für den Pixelshader texld r1, t0 mov r0, r1 einsetze. Nach meiner Überprüfung setze ich für die Stages aber wirklich unterschiedliche Texturen ein.
Genial, so ein schön einfach zu behebendes Problem, jetzt läufts. Aber auf so etwas kommt man nicht, wenn DX das sonst automatisch erledigt (in HLSL). Ich Danke
Was passieren soll: die Shader sollen zwischen mehreren Texturen (4) über eine Alphamap in den Vertizen interpolieren. (Dies ist Teil meiner Terrainengine) Ohne diese Shader wird das Terrain vollständig ordnungsgemäß gerendert (, mal abgesehen davon, dass es natürlich nur eine Textur hat). Die Vertexdaten und Matrizen sind also richtig. Quellcode 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 ps_1_4 texld r0, t0 texld r1, t0 texld r2, t0 texld r3, t0 mul r0, r0, v1.r ...
Sieht ganz nett aus, das dumme ist nur, dass ich DX verwende. SetSamplerState( 0, D3DSAMP_ADDRESSW, D3DTADDRESS_CLAMP); Ist aber glaube ich das Equivalent dazu und funktioniert leider nicht. Die Adresse läuft ja auch nicht über, es wird eben einfach interpoliert, wie das ja auch zwischen den anderen Schichten sein soll.
Ich verwende ganz einfache Volumentexturen, ohne Shader... Mein Problem: bei den Tiefenkoordinaten 0.0 und 1.0 wird so interpoliert, dass die erste und die letzte Schicht zu sehen sind (auf einmal). Das soll aber nicht so sein, ich möchte, dass dann nur die erste bzw letzte zu sehen sind. Geht das überhaupt auszustellen? Ich vermute es ist in der Hardware festgelegt. Ich hab schon allerlei Renderstates ausprobiert (Adressmodus,..)
Komerzielle Spiele können gar keine eigenen Formate haben. Die Formate werden von der Hardware gestützt, ein eigenes Format würde auch eigene Grafikkarten vorraussetzen. (Schon mal eine Grafikkarte von EA-Games oder JoWood gesehen?) Die werden irgend ein RGB Format verwenden, und in den meisten Spielen kann man 16 / 32 bit - Farbe einstellen, je nach dem wird dann ein 8bit-ARGB oder R5G6B5 eingesetzt (intern).
In VS2005 kann man als Debbugoption Disassemble einstellen, die man dann einzeln durchgehen kann. Da Interrupt 3 ein Breakpoint ist, ist es nicht schwer diesen zu finden. Mit der Adresse, die daran steht, kann man mit einem Hexeditor direkt in der exe/dll/... herumschreiben. Das heißt ich habe das Byte "CC" (int 3) gegen "90" (nop=no operation) ausgetauscht, damit die Adressen in der dll nicht verutschen ist es wichtig die Lücke zu füllen. Aber aus irgendeinem Grund ist Windows an diesen Interru...
Den Leiter habe ich nun übernommen. Es werden aber dringend weitere Programmierer gesucht. Meldet euch, wenn ihr Lust auf dieses Projekt habt!
25.04.2024, 15:38
Zum Seitenanfang
