yo lo veo bien, aunque algunos parecen más propios de comic que de videojuegos, quiero decir que en los videojuegos yo creo que todo está como más suavizado, sin tanto detalle y sin trazos aleatorios, como más tipo render, no sé si me explico, aunque es una opinión.

yo creo que deberías de aprender java o C++. Si va a ser juegos de android pues Java es suficiente. Y practicar probando frameworks hasta que encuentres el que mejor te va. LibGDX está bien.

yo creo te lo que se usan son billboards, que son simples rectángulos con textura que solo tiene la particularidad de que siempre están orientados a la cámara, es lo que se usaba para los objetos en la prehistoria del 3D.  Así que no te tienes que complicar con las proyecciones ni hacerlo por separado, lo único que tienes que hacer es dibujar un rectángulo y tratarlo como un objeto 3D más, cuando la cámara se aleje o se desplace, el objeto lo hará con el escenario.

Simplemente antes de dibujarlo hay que establecer la matriz de modelado para que el objeto se dibuje orientado a la cámara. Que creo que era multiplicando la matriz del objeto por la de la cámara. Es decir, que la matriz del objeto siempre ha de ser la de identidad en su rotación, solo se modificaría la posición, y esa matriz al multiplicarla por la de la cámara justo antes de dibujar rotaría el objeto para dejarlo orientado, aunque bueno, no me acuerdo muy bien pero algo así creo recordar.

Pero vamos, seguro que hay mucha info por ahí, si es eso lo que quieres busca como billboard o impostor.

http://www.lighthouse3d.com/opengl/billboarding/

puedes usar 2d en un entorno 3d, por lo que lo mejor sería combinar. Obviamente lo tienes que hacer en 3d.

por ejemplo un bosque de árboles sería muy costoso en 3d y probablemente cutre, así que podrías hacer rectángulos con textura de dibujos de árboles detallados.

El terreno, edificios, y en general objetos que no tengan muchos vértices como los suelos y paredes sí quedarían mejor en 3D y ahorraría en recursos y facilidad de generación, además de poder aplicar luces y sombras.

vale, pues lo haré así que supongo que valdrá perfectamente, si alguien conoce algo específico para Cocos o lo encuentro por ahí supongo que no habría ningún problema en adaptarlo.

A ver si alguien que haya hecho una aplicación o juego usando Cocos2D me puede decir cómo hay que hacerlo porque no sé cómo pasar de una escena a otra. Sé que hay que usar replaceScene, pero dónde.

Desde AppDelegate corro la escena del juego  director->runWithScene(game);

Ahora supongamos que al pulsar ESCAPE quiero cambiar a la escena de menú. Entonces supongo que desde un Evento en la clase Game lo llamaría, pero creando una escena nueva. así

auto menu = MyMenu::create();
Director::getInstance()->runWithScene(menu);

¿Pero y luego para volver al juego?, no puedo volver a crearlo, ya de hecho me parece absurdo crear un nuevo menú cada vez que accedo a él.

¿hay que crear las escenas en appDelegate y que luego Tengan acceso global?, ¿o cómo va esto?

Creo que lo ideal sería que usases Opengl, y que las piezas fueran modelos 2D. Toda la imagen del puzzle sería una textura y bastaría con asociar a cada pieza las coordenadas de la textura, que se corresponderían con su posición en el mosaico. Aunque no tienen porqué ser necesariamente polígonos, pueden ser rectángulos y usar aparte de la textura de la imagen otra textura de máscara alpha para cada tipo de pieza.

Y bueno, aparte, con Opengl todo sería mucho más rápido y versátil, permitiendo zoom, rotaciones y desplazamientos suaves, filtros, efectos, etc. Hasta podrían tener cierto volumen y perspectiva inclinada en 3D sin demasiado esfuerzo.

prueba a rellenar la textura de un color para ver si está dibujando la textura, si sale bien es que es problema de la carga.

A ver, el shader y los atributos de vértice le dicen a la tarjeta cómo lo tiene que dibujar, y los vértices y las texturas le dicen qué es lo que tiene que dibujar. Todos los datos residen en objetos, que se llaman por su abreviatura, en el caso en el caso de los arrays de vertices, VBO, y no es otra cosa que bloques de memoria que normalmente residirán en la VRAM, así que no son necesarios "enviarlos" más que una vez, cuando se cargan con glBufferData.

crea y carga cada submodelo en un VBO y establece sus atributos, si no recuerdo mal opengl asignará esos atributos de vértice al buffer actual enlazado con glBindBuffer(GL_ARRAY_BUFFER.

Luego para dibujar basta con enlazar el buffer que se vaya a usar y opengl lo usará en el próximo dibujado con glDrawArrays o glDrawElements.

no sé exactamente lo que quieres decir.

pero yo creo que teniendo cada modelo en un VBO en la memoria gráfica basta con hacer el bind del VBO correspondiente justo antes de dibujar sin tener que pasar nada a ningún lado.

intenta acotar el problema, prueba a cargar los shader que te he puesto antes de ejemplo, para ver si compilan bien.

si compilan bien entonces entonces es problema del código que estás cargando, analiza con el depurador el string justo antes de pasarle el source, a ver qué es lo que le está llegando.

puede ser porque esas cadenas de texto tienen que tener al final el null '0\' para que sepa donde termina.

es que no se ve que cargues ningún código en ese array, o no se sabe lo que contiene porque puede ser algún error de compilación.

te pongo un ejemplo de shader simple que está sacado del opengl superbible, se crea en una función sin nada más, esta función devuelve el programa que luego se usará

Código [Seleccionar] Expand

GLuint compile_shaders(void)
{
GLuint vertex_shader;
GLuint fragment_shader;
GLuint program;

/*
aquí el código se carga directamente pero también se puede cargar de un archivo de texto de manera normal
lo que hace este vertex shader es dibujar un triángulo enviando la posición de cada vértice que le llegue para ser dibujado,
como en este caso no se le va a pasar ningún  vértice lo que hará es pasar el vertice del vector que se define en el propio shader,
basta con que el shader sepa qué número de vertice es, que le viene indicado en gl_VertexID */

static const GLchar * vertex_shader_source[] =
{
"void main(void) \n"
"{ \n"
" const vec4 vertices[3] = vec4[3](vec4(0.25, -0.25, 0.5, 1.0), \n"
" vec4(-0.25, -0.25, 0.5, 1.0), \n"
" vec4(0.25, 0.25, 0.5, 1.0)); \n"
" gl_Position = vertices[gl_VertexID]; \n"
"} \n"
};

// el fragment shader simplemente coge todos los vértices que le lleguen y los pinta del color que está definido en un vector

static const GLchar * fragment_shader_source[] =
{
"out vec4 color; \n"
" \n"
"void main(void) \n"
"{ \n"
" color = vec4(0.0, 0.8, 1.0, 1.0); \n"
"} \n"
};

// esto es lo típico, se crea el shader, se le carga el código, y se compila.

// Create and compile vertex shader
vertex_shader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertex_shader, 1, vertex_shader_source, NULL);
glCompileShader(vertex_shader);

// Create and compile fragment shader
fragment_shader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragment_shader, 1, fragment_shader_source, NULL);
glCompileShader(fragment_shader);

// luego ya se crea el programa, se asigna los shader y se enlaza, listo para ser ejecutado
// Create program, attach shaders to it, and link it
program = glCreateProgram();
glAttachShader(program, vertex_shader);
glAttachShader(program, fragment_shader);
glLinkProgram(program);

// los shader se puede borrar porque ya se cargaron en el programa
// Delete the shaders as the program has them now
glDeleteShader(vertex_shader);
glDeleteShader(fragment_shader);

return program;
}



para usarlo es muy simple, primero se carga el programa

   rendering_program = compile_shaders();

y para ejecutar el shader, basta con activar el programa de shader que vamos a usar
   
   glUseProgram(rendering_program);

y dibujar los triángulos, (que en este caso solo va a dibujar uno porque se le pasan 3 vértices)
   glDrawArrays(GL_TRIANGLES, 0, 3);


una vez que tienes esto podrías modificar el shader para que dibuje por ejemplo una tira de triángulos con 20 vértices mediante un bucle, y mandando la función de dibujo correspondiente.

   glDrawArrays(GL_TRIANGLE_STRIP, 0, 20);

Hola, yo soy programador, me ha parecido ver que muchos de vosotros hacéis diseños que no siempre se adapta a lo que los equipos o programadores requieren para sus videojuegos, pero he pensado que si se tiene una buena idea ¿por qué no va a poder surgir algo interesante a partir de esos gráficos, dibujos, o animaciones?, con casi total libertad creativa.

Obviamente no tiene porque ser un videojuego típico, ni siquiera un videojuego, ahora también se llevan las "experiencias audiovisuales" con alguna historia o mensaje que contar, o con algo diferente a lo ya existente. Yo en principio estoy abierto a todo (aventura gráfica, abstracto, conversacional, utilidad, pedagógico, infantil...),  pero de momento solo sería estudiar un hipotético proyecto antes de iniciarlo o de formar un equipo, o simplemente tomarselo como algo experimental, sin pretensiones. Se podría hacer alguna demo para ver si "funciona", pero creo que lo fundamental sería primero encontrar unas buenas ideas, y por supuesto saber que se dispone de gráficos con un mínimo de estilo a los que sacar partido, y enfocar ese estilo al juego.

si hay alguien interesado (o simplemente busca un programador para sus gráficos e ideas) contactad por privado, gracias.

¿pero qué hay en "fuenteShader"?, ¿estás cargando algo?