Un ejemplo simple... un bitmap de 1024x768, sólo eso, me da un resultado de 170 frames/segundo en un pentium 4 1.700 con una geforce4 mx 440

A mi se me antoja poco...

Un bitmap de 1024x768 parece pero no es tan simple, son casi 80000 pixels que la tarjeta tiene que procesar y pintar uno a uno.

Si lo que quieres es trasladar a la pantalla cantidades grandes de pixels como el caso del fondo del juego quizás deberías probar a crear surfaces igual que hacías en DDraw, solo que el método ahora se llama CreateOffscreenPlainSurface. Después usas UpdateSurface, que es parecido al Blt de DDraw para copiar todo o parte de la surface al backbuffer. Debes crearla con D3DPOOL_SYSTEMMEM.

Para obtener el backbuffer debes usar GetBackBuffer y para obtener la información de la surface si te hace falta hay que usar GetDesc. Todos son métodos de IDirect3ddevice9 incluidos el UpdateSurface, excepto el GetDesc que es un método de la surface para obtener su información.

Por otro lado... Según dijiste anteriormente usabas la librería D3DX, y para cargar las texturas 3DXCreateTextureFromFile. Puedes también usar D3DXLoadSurfaceFromFile y copiarlas a la pantalla con D3DXLoadSurfaceFromSurface, tiene opción para añadir color key, por lo que puedes usarlo incluso para los sprites que no usen otros efectos, aunque desconozco su rendimiento y sus posibles problemas.

Y del resto no te preocupes por usar texturas, si dibujas sprites grandes (que son las más lentos) tendrás que dibujar pocos porque no caben tantos en pantalla y si dibujas muchos tendrán que ser pequeños por lo que irán rápidos y tampoco tendrás problema.

Y si sigue sin funcionar les decimos a microchof, que inventen el DirectK, (la K de kachorro) pero eso tiene que irte rápido por cojones.

(GetAvailableTextureMem(), en bytes me parece).

 Tienes razón de optimizar al final, pero yo hay dos cosas que intentaría fijarlas al principio, que son el tamaño de los buffers de vertices y de las texturas.

intenta meter los sprites agrupados en texturas grandes, crear una textura independiente para cada uno es una locura. Al menos todos los objetos pequeños como botellas, velas, libros, etc. los metería en una única textura.

¿Que tamaño de sprite estás usando para las pruebas? porque para muchos sprites pequeños tienes que optimizar los vertices y para sprites grandes los pixels.

saludos.

 Quizás lo mejor sería crear una ventana de 640x400 y dibujar en una surface de de 320x200 (como dice TheAzazel debe ir bastante rapido).

despues usas el SDL_BlitSurface para copiar todas las columnas por duplicado a una surface auxiliar de 640x200, y finalmente repites el proceso para copiar las 200 filas a las 400 filas que tiene la ventana, eso creo que hay que hacerlo con SDL_UpdateRects.

No tengo ni idea cuan lento o problemático puede ser esto pero al menos evitas el tener que bloquearlas y urgar en ellas.

 Siempre me pasa igual (nooo)
saludos.

 Si usas opengl hay una forma eficiente de guardar y renderizar posteriormente la informacíon de los estados, primitivas, etc.  Con listas de presentación.

Así es su uso.

Código [Seleccionar] Expand


GLuint Arbol;
glNewList( Arbol=glGenLists(1), GL_COMPILE);

/*
aqui establecemos la textura, mezclas, primitivas, y cualquier tipo de operación necesaria para dibujar el sprite, objeto 3d, o combinaciones de estos, sin importar el número de cálculos o funciones propias que usemos para ello. Nos despreocupamos.
*/

glEndList();

En la lista queda guardada solo la información necesaria y optimizada para ser enviada a la tarjeta gráfica cuando queramos dibujar.  Lógicamente cuantos menos hayan más rápido irá, por lo que siempre es mejor hacer grupos que usen la misma textura.

Con glTranslate le decimos donde queremos situarlo antes de llamar a la lista.

Código [Seleccionar] Expand


glTranslatef(200.0, 20.0, 0.0);
glCallList(Arbol);

glTranslatef(100.0, 50.0, 0.0);
glCallList(Arbol);
...


Me gusta OpenGL  B)  

 Solo por la jovencita en camisetita ajustadita valdrá la pena.  (uoh)

(Acabo de incrementar la visita a ese foro en un 300%)  :P  

 Creo que podría ser correcto pero no se si con la suficiente precisión. Supongamos que el juego corre a 100pfs, cada pasada tardará 10 milésimas aprox.

unframe = 10.0 / 1000 = 0.01;
fps = 1.0 / unframe = 100;

o lo que es lo mismo  1000.0 / 10 = 100 fps;

hasta aquí bien, el problema es que seguramente cada vez te va a dar un resultado diferente en milésimas, 8, 9, 10, 11, 12.., de manera que si el valor es por ejemplo 8 aumenta en 25 los fps:

fps = 1000.0 / 8 = 125;

Todas estas variaciones vistas en pantalla serán un baile de cifras a una velocidad imposible de leer y que no te va a ser muy útil. Lo mejor es llevar un contador de frames,y visualizarlo cada vez que transcurre un segundo, te pongo un ejemplo sencillo aunque existen formas de hacerlo mejor.

Código [Seleccionar] Expand


void fps()
{
static DWORD OldTime=timeGetTime();
static DWORD FrameCount=0;
static DWORD fps=75;

DWORD NewTime = timeGetTime();

if (NewTime - OldTime >= 1000) {

  fps = FrameCount;

  FrameCount=0;

  OldTime = NewTime;
  }

FrameCount++;

// Visualizar fps
}


 Quizás es una opción del compilador oculta por ahí, que tienes que activar.

Como alternativa prueba a mostrarla dinamicamente con AllocConsole, al menos tiene la ventaja de que la puedes crear y destruir cuando quieras. Te pongo un ejemplo de uso sencillo, aunque tendrás que consultar la ayuda de referencia para saber si te vale para lo que tu quieres.

Código [Seleccionar] Expand


void HolaConsola()
{
HANDLE Consola;

if (!AllocConsole()) return;

if ( (Consola=GetStdHandle(STD_OUTPUT_HANDLE)) ==INVALID_HANDLE_VALUE) return;

WriteConsole(Consola,"Hola windows", strlen("Hola windows"), NULL, NULL);
}


void AdiosConsola()
{
FreeConsole();
}


 De repente me han vuelto las ganas de hacer el juego de la mili. (ole)

Crítica: el casco parece a veces una gorra con la visera hacia atrás.

 Con LockRect estás trabajando a muy bajo nivel, nunca asumas que lo que te funciona en una circustancia lo vaya a hacer en otras o en otro ordenador.

En la forma en que obtienes los pixels te aconsejaría que no accedas a la superficie o textura con el puntero "ptr" una vez desbloqueada.

Intenta comprobar siempre que el metodo han pasado correctamente y usa el pitch para obtener el ancho real de la textura o surface.

Crea la textura con D3DPOOL_MANAGED, seguramente puedas hacer cientos de lecturas sin perder nada de velocidad, aunque como ya he dicho antes, a veces no se puede saber nada con seguridad sin antes probarlo en montones de ordenadores.

Te pongo mi versión para leer un pixel asumiendo que el color es de 4 bytes (DWORD), pruebala y compara el rendimiento con la tuya si quieres, aunque supongo que no diferirá mucho en velocidad.

Código [Seleccionar] Expand


void GetPixelTextura(LPDIRECT3DTEXTURE9 &textura, int px, int py, DWORD *Color)
{
D3DLOCKED_RECT rect;
if (SUCCEEDED( textura->LockRect(0, &rect, NULL, 0) ) ) {
     *Color = *((DWORD *)rect.pBits + (rect.Pitch>>2) * py + px);
     textura->UnlockRect(0);
     }
}


 Si te desesperas intentando hacer algo avanzado, yo creo que podrías practicar con algo asequible como un juego parchís o de la oca en gdi, que tenga opciones para jugar varios jugadores y que pueda jugar tambien la máquina.

No es coña, me parece un reto asequible y a la vez lo suficientemente complejo como para ir cojiendo el tranquillo a la programación gráfica y de videojuegos en general.

Y al mismo tiempo y a parte te vas peleando con todo cristo de DirectXs, OpenGL, SDLs, intentando iniciarlos y hacer cosas sencillas como limpiar el fondo de un color, o dibujar algo.

 ¿Y por qué no lo pasas a la 6?, creo que no hay mucha diferencia con la 5 y te podría resolver de un plumazo el problema.

Al menos tiene un IDirectDrawGammaControl y no me extrañaría que sea un parche para resolver tu (el de todos) problema cuando vieron que se cepillaba los perfiles esos.

 Imagino que lo chungo está en enlazar las conversaciones con la programación y los gráficos, y saber si va primero la gallina o el huevo.

Se me ocurre escribir los diálogos en archivos y que el programa los lea y mueva la boca de los muñecos el tiempo que sea necesario mientras aparecen subtitulados. Cuando está acabado se dobla como una peli y los diálogos se guardan en archivos de audio que se sustituyen por los de texto y en lugar de leerse se reproducen o ambos al mismo tiempo.

No se, a ver si sale un experto que os pueda ayudar.

En cuanto a los guiones no os preocupéis, peores que los de la mayoría de películas y series que echan por la tele no lo vais a hacer.

Un saludo.

[QUOTE]

 pequeño (gran) error que cometí en el ejemplo de DrawPrimitive, asumí que el ultimo parámetro indicaba el número de vertices pero en realidad lo que hay que poner es el número de primitivas y como son 2 triangulos necesarios para dibujar el QUAD el valor es 2, no 4.

Código [Seleccionar] Expand


lpDevice->DrawPrimitive( D3DPT_TRIANGLESTRIP, n*4, 2);

El 1º párametro indica la forma en que se dibujan los triángulos, y el 2º la posición del primer vertice del sprite en la lista que hemos establecido en SetStreamSource.

QUOTE (Lord Trancos 2)

Creo q si ordena él ganaria rendimiento, pero si desactiva el z-buffer eso podria provocar que aumentará el overdraw, ¿no? [/quote] Cierto, no siempre interesa desactivar el z-buffer. Si se dibujan cientos de objetos pequeños va a ser más rápido y sencillo usar z-buffer que clasificarlos uno mismo. Si se dibujan muchos objetos unos detras de otros como los arboles de una carretera o una serie de muros mejor ordenarlos de atras hacia delante y dibujar usando z-buffer, todo lo que tapen los primeros objetos no lo tendra que dibujar la tarjeta en los pixels de los dibujos restantes que pueden ser millones de calculos entre texturas, luces, efectos, niebla, etc. Tambien se puede comprobar el test pero desactivar la escritura, para dibujar cristales, humo, luces, y otros efectos traslúcidos, siendo esto lo último que se dibuje. Código [Seleccionar] Expand lpDevice->SetRenderState( D3DRS_ZWRITEENABLE,  FALSE); a veces puede interesar hacer que el test siempre pase y que tape a dibujos posteriores, por ejemplo para un simulador de avión mejor dibujar primero la cabina y luego la escena, ahorrando a la tarjeta el trabajo de tener comprobar el test de la cabina y de calcular el color de todos los pixels que esten ocultos por ella. Código [Seleccionar] Expand lpDevice->SetRenderState( D3DRS_ZFUNC,  D3DCMP_ALWAYS); // dibuja siempre DibujarCabina(); lpDevice->SetRenderState( D3DRS_ZFUNC,  D3DCMP_LESS); // dibuja si está mas cerca DibujarEscenario(); yo creo que lo mejor en el caso de cachorro es desactivar el z-buffer para el fondo (dibujandolo primero) si la pantalla tiene 800x600 se va a ahorrar 480000 comprobaciones, y lo dejaría activado para el resto y así evitar el coñazo de tener que ordenar constantemente, con darles una coordenada z es suficiente, además lo que pierdes al realizar la comprobación luego lo ganas al ahorrar el cálculo de los pixels de los objetos que queden ocultos, de hecho ganaría en velocidad si ordenase los sprites de atras a adelante con el z-buffer activado. #75 General Programadores / Gcc Y Ensamblador 25 de Octubre de 2005, 12:43:09 PM  He desempolvado un viejo libro que tenía por ahí, y lo hace igual que tu, pero dice que para los datos hay que especificar no se qué de un segmento..... Ya que los datos no se transfieren automáticamente en una zona de memoria fija, se ha de especificar la dirección del buffer en la pareja de registros ES:BX. Como siempre, ES acoge la dirección de segmento del buffer y BX la dirección de offset. sí..., si va a ser eso  B)   Páginas 1 ... 3 4 5 6 7 ... 18 Ayuda | Ir Arriba ▲ SMF 2.1.4 | SMF © 2013, Simple Machines Síguenos en Aviso legal Tratamiento de datos Seguridad Cookies © 2024 Stratos Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad. Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante. Muchísimas gracias.

 He desempolvado un viejo libro que tenía por ahí, y lo hace igual que tu, pero dice que para los datos hay que especificar no se qué de un segmento.....

Ya que los datos no se transfieren automáticamente en una zona de memoria fija, se ha de especificar la dirección del buffer en la pareja de registros ES:BX. Como siempre, ES acoge la dirección de segmento del buffer y BX la dirección de offset.

sí..., si va a ser eso  B)