ZFX + Developia

Krishty hat geschrieben:Hast du das hier gelesen? Directly Mapping Texels to Pixels (Direct3D 9)

Krishty hat geschrieben:Hmm … die dritte Lösung mit dem Runden klingt interessant. Vielleicht findest du dafür irgendeine Garantie in D3D!

Krishty hat geschrieben:Mir ist der Point Filter nur als sehr instabil bekannt, sobald irgendwie transformiert wird – vielleicht durch geringe Präzision auf der GPU, aber das rate ich gerade nur.

Krishty hat geschrieben:Du solltest das auch unbedingt mal auf einer Grafikkarte eines Drittherstellers testen: einer von hier hatte bei seinem Zelda-Klon das Problem, dass die Karten eines Herstellers (S3 oder so?) mit Point Filter grundsätzlich alle Texel verschoben haben und dann alles wie Grütze aussah …

Schrompf hat geschrieben:Ich sollte da echt mal ein Paper zu machen.

Schrompf hat geschrieben:Das -0.5 nach innen bringt Dir nur was auf der höchsten MipMap-Stufe. Und versaut Dir nebenbei die Texel-Zu-Pixel-Zuordnung. Bei perfektem 1:1-Mapping und Point Sampling fällt das evtl. noch nicht auf, aber spätestens mit leichter Rotation/Skalierung oder linearer Interpolation werden Deine Sprites dann matschig. Sobald Deine Grafik ein bisschen kleiner als Orginalgröße auf dem Rendertarget scheint, reicht -0.5 Texel vom Rand nicht mehr aus.

Hatte das gleiche Problem, hab ich vor Ewigkeiten mal in Splatter implementiert:

Im VertexShader berechnest Du Dir die Ausdehnung auf dem Rendertarget relativ zur Größe der Quellgrafik auf dem Texturatlas. Da kommt dann z.B. raus: das Ding erscheint in der Breite 0.673f mal so groß wie das Orginal, in der Höhe sogar nur 0.375f mal so groß wie das Orginal. Du weißt also, dass der Filter schlimmstenfalls das zweite MipMap-Level rausholt. Denn: der kleinere der beiden Werte ist zwei Zweierpotenzen unter der Eins, also zweites MipMap-Level. Und diese Erkenntnis habe ich das genutzt, um meinem PixelShader ein zusätzliches Attribut namens Clamping-Grenze mitzugeben. Zweites MipMap-Level bedeutet, dass ich ab 0.5f * 2^(Zweites MipMap-Level) Texeln Nähe zum Grafikrand nicht mehr samplen darf, sonst zieht der Texturfilter Farbmüll von außerhalb der Grafik mit rein. Ich habe dem PixelShader also die ursprünglichen Texturkoordinaten (vom Rand der Grafik) als Texturkoordinaten mitgegeben und zusätzlich eine um diese Ausdehnung nach innen versetzte Texturgrenze als zusätzliches Attribut. Im PixelShader clampe ich dann die Texturkoords auf diese Texturgrenze und sample erst dann.

Das Ergebnis: pixelperfektes Mapping bei Sollgröße, korrektes Interpolieren bei Vergrößerung, absolut sauberes Bild ohne Fehlfarben bei Rotation und Verkleinerung. Zur Nachahmung empfohlen.

Goderion hat geschrieben: Wenn ich das richtig verstanden habe, interpolierst Du im Pixelshader selber?

Schrompf hat geschrieben:Im VertexShader berechnest Du Dir die Ausdehnung auf dem Rendertarget relativ zur Größe der Quellgrafik auf dem Texturatlas. Da kommt dann z.B. raus: das Ding erscheint in der
Breite 0.673f mal so groß wie das Orginal, in der Höhe sogar nur 0.375f mal so groß wie das Orginal.

Goderion hat geschrieben:Jedenfalls funktioniert es jetzt und ich kann in realtime die Shader anpassen. In jedem Frame wird einfach D3DXCompileShaderFromFile wieder aufgerufen, und kommen Fehler, wird kein Shader genutzt, bis wieder was funktionierendes in den Dateien steht. Zum Testen reicht es. Für den Release möchte ich die bereits compilierten Shader nutzen, damit ich kein D3DX nutzen muss.

Wie funktioniert das? Ich bräuchte doch in einem Aufruf vom Vertexshader alle Quellkoordinaten, die Größe der Quelltextur, und die Zielkoordinaten, damit ich die Skalierung im Vertexshader ermitteln kann, um diese dann an den Pixelshader weiterzureichen.

float3 instZielPos; // Zielposition aufm RenderTarget in Pixeln
float2 instGroesse; // Zielgröße aufm RenderTarget in Pixeln
float4 instGrafik;   // Quell-Grafikausschnitt - .xy links oben, .zw Größe in Pixeln
float4 instFarbe;    // Farbmodulation
float2 instParam;   // Parameter - .x Rotation in Radian, .y Griffpunkt 

Goderion hat geschrieben:Ich habe mich heute ein wenig mit Vertex -und Pixelshadern beschäftigt und sie auch gleich in die Engine implementiert. Heute mittag gleich direkt mal eine Stunde sinnlos verbraten, weil ich D3DXAssembleShaderFromFile statt D3DXCompileShaderFromFile benutzt habe. Informationen zu den beiden Funktionen sind mal wieder dürftig oder ich bin blind. Generell fand ich es recht schwer "gute" Tutorials zu dem Thema zu finden, aber ich glaube langsam, heute ist einfach nicht mein Tag.

Jedenfalls funktioniert es jetzt und ich kann in realtime die Shader anpassen. In jedem Frame wird einfach D3DXCompileShaderFromFile wieder aufgerufen, und kommen Fehler, wird kein Shader genutzt, bis wieder was funktionierendes in den Dateien steht. Zum Testen reicht es. Für den Release möchte ich die bereits compilierten Shader nutzen, damit ich kein D3DX nutzen muss.

Schrompf hat geschrieben:Du schreibst aktuell wahrscheinlich 2x3 Vertizes pro Sprite in einen VertexBuffer und renderst den dann. Das ist für Dein Spiel wahrscheinlich auch völlig ausreichend. Andere Szenarien wollen dann aber irgendwann mal rotieren, skalieren, verfärben, ein- und ausblenden und wasweißichnoch. Dann lohnt es sich, die finalen Vertizes erst auf der Grafikkarte auszurechnen, und nur ein Platzhalter-Set an Vertizes hochzuladen, in denen alle Parameter des Sprites drinstehen. Dann hast Du in den Shadern sowieso alle Daten da, und kannst daraus auch die Skalierung im VertexShader ermitteln.

const UInt32 D3DFVF_CUSTOM_2D = Direct3D9::D3DFVF_XYZRHW | Direct3D9::D3DFVF_DIFFUSE | Direct3D9::D3DFVF_TEX1;

struct StructCustomVertex2D
{
	Float32 x; // Bildschirm-X
	Float32 y; // Bildschirm-Y
	Float32 z; // immer 0
	Float32 rhw; // immer 1
	UInt32 color; // Farbe und Transparenz
	Float32 u; // Texture-X (0 bis 1)
	Float32 v; // Texture-Y (0 bis 1)
};

Schrompf hat geschrieben:Ich löse das aktuell mittels Instancing. Der primäre VertexBuffer und IndexBuffer enthält genau zwei Dreiecke mit (0,0), (1,0), (0,1) und (1,1). Kannst Du auch aus der VertexID im VertexShader live berechnen. Pro Instanz gebe ich dann einen Satz Parameter mit:

Schrompf hat geschrieben:Das ist natürlich nur ein Vorschlag. Du schleifst da durch, was auch immer Du an Parametern brauchst, und verwurstest die erst im VertexShader zu tatsächlichen Bildschirmpositionen. Und zu beliebigen Parametern, die Du Dir zum PixelShader durchreichst. Lass Dich nicht von den Oldschool-Bezeichnern wie NORMAL oder COLOR0 oder sowas beeindrucken. Das sind nur Namen für Menschen. Du kannst einfach alles als TEXTURE0 bis TEXTURE7 bezeichnen. Nur ein einziges POSITION0 muss Dein VertexShader haben, weil das einer der letzten noch nicht frei programmierbaren Teile der GPU braucht, nämlich der Rasterizer. Alles andere sind beliebig nutzbare Vektoren, und Du solltest sie so auch nutzen.

const UInt32 D3DFVF_CUSTOM_2D = Direct3D9::D3DFVF_XYZ | Direct3D9::D3DFVF_DIFFUSE | Direct3D9::D3DFVF_TEX1 | Direct3D9::D3DFVF_TEX2 | Direct3D9::D3DFVF_TEX3;

struct StructCustomVertex2D
{
	Float32 x;
	Float32 y;
	Float32 z;
	UInt32 color; 
	Float32 u;
	Float32 v;
	Float32 u2;
	Float32 v2;
	Float32 u3;
	Float32 v3;
};

Schrompf hat geschrieben:Wenn Du Instancing nicht haben willst, kannst Du auch die Sprite-Daten auch in jeden Vertex kopieren. Du hast dann halt pro Sprite vier dicke Vertizes (0, 0, <Instanzdaten>), (1, 0, <Instanzdaten), ... - aber egal, funktioniert auch, verbraucht nur minimal mehr Speicher. Später kannst Du dann die VertexPosition aus der VertexID berechnen, die Dreiecke erst im GeometryShader erzeugen oder wasweißich. Da kann man kreativ werden. Ist aber alles erst später wichtig, zuerst muss man mal artefakt-frei rotieren und skalieren können.

Krishty hat geschrieben:Off-Topic: Kompilierte Shader sind auch schneller zu entwickeln. Speicher sie mit der Endung .hlsl und füge sie deinem Visual C++-Projekt hinzu. Dann werden sie beim Kompilieren des Projekts von Visual Studio mitkompiliert und liegen als fertige .dxbc-Dateien vor. Falls es dir zu aufwändig ist, die Dateien zu laden, kannst du in den Projekteinstellungen Header mit dem fertigen Bytecode als Array erzeugen lassen, die du im Projekt #includeieren und direkt an CreateVertexShader() & Co. übergeben kannst. Mit D3DX musst du überhaupt nichts zu tun haben (deshalb ist auch die Dokumentation so schwach).

Zudomon hat geschrieben:Und zwar ist bei den Texturkoordinaten noch zu beachten, dass du nicht einfach mit der Texturbreite multiplizierst. Wenn du z.B. eine 1024 Textur hast, dann sind die adressierbaren Pixel von 0 - 1023. Benutzt du einen Texturatlas und unterteilst deine 1024 Textur in 8 Blöcke pro Zeile von je 128 Pixel, dann muss die Texturkoordinate mit 127 multipliziert werden. Also das ganze muss natürlich auch wieder zurück skaliert werden, also so:
Texturkoordinate = Texturkoordinate * (Grafikbreite - 1) / Grafikbreite

Texture.SizeX = 256;
Texture.SizeY = 128;
Sprite.X1 = 123;
Sprite.Y1 = 33;
Sprite.X2 = 146;
Sprite.Y2 = 74;
TexCoord.X1 = 123 / 256 = 0.4805;
TexCoord.Y1 = 33 / 128 = 0.2578;
TexCoord.X2 = 146 / 256 = 0.5703;
TexCoord.Y2 = 74 / 128 = 0.5781;

Zudomon hat geschrieben:Soweit ich weiß fällt übrigens diese 0.5 Texelverschiebung bei Pointsampling weg. Also da muss man auch genau drauf achten, ob man Point Filtert oder Linear. Bei mir verwende ich Pointsampling, um auch nur die kleinsten Rundungsfehler nicht als lineare Interpolation der Daten zu verschandeln.

Zudomon hat geschrieben:MipMaps sind dann nochmal eine Stufe härter. Denn dieses multiplizieren mit der ((Grafikbreite - 1) / Grafikbreite) der Texturkoordinaten pflanzt sich natürlich auf den Mipmapstufen fort. Da muss man dann schauen, ob es zu sichtbaren Fehlern kommt.

struct VS_INPUT
{
	float4 Position : POSITION;
	float4 Color : COLOR;
	float4 TexCoord0 : TEXCOORD0;
};

struct VS_OUTPUT
{
	float4 Position : POSITION;
	float4 Color : COLOR;
	float4 TexCoord0 : TEXCOORD0;
};

VS_OUTPUT VertexShader(VS_INPUT Parameter)
{
	VS_OUTPUT Result;

	Result.Color = Parameter.Color;

	Result.Position[0] = Parameter.Position[0] / 640;
	Result.Position[1] = (720 - Parameter.Position[1]) / 360;
	Result.Position[2] = 0;
	Result.Position[3] = 1;

	Result.Position[0] -= 1;
	Result.Position[1] -= 1;

	Result.TexCoord0 = Parameter.TexCoord0;

	return Result;
}

struct PS_INPUT
{
	float4 TexCoord0 : TEXCOORD0;
	float4 Color : COLOR;

};

struct PS_OUTPUT
{
	float4 Color : COLOR;
};


sampler2D samp;


PS_OUTPUT PixelShader(PS_INPUT Parameter)
{
	PS_OUTPUT Result;

	Result.Color = tex2D(samp, Parameter.TexCoord0) * Parameter.Color;

	return Result;
}

float4 rti : register(c0);

struct VS_INPUT
{
	float4 Position : POSITION;
	float4 Color : COLOR;
	float2 TexCoord0 : TEXCOORD0;
};

struct VS_OUTPUT
{
	float4 Position : POSITION;
	float4 Color : COLOR;
	float2 TexCoord0 : TEXCOORD0;
};

VS_OUTPUT VertexShader(VS_INPUT Parameter)
{
	VS_OUTPUT Result;

	Result.Color = Parameter.Color;

	Result.Position[0] = Parameter.Position[0] / rti[2];
	Result.Position[1] = (rti[1] - Parameter.Position[1]) / rti[3];
	Result.Position[2] = 0;
	Result.Position[3] = 1;

	Result.Position[0] -= 1;
	Result.Position[1] -= 1;

	Result.TexCoord0 = Parameter.TexCoord0;

	return Result;
}

Schrompf hat geschrieben:Im VertexShader berechnest Du Dir die Ausdehnung auf dem Rendertarget relativ zur Größe der Quellgrafik auf dem Texturatlas. Da kommt dann z.B. raus: das Ding erscheint in der Breite 0.673f mal so groß wie das Orginal, in der Höhe sogar nur 0.375f mal so groß wie das Orginal. Du weißt also, dass der Filter schlimmstenfalls das zweite MipMap-Level rausholt. Denn: der kleinere der beiden Werte ist zwei Zweierpotenzen unter der Eins, also zweites MipMap-Level. Und diese Erkenntnis habe ich das genutzt, um meinem PixelShader ein zusätzliches Attribut namens Clamping-Grenze mitzugeben. Zweites MipMap-Level bedeutet, dass ich ab 0.5f * 2^(Zweites MipMap-Level) Texeln Nähe zum Grafikrand nicht mehr samplen darf, sonst zieht der Texturfilter Farbmüll von außerhalb der Grafik mit rein. Ich habe dem PixelShader also die ursprünglichen Texturkoordinaten (vom Rand der Grafik) als Texturkoordinaten mitgegeben und zusätzlich eine um diese Ausdehnung nach innen versetzte Texturgrenze als zusätzliches Attribut. Im PixelShader clampe ich dann die Texturkoords auf diese Texturgrenze und sample erst dann.

Das Ergebnis: pixelperfektes Mapping bei Sollgröße, korrektes Interpolieren bei Vergrößerung, absolut sauberes Bild ohne Fehlfarben bei Rotation und Verkleinerung. Zur Nachahmung empfohlen.

Goderion hat geschrieben:5. Laut Microsoft ist TEXCOORD[n] ein float4 (https://msdn.microsoft.com/en-us/librar ... 5).aspx#VS).

Goderion hat geschrieben:1. Wenn ich im Test (ca. 60.000 Sprites, ca. 2.000 SetTexture) jedesmal beim SetTexture auch zusätzlich SetVertexShaderConstantF aufrufe, um z.B. die Texturgröße zu setzen, fallen die FPS von 330 auf 90. Wieso auch immer scheint der Aufruf von SetVertexShaderConstantF extrem langsam zu sein und ich werde alle nötigen Daten, die oft wechseln, wie z.B. hier bei jeder Textur, mit in die Vertexdaten packen müssen.

Goderion hat geschrieben:2. Ich habe zwei Rendermodi, die eigentlich das gleiche machen, aber unterschiedliche FPS liefern. […] Mit "Image" erreiche ich ca. 330 FPS, mit "ImagePro" ca. 390 FPS. Warum?!

Goderion hat geschrieben:3. Ich habe auch nochmal Vertex -und Indexbuffer getestet. Es scheint so zu sein, das Vertex -und Indexbuffer nur sinnvoll sind, wenn man sie inhaltlich nicht in jedem Frame ändern muss, was bei mir aber leider der Fall ist.

Goderion hat geschrieben:4. Mit dem VertexFormat "XYZ | DIFFUSE | TEX1" erreiche ich ca. 390 FPS. Mit dem VertexFormat "XYZ | DIFFUSE | TEX1 | TEX2 | TEX3 | TEX4" fallen die FPS auf 300. Die VertexDaten für TEX2, TEX3 und TEX4 werden nicht gesetzt oder im VertexShader verarbeitet. Schon etwas erschreckend, dass 24 Byte mehr pro Vertex so auf die Performance gehen.

Goderion hat geschrieben:5. Laut Microsoft ist TEXCOORD[n] ein float4 (https://msdn.microsoft.com/en-us/librar ... 5).aspx#VS). Nutze ich das so, kommt bei mir bei der Verwendung mehrerer TEXCOORD[n] im VertexShader Blödsinn raus. In vielen Beispielen zu VertexShadern, die ich durch Googlen gefunden habe, wird TEXCOORD[n] aber als float2 genutzt. Stelle ich in meinen TestVertexShadern das auch auf float2, funktioniert alles wie erwartet. In der Struktur vom Vertex werden pro TEXCOORD[n] ja auch nur zwei float übergeben. Was ist hier los? Fehler von Microsoft oder habe ich was überlesen?

MSDN, Texture Coordinate Formats (Direct3D 9) hat geschrieben:The D3DFVF_TEXTUREFORMAT1 through D3DFVF_TEXTUREFORMAT4 flags describe the number of elements in a texture coordinate in a set, but these flags aren't used by themselves. Rather, the D3DFVF_TEXCOORDSIZEN set of macros use these flags to create bit patterns that describe the number of elements used by a particular set of texture coordinates in the vertex format.

Krishty hat geschrieben:

Goderion hat geschrieben:2. Ich habe zwei Rendermodi, die eigentlich das gleiche machen, aber unterschiedliche FPS liefern. […] Mit "Image" erreiche ich ca. 330 FPS, mit "ImagePro" ca. 390 FPS. Warum?!

Irgendein Slow Path im Treiber; die wenigsten Spiele nutzen ausgiebig XYZRHW.

dot hat geschrieben:Statt FVF Codes, die selbst in D3D9 damals schon veraltet waren, schau dir mal VertexDeclarations an: https://msdn.microsoft.com/en-us/librar ... 06335.aspx ;)

Krishty hat geschrieben:Alternativ sind Vertex Declarations deutlich angenehmer zu benutzen.

Krishty hat geschrieben:Gut möglich; siehe die Tabelle hier ganz unten: Accurately Profiling Direct3D API Calls (Direct3D 9) Ab D3D 10 müsste das durch Constant Buffers viel schneller sein.

Krishty hat geschrieben:Äh … von Caches und Speicherbandbreite hast du aber schon gehört, oder? Wenn du statt 24 B jetzt 48 überträgst, ist die Übertragung halt nur noch halb so schnell … und dass die ein Flaschenhals ist, weißt du, seit Vertex Buffers nichts gebracht haben.

dot hat geschrieben:Abgesehen davon, bedeutet XYZRHW doch, dass du deine Vertices auf der CPU transformieren und dann ständig neu auf die GPU laden musst!?

Goderion hat geschrieben:

Krishty hat geschrieben:Äh … von Caches und Speicherbandbreite hast du aber schon gehört, oder? Wenn du statt 24 B jetzt 48 überträgst, ist die Übertragung halt nur noch halb so schnell … und dass die ein Flaschenhals ist, weißt du, seit Vertex Buffers nichts gebracht haben.

Ja klar, so gesehen ist das schon verständlich. Aber ich finde es trotzdem immer wieder etwas überraschend. Es geht um 60.000 x 6 x 24 Byte, also insgesamt 8,64 MB pro Frame. Bei 400 FPS wären das grob zusätzlich 3,5 GB/s. PCIe 3.0 x16 soll 32 GB/s schaffen. D3D9 ist da aber wohl bekannter Weise nicht so gut umgesetzt. Neuere D3D Versionen wie z.B. D3D10 würden das vermutlich besser "wegstecken", oder?