Entrevista a Jason Rubin de Oculus - Gamescom 2016

En esta ocasión hemos tenido la oportunidad de charlar con Jason Rubin, director de contenidos en Oculus VR, que responde a nuestras cuestiones sobre diversos aspectos del lanzamiento de Oculus Rift y Touch.

25 AGO 2016  13:17

lna

32 comentarios

Entrevista a Jason Rubin de Oculus - Gamescom 2016

 

 

 

Jason Rubin nos comenta los problemas sufridos inicialmente durante el lanzamiento del Rift, así como del controvertido aspecto de la elección de las lentes y el famoso efecto glare. También nos hablará de cómo Oculus ha superado y aprendido los problemas de fabricación y de su seguridad absoluta en que el lanzamiento de Touch no tendrá nada que ver con el del Rift. También comentaremos con él qué es lo que echamos de menos en Oculus Home y qué es lo que podemos esperar en los próximos años de la realidad virtual. Como siempre, no olvidéis activar los subtítulos en castellano. 

 

Comentarios (32)

Enlace al foro
  • Lorient:

    Creo que pecas de poca experiencia como programador. Te pongo un ejemplo de un algoritmo de inteligencia artificial que optimicé hace un par de años. Cambiando una única línea de código, pase de 58 minutos que tardaba en resolverse el problema, a 2 segundos.

    Este es un ejemplo de lo equivocado que estás, donde solo cambiando una única línea, has pasado de un programa inservible a un programa útil. Y no hace falta tocar ni texturas, ni polígonos, ni aumentar memoria, ni cambiar 1000 líneas como comentas, simplemente se cambió una mísera línea de código.

    Es tan simple como que si tienes un bucle que se repite miles o millones de veces para resolver un problema complejo como sucede habitualmente en la inteligencia artificial u otros algoritmos complejos. Si dentro de ese bucle tienes una tontería que tarda un par de segundos, ese par de segundos lo estás multiplicando por el número de veces que se repite el bucle. Optimizando esa línea bajando el tiempo de ejecución, estás ganando minutos o incluso horas. Y ojo, esa línea que cambié, no era una chapuza, era un código bien realizado que ejecutándose en otra parte del programa no daría ningún problema, pero estaba en un bucle crítico y había que optimizarlo.



    Si haces un código que te cuesta 58 minutos y no lo corriges en el momento... me parece que el que tiene poca experiencia eres tú. Eso no es optimizar es programar mal.

    En los sistemas de tiempo real utilizar bucles es un pecado. (Un juego es un sistema de tiempo real).

    No creo que los problemas de optimización de la gente que hacen los triples A sean tus mismos problemas. Dudo mucho que el problema de un juego que necesita una buena tarjeta gráfica y un buen procesador sea porque sus programadores no vigilian los bucles de sus programas.

    En cuanto a la optimización de los videojuegos de los años 80 ni muchisimo menos iban por los derroteros de los que hablas, no hablo de malos programadores, hablo de gente que reutilizaba la misma variable en 10 cosas para ahorrar un byte de memoria, que metía 100 líneas de ensamblador para ahorrar un milisegundo de ejecución y que incluso el código tenía que ser compacto para que cupiese en memoria, había casí que pensar si estabas escribiendo líneas de más o de menos para que al compilar no te pasases de los 64K.

    Los ejemplos que me pones son de chapuzas y malos programadores, veo que no entiendes la diferencia entre programar bien y optimizar (que no tienen porque ser lo mismo, yo he visto códigos super óptimos muy chapuceros y llenos de ñapas) y veo que el que no ha tenido mucha experiencia programando con ordenadores antigúos eres tú.

    Optimizar es coger un código que está bien hecho y modificarlo para arañar milisengundos de ejecución o kb de memoria, corregir un programa que derrocha memoria y tiempo de ejecución no es optimizar es arreglar un código que está mal.

    Por cierto llevo programando desde los 10 años y tengo 40, creo que he programado en todo lo que se pude programar y en casi todos los lenguajes, desde juegos y sistemas empotrados con microprocesadores muy limitados a programas de gestión, servidores, drivers,... se lo que es optimizar y cuando hace falta.
    3 1
  • omg

    omg

    me gustaria saber a q llama cada uno programar. alguno ya se cree el dios de la programacion por usar unity o unreal y eso señores ni es programacion de alto nivel ni optimiza hardware alguno. eso es usar la fuerza bruta.
    0 1