problema con inicializacion directx para utilizar en looverL

[klarth]

Hola, que tal. Tengo un problema al intentar pasar al looverLib los punteros device y direct3d que inicializo. Tengo que inicializarlos por mi cuenta porque utilizo una ventana que he creado (hwnd) que le paso al puntero direct3d, por lo que no podía utilizar GetDevice y GetDirect3d de looverLib ya que la aplicación me daba un error y finalizaba al utilizar los punteros devueltos por esas funciones en render.init(). Pensé que lo mismo el error se debía al crear una ventana, no crearla con looverLib y no poder pasarla con ninguna función a través del api.

La inicialización en sí la hago con esta funcion (los punteros al device, direct y la ventana hwnd (que se muestra correctamente) están declarados como global de momento):

void Inicializa_D3D(void)
{
HRESULT hr;
D3DPRESENT_PARAMETERS d3dpp;
D3DDISPLAYMODE modo_de_video;
// creamos nuestro objeto 3D, siempre enviando como argumento la variable D3D_SDK_VERSION,
// esto para que D3D compruebe que los .h que se estan usando son los correctos.
//Always pass D3D_SDK_VERSION to the function.
obj_D3D = Direct3DCreate9( D3D_SDK_VERSION );
if(!obj_D3D ){
Error_Fatal("Error intentando crear Direct 3D");
}
// Captura nuestro modo de video actual. Esto solamente es necesario si estamos corriendo
// en modo de ventana normal. pero ...
hr=obj_D3D->GetAdapterDisplayMode(D3DADAPTER_DEFAULT,&modo_de_video);
if(FAILED(hr)){
Error_Fatal("Error capturando el modo de video");
}
// Limpia nuestra estructura de parametros. Aunque vamos a llenar todos sus campos, pero es
// una buena practica inicializar variables.
ZeroMemory(&d3dpp,sizeof(d3dpp));
d3dpp.BackBufferWidth = g_ancho;
d3dpp.BackBufferHeight = g_alto;
d3dpp.BackBufferFormat = D3DFMT_A8R8G8B8;
d3dpp.BackBufferCount = 1;
d3dpp.MultiSampleType = D3DMULTISAMPLE_NONE;
d3dpp.MultiSampleQuality = 0;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.hDeviceWindow = hwnd;
d3dpp.Windowed = true;
d3dpp.EnableAutoDepthStencil = true;
d3dpp.AutoDepthStencilFormat = D3DFMT_D24S8;
d3dpp.Flags = 0;
d3dpp.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;
d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;


// Despues de llenar nuestra estructura de parametros, estamos listos para crear nuestro
// dispositivo.
// La mayoria de opciones sobre como crear nuestro dispositivo se configuran con esta
// estructura de parametros.
hr=obj_D3D->CreateDevice(D3DADAPTER_DEFAULT, // El adaptador de pantalla por defecto,
// En un sistema con mas de un monitor debemos
// escoger en cual.
// Usa la aceleracion de hardware antes que la renderizacion por software
D3DDEVTYPE_HAL,
// Nuestro puntero a la ventana principal
hwnd,
// procesa lso vertices por software. Esto es un poco mas lento
// que con hardware, pero funciona en TODAS las tarjetas de video.
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
// Nuestra ya conocida estructura de parametros
&d3dpp,
// Setea el puntero hacia nuestro nuevo dispositivo 3D
&obj_dispositivo_D3D);
if(FAILED(hr)){
Error_Fatal("Error creando el dispositivo");
}
}

Tras esto, que no da ningún tipo de error, le paso los punteros al render.init... y ahí se acaba la aplicación. Y atascao me quedé, jeje. Mi teoría es que algún parámetro de los que se pasa en createDevice no es correcto para que funcione con el api, pero no se... quizás si hubiera alguna forma de cambiar el atributo que apunta a la ventana del objeto lpdirect3d9 obtenido con GetDirect3d9 con algún método público...

[Loover]

Hola,

Como ya me has puesto en el mail:

El caso es que parece ser que al crear una ventana e inicializar el directx de forma independiente, hay que llamar a la función Init(punteros direct) de LOV_Render, lo que ocasiona que en ningún momento se obtenga la frecuencia del procesador con la sentencia
QueryPerformanceFrequency (&mFrecuency) que sí se ejecuta si se llama a la función Init (lov_window). Esto ocasiona que en el método EndScene se utilice la variable mFrecuency sin habérsele otorgado ningún valor (en realidad no se si esa variable se inicializa a 0 en algún punto, pero creo que no).

Te comento esto porque los problemas que tenía al final provenían de la ejecución de esa función y siguiendo el código vi que podía deberse a lo que te acabo de comentar. Añadiendo el código de las funciones que me interesaban a mi aplicación y añadiendo también esa línea para que se ejecute me funciona correctamente. Creo que es un bug, pero tampoco estoy seguro, puede que fuera cosa mía...

¡Efectivamente! Has dado con un bug. Voy a mandarte al correo la nueva versión de la librería que utiliza SDL para input, reloj y otros menesteres.

Un saludo y muchas gracias por reportar el bug. A ver cuando tengo tiempo para remodelar la web de looverlib y subir la última versión.