El que es un caso especial es el primero, no el segundo.

En el primero el compilador deduce el tipo y no necesitas especificarlo como parámetro de plantilla, en el segundo no.

Cuando ande más despejado intentaré pensar en un explicación más currada, pero muchas veces no sé de antemano si el compilador deduce o no y es cuestión de probarlo :ojo:.

La duda que tengo yo es si todos los compiladores hacen las mismas deducciones(cosa que no creo), por lo que puede ser mejor especificarlo siempre(salvo en casos muy claros, tras hacer pruebas en distintos compiladores)




                               

                                Jeje, menudo post más raro hemos montado, mitad de programadores, mitad de artistas... :lengua:
                               

                                Los 2 libros que dice Nelo son los que yo recomiendo. Pasa del Beginning D3D :lengua:

Yo tengo el Special Effects y me parece el mejor libro para aprender DX... y además efectos especiales muy wapos.

EL Real Time Tricks es un poco más avanzado pero explica muy bien DX y es la mejor referencia para aprender shaders

Si tienes alguna pregunta déjala por aquí...
                               

                                Como bien dices usa una técnica para usar modelos de baja poligonalización con gran detalle.

Se basa en crear un modelo de muy muy alta poligonalización offline, sacar su mapa de normales y aplicarlo a uno de pocos polígonos.

Una cosa whopper de esta técnica es que sirve tanto para tarjetas "antiguas", soporte dx7 con el DotProduct3 bumpmapping, como para las super modernas ,dx9 y displacememnte mapping. La 2 técnicas usan el mismo mapa de normales.

Los modelos quedan muy wapos, muy bien iluminados, pero un poco poligonales en la silueta.

Pensad que el motor del DOOM3 está todo pensado para usar con otras técnicas. Como usa stencil shadows, no puede ampliar mucho el nº de polígonos o se va de madre.

En las listas de GDAlgorithms se han diseccionado a fondo las técnicas del DOOM3, lo que pasa es que es un motor más o menos específico para un juego de ese estilo.

En el gems3 hay una gema sobre ésto, escrita por nuestro vecino Oscar Blasco:Curvature Simulation Using Normal Maps
                               

                                Fué un juego pseudo3d a base de voxels que tuvo buena aceptación y muy buenas críticas.

La empresa desarrolladora es belga(suponiendo que son los mismos que los del Outcast2)


                               

                                Con Tn&L lo que hay que hacer es NO tocar los vertex buffers, nada de algoritmos de LOD a base de CPU.

En el libro GameProgrammingGems2 viene un estupendo resúmen y comparativa de distintos algoritmos de LOD para TN&L, que se basan generalmente en tener el modelo en un vertexBuffer al máximo detalle y crear distintas versiones a bajo de detalle en IndexBuffers, dibujando usando el IndexBuffer correspondiente al LOD adecuado. Ésto es *muy* rápido.

Para no hacerme caso :ojo:(o intentar construir los IndexBuffers del LOD offline,supongo) buscad un paper de Stan Melax(le nombro de cabeza), programador de BioWare sobre un algoritmo de LOD continuo. También están Hoppe y Bloom en éstos temas...
                               

                                No.                                

                                Jorl, la de programadores que daríamos nuestra alma al diablo por un grafista... :ojo:

O es por tema de licencias?
                               

                                En http://nehe.gamedev.net/ tienes todo sobre OpenGl, junto con http://www.opengl.org y las webs de NVIDIA y ATI para sus extensiones propias...

Yo soy de DX(y de Kas Naranja :riendo: ) y todo esto me parece un suplicio, pero tú verás...

OFFTOPIC: Cuando he visto tu nicl, me he ido rápidamente a flipcode, a ver el profile del que postea ahí como Altair... intuyo que NO sois el mismo :ojo:, o llamándote Jarkko Lempiäinen hablas muy bien español :ojo:                                

                                Dios!, estás vivo! :lengua:

Tranquilo, tienes razón te metiste mucha presión con lo de las fotos y lo que se hace por hobby, si no disfrutas malo.

Todos andamos igual, cuando estamos con ganas y haciendo cosas wapas... o la novia, los estudios,etc, etc... despacito y sin agobios.

Eso sí, seguimos esperando las imágenes :lengua: y las discusiones técnicas, me da que el multithreading que usas te empeora en vez de mejorar y te complica muchísimo el código, pero ya lo habrás evaluado tú...
                               

                                Al que escribió originalmente... Creo que te equivocas... lo menos acaba y haz el módulo de FP.

Respecto a los lenguajes... En la Complutense empezamos con Pascal... y me parece óptimo. Después ya damos C++, Java, VB... Los profesores son lo peor en todos los lados... se salvan un 10%(tirando alto :lengua:). Pero lo primero es aprender a programar, no los detalles de un lenguaje concreto. Aprender a pensar, modularizar, escribir clarito y bueno algoritmos no depende de usar C++. Empezar a aprender a programar con C... muy duro. Miles de detalles que te apartarán de lo que realmente hay que aprender.

Programación Orientada a Objetos?, lo mismo, entiende lo que es y sabrás aplicarla a los lenguajes.

Aunque no os parezca, soy un freaky de C++, POO, STL, Design Patterns...hasta componentes ando ahora investigando. Y sigo encantado de aprender las cosas claras. Cuando he pasado a usar Java, sabiendo POO ha sido todo muy fácil(por cierto, gran lenguaje... para aplicaciones que no sean en tiempo real).

Bueno, resumiendo:
 
       -Hay que tener una base teórica, a base de leer muchos libros y gracias a la universidad. Más importante los libros. La universidad suele enseñarte qué es lo que debes aprender, más que enseñartelo...

       -Para empezar a programar, mejor un lenguaje claro y sencillo. Aritmética de punteros?, puaff. Poco vas a usarla en un programa :lengua:. Una vez aprendas los fundamentos de cada cosa, ya te expecializas... .Y lo que aprendas "con" un lenguaje, te sirva para muchos otros... Lo que queda no es la implementación, es el diseño...
                               

                                No recuerdo ya casi nada del modo 13h, pero juraría que sin un extendedor de memoria(DOS4GW??) no podías asignar 64000(320*200), busca algún tutorial por la red, pero prueba a poner justo uno menos 63999... Qué tiempos...prefiero los nuevos tiempo :lengua:
                               

                                Me lo comentó Daventry anoche :triste:

No se sabe nada del como?,por qué?. Los familiares lo daban como normal... algo tendría
                               

                                Me lo comentó Daventry anoche :triste:

No se sabe nada del como?,por qué?. Los familiares lo daban como normal... algo tendría
                               

                                Lo mismo digo :ojo:

Me apunte a la última beta, puede que sea más tarde que el 15 de Junio, pero será muy estable... y seguramente ya tenga una GF4 Ti4200...(la mejor en calidad precio de fijo)