Bueno, esto es un error en un código muy sencillo, del que me acabo de dar cuenta. Resulta que quiero multiplicar un número en coma flotante por 10 y asignarselo a un entero. Algo en teoría trivial, pero que requiere dos lineas de código para que salga el resultado que yo quiero:

Código [Seleccionar] Expand



int entero;

float flotante,angulo=-179.9;



entero=angulo*10; //Resultado de esta operación entero=-1798



flotante=angulo*10;

entero=flotante;  //Resultado de esta operación entero=-1799



La línea de arriba es la que yo ponía antes de detectar el error, y como veis, se pierde una décima en la operación. Las líneas de abajo funcionan bien.

Explicación:

Código [Seleccionar] Expand



entero=angulo*10;

  fld     dword ptr [angulo] // ST0 = -1.79899993896484375e+0002

  fmul  dword ptr [__real@41200000]   // numero 10.0

  call    __ftol

  mov  dword ptr [entero],eax





flotante=angulo*10;

  fld     dword ptr [angulo] // ST0 = -1.79899993896484375e+0002

  fmul  dword ptr [__real@41200000]   // numero 10.0

  fstp   dword ptr [flotante]  // flotante=-1799.0



entero=flotante;

  fld     dword ptr [flotante] // ST0 = -1.79900000000000000e+0003

  call    __ftol

  mov  dword ptr [entero],eax



Como veis, el error se produce porque la instrucción FLD carga el número -1.79899993896484375e+0002 en el coprocesador, en vez de -1799.0 y luego al pasarlo a entero con la función FISTP (que hay dentro de __ftol) se recortan los decimales y se jode una decima del número. Por defecto el copro siempre "recorta" en vez de "redondear".
En las instrucciones de abajo el error se corrige porque la instrucción FSTP redondea el número a -1799.  INEXPLICABLEMENTE  :o en la siguiente instrucción FLD se carga ST0 = -1.79900000000000000e+0003

Alguien me puede decir por qué en la primera operación FLD se carga ST0 = -1.79899993896484375e+0002 y en la segunda ST0 = -1.79900000000000000e+0003 ????

Tambien me gustaría saber si este código funciona igual en un K7, yo tengo un PIII. Solo teneis que copiar las 5 líneas en C para probarlo...

gracias y perdón por el tocho
un saludo                                

                                Bueno, esto es una cosa que no habia tenido nunca la necesidad de utilizar. Me refiero a realizar operaciones con el coprocesador matemático y a la vez, en el mismo bucle,  tener unas variables en registros mmx que se van incrementando.

Lo he probado dejando los registros MM0 y MM7 sin usar y funciona perfectamente. En el MM0 (ó ST) se carga el número en coma flotante y al hacerlo se machaca el valor del MM7 ó ST(7) debido al desplazamiento de todos los registros. No he notado tampoco ninguna diferencia de velocidad en los cálculos al mezclar los dos tipos de instrucciónes.

¿Sabeis algo al respecto? ¿Algúna web donde se comente la cuestión? Recuerdo que cuando aparecieron las instrucciones mmx se habló algo de este tema, pero no me he topado con  ninguna discusión técnica sobre el asunto...

un saludo                                

                                Hola,
Yo hasta ahora hacia el backface culling en 2D, pero voy a implementarlo en 3D para eliminar los poligonos desde el principio.

He buscado sobre el tema y las dos webs más claras son:

http://www.cubic.org/~submissive/sourcerer...er/backcull.htm

http://www.gamedev.net/reference/articles/...article1088.asp

Lo que he probado hasta ahora no me funciona del todo bien o es que no lo tengo del todo claro... Según decís es algún otro post (y tambien pensaba yo) basta con hacer un dot product entre el vector Z de la cámara y la normal del triángulo, pero tampoco me acaba de funcionar.

Según las webs anteriores hay que hacer dos operaciones por cada triángulo, una con un punto perteneciente al triángulo (un vertice) y otra con la cámara, y eso es lo que no entiendo.

¿Podriais indicarme algún otro tutorial o explicarme como lo haceis vosotros?

un saludo y gracias                                

                                Hola,
Lo he visto en algunas demos, me gustaria saber cómo se inician las superficies de DX para que la ventana de visualización sea más pequeña que la pantalla. Por ejemplo, inicializar el modo 640x480 y luego que la ventana del programa sea de 400x400 y que aparezca centrada.
Lo he intentado hacer, pero la ventana se me posiciona siempre en 0,0 y no me deja moverla :-?

un saludo                                

                                Yo utilizo lo siguiente, meto los valores del zoom en la matriz de proyección:

D3DMATRIX zoom = D3DMATRIX(1*m_camara->zoom,0,0,0
   ,0,1*m_camara->zoom,0,0,0,0, 1*m_camara->zoom,0,0,0,0,1);
D3DMath_MatrixMultiply(m_matProjec, m_matProjec,zoom);

.
Lo que pasa con eso es que al calcular el frustum, cuando el zoom es superior a 1.0 desaparece toda la imagen, o sea que se sale toda del frustum.

Esto me lleva a la siguiente cuestión, resulta que siempre me habia pasado que al renderizar con DX me desaparecia la imagen al aumentar el zoom más de 1.0, ¿quiere esto decir que DX implementa el frustum a nivel de triangulos internamente?
Usaba esto con DX7:

m_pd3dDeviceActual->DrawIndexedPrimitive( D3DPT_TRIANGLELIST
   ,D3DFVF_XYZ|D3DFVF_NORMAL|D3DFVF_DIFFUSE|D3DFVF_TEX0|D3DFVF_TEX1
   ,m_p3D, m_nump, m_indice, m_numindices,0);

un saludo


[ Este Mensaje fue editado por: fiero el 2002-06-08 22:35 ]                                

                                Hola,
pues eso, para calcular los triángulos de un objeto que están dentro del frustum, puede darse el caso de que los tres vértices estén fuera de éste y sin embargo parte del triángulo se vé en una esquina de la pantalla. ¿Cómo calcular ésto rápicamente? a mi se me ocurre alguna ecuación con las aristas, pero no es plan calcular si alguna arista pasa por el frustum, sería muy lento. O también mirar los máximos y mínimos del triángulo y comprobar el cubo que lo envuelve, pero tampoco parece apropiado.

Puede parecer descabellado discriminar a nivel de triángulos, pero viendo que te ahorras las transformaciones de vértices y las comprobaciónes de si dentro o fuera de pantalla (a nivel 2D), creo que se aligera el código. Estoy hablando siempre de un motor SOLO SOFTWARE.

un saludo                                

                                Hola, estoy haciendo una función para optimizar mallas. Cuando borro un vértice, tengo que formar triángulos con los vértices que antes formaban triángulos con ese vértice, y que ahora quedan "desunidos". Mi problema es que no encuentro ningún método que funcione correctamente en todos los casos, siempre encuentro un caso en que al formar los nuevos triángulos alguno se forma "al revés" o se monta encima de los demás en la malla.
Conoceis algún método o alguna web con tutoriales sobre estos asuntos?

un saludo                                

                                Pues eso, si sabeis como se puede esperar el retrazo vertical, para sincronizar el refresco de la pantalla, con las funciones de la GDI o MFC.

He implementado las superficies con MFC en vez de con DX y al ejecutar CDC:BitBlt(...) me gustaria esperar el retrazo para que no se vean parpadeos (aunque me bajen los FPS).

un saludo                                

                                Hola,
yo ahora utilizo el GetDisplayMode de DirectX para recoger los bpp de pantalla. Ahora quiero hacerlo sin utilizar DirectX y no encuentro la forma de saber cuando la pantalla está a 15 ó 16 bits, he usado esto:

if(EnumDisplaySettings(NULL,ENUM_CURRENT_SETTINGS,&devmode))
{
bpp=devmode.dmBitsPerPel;
}

pero siempre da 16, aunque la tarjeta sólo acepte el modo de 15 bits.

Sabeis la forma de averiguar esto mediante las MFC o funciones de windows?

un saludo                                

                                Hola,
resulta que me preguntaba como podia ser que no se puedieran capturar las pantallas de un video .MOV visto con el visor de Quick Time. He hecho un pequeño programilla para probar, capturando con directX la surface primaria y escribiendo los datos en un bmp.

Bueno, pues la prueba no ha resultado, se ve todo negro en el bmp. Todas las demás cosas que tenga en el escritorio las captura perfectamente. Pero cual es mi sorpresa, cuando teniendo el QT minimizado se proyecta la pantalla del vídeo dentro del bmp, cuando muevo la ventana por donde estaba el visor del QT.
Resulta que me ha capturado un bmp con todos los pixels con el valor RGB(16,32,16) y el QT muestra la pantalla del video sólo en los pixeles de la pantalla que tienen este color (aunque esté minimizado).

¿Sabeis como se las arregla para que no se pueda capturar la ventana?, parece como si las imagenes del video se imprimieran en un overlay o algo asi, no se me ocurre como...

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,
Pues resulta que este problema no lo tenía cuando empecé la aplicación y ahora resulta que al hacer pantalla completa, volver al escritorio, y luego regresar otra ver al programa, me pierde la surface al intentar hacer un Lock().

Yo renderizo por software, con funciones relleno de polígonos propias, por eso, utilizo DX5, ya que sólo utilizo algunas funciones de DirectDraw.

Al hacer el Lock(), después de regresar del escritorio, me devuelve DDERR_SURFACELOST y al hacer Restore() me devuelve DDERR_IMPLICITLYCREATED. Será porque la creo con m_pSuperficieFrontal->GetAttachedSurface(&ddsCaps,&m_pSuperficiePosterior);

Mi preguntas son, ¿que se hace en el caso de perder una superficie así y no poder restaurarla? ¿la creo otra vez?

un saludo
                               

                                Hola a todos, vamos a estrenar esto

Pues eso, que estoy haciendo un ActiveX y hasta ahora solo lo desarrollo para explorer. Cuando he visto la pagina de desarrolladores de componentes para Netscape he flipao de lo complicado que era hacer rular un componente con el netscape, hay que hacer un nuevo proyecto en visual C, con la sdk de netscape, en fin, un lio....

Hace tiempo oí que existia un plugin para netscape que hacia funcionar los componentes activeX (*.ocx) igual que con el explorer, sabeis algo de eso??

un saludo