Los años anteriores hablaba más de cosas técnicas sobre los motores y plataformas que usaba. Lo que de verdad le gusta a él (y a mí :p).

Este año parecía un vendedor o evangelista. Le han debido dar un toque sobre lo que debía decir y como

Durante el 80% de la charla su lenguaje corporal era forzado, estilo vendedor, no era el suyo. Se ha tirado demasiado tiempo justificando la adquisición de ID y en general la charla era simplista. Lo dicho, le han dado órdenes "desde arriba".

En todo caso, quien tenga interés en su tecnología, que le eche un vistazo a las fichas de la charla de id en SIGGRAPH 2009:
http://s09.idav.ucdavis.edu/talks/05-JP_id_Tech_5_Challenges.pdf

Éste es el único enlace que he podido encontrar de la charla al completo. Si alguien conoce uno mejor que lo ponga.
http://gamevideos.1up.com/video/id/25917

Si en vez de verlo online os descargais los videos en definición "standard" son 250MB por cada una de las 5 partes.

Imagino que estará interesante, como siempre.

Si el escenario es muy detallado no hay mas narices que cargarlo todo al principio y limitar el tamaño total. Dado el nivel de detalle es inviable cargarlo sobre la marcha, Toca esperar mientras se carga el nivel al principio.

Si el escenario debe ser extenso, no vas a tener suficiente memoria y entonces debes limitar el nivel de detalle de manera que puedas ir cargando del disco las partes necesarias sobre la marcha. Dada la velocidad del disco duro o DVD no vas a poder cargar muchos datos por segundo.

Lo de arriba se aplica tanto a personajes como a escenarios. Lo que no esté cargado a tiempo pues no se dibuja en ese fotograma, por ejemplo.

En cuanto a como representar los escenarios, lo típico es tener todo subdividido en grandes bloques de, por decir algo, 40x40 metros, o una habitación o lo que sea que se ajuste a tu tipo de escenario. El rollo del batching y coste de hacer llamadas al API 3D. Dependerá de como funcione el motor que uses.

Tranquilo Mars, que no estás solo. Aquí especulan con lo util que sería poder usar los muñones con Natal  >:D
http://www.gameplayer.com.au/gp_documents/NatalGift.aspx

Y aquí tenéis a Miyamoto dando su opinión a Wired sobre Natal, el de Sony, WiiMote Plus y los mandos remotos en general:
http://www.wired.com/gamelife/2009/06/shigeru-miyamoto-interview/

joder, un virus que se incrusta en tu web, lo que me faltaba por ver. :S

Cientos de ellos.
De hecho, son los más comunes los que te enlazan a un PDF que utiliza un exploit reciente y te mete el troyano como si nada.

Bueno, el caso es que ahora entro y no me da ningún error, me alegro de que se haya solucionado rápido :)

Semi offtopic: Para ver PDFs en windows nada como el visor PDF de KDE: Okular
Os bajais el instalador de KDE para windows y marcáis el paquete KDEgraphics/Okular
http://www.winkde.org/pub/kde/ports/win32/installer/kdewin-installer-gui-latest.exe

No, no os va a llenar el disco duro de ficheritos raros.

Solamente voy a opinar sobre la tecnología del aparatejo, que los juegos dependerán de algo tan etéreo como la creatividad del desarrollador de turno.

A mi si me convence el cacharro y creo que la tecnología en si misma sí que es sólida, otra cosa es la implementación que hagan, y tengo la intuición de que lo harán bien.

Quien tenga curiosidad sobre como podría funcionar la cámara que se mire los papers de 3DV en http://www.3dvsystems.com/technology/tech.html#1  que por mucho que digan que no esta basado en su tecnología, el hardware no puede variar mucho al usar ambos el mismo principio: emitir una señal (en este caso infraroja) y analizar características del rebote. Si le dan suficiente precisión puede ser la repera. El nivel de iluminación no importa demasiado para esto porque no analizan la imagen del sensor RGB para construir la profundidad.

Lo bueno de ser un sistema específico para detectar humanos en interiores es que puedes asumir muchas cosas para ganar en fiabilidad. En mi barrio todos los humanos tienen cabeza, tronco y cuatro extremidades y todos tienen las articulaciones en el mismo sítio y con la misma limitación de movimientos. Yo sí que lo veo robusto, sobre todo porque simplificas muchísimo el problema de segmentación de la imagen gracias a la información de profundidad. Representar cada esqueleto con 48 articulaciones puede dar mucha inmersión de cara a simulaciones, espero que no sean chapuceros :)

Lo de detectar el sexo o la edad si que aparenta ser más complicado, pero aunque falle de vez en cuando no nos va a pasar nada por indicar nosotros el sexo en un menú.

Francamente, la única duda que tengo es que por motivos de coste lo dejen en una chapuza de escasa resolución, precisión o retardo. Nivel técnico seguro que tienen.

también le dará un empujón a opengl

Lo dudo, porque bajo windows usa Direct3D9 y porque el lenguaje de shaders que emplea es un dialecto de HLSL / Cg (lenguaje shader de nvidia casi idéntico a HLSL).

Por cierto, que requiere tarjetas con shader model 2.0
En principio está curioso, aunque me he limitado a instalarlo y probar las demos. Estoy mirando por encima la documentación.

Que sepa en linux y mac utiliza opengl (evidentemente) y en windows se puede utilizar ambos renderers, de todas formas habría que investigar en las opciones para estar seguros.

En cuanto a los shaders, es normal que el hlsl se parezca al cg, porque los de microsoft básicamente se copiaron del de nvidia, que fueron los primeros en dar el paso  :P

El cg de nvidia es indistintamente para opengl/direct3d, de hecho los shaders hechos en o3d tendran que tirar en ogl en mac y cia...

En windows O3D usa Direct3D9.

Los shaders que el desarrollador va a programar son en un lenguaje que es básicamente el de Direct3D luego no tendrán necesidad de aprender  nada sobre OpenGL. Un tutorial de javascript y otro de HLSL ya les permitirá hacer cosillas 3D en la web con O3D.

Las nuevas plataformas que quieran tener un API de aceleración 3D no van a verse más motivadas a elegir OpenGL a causa de O3D ya que no están relacionados en absoluto. Se puede implementar O3D sobre otros API. Las que ya usan OpenGL, pues eso, ya lo usaban de antes.

Por tanto, no veo yo que O3D de ningún empujón a OpenGL entre los desarrolladores de soft o hard.



Sobre lo de engordar el navegador, no me pronuncio. Cada dia que pasa se parecen más a un sistema operativo, ya veremos como acaba.

también le dará un empujón a opengl

Lo dudo, porque bajo windows usa Direct3D9 y porque el lenguaje de shaders que emplea es un dialecto de HLSL / Cg (lenguaje shader de nvidia casi idéntico a HLSL).

Por cierto, que requiere tarjetas con shader model 2.0
En principio está curioso, aunque me he limitado a instalarlo y probar las demos. Estoy mirando por encima la documentación.

Tei, as linkado el mismo artículo que había puesto yo pero enlazando a la copia en la web del autor en lugar del artículo en Gamasutra  :P

EDIT: Y si no es la web del autor da igual, es el mismo artículo de Thomas Jacobsen.

Te va a quedar mucho más bonito precalculando un par de animaciones resultonas y trucando la textura/rotación inicial, pero ya que te empeñas en usar físicas, te doy unas ideas. Vatya por delante que lo mejor es usar un motor de física existente, pero bueno.

Los motores de físicas funcionan de manera numérica, no analítica. Te pillas unas fórmulas muy sencillas para actualizar las posiciones y rotaciones y haces varios pequeños pasos de simulación por cada fotograma de animación.  Dar varios pasos con cálculos sencillos es más rápido, paralelizable y facil que hacer cálculos exactos que no cometen error pero son un coñazo. Básicamente reemplazas un movimiento o reacción complejo con pequeños pasos en línea recta, como cuando dibujas una spline o círculo mediante muchos segmentos pequeños, o calculas 37*B sumando B 37 veces en un bucle. Es feo, es impreciso, y es facil. Funciona.

Esto se reduce a hacer sumas y restas de posiciones, ángulos y velocidades cuando el objeto no interactúa con ningún otro.
Cuando un objeto colisiona con otro necesitas calcular los puntos/áreas  de contacto y aplicar determinadas reglas para reasignar las nuevas direcciones, posiciones, rotaciones y velocidades de los cuerpos que han interactuado (contactado).
Primero calculas que porcentaje del movimiento deberías haber hecho para que simplemente contactasen sin invadirse. Recalculas la posición haciendo solo ese movimiento. Ahora están en contacto y tienes un % de la energía (del movimiento) por usar ya que no has dado el paso completo pues invadía al otro cuerpo.
Calculas, con reglas que tu te definas, la nueva velocidad/rotación desde el punto de contacto, por unidad de tiempo. La aplicas en un mini paso reducida por el % de movimiento que te queda por hacer en este paso de simulación. Ya tienes la posición final para este fotograma.

Como mínimo necesitas dos copias del estado del mundo (posiciones y tal): uno es el último estado válido conocido (el pasado), que es simplemente el último estado calculado en el fotograma anterior, y otro es el que va a ser el presente cuando lo tengas bien calculado, y que lo vas a modificar, deshacer, repetir y engorrinarr varias veces en cada mini paso de simulación hasta que te salga correcto.

En tu caso es muy sencillo ya que tu mundo consta de un cubo y un plano infinito (la mesa). La colisión la detectas por la distancia entre el plano y el centro de la esfera cuyo radio es la mitad de la diagonal del cubo y centro el del cubo. Si la esfera colisiona detectas la distancia entre los vértices y el plano para saber si ha chocado una esquina, una arista o se desliza por una cara.

Según el tipo de colisión reaccionas de una manera u otra. Búscate reacciones que queden bien y a correr. SI quieres que sea realista te toca repasar física. Puedes salir del paso usando el producto entre la normal del plano y el movimiento del dado (coseno de su ángulo) y hacer palanca en el punto de contacto, por decir algo al azar.

Te recomiendo un tutorial muy majo sobre físicas en Gamasutra, el de los autores del juego Hitman. Es muy sencillo y bien explicado, usando métodos numéricos muy asequibles, en lugar de complejas fórmulas analíticas.
http://www.gamasutra.com/view/feature/2904/advanced_character_physics.php

[vertex]

Creo que tenía register combiners, no shaders. En todo caso, con la fixed pipeline puedes hacer bump map (dot3) sin recurrir a shaders, aunque claro está, no queda igual que un buen normal map con ellos.
DOOM III tenía varios codepaths uno de ellos usaba la fixed con dot3, otro register combiners y otro shader model (¿ 2.0 ?). Incluso creo recordar que podía funcionar sin ningún tipo de efecto de relieve, usando solamente la textura difusa (color) y quedaba feo. Con dot3 no quedaba del todo mal.

De wikipedia sobre la gf4:

It should be noted that older versions of the drivers (versions 53.xx for example) for the NV17 based GeForce4 MX and GeForce4 Go supported vertex shader model 1.1 via hardware assisted software emulation, however at some point this support was dropped completely. The newer drivers report that they support vertex shader model 1.1. On certain games which are able to take advantage of vertex shading, using the older drivers can actually result in a significant performance increase. Some games that require pixel and vertex shading will not run at all on these newer drivers.

[Que ahora comienza a haber jugadores que comienzan a gobernar]

joer, leo esto en el articulo ese de meristation

"Luego hay que entender que la política está llevada por individuos no jugadores. ¿Qué ocurre? Que ahora comienza a haber jugadores que comienzan a gobernar"

Dios MIO!!!!!!!!!!! ¿Estamos locos? ¿Que tiene que ver el tocino con la velocidad?

Teneis tantas ganas de pegar a Gonzo que os pasais un par de pueblos. Tiene mucha razon en eso que dice, y estaria bien pegar el parrafo que lo precedia para darle mas contexto.

El videojuego era una cosa de frikis y ahora esta enraigado en la sociedad. Esos señores que hacen las leyes, que empezaran a otorgar subvenciones dios sabe cuando, y que empiezan a darle respaldo al videojuego, quien sabe si incluso fiscalmente, son los mismos que antes les daban la espalda o incluso lo demonizaban. Hablamos de los que cortan el bacalao, los legisladores.
Ahora regalan Wiis, juegan al solitario de windows, y los mas jovenes (acabando la treintena) han jugado con consolas o tienen conocidos que lo hacen.
Esta socialmente aceptado, o en proceso.

No pensariais que el cambio se debe a que se han leido el blog de Nae o el de Exelweiss y les han abierto los ojos...

Hay que tener mala leche para atacar una metafora (jugadores) interpretando exprofeso la frase en sentido literal. Sabeis perfectamente a que se refiere.





(No se que le pasa a mi PC hoy que no me pone ni una tilde...)

Copiar software sí que es delito. Es lo que tiene no ser cultura, supongo :p

Si además posees cracks (los uses o no), estás cometiendo otro segundo delito. No así si te bajas el juego precrackeado, que solo cometes el de descarga, no el de reventar una proteción (ya lo hizo otro).

Dirty rects (ajustando frustrum) y MRTs con lo poco que cuentas.

Si puedes ser un poco más específico con lo que pretendes conseguir tal vez pueda ayudarte con más detalles.

¿Estas poniendo las librerisa en el orden adecuaod al linkar?

El linker de GNU es de una sola pasada y solo hace caso de los nombres que hayan sido referenciados previamente por otras librerias y objetos al linkar.

Si pones -llua antes de -lscript te mostrara unresolveds pero si pones -lscript -llua funcionara.

Supogo que las rutas donde mirar las librerias estan todas correctas ¿verdad?

Mira a ver si es algo de eso.