Por cierto, ahi va el (posiblemente) peazo Logo, acorde con el nombre:



La verdad es que le logo me gusta ;)
Aunque es bastante probable que sea un fake.

 Los de Nintendo tienen a todo el mundo bailando a su son. Desde hace meses esta esa la única nueva noticia que se tiene de la nueva consola (no de los juegos). Y al momento de actualizar la web oficial el nombre ya se ha ido extendiendo como la pólvora (wiiiiiiiiii) por todos los foros. Parece que la política de nintendo de ultrasecretismo da sus frutos. Los jugones están expectantes del próximo E3 (quedan 12 dias) porque es donde nintendo por fin revelará toda la información. Además del "secreto" que aún les falta revelar, según ellos más impactante todavia que su revolucionaria forma de concevir los juegos.
Sony ya hace tiempo que reveló todos los entresijos de la PS3, y eso le restará protagonismo en el E3 frente a la ultrasecreta consola de Nintendo. Parece que hasta ahora ha sabido jugar bien sus cartas. De la XBox apenas se espera nada nuevo, en comparación.

Veremos como terminan de rematarnos en el próximo E3 (uno de los más apasionantes desde que se presentaron las veteranas PSX y Saturn a mi parecer).

Por cierto, hubieran puesto el nombre que fuera se hubiera dado eco en todos los foros videojueguilies: por dios! un nuevo dato oficial sobre la nueva revolition!, perdon, Wiiiiiiiiiiiii!.

Personalmente no me gusta el nombre, pero me parece acertado escoger un nombre extraño y inesperado, siguiendo el enfoque que han querido darle a la consola en general.
Lo priiiiiiiiiiimero que pensé al ver el mando de la revolution (wiiiiiiiiiiiiiiii) fue, ¡Pero si es un puto mando de TV! Cuando después comprendí su potencia me fascinó. Un ejemplo es el desarrollo de un Dragon Ball para la revolution en el que, según sus desarrolladores, los ataques especiales se harán mediante gestos O_O.
Imaginad lanzar un KameHAmeHA! delante del TV y que sirva para algp! El sueño de todo videoadictoDragonBolero!

Le auguro un gran éxito o un fracaso absoluto a esta consola. Todo puede pasar.

[Wii]

 Parece ser que el nombre final de la consola será Wii (aludiendo al inglés we). Un nombre fatal a mi parecer,  pero al que seguro que acabaremos acostumbrándonos...

Podemos ver el anuncio oficial en la página de Nintendo.

Según nintendo:

Os presentamos a? Wii.
Se pronuncia como la palabra inglesa we, que significa nosotros.
El nombre en clave Revolution expresaba la dirección que queríamos seguir, Wii representa a dónde queríamos llegar.
Wii romperá todas las barreras que separan a los usuarios de videojuegos con el resto del mundo.
Wii acercará a los usuarios a sus videojuegos? y al resto de la gente.

Pero lo que te estarás preguntando es, ¿qué significa Wii?

Wii suena como we, lo que enfatiza que esta consola es para todo el mundo.
Wii es muy fácil de recordar para una persona de cualquier parte del globo, hable el idioma que hable. Sin confusiones. Sin necesidad de abreviaturas. Sólo Wii.
Wii tiene una peculiar doble i que simboliza tanto su mando único como la imagen de gente que se da cita para jugar.
Y Wii es el nombre de una consola que va a traer la revolución al mundo de los videojuegos.

Por todo esto es Wii.

 Para que después digan que los programadores no tenemos alma de artista.... ;)

 Hace un tiempo seconfirmaba que la PS3 contará con un port del SDK del Physx de Aegia para simular físicas usando algunos de sus cores del procesador CELL para esta tarea. Pero creía que todo esto se trataba de simulación de cuerpos RÍGIDOS, al estilo ODE. Sin embargo, en este video se ven además simulaciones de fluidos y deformaciones de objetos.

Que buena pinta tiene.

 De nada hombre, a mandar. De todas formas, para acabar de rematarlo:

Según la documentación de glTexParameter, el valor por defecto de GL_TEXTURE_MIN_FILTER es GL_NEAREST_MIPMAP_LINEAR. Esto significaría que por defecto intenta usar mipmapping. Y como no has especificado los mipmaps (solo tienes el nivel base), no te podía dar por completo el FBO. Por eso al cambiar a GL_NEAREST te ha funcionado. Supongo que podrías cambiar a GL_LINEAR para usar el filtrado bilineal y seguiría yendo bien. Y si quieres utilizar mipmapping, puedes decirle que te genere automáticamente los mipmaps cada vez que calcule la textura con GenerateMipmapsEXT de la misma extensión.

Hasta luego!

 Prueba a usar GL_DEPTH_COMPONENT24 en vez de GL_DEPTH_COMPONENT16. Por lo demás lo veo bien.

Sí, me refería a actualizar los drivers de la gráfica.  

 Creo que ya tienes clara la teoría.  Aunque no es un formalismo. Necesitas decirle cual es el DepthBuffer. Por ejemplo, podrías crear un único renderbuffer y attachearlo a múltiples FBO diferentes para ahorrar espacio en memoria (siempre que todos tengan el mismo tamaño).

Es así? Pero entonces si creamos un FBO este ocupa memoria extra que solo se usa a veces (ya que he leido que no es recomendable destruirlos cada dos por tres). Bueno, supongo que es un sideeffect.

Cualquier otra opción (como los PBuffers) ocuparían memoria de la misma forma que los FBO, con la desventaja que los PBuffers son mucho mas lentos de intercambiar y no son tan portables. De todas formas, siempre podrías destruir un FBO cuando pase un cierto tiempo después de su utilización (10 segundos por ejemplo, por si la zona en la que estas ya no es visible ese agua con sus efectos de refracción).

A todo esto, cuando por mi creo que lo hago todo correctamente me encuentro con que al chequear el status me dice que GL_FRAMEBUFFER_UNSUPPORTED_EXT. Pero tengo una G6600. Necesito instalar algunos drivers nuevos? Yo checkeo si me soporta la extensión mediante glew haciendo un - if (GLEW_EXT_framebuffer_object) - y me cierto, además si pongo las cosas mal entonces me avisa de que no está completeness, pero si lo pongo todo bien salta con que no está soportado.

Yo en una 6800 Ultra tuve que actualizar los drivers para que me detectara la extensión. Puede que tengas un problema como el que tuve hace tiempo al intentar configurar un FBO con color+depth+stencil. Prueba a configurar un FBO solo con color o con colo+depth a ver si funciona. Puede que necesites la extensión EXT_paked_depth_stencil para conseguir que te funcione el depth+stencil a  la vez. Si sigue sin funcionarte copianos todo tu código de configuración del FBO.

 Piensa esto, en tu caso quieres utilizar el color buffer como una textura. Lo primero que se te ocurre es utilizar un FBO con un color attachment como texture2D. Ahora viene el problema: necesitas utilizar el test de profundidad y para ello necesitas un DepthBuffer. ¿Qué depth buffer? El de la pantalla principal no, porque: a) no tiene porque ser del mismo tamaño que tu color attachment y B) no tienes porqué querer que se te machaque el depth buffer principal.

Ahí entran en juego los render buffer. Estableces un DepthBuffer como RenderBuffer para tu FBO y ya tienes un depth buffer que necesitas para hacer correctamente el ZTest. Lo estableces como render buffer y no como texture2D porque no queires para nada su contenido una vez terminado el render. Es como un buffer temporal.

Y para el stencil 3 cuartos de lo mismo.

 

Pero ahora segun lo que dices entiendo que el unico que se puede mostrar en pantalla es el 0, los demás van destinados a usar texturas. Pero no me cuadra qué pintan los renderbuffers.

He modificado mi mensaje mientras tu escribías el anterior. Así que supongo que no has leido la modificación. Te la pasteo aquí por si te aclara esta duda.

Tu piensa que un renderbuffer sirve de contenedor de datos de render, que si bien no los quieres usar como tal, es necesario almacenarlos para renderizar correctamente la escena. Por ejemplo, el depth buffer se suele configurar como renderbuffer y no como texture2d porque lo que tu quieres al final no es el contenido del depth buffer, sino la imagen final. Pero es necesario almacenar en algun sitio el depth buffer para que se renderice correctamente la escena. El color buffer en este caso es el que deberia configurarse como texture 2D porque es lo que buscas utilizar.

Por otra parte, en el caso de hacer shadow mapping, lo que tu quieres es precisamente es contenido del depth buffer. Por lo tanto en este caso configurarias un FBO con una texture 2D como depth attachment y ningún buffer como color attachment. Ya que solo nos interesa el contenido del buffer de profundidad.

¿Me explico?

Cuando lo entiendas todo te parecerá hermoso y perfecto  (ole)  

 

Drakkar, dices que un renderbuffer no se puede enviar a la pantalla? eso me ha parecido entender por lo que dices de blittearlo.

Exacto. Esto es así porque el API no permite especificar diferentes FBO de source y FBO de destino por separado para hacer opraciones entre ellos (como hacer un volcado). Para esto mismo existe una extension 'EXT_framebuffer_blit' pero creo que aun no es utilizable (al menos hace unos meses no lo era, no he vuelto a problarlo (si descubres que sí, avisa ;))). Esta extensión permite literalmente "This allows copying directly from one framebuffer to another".

Por eso te decía que no se como compruebas el contenido del renderbuffer. Necesitarias hacer un readpixels, cambiar al FBO normal y hacer un drawpixels o crear una textura con esos pixeles para comprobar su contenido.

Tu piensa que un renderbuffer sirve de contenedor de datos de render, que si bien no los quieres usar como tal, es necesario almacenarlos para renderizar correctamente la escena. Por ejemplo, el depth buffer se suele configurar como renderbuffer y no como texture2d porque lo que tu quieres al final no es el contenido del depth buffer, sino la imagen final. Pero es necesario almacenar en algun sitio el depth buffer para que se renderice correctamente la escena. El color buffer en este caso es el que deberia configurarse como texture 2D porque es lo que buscas utilizar.

Por otra parte, en el caso de hacer shadow mapping, lo que tu quieres es precisamente es contenido del depth buffer. Por lo tanto en este caso configurarias un FBO con una texture 2D como depth attachment y ningún buffer como color attachment. Ya que solo nos interesa el contenido del buffer de profundidad.

¿Me explico?

Arg, empiezo a estar algo desesperado. Si alguna persona paciente me quiere agregar al msn o al gmail para ver qué hago mal se lo agradeceré. tamatito en hotmail y javi.agenjo en gmail

Prefiero hablar por aquí, así esto puede servirle a más gente con tu problema, ademas de mi limitada disponibilidad para el MSN.

 No veo nada claro ese código:

En ningún momento veo que le digas a OpenGL cual es el buffer de color que tiene que usar (con un glFramebufferRenderbufferEXT, al igual que has hecho con el depth y stencil). Por lo tanto tu FBO no tiene buffer de color asociado.

No estableces el tamaño para todos los renderbuffers, solo para el colorbuffer (que no attacheas)

¿Como compruebas el resultado del RTT? Supongo que con un ReadPixels o similar puesto que un renderbuffer no puedes usarlo como textura, ni blitearlo sobre la pantalla. Mi teoría es que no estas enviando los pixels resultantes donde tu crees y por lo tanto no le afecta ese tamaño que le pasas al colorbuffer (pq realmente no se utiliza!). Y al hacer le ReadPixels o lo que sea estas cogiendo los pixels de ese mismo sitio mágico (el color buffer principal por defecto?) y por eso no ves que cambie nada al variar el tamaño.


Por otra parte, no hay problema al utilizar texturas que no sean potencia de 2. Comprueba que el driver soporta alguna de estas 2 extensiones:
- ARB_texture_non_power_of_two
- ARB_texture_rectangle

Y usa el tamaño que quieras para las texturas.

Por cierto, si no tienes  ningun problema utilizando un FBO con color + depth + stencil avisa ;)

 Ithaqua: el problema era que no me dejaba configurar un FBO con attachements de color + depth + stencil. Buceando por internet la gente hablaba de que para utilizar FBO+depth+stencil había que usar la extensión  EXT_packed_depth_stencil. Al parecer esto era así porque el hardware actual intercala en un mismo buffer de 32 bits los buffers de profundidad y de stencil (24+8 bits) por temos de velocidad.

Usando esta extensión me dejó configurar el FBO con color+depth+stencil. Sin embargo el stencil buffer no se comportaba bien. Cambiando el FBO por un Pbuffer con stencil SÍ funcionaba bien (con extactamente las mismas instrucciones de manejo del stencil buffer). Así que al final me tuve que conformar con usar PBuffer SOLO cuando se requiere el stencil buffer para RTT. De esto ya hace unos meses, así que puede que ya estén solucionados estos temas. Si alguien conoce la verdad me gustaría saberlo ;)

tamat:
- un frame buffer object es una colección de buffers donde el usuario destina el resultado de sus renders (resultados de color, profundidad...). Un FBO admite varios buffers porque hay varios resultados que almacenar: color + profundidad + stencil...

- Cada uno de estos buffers puede ser de 2 tipos:
-- un renderbuffer que es simplemente un buffer de destino dentro del FBO
-- una textura

Generalmente para un attachment de un FBO usaras una textura 2D como buffer si quieres reutilizarla en futuros renders como una textura más. Si no va a ser así, el attachment lo configuras como renderbuffer.

Por ejemplo, podrías tener un FBO compuesto de 3 attachments:
- un texture2d para el color (para reutilizarlo como textura para lo que sea)
- un renderbuffer para el depth buffer
- un renderbuffer para el stencil buffer


Un framebuffer SOLO puede tener un buffer de profundiad asociado. SOLO uno de stencil. En cambio puede tener hasta 4 buffers de color por lo del Multiple Render Target.


¿Te he aclarado algo?

 ¿Porqué no usas Framebuffer Objects en vez de PBuffers para el RTT?Son mucho más rápidos, portables y cómodos de utilizar y ya deberían estar soportados por los drivers actuales (he probado con nvidia y ati y bien). Es lo que utilizo para los shadow maps en el motor. La única pega es que he tenido algún problemilla con FBO+Stencil.

Tamat: con los FBO son cosa de OpenGL , no tiene nada que ver con el SO, por lo tanto nonecesitas el HDC para nada.

 Volviendo al tema de la Revolution. Me encanta!. Hasta hace poco estaba expectante de la PlayStation3 (soy un tekken adicto). Sin embargo, a medida que he ido descubriendo cosas de las nueva consola de Nintendo me he ilusionado mucho con ella. La nueva forma de jugar tiene muy buena pinta. Los gráficos (aunque serán peores que los de XBox y PS3) no son tan malos como esperaba, es más estas capturas transmiten una sensación de suavidad en la imagen que me encanta.

Tiene que ser una maravilla moverte semilibremente con la mano izquierda (e incluso agacharte con algún botón de esa misma mano) y con la otra apuntar libremente por la pantalla. Además, dice que se podrá combatir com a cuerpo cuerpo (supongo que pudiendo dar algun golpe a alguien cercano).

La verdad es que tengo muchas ganas de que salga esta consola porque promete mucho. Además parece que va a ser baratilla y con juegos bastante más baratos que los de la competencia (40 euros me parece que leí). Seguramente me haga con una nada más salir.