[Direct3D] Shaderbestand inladen

[Orwell]

Ben laatst aan het proberen geweest om de Fixed Function Pipeline de deur uit te gooien, en die te vervangen door Programmable Shaders, HLSL dus.

Maar het gaat nog niet zo lekker. Elke keer als ik probeer om ID3DXEffect::Begin te gebruiken, crasht het programma. En ik heb geen idee waarom. Hier is de code die met de shaders te maken heeft:

C++:

// De shaders laden en daarmee tekenen
FX->SetTechnique(tech);
FX->SetMatrix(matrix,&(matView*matProjection));
UINT numPasses = 0;
FX->Begin(&numPasses,0);
for(UINT i = 0; i < numPasses; ++i) {
    FX->BeginPass(i);
    d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 3*numfaces-numoffsets, 0, numfaces);
    FX->EndPass();
}
FX->End();

Als ik alle dingen één voor één weg ga commenten, blijft over dat Begin() de fouten veroorzaakt. De fout post ik hier even niet, het is gewoon een standaard 'has stopped working'-fout. Dan nog even het shaderbestand:

C++:

uniform extern float4x4 WVP : WORLDVIEWPROJ;

/////////////////////////////////////////////////////////////////////
// Structs

struct OutputVS {
    float4 position : POSITION;
};

struct OutputPS {
    float4 color : COLOR0;
};

/////////////////////////////////////////////////////////////////////
// Shaders

OutputVS TransformVS(float3 posL : POSITION0) {
    OutputVS outVS = (OutputVS)0;
    outVS.position = mul(WVP, float3(1.0f,1.0f,0.0f));
    return outVS;
}

OutputPS TransformPS() {
    OutputPS outPS = (OutputPS)0;
    outPS.color = float4(0.0f, 1.0f, 0.0f, 1.0f); // Simpel groen returnen
    return outPS;
}

/////////////////////////////////////////////////////////////////////
// Techniques

technique testtechnique {
    pass P0 {
        VertexShader = compile vs_2_0 TransformVS();
        PixelShader  = compile ps_2_0 TransformPS();
    }
}

Had ook nog de shadercompiler op debug gezet, maar die vond het allemaal wel goed:

C++:

D3DXCreateEffectFromFile(d3ddev,"shaders.fx",0,0,D3DXSHADER_DEBUG,0,&FX,&error);
if(error) {
    MessageBox(hwnd,(char*)error->GetBufferPointer(),"Error",MB_ICONERROR);
} else {
    tech = FX->GetTechniqueByName("testtechnique");
    matrix = FX->GetParameterByName(0,"WVP");
}

Wat dus gaar is, is dat als ik het venster (met de daarop gelockte viewport) niet beweeg, dat alles goedgaat. Pas als ik messages op het programma afgooi (WM_SIZE bijvoorbeeld), loopt 'ie vast.

Erg vervelend natuurlijk, zeker als je niet weet wat je verkeerd doet. Is hier nog iemand die een helder idee heeft?

[Orwell]

Please, iemand?

Heb wel wat aan zitten debuggen, maar alles gaat goed er returnt gewoon D3D_OK, dus daar word je dan ook niks wijzer van.

[Bahmi]

Misschien dat het setten van de technique faalt?

Probeer dit eens:

C++:

if (SUCCEEDED(FX->SetTechnique(tech)))
{
FX->SetMatrix(matrix,&(matView*matProjection));
UINT numPasses = 0;
FX->Begin(&numPasses,0);
for(UINT i = 0; i < numPasses; ++i) {
    FX->BeginPass(i);
    d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 3*numfaces-numoffsets, 0, numfaces);
    FX->EndPass();
}
FX->End();
} else {
MessageBox(hwnd,"SetTechnique fail","Barf",MB_ICONERROR); 
}

Of iets dergelijks, heb C++ al iets van 5 jaar niet meer aangeraakt.

Het kan ook zijn dat je teveel data verstuurt, dus dat je bv een lijst met structs die een positie en normal bevatten, en dan raar overflowen in videogeheugen (meestal crashed dan de videodriver).

[Orwell]

Bahmi schreef op maandag 04 oktober 2010 @ 19:01:
Misschien dat het setten van de technique faalt?

Probeer dit eens:

C++:

if (SUCCEEDED(FX->SetTechnique(tech)))
{
FX->SetMatrix(matrix,&(matView*matProjection));
UINT numPasses = 0;
FX->Begin(&numPasses,0);
for(UINT i = 0; i < numPasses; ++i) {
    FX->BeginPass(i);
    d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 3*numfaces-numoffsets, 0, numfaces);
    FX->EndPass();
}
FX->End();
} else {
MessageBox(hwnd,"SetTechnique fail","Barf",MB_ICONERROR); 
}

Of iets dergelijks, heb C++ al iets van 5 jaar niet meer aangeraakt.

Het kan ook zijn dat je teveel data verstuurt, dus dat je bv een lijst met structs die een positie en normal bevatten, en dan raar overflowen in videogeheugen (meestal crashed dan de videodriver).

Dat had ik dus helaas al gedaan. Alles returnt dus netjes D3D_OK. Wat dus erg vervelend is. Voor de duidelijkheid: de letterlijke code gaat netjes verder met zijn passes. Alle andere functies controleren levert ook allemaal pass op.

En dan die overflow of niet van de buffers. Daar gaat niets fout hoor, die code werkt perfect binnen de Fixed Function Pipeline. Geen byteje Memory Leak, perfecte instelling van de structs. Etc. Etc.

Bewijs:

[Sponge]

Wat dus gaar is, is dat als ik het venster (met de daarop gelockte viewport) niet beweeg, dat alles goedgaat. Pas als ik messages op het programma afgooi (WM_SIZE bijvoorbeeld), loopt 'ie vast.

Moet je wellicht na een resize van het scherm (wat een reset van de device is, toch?) niet de shader referenties eerst verwijderen en dan weer opnieuw maken? Het is een behoorlijke tijd geleden dat ik met D3D in mijn 3D engine gewerkt heb... Maar dat soort grapjes zaten wel vaak in D3D (net zoals references naar backbuffers e.d.)

[MLM]

Probeer ook een Validate voordat je begint, misschien kan die nog wat fouten vinden. Heb je de debug functies aanstaan? Probeer eens een link met d3dx9d ipv d3dx9, en gebruik het DX Control Panel en switch naar debug runtime. Met wat geluk heb je dan in elk geval wat nuttige informatie in de debug output (draai dus wel met Visual Studio attached)

[Orwell]

MLM in "[Direct3D] Shaderbestand inladen"

Sponge schreef op dinsdag 05 oktober 2010 @ 21:38:
[...]


Moet je wellicht na een resize van het scherm (wat een reset van de device is, toch?) niet de shader referenties eerst verwijderen en dan weer opnieuw maken? Het is een behoorlijke tijd geleden dat ik met D3D in mijn 3D engine gewerkt heb... Maar dat soort grapjes zaten wel vaak in D3D (net zoals references naar backbuffers e.d.)

Het zal weer is niet waar zijn hoor, ik moest 'em resetten OnLostDevicen en OnResetDevicen. Lame. Dit is dus echt wat je bedoelt met 'dat soort grapjes'.

Hier is 'ie dan (met nog een beetje een duffe shader, maar goed):



Debuggen is dus verder niet nodig geweest, maar dank u beiden!