Errores internos del controlador (Direct3D 9)
En Direct3D 9, Direct3D permitirá al controlador devolver códigos de error como E_OUTOFMEMORY, D3DERR_OUTOFVIDEOMEMORY y D3DERR_UNSUPPORTEDCOLORARG para que una aplicación pueda responder a ellos. Sin embargo, a veces, las llamadas API que generaron estos tipos de valor devuelto se cargan en un búfer de comandos y se procesan por lotes para enviarse a la GPU (consulte Control del tiempo de ejecución y optimizaciones de controladores). En este caso, los errores no se pueden retransmitir a la aplicación cuando es necesario realizar la acción, por lo que el tiempo de ejecución consume el código de error y se toma una nota en el objeto de dispositivo que ha ocurrido. Más adelante, cuando la aplicación invoca IDirect3DDevice9::P resent, IDirect3DDevice9::P resent devolverá D3DERR_DRIVERINTERNALERROR. Por este motivo, el mejor enfoque para que una aplicación tome al recibir un D3DERR_DRIVERINTERNALERROR de IDirect3DDevice9::P resent es destruir y volver a crear el dispositivo.
Si desea intentar depurar aún más, estas son algunas sugerencias para intentar averiguar qué llamada API está generando el error:
Dado que la lista de posibles valores devueltos no está completa, puede intentar encontrar qué llamada produce un error rodeando cada llamada API como esta:
TRACE ( "Calling DrawPrimitive" ); d3ddev->DrawPrim(...); TRACE ( "done\n" );A continuación, el flujo de depuración de salida debe mostrar la llamada que está causando el problema.
Además, con fines de depuración, intente llamar a IDirect3DDevice9::ValidateDevice inmediatamente antes de cada IDirect3DDevice9::D rawPrimitive para ver si hay un problema adicional con el controlador del dispositivo (operación no admitida, combinación inutilizable de formatos de textura, etc.).
Nota
IDirect3DDevice9::ValidateDevice debe usarse cuidadosamente y con moderación debido a la cantidad de trabajo de validación que el controlador debe realizar para devolver una respuesta.
Temas relacionados