Un vértice, dos vértices, tres vértices ¡coño un triángulo!

Publicado el Sábado 25 septiembre 2010 en DirectX por Thund

Ha pasado más tiempo del que me gustaría desde que escribí el anterior post sobre la inicialización de Direct3D, pero es que hacía mucha calor para ponerme a redactar… espero me comprendan, ejem. De hecho, el código expuesto aquí lleva escrito desde hace un mes. Pero vamos al lío, que no hay tiempo que perder. En éste post mostraré el tortuoso camino hacia la visualización de elementos geométricos, desde donde lo dejamos.

Hasta ahora teníamos 4 interfaces de objetos correctamente inicializados: ID3D11Device, IDXGISwapChain, ID3D11DeviceContext e ID3D11RenderTarget. Esto era suficiente para poder arrancar la maquinaria de Direct3D y rellenar el área de cliente de la ventana con un color para probarlo; sin embargo, en el paso 4, que era el último, sería lógico incluir algo que necesitaremos en adelante, que es la asociación del render target al device context:

pImmediateContext->OMSetRenderTargets(1, &pRenderTargetView, NULL);

Paso 5: El ojo de buey

Es necesario definir sobre qué porción de nuestra ventana será proyectado el front buffer. Antes se utilizaba la estructura D3DVIEWPORT9 para empaquetar los parámetros del viewport, ahora utilizamos D3D11_VIEWPORT, que ni quita ni pone nada nuevo.

D3D11_VIEWPORT viewport;
viewport.Height   = 600.0f;
viewport.Width    = 800.0f;
viewport.TopLeftX = 0.0f;
viewport.TopLeftY = 0.0f;
viewport.MaxDepth = 1.0f;
viewport.MinDepth = 0.0f;

pImmediateContext->RSSetViewports(1, &viewport);

Paso 6: El átomo

Como bien sabe el lector, el universo tridimensional que vemos por pantalla está formado en su inmensa mayoría por vértices que, ordenados de cierta manera, definen superficies triangulares que, a su vez, pueden formar mallas. Toda la parafernalia geométrica puede encontrarse fácilmente en Internet y no es el objeto de éste blog por el momento, así que me lo salto. El hecho es que, tal como ocurre con los átomos tradicionales, no todos los vértices son iguales; podemos definir un vértice al cual afecte la luz, que pueda ser envuelto por una textura o que sea representado por un color determinado. O podemos diseñar otro para el cual las anteriores propiedades no tengan sentido.

struct MyVertexType
{
    XMFLOAT4 position;
    XMFLOAT4 color;
};

D3D11_INPUT_ELEMENT_DESC arElements[] =
{
    { "POSITION", 0, DXGI_FORMAT_R32G32B32A32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 },
    { "COLOR", 0, DXGI_FORMAT_R32G32B32A32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 },
};

Lo único que hacemos aquí es declarar nuestro tipo de vértice, como hacíamos con DirectX 9. No, no es así de simple, hay un montón de cosas que explicar. Empezaré por la primera estructura, en la que aparece un nuevo "tipo básico" de DirectX llamado XMFLOAT4. Se trata de una de las muchas nuevas estructuras matemáticas añadidas a la API mediante la librería XNAMath. ¿Y de dónde sale XNA si lo que vamos a usar es DirectX11 a pelo? Pues se trata  de un intento por unificar parte de las APIs de ambas plataformas, aumentando la portabilidad entre PC y XBox; aunque aún no han marcado como deprecated los antiguos tipos, creo que es preferible ir migrando desde ya en lugar de hacer adaptaciones posteriores. Para añadir la librería a nuestro código hay que incluir el archivo "xnamath.h". En éste caso, XMFLOAT4 vendría a sustituir a D3DXVECTOR4.

La siguiente estructura es también muy similar a lo que estábamos acostumbrados, usamos el tipo D3D11_INPUT_ELEMENT_DESC en lugar de D3DVERTEXELEMENT9. Nótese cómo Microsoft ha optado por un nombrado más legible. El contenido de este nuevo tipo ha cambiado bastante, y para verlo mejor, observemos las diferencias:

typedef struct D3DVERTEXELEMENT9 {
  WORD Stream;
  WORD Offset;
  BYTE Type;
  BYTE Method;
  BYTE Usage;
  BYTE UsageIndex;
} D3DVERTEXELEMENT9, *LPD3DVERTEXELEMENT9;
typedef struct D3D11_INPUT_ELEMENT_DESC {
  LPCSTR                     SemanticName;
  UINT                       SemanticIndex;
  DXGI_FORMAT                Format;
  UINT                       InputSlot;
  UINT                       AlignedByteOffset;
  D3D11_INPUT_CLASSIFICATION InputSlotClass;
  UINT                       InstanceDataStepRate;
} D3D11_INPUT_ELEMENT_DESC;

Antes especificábamos el índice del stream que iba a contener vértices con tal elemento, el desfase de bytes respecto al inicio de la estructura, el tipo del elemento (vector de 3 floats, un entero, etc.), la interpretación del tesselator, la semántica del elemento en los shaders (elegido de un enumerado) y el índice del elemento para esa semántica. Ahora nos olvidamos de los streams y nos centramos únicamente en lo que respecta al formato de entrada a los shaders: determinamos la semántica del elemento en los shaders mediante una cadena, y su índice, por si hay más de un elemento con la misma; a continuación pasamos el formato del elemento, tal y como queremos que sea interpretado por los shaders (dense cuenta de que es el mismo enumerado de la API de DXGI que usamos anteriormente). El hueco de entrada (input slot) es un índice que determina por qué "puerto" del Input Assembler entrará la información de los vértices, de manera que, si ponemos los datos de posición (vectores de 3 componentes, por ejemplo) en un buffer de vértices y los datos de color (un entero) en otro buffer, podamos introducirlos por distintos slots y obtener como entrada al vertex shader una estructura con ambos datos ensamblados; ya veremos un ejemplo de esto en el futuro. Lo siguiente es especificar cuántos bytes de desfase hay entre el elemento actual, según su formato, respecto al precedente; lo normal aquí es usar la constante D3D11_APPEND_ALIGNED_ELEMENT que, como puede deducirse, pone el elemento justo después del anterior. Quisiera apuntar que el valor de este dato se calcula respecto al input slot al que pertenece el elemento, pudiendo tener 2 elementos con desfase cero si son los primeros de 2 slots distintos. Los 2 datos restantes está relacionados con el concepto de instanciación, disponible desde DirectX 10, al que dedicaré un post en su momento.

Alguien puede pensar que la declaración del tipo de vértice está incompleta, ¿dónde está la interfaz IDirect3DVertexDeclaration9? Ha dejado de existir, ahora lo que se crean son una especie de objetos intermediarios (layouts) que relacionan el array de la declaración con la firma de un shader determinado, como veremos más adelante. A partir de DirectX 10 ya no tenemos la fixed function pipeline, así que no es posible especificar el formato de un vértice mediante constantes D3DFVF, hay que seguir forzosamente ésta metodología. Otra cosa que falta a la declaración es el uso de la macro D3DDECL_END() como último elemento, que ya no es necesaria.

Paso 7: El cristal con que miramos

Ahora empieza la parte terrorífica de la historia, es hora de hablar de los… ¡shaders! Pero que nadie se achante, en realidad son como los dobermanns, acojonan al principio pero cuando los conoces pueden ser tus mejores amigos (vaya comparación de mierda :D ). El primer bicho con el que trataremos es la interfaz ID3DBlob, que encapsula un trozo de memoria de tamaño determinado, sin estructura definida. El uso que le daremos en esta ocasión será como recipiente de un shader compilado y como salida de los mensajes de error de la compilación. No voy a utilizar el Effects Framework todavía sino las funciones globales de que nos provee DirectX 11. Por tanto, para compilar un shader escrito en HLSL en un archivo de texto, llamaré a D3DXCompileShaderFromFile… ah no, que ahora se llama D3DX11CompileFromFile. Las diferencias entre una y otra función son ínfimas, quizá lo más destacable sea la posibilidad de realizar la compilación en un thread distinto mediante el uso de la interfaz ID3DX11ThreadPump, que no explicaré aquí, pero que según tengo entendido consume más de lo que ahorra. Para tener acceso a tal función hay que incluir la cabecera "D3DX11async.h".

UINT shaderFlags = D3D10_SHADER_DEBUG | D3D10_SHADER_SKIP_OPTIMIZATION | D3D10_SHADER_ENABLE_STRICTNESS;

ID3DBlob* pBlobVS = NULL;
ID3DBlob* pErrorBlobVS = NULL;
D3DX11CompileFromFile( L"MyEffect.fx", NULL, NULL, "vs_main", "vs_4_0", shaderFlags, NULL, NULL, &pBlobVS, &pErrorBlobVS, NULL );

ID3DBlob* pBlobPS = NULL;
ID3DBlob* pErrorBlobPS = NULL;
D3DX11CompileFromFile( L"MyEffect.fx", NULL, NULL, "ps_main", "ps_4_0", shaderFlags, NULL, NULL, &pBlobPS, &pErrorBlobPS, NULL );

Al igual que con las versiones anteriores, especificamos la ruta (relativa o absoluta) del archivo de texto, las macros del shader (que aquí no usamos), los trozos de shader a incluir (que tampoco necesitamos), el nombre de la función principal del shader y la versión del Shader Model para la cual se compilará. A continuación, se especifican los flags de compilación, valores constantes heredados de DirectX 10 (con prefijo D3D10_SHADER_) que se pueden combinar para modificar el comportamiento del compilador de shaders; aquí hemos usado, por ejemplo, D3D10_SHADER_DEBUG para generar información de depuración que sirva a un depurador, como el de PIX, para mostrar el código HLSL directamente, en lugar del código ensamblador; D3D10_SHADER_SKIP_OPTIMIZATION evita que el compilador realice optimizaciones, lo cual provocaría que el código HLSL visto en el depurador no concordara con el generado; finalmente, el flag D3D10_SHADER_ENABLE_STRICTNESS nos obligará a utilizar la sintaxis de la versión 4.0 y posteriores del Shader Model. Lo siguiente que se nos pide es una combinación de flags para efectos (no ponemos nada), un puntero a la interfaz del thread antes mencionada y variables de salida, de las que sólo cabe destacar la última, pHResult, que debe apuntar a una zona válida de memoria para almacenar el resultado de la operación llevada a cabo en el otro thread, siempre y cuando se haya especificado la susodicha interfaz. Otro NULL al bote.

Para poder insertar nuestros shaders en la pipeline, primero tenemos que encapsularlos en sendas interfaces ID3D11VertexShader y ID3D11PixelShader (antes llamadas IDirect3DVertexShader9 y IDirect3DPixelShader9, respectivamente). La única información que hay que pasar al dispositivo para crear los objetos es el punto de inicio del buffer que contiene el resultado de la compilación y su longitud. A continuación se asocian al contexto encargado de dibujar nuestro polígono.

ID3D11VertexShader* pVS = NULL;
pDevice->CreateVertexShader(pBlobVS->GetBufferPointer(), pBlobVS->GetBufferSize(), NULL, &pVS);
pImmediateContext->VSSetShader(pVS, NULL, 0);

ID3D11PixelShader* pPS = NULL;
pDevice->CreatePixelShader(pBlobPS->GetBufferPointer(), pBlobPS->GetBufferSize(), NULL, &pPS);
pImmediateContext->PSSetShader(pPS, NULL, 0);

Ya tenemos nuestros shaders cargados en memoria, compilados y preparados para ser ejecutados por el mecanismo de DirectX para representar nuestra geometría con el aspecto que más nos guste. Alto, ¿cómo sabe DirectX qué tipo de datos va a enviar al Input Assembler para que los shaders los procesen? ¿Cómo deben ser transformados aquéllos para que coincidan con los esperados?

Paso 8: Las gallinas que entran por las que van saliendo, o no

Como mencioné anteriormente, en DirectX 11 se usan unos intermediarios que actúan como adaptadores entre los shaders, el Input Assembler (por cierto, aunque ya lo expliraré, el Input Assembler es una de las fases (stage) de la pipeline, concretamente la de entrada) y los datos de entrada, que llegan en forma de paquetes de vértices. Estos adaptadores van encapsulados en interfaces ID3D11InputLayout y están sujetos a la firma de un shader y al formato de los datos de entrada, información que se transfiere al Input Assembler.

ID3D11InputLayout* pMyInputLayout = NULL;
pDevice->CreateInputLayout(arElements, sizeof(arElements) / sizeof(arElements[0]), pBlobVS->GetBufferPointer(), pBlobVS->GetBufferSize(), &pMyInputLayout);
pImmediateContext->IASetInputLayout(pMyInputLayout);

Tal y como puede verse claramente, se utilizan la declaración del tipo de datos de nuestro vértice y el resultado de la compilación del vertex shader (especificando sus puntos de inicio y su tamaño en memoria). Acto seguido se asocia el nuevo layout con el Input Assembler por medio del método IASetInputLayout (es obvio de dónde le viene el prefijo, veremos que han usado tal convención de nombres para todos los métodos relacionados directamente con ciertas fases de la pipeline).

Paso 9: Un pino, dos pinos, tres pinos… ¡coño un pinar!

Sólo resta meter datos en la tubería para que sean procesados por la maquinaria que acabamos de ajustar. Primero creamos una lista de 3 vértices cuyas coordenadas en el espacio proyectado sobre el viewport forman un triángulo (no vamos a aplicar transformaciones aún). Tal información irá empaquetada en un buffer cuya estructura debemos describir usando el tipo D3D11_BUFFER_DESC.

MyVertexType vertices[3];
vertices[0].position = XMFLOAT4(0.0f, 0.5f, 0.0f, 1.0f);
vertices[1].position = XMFLOAT4(0.5f, -0.5f, 0.0f, 1.0f);
vertices[2].position = XMFLOAT4(-0.5f, -0.5f, 0.0f, 1.0f);
vertices[0].color = vertices[1].color = vertices[2].color = XMFLOAT4(1.0f, 1.0f, 1.0f, 1.0f);

D3D11_BUFFER_DESC bufferDesc;
bufferDesc.Usage = D3D11_USAGE_DEFAULT;
bufferDesc.ByteWidth = sizeof( vertices );
bufferDesc.BindFlags = D3D11_BIND_VERTEX_BUFFER;
bufferDesc.CPUAccessFlags = 0;
bufferDesc.MiscFlags = 0;

Antes de continuar, quisiera remarcar que el buffer que estamos definiendo es tratado por DirectX 11 como un recurso, al igual que las texturas (sus interfaces heredan de ID3D11Resource), por lo que la manera de crearlos y parametrizarlos es muy similar, basta observar cómo se repiten determinados campos en las estructuras D3D11_BUFFER_DESC, D3D11_TEXTURE1D_DESC, D3D11_TEXTURE2D_DESC y D3D11_TEXTURE3D_DESC. En DirectX 9 ocurría igual, aunque ahora se ha simplificado o unificado las opciones. Un ejemplo de esto era el parámetro de tipo D3DPOOL en el que especificábamos dónde alojar el recurso (memoria de sistema, de la tarjeta gráfica o administrado por DirectX), o la cantidad de tipos de uso, que ahora se ve reducida de 16 opciones a 4. También hay que mencionar la pérdida de las interfaces IDirect3DVertexBuffer9 e IDirect3DIndexBuffer9, cuyas responsabilidades son ahora cubiertas por ID3D11Buffer, según el flag de enlazado (bind flag).

Prosigamos. Rellenar la estructura es sencillo, como puede verse. Primero especificamos el uso (acceso de lectura / escritura por parte de la CPU y la GPU); luego el tamaño de nuestra lista de vértices; seguidamente el flag de enlazado, que en este caso indica que nuestro buffer actuará como un "vertex buffer"; no necesitamos acceder al recurso desde la CPU en esta ocasión, por lo que pasamos un cero, igual que para los flags especiales.

D3D11_SUBRESOURCE_DATA initialData;
initialData.pSysMem = vertices;
initialData.SysMemPitch = 0;
initialData.SysMemSlicePitch = 0;

ID3D11Buffer* pBuffer = NULL;
pDevice->CreateBuffer( &bufferDesc, &initialData, &pBuffer );

Para crear el buffer tenemos que "empaquetar" los datos en oootra esctructura (nótese mi jartura, con jota), D3D11_SUBRESOURCE_DATA, a la que pasamos un puntero a nuestra lista de vértices. Los otros 2 campos no son necesarios dado que no estamos tratando con una textura. De este modo, tenemos por un lado los datos y por otro su forma. Los usamos en el método CreateBuffer y hala, ya tenemos un dichoso buffer.

Como colofón, pasamos nuestro recién armado vertex buffer como entrada del Input Assembler:

UINT stride = sizeof( MyVertexType );
UINT offset = 0;
pImmediateContext->IASetVertexBuffers( 0, 1, &pBuffer, &stride, &offset );
pImmediateContext->IASetPrimitiveTopology( D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST );

El método IASetVertexBuffers reemplaza al antiguo SetStreamSource, con el añadido de que se le pueden pasar varios vertex buffers en una sola llamada. La última sentencia especifica qué tipo de primitivas forman los vértices suministrados, es decir, si se trata de una lista de líneas (cogiendo los vértices de 2 en 2), o si es una tira (que es distinto de uns lista) de triángulos, etc. Aquí se envía una lista en la que hay un único triángulo.

El resultado de todo este trabajo lo podemos ver si llamamos al método Draw del immediate context. Existen varias versiones de este método según el proceso que queramos seguir a la hora de dibujar. Por ejemplo, si estuviéramos usando índices llamaríamos a DrawIndexed, y en caso de usar instanciación invocaríamos a DrawInstanced. Hablaré de todos ellos en los próximos posts. Como es obvio, tales métodos son evoluciones de sus casi homónimos de la interfaz del dispositivo de DirectX 9.

pImmediateContext->Draw( 3, 0 );

Con esto expresamos que queremos dibujar 3 vértices, empezando por el número cero. Y éste es el resultado:

Sumario de Portabilidad

DirectX 9 DirectX 11 Comentario
D3DVIEWPORT9 D3D11_VIEWPORT  
D3DXFLOAT4 XMFLOAT4  
D3DVERTEXELEMENT9 D3D11_INPUT_ELEMENT_DESC  
IDirect3DVertexDeclaration9   No hay análogo.
Constantes D3DFVF   No hay análogo.
D3DDECL_END()   No hay análogo.
D3DXCompileShaderFromFile D3DX11CompileFromFile  
IDirect3DVertexBuffer9 ID3D11Buffer Bind Flag = D3D11_BIND_VERTEX_BUFFER
IDirect3DIndexBuffer9 ID3D11Buffer Bind Flag = D3D11_BIND_INDEX_BUFFER
IDirect3DDevice9::CreateVertexBuffer ID3D11Device::CreateBuffer  
IDirect3DDevice9::CreateIndexBuffer ID3D11Device::CreateBuffer  
IDirect3DVertexShader9 ID3D11VertexShader  
IDirect3DPixelShader9 ID3D11PixelShader  
IDirect3DDevice9::SetStreamSource ID3D11DeviceContext::IASetVertexBuffers  
IDirect3DDevice9::DrawPrimitive ID3D11DeviceContext::Draw  

 

Descargas

Podéis descargar el código de ejemplo desde aquí:

EndlessGameTriangle.zip (23 Kb)
 

Etiquetas: , ,

Lectura recomendada

Publicado el Domingo 15 agosto 2010 en DirectX por Thund

Aquí os dejo una lista de libros relacionados con DirectX o con la programación gráfica en general que he leído o que conozco. Son todos en inglés, obviamente, y los podéis encontrar tanto en la Amazonia como pidiéndoselos a una mula, que cada cual elija su locura.

Introduction to 3D Game Programming With DirectX 9.0
 

Éste fue el primer libro sobre DirectX que leí. Se me hizo un poco cuesta arriba debido a que, por aquel entonces, mi conocimiento acerca del funcionamiento de una API gráfica era inexistente y mi dominio tanto del inglés como de C++ algo mediocre. Aun así le eché un par de voluntades y me fui enterando de toda la teoría que hay delante y detrás de la programación de una aplicación basada en DirectX. Como el título indica, se trata de una introducción, es decir, toca los palos principales y sin entrar en mucho detalle. Esto no quiere decir que explique las cosas de pasada y te deje más perdío que Marco el día de la madre; se centra en los aspectos más básicos, desde cero, siguiendo una curva poco pronunciada, fácil de seguir. Si te apoyas en la referencia del SDK de DirectX a la par que avanzas por los capítulos, el aprendizaje se verá mucho más reforzado. Está claro que es un libro obsoleto, no sirve a alguien que vaya a emprender su andadura por DirectX 11, pero ésto es una verdad a medias; dado que es un libro introductorio, no hace hincapié en el código y en las particularidades de la API, por lo que hay muchas técnicas y bases descritas que son comunes a cualquier librería del estilo, y que pueden ser de gran utilidad para comprender la arquitectura y la forma de trabajar de cualquier versión. Unas 394 páginas, poca cosa.

Aviso de que quizás, tras haber terminado el libro, no seáis capaces de hacer un dragón rojo echando fuego.

Advanced 3D Game Programming with DirectX 9.0
 

Una extensión del anterior, lo que no quiere decir que empiece donde aquél lo dejó, sino que entra en mucha más profundidad en los temas ya tratados y añade muchos nuevos. Si la introducción abarcaba mayormante el campo de los gráficos, éste tomo expande las fronteras hacia el resto de componentes de DirectX, como son DirectSound y DirectInput, y mete la cabeza en la inteligencia articial y las telecomunicaciones. Digno de mención son el capítulo acerca de la gestión de la escena y los detalles sobre mallas progresivas. No me gustó demasiado la maquetación con respecto a su antecesor. De las 514 páginas puedes saltarte las 60 primeras y luego ir dando saltos, el orden no es importante.

Sí, la portada es fea de cojones.

DirectX 9 Graphics The Definitive Guide to Direct3D
 
Este libro es un intento por cubrir todas las áreas habidas y por haber en torno a los gráficos, aunque se deja un apartado sin cubrir de gran importancia, como son los shaders. Empieza desde lo básico, da una base matemática y en pocas páginas nos encontramos iluminando la escena. Como puntos fuertes tiene la descripción de los archivos .X y su utilización; explica la animación por esqueletos y pieles y mediante keyframes; y es de los pocos que tratan temas de animación de texturas y el uso de DirectShow. En total 351 páginas, recomendable como libro de consulta.
Advanced Animation with DirectX
 
Se trata de un libro más especializado, concretamente en el mundo de la animación mediante código y la interpretación de formatos de animación estándar, como la animación por esqueleto / piel (incluyendo el efecto rag doll), morphing, movimiento de partículas, animación de texturas y efectos de animación de objetos blandos como la ropa. A destacar la explicación del uso de archivos .X de DirectX. Unas 346 páginas en las que no se llega a profundizar demasiado en las técnicas aunque se dan buenas bases. Lo bueno de éste libro es que vale para cualquier API gráfica, aunque en el título aparezca DirectX.
Real-time Rendering Tricks and Techniques in DirectX
 
Éste no lo he leído, más bien lo he usado como libro de consulta. Básicamente hace un breve recorrido por los elementos gráficos de Direct3D hasta que empieza a hablar de shaders. Contiene un montón de ejemplos tanto de pixel shaders como de vertex shaders; lo malo para los programadores que usen DirectX es que tales ejemplos no contienen código HLSL sino ensamblador, lo cual es bueno para los que usen otras APIs como OpenGL (si saben traducirlo a GLSL claro). Al final del libro describe técnicas como el motion blur y el picking, y dedica apartados al stencil buffer y a DirectShow. Unas 827 páginas muy recomendables.
The Complete Effect And HLSL Guide
 
Libro dedicado exclusivamente a shaders, tanto en ensamblador como en HLSL, y al framework de efectos de DirectX 9. Éste sí me lo leí de cabo a rabo porque necesitaba coger una buena base, que fuera especializada, acerca de los shaders. Tiene cosas muy malas y otras muy buenas. Una de las malas es que hay muchas partes que son copy&paste de la MSDN; si quisiera leer la MSDN me iría a la maldita MSDN. En cambio, una de las características más destacables es lo detallado de la información acerca de las equivalencias entre el lenguaje HLSL y el ensamblador, las capacidades de los distintos shader models, desde el 1.0 al 3.0, y una precisa descripción de cada instrucción de la GPU. Sabemos que, a día de hoy, contamos con el shader model 5.0 pero, si nos fijamos bien, nos damos cuenta de que desde la versión 3.0 no ha cambiado demasiado el abanico de funciones ni su comportamiento, aunque sí lo hayan hecho algunos elementos de la semántica y la capacidad del hardware (número de instrucciones permitidas, número de constantes…), casos para los que disponemos de la referencia del SDK o la MSDN. El otro aspecto a remarcar de éste libro es que es de los pocos sitios donde se habla del Effects Framework, que parece siempre como si lo guardaran en secreto por la poca información que se puede encontrar por ahí. A mí me aclaró muchas cosas, por eso lo recomiendo, o si ha salido alguna nueva versión del libro tanto mejor. Se hace cortito, 307 páginas de las que la mitad son tablas.
3D Math Primer for Graphics and Game Development
 
Bases matemáticas para muchas de las cosas que normalmente utilizamos y que damos por sentado. No me lo he leído, pero lo pongo aquí para que se sepa de su existencia. Son 435 páginas.
Geometric Tools for Computer Graphics  
El libro gordo de Petete, 1055 páginas para explicarnos una barbaridad de conceptos y algoritmos matemáticos. Los amantes del álgebra, los espacios vectoriales y la geometría se harán pajas con él. Echando un vistazo al índice (pues no me lo he leído aún) puede verse claramente cómo cubre un montón de aspectos útiles, como la formación de elementos geométricos, intersecciones, partición espacial binaria, triangulación, cálculos de distancias, etc. Por ahí se dice que tiene un montón de erratas, pero en su página web vienen todas aquellas que se han detectado (que oye, son unas cuantas). Recomendabilísimo.
Game Programming Gems  
He decidido poner toda la saga junta porque su descripción es similar y no quiero morirme escribiendo. Muchos ya la conoceréis, se trata de una serie de publicaciones que contienen perlas algorítmicas, técnicas geniales y muy extendidas en la programación de juegos en el ámbito profesional, escritas por veteranos de la industria en muchas ocasiones. Los que no sabíais de su existencia, quedaréis gratamente sorprendidos. Eso sí, yo miraría antes el índice de cada uno antes de comprarlo, ya que cada cual contiene métodos muy dispares, a todos los niveles, no sólo relacionados con los gráficos. Imprescindibles.
Introduction to 3D Game Programming with Direct3D 10
 
Homólogo del anteriormente descrito pero para DirectX 10 (además, escrito por el mismo autor). No lo he leído pero se ve que es lo mismo adaptado a la siguiente versión. Unas 500 páginas.
Advanced 3D Game Programming with DirectX 10
 
La temática es la misma que la de su homólogo de DirectX 9 (y otra vez, coincide el autor). Amplía el contenido acerca de la IA y habla de las curvas beizer y los quads. Este lo he leído un poco por encima. Un total de 527 páginas.
C++ for Game Programmers
 
Este post no es para libros de C++, pero el que he puesto está precisamente orientado a la programación de juegos, o aplicaciones gráficas. Muy recomensable, expone una gran cantidad de trucos, recomendaciones y optimizaciones que todo programador agradece, y siempre hay alguna cosa que se aprende por muy ducho que seas en la materia. Son 434 muy amenas para los amantes de C++.

Hay muchos más por ahí, pero esto es un post no la Biblioteca de Alejandría.

Etiquetas: , , ,

Inicializando Direct3D – Parte 2/2

Publicado el Lunes 26 julio 2010 en DirectX por Thund

En la primera mitad de este post presenté las nuevas interfaces de Direct3D y DXGI necesarias para empezar a mostrar imágenes por pantalla. Ahora voy a mostrar cómo se utilizan, de forma básica.

Paso 0: Dependencias

Para este ejemplo, necesitaremos estas librerías de DirectX 11: d3d11.lib y dxgi.lib

Incluiremos en nuestro código el siguiente archivo de cabecera: d3d11.h

#include <d3d11.h>

Nótese que tal archivo de cabecera ya incluye a dxgi.h (además de d3d10_1.h, para quien le interese saberlo).

Paso 1: En busca del adaptador

Lo primero que haremos será seleccionar un dispositivo gráfico de entre los que tengamos instalados en nuestro ordenador. Como la mayoría somos mileuristas, lo normal es que sólo tengamos uno, así que elegiremos el primero que aparezca. La forma de hacerlo es usando una de las interfaces más importantes en la API de DXGI: IDXGIFactory. Ésta interfaz de nombre tan original se encarga de la creación de swap chains y adaptadores; para instanciarla se utiliza la función global CreateDXGIFactory. Un adaptador gráfico físico está representado por la interfaz IDXGIAdapter, y se obtiene mediante el método CreateSoftwareAdapter de IDXGIFactory en el caso de necesitar un adaptador por software, o a través de la enumeración de todos los adaptadores hardware disponibles, como es lo habitual, con el método EnumAdapter de la misma interfaz.

IDXGIFactory* pFactory = NULL;
CreateDXGIFactory(__uuidof(IDXGIFactory), reinterpret_cast<void**>(&pFactory));

IDXGIAdapter* pAdapter = NULL;
pFactory->EnumAdapters(0, &pAdapter);

Más de uno estará ahora mismo pensando qué cojones es esa función de nombre tan típico de Microsoft… os ahorraré la búsqueda. La función __uuidof se encarga de obtener un GUID (Globally Unique IDentifier) a partir de un tipo, una referencia, un puntero, una variable, un array o una plantilla especializada; en nuestro caso, necesitamos pasar como primer parámetro el GUID del tipo IDXGIFactory.

El método EnumAdapters rellena el puntero con la dirección del IDXGIAdapter que indiquemos con el índice del primer parámetro; aquí usamos el 0 (cero) puesto que sabemos que sólo tenemos un dispositivo. En caso de que pasemos un índice igual o superior al número de adaptadores, el método devolverá el código de error DXGI_ERROR_NOT_FOUND. Cuando necesitemos enumerar todos los adaptadores, nos valdremos de tal resultado como condición para iterar.

Éste no es un paso totalmente necesario, como podrá verse más abajo, pero en cierto modo es ilustrativo.

Paso 2: Swap chain a medida

Antes de montar la swap chain hay que definirla, esto es, determinar las dimensiones de los buffers, el formato de sus texels, la frecuencia del swapping (intercambio)… Exactamente lo mismo que hacíamos con DirectX 9, como ya mencioné, cuando usábamos la estructura D3DPRESENT_PARAMETERS, que ahora se llama DXGI_SWAP_CHAIN_DESC. Pasaré ahora a describir brevemente los atributos:

DXGI_SWAP_CHAIN_DESC swapChainDesc;

swapChainDesc.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
swapChainDesc.BufferDesc.Height = 600;
swapChainDesc.BufferDesc.RefreshRate.Denominator = 1;
swapChainDesc.BufferDesc.RefreshRate.Numerator = 60;
swapChainDesc.BufferDesc.Scaling = DXGI_MODE_SCALING_UNSPECIFIED;
swapChainDesc.BufferDesc.ScanlineOrdering = DXGI_MODE_SCANLINE_ORDER_UNSPECIFIED;
swapChainDesc.BufferDesc.Width = 800;
swapChainDesc.SampleDesc.Count = 1;
swapChainDesc.SampleDesc.Quality = 0;
swapChainDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
swapChainDesc.BufferCount = 1;
swapChainDesc.OutputWindow = windowsHelper->GetWindowHandler();
swapChainDesc.Windowed = true;
swapChainDesc.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
swapChainDesc.Flags = 0;

El formato (aributo BufferDesc.Format) está formado, normalmente, por 32 bits divididos en grupos de 8 con el orden RGBA. El alto y el ancho (BufferDesc.Height y BufferDesc.Width) se refieren a la resolución de los buffers, en píxeles. La tasa de refresco (BufferDesc.RefreshRate) es un número racional del cual especificamos el numerador y el denominador; como mi monitor es un TFT, he puesto 60 / 1 = 60 hz. Tenemos que elegir cómo se dibujará la imagen en el monitor cuando la resolución del mismo sea mayor que la del front buffer: si cambiará su tamaño para ajustarse (DXGI_MODE_SCALING_STRETCHED) o si aparecerá el recuadro centrado en la pantalla (DXGI_MODE_SCALING_CENTERED). Como me la suda lo que ocurra, he dejado el atributo BufferDesc.Scaling sin especificar (DXGI_MODE_SCALING_UNSPECIFIED). El siguiente atributo (BufferDesc.ScalineOrdering), he de reconocer que no conozco su utilidad exacta, aunque se puede deducir que tiene que ver con el orden con que el rasterizador dibuja las líneas de píxeles horizontales que forman la imagen. No vamos a usar antialiasing por lo que ajustamos el número de multisamples por píxel (SampleDesc.Count) a 1 y la calidad (SampleDesc.Quality) del mismo a 0 (cero). Las texturas que actúan como buffers serán usadas (BufferUsage) como objetivos para la renderización, por lo que elegimos el valor DXGI_USAGE_RENDER_TARGET_OUTPUT (la otra única opción posible es DXGI_USAGE_SHADER_INPUT). Cuando vi esto último quedé extrañado, estaba convencido de que habría que usar el valor DXGI_USAGE_BACK_BUFFER, pero da la impresión de que su uso es muy específico. Indicamos ahora la cantidad de buffers (BufferCount) que compondrán nuestra swap chain; aquí habría que darle una colleja a alguno de Microsoft, porque la documentación está mal. Claramente dice que en el número hay que incluir al front buffer, o sea, front buffer + back buffer = 2 buffers. Pues no, si sólo vamos a usar un back buffer, el resultado es 1; el front buffer no hay que contarlo para nada. Cada swap chain está vinculada desde su creación a una ventana y un dispositivo y deberá ser creada de nuevo si se quiere enlazar a otros; le pasamos el manejador de la única ventana que tenemos ahora mismo. Establecemos que queremos renderizar en modo ventana (Windowed), que es más fácil depurar. El efecto del intercambio (SwapEffect) es lo que ocurrirá con el back buffer cuando llamemos al método Present; nosotros no vamos a hacer nada en especial con él, por lo que lo descartamos (DXGI_SWAP_EFFECT_DISCARD). Por último, no queremos ajustar ninguna opción especial de la swap chain, así que ponemos los Flags a 0 (cero).

Paso 3: Enhorabuena, ha tenido usted trillizos

Una vez rellenado el bloque de configuración de la swap chain, aún quedan más parámetros que definir. Qué coñazo ¿no? Hay que elegir el tipo de driver, la capa que queremos activar, algunos flags… y el nivel de funcionalidad (feature level). ¿Qué carajo es eso de los feature levels? Pues bien, son un gran avance en la cohesión entre proveedores de hardware y los desarrolladores de APIs gráficas de bajo nivel, impulsado desde DirectX 10 (incluso antes, desde la aparición del Shader Model 3.0 en DirectX 9). Consiste en cargarse los flags de los Device Capabilities (a.k.a. CAPS) con los que había que pelearse en DirectX 9, y reemplazarlos por una especie de "contratos" que aseguran que un determinado dispositivo provee de un paquete de funcionalidades, según la versión de DirectX que las soporta. Así, cuando compramos una tarjeta gráfica con la etiqueta "DirectX 11" en la caja, quiere decir que implementa el conjunto mínimo establecido de las características que ofrece DirectX 11. Aún tendremos que hacer ciertas comprobaciones sobre la capacidad del hardware mediante ciertos métodos de la interfaz IDXGIOutput, como veremos en posts posteriores, pero ya no hay que ponerse a enmascarar ristras de bits para saber si la tarjeta soporta T&L, ciertos modos de presentación, algunas operaciones del stencil buffer, etc. Hay que decir que la selección explícita del nivel de funcionalidad es algo nuevo en DirectX 11 que permite orientar la implementación de nuestro programa a un determinado conjunto de hardware. Cuando especificamos que queremos crear un manejador de dispositivo para DirectX 9, lo que ocurrirá es que las instrucciones que demos con interfaces de DirectX 11 se traducirán a las que lanzaría DirectX 9 al dispositivo (lo cual conlleva una penalización de rendimiento que no tendríamos si usáramos la API de DirectX 9 directamente). Ésto que parece tan bonito también tiene su aquél, ya que hay algunas características que no pueden ser traducidas, pues no existen en el hardware, como el soporte de arrays de texturas o el uso de DirectCompute. De modo que habrá que seguir haciendo comprobaciones durante el desarrollo para evitar que ciertas cosas les exploten en la cara a los usuarios de tarjetas de video obsoletas. Podéis encontrar una tabla con todas las incompatibilidades en la documentación.

ID3D11Device* pDevice = NULL;
IDXGISwapChain* pSwapChain = NULL;
ID3D11DeviceContext* pImmediateContext = NULL;

D3D_FEATURE_LEVEL featureLevels[1] = { D3D_FEATURE_LEVEL_10_1 };

D3D_FEATURE_LEVEL* pFeatureLevelsOut = NULL;

D3D11CreateDeviceAndSwapChain(	pAdapter,
								D3D_DRIVER_TYPE_UNKNOWN,
								NULL,
								D3D11_CREATE_DEVICE_DEBUG,
								featureLevels,
								1,
								D3D11_SDK_VERSION,
								&swapChainDesc,
								&pSwapChain,
								&pDevice,
								pFeatureLevelsOut,
								&pImmediateContext );

El código precedente comienza declarando e inicializando punteros a las 3 interfaces de los elementos principales que necesitamos para renderizar: el dispositivo, la swap chain y el contexto del dispositivo que, como puede deducirse del nombre de la variable, será un contexto inmediato. A continuación, rellenamos un array de niveles de funcionalidad con un único elemento, que hace referencia a la versión 10.1 de DirectX. Es un nivel que funciona en mi máquina, puede cambiarse por cualquier otro o incluso usar un puntero nulo en lugar de un array, lo que significa que se usará la versión más avanzada compatible con el sistema. La siguiente declaración es un puntero que será asignado internamente, en el momento de la creación de los elementos, a una lista de niveles de funcionalidad soportados por el dispositivo, es decir, actuará como parámetro de salida. Por fin, usamos la función global D3D11CreateDeviceAndSwapChain para reunirlo todo y crear los 3 objetos ya mencionados. Podría crear el manejador del dispositivo y el contexto por un lado (función D3D11CreateDevice), y la swap chain por otro (método CreateSwapChain de la interfaz IDXGIFactory), pero ya que se nos facilita un todo-en-uno ahorraremos líneas.

Voy a comentar cada uno de los parámetros de la función refiriéndome al número de línea en el que aparecen, por facilidad. Como primer parámetro, en la línea #09 utilizo el puntero a la interfaz del adaptador que seleccionamos en el paso 1; podría pasar un puntero nulo, en cuyo caso se usaría el adaptador por defecto. El siguiente parámetro, en la línea #10, es el tipo de driver que será creado (hardware, WARP, de referencia…); tiene como restricción que, si hemos pasado un puntero no nulo como adaptador, el tipo de driver debe ser "desconocido" (D3D_DRIVER_TYPE_UNKNOWN); si el puntero era nulo, forzosamente deberemos elegir entre un driver de tipo hardware (D3D_DRIVER_TYPE_HARDWARE) o software (D3D_DRIVER_TYPE_SOFTWARE). En la línea #11 hay que proporcionar un manejador de la DLL del rasterizador por software, si es que vamos a usar un driver de tipo software; si el driver era de tipo distinto de software, obligatoriamente hay que usar un puntero nulo. Quiero disponer de toda la información posible durante el proceso de desarrollo y depuración, por lo que, mediante el flag de la línea #12, activo la capa de depuración de DirectX. Seguidamente, establezco los niveles de funcionalidad (#13) y el número de elementos de tal array (#14); si pasara un puntero nulo, se usaría internamente un array con todos los niveles (el número de elementos tendría que ser cero). Tras indicar la versión del SDK (#15), suministramos la estructura con las características de la swap chain (#16) que rellenamos en el paso 2 y, a continuación, todos los parámetros de salida. Si todo sale bien, la función devolverá el código S_OK.

Paso 4: Y se hizo la luz

Gracias al mecanismo que acabamos de construir, tenemos total control sobre el adaptador. Sin embargo, para poder enviar las órdenes de renderizado, hay que crear un canal que nos comunique con los recursos, esto es, una vista. Para este ejemplo, lo único que vamos a hacer es pintar la pantalla de un color, para lo cual crearemos una vista del back buffer.

ID3D11Texture2D* pBackBuffer = NULL;
pSwapChain->GetBuffer(0, __uuidof(*pBackBuffer), reinterpret_cast<void**>(&pBackBuffer));

ID3D11RenderTargetView* pRenderTargetView = NULL;
pDevice->CreateRenderTargetView( dynamic_cast<ID3D11Resource*>(pBackBuffer), NULL, &pRenderTargetView );

Como puede verse, primero extraemos la textura que hace de back buffer de nuestra swap chain y, a continuación, la usamos para generar una vista a la misma. Lo único que puedo remarcar aquí es que el índice del back buffer es el 0 (cero) debido a que es el único que hay y el efecto de intercambio de la swap chain no es secuencial (DXGI_SWAP_EFFECT_SEQUENTIAL).

Ya sólo queda enviar los comandos para que el dispositivo rellene el back buffer del color que queramos y lo presente al monitor en forma de ventana. Para ello hay que organizar el código del hilo perteneciente a la ventana, de manera que en el bucle de mensajes de Windows se llame a los procesos de renderización. Describir el código es trivial, pero por no perder las costumbres… Lo primero que hago es llamar al método ClearRenderTargetView del contexto inmediato, pasándole la vista del back buffer y el color, y luego, simplemente, ordeno a la swap chain que ponga el back buffer en el lugar del front buffer, enviándolo a la pantalla.

Editado 04/08/2010 – Ver Antiguo

En el caso que nos ocupa, se renderizará a toda máquina, sin límite de FPS (Frames Per Second), siempre que no llegue el mensaje WM_QUIT. Se usa PeekMessage en lugar de GetMessage debido a que ésta última accede a la cola de mensajes del hilo y bloquea la ejecución hasta que capture uno, mientras que PeekMessage vuelve inmediatamente, haya mensajes en la cola o no.

// Main message loop:
while ( msg.message != WM_QUIT )
{
    if( PeekMessage(&msg, NULL, 0, 0, PM_REMOVE) )
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    else
    {
        // Render
        pImmediateContext->ClearRenderTargetView(pRenderTargetView, backColor);
        pSwapChain->Present(0, 0);
    }
}

Quisiera explicar por encima los parámetros del método Present y sus consecuencias. El primero se encarga de desactivar la sincronización vertical (Vsync) mediante el valor 0 (cero), o de activarla, especificando el número de refrescos del monitor que la swap chain esperará antes de presentar el back buffer. El segundo parámetro es un flag que tiene que ver con 2 cosas: una, el modo de presentar los buffers de la swap chain (renderizar un frame por buffer o sólo el primer buffer), y otra, el test de presentación. Ya os lo estaréis oliendo, el flag DXGI_PRESENT_TEST es el sustituto (en parte) del antiguo método TestCooperativeLevel. Cuando pasamos éste valor al método Present no se enviará nada a la pantalla y obtendremos un código de resultado que, según el caso, puede informarnos de que nuestra ventana está siendo totalmente eclipsada por otra (DXGI_STATUS_OCCLUDED), que se ha cambiado la resolución (DXGI_STATUS_MODE_CHANGED), o si ha ocurrido algo extraño y hay que volver a crear el manejador del dispositivo (DXGI_ERROR_DEVICE_RESET), por ejemplo. Una gran novedad respecto a éste último tipo de error es que ya no hay que partirse el pecho volviendo a crear todos los recursos dependientes de un dispositivo para cambiar de modo ventana a pantalla completa, ya no existen OnResetDevice y OnLostDevice, sino que ahora basta con llamar al método SetFullscreenState de la interfaz de la swap chain. Imagino, y remarco que esto es una suposición porque a día de hoy no lo he probado, que si se diera el error DXGI_ERROR_DEVICE_RESET, sí que habría que montar todo el chiringuito de nuevo. Me permito hacer especulaciones, aunque no me gusten, porque lo comprobaremos en breve. Hay que anotar en la cabeza que nuestra aplicación siempre debe tener un modo de espera, es decir, un estado en el que no se realice ningún tipo de tarea relacionada con la renderización, de manera que no se consuman recursos tontamente cuando, por ejemplo, nuestra ventana esté siendo ocultada por otra.

No nos olvidemos de que todos los objetos COM que hemos creado deben ser liberados mediante el correspondiente método Release de cada uno. Un detalle importante es que nunca debe liberarse la swap chain mientras el modo de visualización sea pantalla completa, pues eso causará un error de los chungos. Hay que cambiar a modo ventana antes de destruirla. Ahí va una espectacular captura del resultado del ejemplo:

[Imagen ventana verde]

Sumario de Portabilidad

DirectX 9 DirectX 11 Comentario
Direct3DCreate9 D3D11CreateDeviceAndSwapChain  
IDirect3DDevice9 ID3D11Device  
IDirect3D9   No hay análogo.
IDirect3DSwapChain9 IDXGISwapChain  
IDirect3DTexture9 ID3D11Texture2D  
IDirect3DCubeTexture9 ID3D11Texture3D  
TestCooperativeLevel DXGI_PRESENT_TEST Es un flag del método IDXGISwapChain::Present.
D3DPRESENT_PARAMETERS DXGI_SWAP_CHAIN_DESC  
IDirect3DResource9 ID3D11Resource  
IDirect3DSwapChain9::GetBackBuffer IDXGISwapChain::GetBuffer  
IDirect3DDevice9::Present IDXGISwapChain::Present  
IDirect3DDevice9::Clear ID3D11DeviceContext::ClearRenderTargetView  

 

Descargas

Podéis descargar el código de ejemplo desde aquí:

EndlessGameDX11Init.zip (23 Kb)
 

Etiquetas: , ,

Inicializando Direct3D – Parte 1/2

Publicado el Martes 20 julio 2010 en DirectX por Thund

¡Por fin, con todos ustedes… el más esperado, el desconocido, el novedoso… DirectX 11! Estoy de acuerdo, vaya chorrada de presentación, pero tenía que hacerlo, lo juro. El presente post y muchos de los sucesivos estarán centrados en Direct3D y DXGI, con pinceladas de DirectWrite o Direct2D, y en ellos trataré de explicar cómo están estructurados, cómo interactúan y cómo se utilizan para distintos propósitos, intercalando teoría y práctica para hacerlo más llevadero y comprensible. Para no complicarlo mucho, el código presentado será el básico e indispensable (en el próximo post ya le añadiré comprobaciones para hacerlo más robusto). Empecemos pues con un corto recorrido alrededor de los principales componentes de Direct3D y los cambios que ésta API ha sufrido respecto a DirectX 9. Como muchos recordaréis, lo primero que se hacía, a parte de la creación de la ventana, era llamar a la función Direct3DCreate9 a la que pasábamos la versión del SDK para obtener un puntero a una interfaz IDirect3D9. Esta última se encargaba de crear el manejador del dispositivo gráfico (IDirect3DDevice9) y la swap chain, y nos surtía de una serie de funciones para comprobar las posibilidades que el hardware ofrecía, de cara a dicha creación. Pues bien, este diseño se ha ido al carajo. Ya no existe una interfaz de entrada a la librería y toda la responsabilidad de comprobación de hardware ha sido desplazada a la API de DXGI. La swap chain ha dejado de estar medio oculta al usuario (tenías que ir específicamente a buscarla para darte cuenta de que estaba ahí) y pasa a primer plano bajo control de interfaces IDXGISwapChain. Como se puede comprobar por el prefijo, también ha pasado a dominio de DXGI. La interfaz del dispositivo (ahora ID3D11Device) se genera gracias a la función global D3D11CreateDevice y ya no se ocupa del envío de instrucciones de dibujo, o al menos no directamente, sino que ha sido dividida en 2 partes: el dispositivo y el contexto del dispositivo (ID3D11DeviceContext); mientras que el primero representa el adaptador en sí y actúa como fábrica de ciertos objetos, el segundo maneja las órdenes de renderizado. Como colofón, hace falta crear, al menos, un render target que apunte al back buffer de nuestra swap chain, y que usaremos para indicarle al device context dónde tiene que dibujar. Sí, Microsoft ha complicado un pelín las cosas. Vamos a verlo en mayor detalle, que así parece muy enrevesado.

 

DirectX Graphics Infrastructure

Nació con DirectX 10 para, según Microsoft, agrupar aquellas porciones de la API gráfica encargadas de realizar operaciones a bajo nivel en una librería independiente. Tales tareas son, por ejemplo, la enumeración de los dispositivos gráficos, el envío de los frames renderizados a los dispositivos de salida (presentación), manejo de transiciones de pantalla completa, etc. Ciertamente, DXGI ha cambiado poco desde que se lanzó, lo único que han hecho ha sido añadir funciones y unas cuantas chorradas* más con la versión 1.1, que aquí ni veremos ni usaremos. Identificaremos fácilmente estas extensiones, ya que los chicos de Redmond han tomado la genial decisión de diseño de añadir un "1" como sufijo, y deberemos tener cuidado de no mezclarla con la versión 1.0, esto es, no se deben usar interfaces o funciones de una y a continuación invocar las de la otra, de lo contrario vendrá Steve Ballmer y os gritará "Developers!" en un oído. Sí bueno, es la típica historia de terror que se cuenta a los niños cuando no se tiene ni puta idea de qué es lo que pasa, como el coco o el efecto invernadero, y con eso hay que conformarse :) . A continuación el conocido esquema sobre DXGI, por cortesía (o no) de Microsoft:

[Diagrama DXGI]

ID3D11Device

Realiza las mismas funciones que su antecesor, menos las relativas al renderizado, como Clear, Draw, Begin, End… Básicamente, es una fábrica de objetos o recursos asociados al dispositivo. Pueden generarse recursos compartidos entre varios dispositivos, pero sólo los podrá usar aquél que los creó. Echando un vistazo a su interfaz os daréis cuenta de que ya no están disponibles los métodos para la creación de vertex buffers e index buffers; de hecho, sí que están, lo que ocurre es que se han unificado los buffers en una única interfaz llamada ID3D11Buffer, que encapsula un objeto cuya funcionalidad puede configurarse en el momento de su creación, de la que se encarga el método CreateBuffer, para que se comporte como index, vertex o constant buffer. Un dispositivo puede dividirse internamente en 2 capas: la capa principal o núcleo (Core Layer), que existe siempre por defecto, y la capa de depuración (Debug Layer), que puede activarse mediante el flag D3D11_CREATE_DEVICE_DEBUG, cuando creamos el manejador del dispositivo. Dependiendo de cómo tengamos configurado el panel de control de DirectX, la capa de depuración nos mostrará una serie de mensajes muy últiles en la ventana de Output de Visual Studio. Cabe destacar que la interfaz ID3D11Device es free-threaded (o thread-safe, como más os guste), lo que significa que se puede llamar a sus métodos desde cualquier hilo simultáneamente (el número de concurrencias dependerá del driver). Al igual que en anteriores versiones, podemos crear un dispositivo de referencia que emulará mediante software todas las características de DirectX. Adicionalmente, existe otro tipo de dispositivo llamado WARP (Windows Advanced Rasterization Platform), que también implementa mediante software (con mucho mejor rendimiento, según tengo entendido) las capacidades de Direct3D 11. Para ver las limitaciones de ambos emuladores echad un ojo a la documentación.

ID3D11DeviceContext

La interfaz del dispositivo antes mencionada ha sido dividida en 2 partes, de manera que la responsabilidad del renderizado ahora recae en los llamados "contextos del dispositivo". Los contextos son creados por el propio dispositivo y pueden ser de 2 tipos: inmediatos y postergados (es mi traducción de deferred). El concepto de "contexto" se refiere al modo de tratar las órdenes de renderizado y cambios de estado que se envían al dispositivo. Mientras que en un contexto inmediato los comandos son transmitidos directamente al dispositivo, en un contexto postergado se genera una cola de comandos que serán ejecutados más tarde utilizando el contexto inmediato. Esto permite utilizar una arquitectura multihilo para renderizar en paralelo aunque, al final, acabe realizándose en serie. Sólo puede existir un contexto de tipo inmediato por dispositivo, e infinitos contextos postergados. Para saber a qué tipo pertenece un determinado contexto, podemos usar el método GetType. Al contrario que la interfaz ID3D11Device, ID3D11DeviceContext no es thread-safe, sólo puede usarse cada instancia desde un único hilo simultáneamente.

IDXGISwapChain

Anteriormente, para acceder a la cadena de intercambio de buffers de salida (swap chain en adelante), teníamos que utilizar el método GetSwapChain de la interfaz IDirect3DDevice9, obteniendo así un puntero a la interfaz IDirect3DSwapChain. Su existencia pasaba inadvertida, aunque la utilizáramos sin saberlo al suministrar la estructura D3DPRESENT_PARAMETERS (cuyo equivalente ahora es DXGI_SWAP_CHAIN_DESC) o al llamar al método Present. Con el diseño actual, la swap chain pasa a un discreto primer plano y no sólo eso sino que, como mencioné en varias ocasiones, las interfaces relacionadas con la misma han sido movidas a la librería de DXGI.

ID3D11RenderTargetView

Antes de explicar el significado de ésta interfaz en concreto, creo que es necesario dar a conocer algunos detalles acerca de la estructura de DirectX 11. Existen los llamados "recursos", que no son más que zonas de memoria con datos que son accesibles desde la pipeline de Direct3D. Tales recursos, encapsulados en derivadas de ID3D11Resource, son generados por la interfaz del dispositivo y normalmente contienen datos "en bruto", en forma de buffers (ID3D11Buffer), o texels, formando texturas (ID3D11Texture1D, ID3D11Texture2D ó ID3D11Texture3D); hay varios tipos de recurso más o, mejor dicho, subtipos, que han sido añadidos con la versión 5.0 de los shaders, tales como StructuredBuffer, que no describiré hasta que lo necesitemos para algo en el futuro. La cuestión es que, para manipular tales datos de memoria, necesitamos una "vista", que actúa como canal de acceso; en función del tipo de recurso, tendremos que elegir un tipo de vista u otro, esto es, una u otra interfaz derivada de ID3D11View. ¿Que por qué me pongo a hablar de esto aquí en vez de crear una sección de introducción para los recursos, otra para las vistas, etc.? Pues porque para fusilar y traducir la documentación de referencia ya tenéis la MSDN y el infalible traductor online de Microsoft. Volviendo a lo que nos ocupa, uno de los tipos de vista que nos permiten dibujar sobre una textura (nuestro back buffer es precisamente eso, una textura 2D) es el representado por ID3D11RenderTargetView. Para crearla hay que usar el método CreateRenderTargetView del dispositivo, al cual hay que suministrar la textura (nuestro back buffer, por ejemplo, obtenido mediante el método GetBuffer de la interfaz de la swap chain) y, opcionalmente, una estructura de configuración. Las vistas son objetos pasivos, tan sólo tienen un método o propiedad que nos devuelve sus descripciones. Veremos más tipos de vista en breve, cuando hable del depth y el stencil buffer.

Sé que el principio del post prometía sangre, pero dado que soy un cenutrio incapaz de condensar tanta información para hacer posts agradables y ligeros, me veo obligado a partirlo en 2. No tardaré mucho en publicar la segunda parte, que es la que contiene el ejemplo de código, que nadie se impaciente.

 

*Para los puristas, cuando digo "chorradas" quiero decir "funcionalidad de uso poco frecuente o de propósito muy específico", aunque suponga una puta revolución tecnológica.

Etiquetas: ,