[Juan Mellado]
en un 386 (las tablas de pentium no las tengo a mano):

lodsw --- 5 ciclos

mov ax,word ptr[esi] --- 2 ciclos
add esi,2 --- 2 ciclos

stosw --- 4 ciclos

mov word ptr[esi],ax --- 2 ciclos
add edi,2 --- 2 ciclos

A mi me parece que tanto monta, monta tanto. Incluso leí en un manual de Intel que con un pentium y posterior es más rápido hacer "dec ecx", "jnz etiqueta"  que un "loop etiqueta" como antiguamente, o sea, que estan optimizando las instrucciones sueltas y las que hacen varias cosas a la vez internamente ejecutan las instrucciones sencillas.

[Emotion]
Coño, no te pierdes una!! :riendo:

un saludo                                

                                Si, como dice Juan Mellado, me parece que para hacer la comprobación de los pixels negros no merece la pena hacerlo de 2 en 2, demasiadas comprobaciones...

prueba sin nada a ver:

__asm    {        mov eax, rSrc.left        shl eax,1        add [sPtr], eax //sPtr= sPtr + (rSrc.top * sPitch)+(rSrc.left * bytesPerPixel)        mov eax, lDestX        shl eax,1        add [dPtr], eax //dPtr= dPtr + (lDestY * dPitch)+(lDestX * bytesPerPixel)        mov ebx, rSrc.bottom //Alto = bottom - top        sub ebx, rSrc.top //ebx = Alto        mov eax, rSrc.right        sub eax, rSrc.left        mov edx, eax        shl eax,1        sub [sPitch], eax //sPitch = sPitch - (ancho*bytesPerPixel)        sub [dPitch], eax //dPitch = dPitch - (ancho*bytesPerPixel)        //edx ancho        mov edi,dPtr        mov esi,sPtr        mov ecx, edx    linea:        mov ax,word ptr[esi]        or ax,ax        jz next        mov word ptr[edi],ax    next:        add esi,2        add edi,2        dec ecx        jnz linea        add edi,dPitch        add esi,sPitch        mov ecx, edx //ecx = edx = ancho en pixels        dec ebx        jnz linea    }

... y haciendo que siempre salte al mismo sitio, a "linea", puede que corra mas...

un saludo

[ Este Mensaje fue editado por: fiero el 2002-05-07 12:18 ]                                

                                Es que necesito que sean fotos de 24 bits, y aunque las parta, como se ven todos los texels se pierde toda la caché de frame a frame, al pasar por todas las texturas...

Creo que es inevitable...

un saludo                                

                                Bueno, ya he hecho las pruebas. He dividido la esfera en 32 cachos y la textura empleada en sus respectivos 32 bmp.
Resultados renderizado de 1 esfera:

1 textura de 364 x 364 pixels, 62 FPS
1 textura de 2912 x 1456 pixels, 45 FPS
32 texturas de 364 x 364 pixels, 43 FPS

Los resultados que interesan son los dos de abajo, ya que lo que quiero es renderizar una esfera con una textura grande (de 2912x1456 por ejemplo). La conclusión que saco de todo esto es que da igual el tamaño de la textura empleado en este caso, ya que poner una grande no agiliza la caché y con texturas más pequeñas también se pierde la caché al ir cambiando de una a otra.

Estoy hablando en el caso de que se visualicen todos los texels de la textura. Otra cosa muy diferente es que se visualicen solamente un porcentaje pequeño de los texels, entonces vendria muy bien implementar mipmaping como dice Ithaqua. Pero en el caso de renderizar el cielo, en el que el objeto siempre es del mismo tamaño creo que no hay na que hacer....

Hola Emotion: Resulta que la textura de 2912x1456 ocupa 12 megas, partir eso en cuadraditos de 32k me parece inviable. Además segun el test, esto resultaria tremendamente pesado a nivel de cálculos, ya que el número de objetos aumentaria considerablemente. Fíjate que solo con aumentar de 1 a 32 objetos en el render ya me ha bajado 2 FPS.

saludos                                

                                Hola Ithaqua,
el SetCursorPos sí genera un mensaje WM_MOUSEMOVE, pero aunque se ponga este código en respuesta a ese mensaje, la segunda llamada no cumple ninguna condición para que se vuelva a llamar a SetCursorPos, por lo que no hay riesgo de bucle infinito.

un saludo                                

                                si claro, con eso se aceleraria todo el render, ya que los objetos lejanos pillarian texturillas pequeñas. Lo que pasa es que en este caso, para renderizar un cielo, la semiesfera es siempre del mismo tamaño, no le afecta la posición de la cámara (el movimiento del  cielo es inapreciable), así que la única forma es partirlo en cachos, creo...

saludos                                

                                Entiendo..., entonces lo mejor va a ser meter las texturas más pequeñas como hacen las aceleradoras y ganar FPS con eso.

Es que lo de las texturas grandes era para poner panoramas, como el cielo por ejemplo, poniendo una gran semiesfera encima de la escena, con una textura grande de cielo. Así que tendré que partir la semiesfera en trocitos con texturas mas petites.

Lo del mipmaping no lo he implementado todavia, ya veremos en un futuro, con el filtro bilinear se ve bastante bien por ahora...

gracias y un saludo
                               

                                Hola,
Yo no utilizo ninguna función de Directx ni de las aceleradoras, solo ensamblador, así que mi problema creo que se debe a los accesos a memoria. El problema es que guardo las texturas un un buffer de memoria, pero a la hora de renderizar, cuanto mayor es la textura más lenta es la renderización. Un ejemplo con una esfera:

Textura de 512x256:   43 FPS
Textura de 4064x2032: 31 FPS

La alineación de los buffers donde guardo las texturas no tiene que ver, tambien lo he probado.

Lo que me imagino es que los accesos a memoria ram serán más rápidos cuando las posiciones son más cercanas, y que si la textura es pequeña se la cargará el sistema en caché, si este es el problema no se me ocurre ninguna forma de arreglarlo, ley de vida :triste:

un saludo

[ Este Mensaje fue editado por: fiero el 2002-05-04 18:08 ]                                

                                Hola,
todo lo que se ha dicho aqui es correcto, simplemente tienes que seguir esa norma, si tienes que leer algo lo pones en memoria de sistema, si solo vas a escribir, pues puedes usar memoria de video.

Para los sprites de los personajes, si vas a utilizar tus propias funciones en ensamblador ("a mano" como tu dices) para pasarlos a la superficie de animación los metes en memoria de sistema, ya que realizas la operación (leer sprite)->(escribir en superficie). Sin embargo si utilizas BitBlt puedes poner los sprites en memoria de video, ya que se realiza la copia por hardware directamente (VideoSprites)->(VideoSuperficie), claro, esto solo si la superficie de destino es tambien en memoria de video. Si la superficie de destino está en sistema, todo en memoria de sistema.

Cuando yo programaba en VESA, en msdos, un simple MOV desde video a un registro era 10 veces mas lento que un MOV de un registro a memoria de video, con las antiguas tarjetas PCI, ahora con las AGP se ha mejorado la lectura, pero no mucho.

saludos                                

                                Hola,
Bueno, al final siempre resulta que hay una solución facil, esto puesto en tu bucle principal de animación funciona bastante bien:

POINT pos;    int moverCursor=0,xPantalla=1024,yPantalla=768;    GetCursorPos(&pos);    if(pos.x==xPantalla-1)    {        pos.x=1;        moverCursor=1;    }    else if(pos.x==0)    {        pos.x=xPantalla-2;        moverCursor=1;    }    if(pos.y==yPantalla-1)    {        pos.y=1;        moverCursor=1;    }    else if(pos.y==0)    {        pos.y=yPantalla-2;        moverCursor=1;    }    if(moverCursor) SetCursorPos(pos.x,pos.y);

un saludo                                

                                Hola,
Lo que quiere Dracula no se puede resolver con la posición actual del cursor, con los mensajes WM_MOUSEMOVE, etc...

Si por ejemplo estamos en una pantalla de 800x600 y tenemos el ratón en la posición 799,400 (o sea a la derecha del todo) y en ese momento movemos el ratón a la derecha, el cursor no se va a mover ya que está en el límite de pantalla, sin embargo queremos detectar ese caso para situar el cursor en la posición 0+DESPLAZAMIENTOX,400 de la pantalla. Movimiento tipo 3DMAX cuando giras o mueves objetos.

Los mensajes WM_MOUSEMOVE no se activan, ya que el cursor no se ha movido, hay que detectar el movimiento antes de eso, o inventarse algun truquillo...

saludos                                

                                No lo entiendo, yo pasé de Qbasic a C y me costó cojerlo...digamos 1 año, hasta que cojes soltura y puedes hacer cualquier cosa.

¿Tu lo has aprendido en 1 dia?

creo que no valgo para esto....                                

                                Hola Dracula
parece que definitivamente a mi no me entra en modo hardware con Merlin:

W2000, PIII 384M 850MHz, ATI RAGE MOVILITY-M1 16M
Metodo1: 2.70 FPS
Merodo2: 2.70 FPS

Debug:

INICIO Características del Device
HAL (sw vp): ATI RAGE MOBILITY-M1 AGP (Spanish)  (D16)
FullScreenGamma OK
CanCalibrateGamma NO DISPONIBLE
Utilizando formato por defecto para las texturas A8R8G8B8
NO Soporta compresión DXT1
NO Soporta compresión DXT2
NO Soporta compresión DXT3
NO Soporta compresión DXT4
NO Soporta compresión DXT5
Escritorio: Ancho=1024 Alto=768
FIN Características del Device

_Grey: aqui hay de esos: http://maps.jpl.nasa.gov/

un saludo


[ Este Mensaje fue editado por: fiero el 2002-05-03 21:31 ]                                

                                Hola,
Me da el siguiente error al iniciar, justo después de ponerse en pantalla completa:

Error in program.
System Error: ERROR 165. [..000. & Direct HAL] Failed to create a D3D Device from BackBuffer Surface

Tengo:
Portatil ACER Travelmate 529 PIII 850
RAM 384MB
Video: ATI RAGE MOBILITY-M1 16MB
Directx 8.1 instaladas

un saludo                                

                                o sea, si yo me hago un descompresor de mp3 en ensamblador, ¿lo puedo usar en mis programas?, o dicho de otra forma, que decis que está protegido por copyright, el formato o el plugin para descomprimirlo....

un saludo