10 9 8 7 6 5 4 3 2 1 ....... (cogiendo aire)

Hola!

¿Tienes experiencia previa en el desarrollo de videojuegos? Si tu respuesta es NO, tienes un 99,99% de probabilidad de fracaso, luego te aconsejo que pidas a un administrador que borre este post para que evites la lluvia de comentarios que estan a punto de caerte encima. Si tu respuesta es si, digamos que tienes un 99% de probabilidad de fracaso (como ves te quito un 0,99%), luego tb te aconsejo que recapacites sobre como de complicado es hacer un juego y mas un MMORPG.

Hace un MMORPG no es una cosa trivial, y es un trabajo de cientos de personas experimentadas durante años con un presupuesto con bastantes mas 0's que el tuyo.

Espero que no te lo tomes a mal, pero es mejor que abras los ojos ahora y de esta manera, que no perdiendo el tiempo y dinero (que aunq sea poco para un proyecto asi es una buena cifra como para invertirla en algo que no va a dar fruto).

Un saludo

a la gente no le valen esos gráficos! quieren "tipo wow o mejores" xD

Buenas,

Estoy haciendo pruebas de rendimiento en la especie de engine que estoy haciendo para Android, y he comparado mi implementacion de render por Vertex Arrays con la implementación de Vertex Buffer Object. La verdad es que me ha sorprendido que vaya peor con VBO que con VA en todos los casos. Habia leido que para gráficos estáticos iba mejor VBO, pero que en gráficos dinámicos suele ir mejor VA. No parece ser este el caso.

Pongo varias muestras de FPS y tiempo de render (mseg de render de 1 frame), por no hacer la media.

Prueba 100 cuadrados


Prueba 400 cuadrados


Me parece curioso lo variable que es el tiempo de pintado (sobre todo rotando), ya que algunos frames doblan en tiempo a otros (supongo que parte del motivo es que debería usar una función más precisa para calcular el tiempo)

En cualquier caso, tengo que mejorar la manera calcular los FPS. Ahora mismo incremento un contador durante 1 segundo y lo muestro. Sé que no es la mas usada (probablemente de la menos), pero el cálculo con estimaciones (si 1 frame dura X mseg, en 1 seg hay Y frames) me parece un tanto irreal.

Mañana pongo parte del código que uso,a ver si se os ocurre algún fallo que este bajandome el rendimiento, porque considero que son resultados algo bajos....

Un saludin!

yo creo que a eso se refiere con "... carencia de iniciativa en la difusión de información ...", en que no se sabe, ni hay medios que te abran los ojos diciendote cuan complicado es hacer un monstruo de dichas envergaduras. Y no es que no haya medios, hay páginas, libros.... información si que hay, pero accedes a ella muchas veces cuando ya estas metido en el mundillo. No hay por asi decirlo una conciencia global de que es un desarrollo software, de hecho la gran mayoria ni se imagina como es posible ni tan si quiera hacer algo asi.

Traslada esto al mundo del cine por ejemplo. Quien mas quien menos sabe la función d cada integrante de un equipo de filmación, o han visto un "Como se hizo" de cierta pelicula, o se ha visto en un DVD la seccion de "comentarios del director" y tiene asi una opcion mas en detalle de como es un proceso de grabacion de una película. Y aunque solo eso sea la punta del iceberg en lo que a grabacion de películas se refiere, la gente tiene una idea de lo que cuesta, el trabajo que lleva, y no ves a gente buscando colaboraciones en foros para hacer un Señor de los Anillos 4.

Hoy en día la gente sigue sin ser consciente del trabajo (y conocimientos, ojala fuese solo trabajo) que lleva hacer un juego, por insignificante que sea. Y creo que a esa carencia de información es a la que se refiere indieesepe.

De todas formas ya hay juegos (ed. coleccionista de Starcraft 2) que empiezan a venir con extras sobre el desarrollo, entrevistas al equipo de desarrollo, etc..... y quieras que no, aportan un poco mas de información sobre un mundillo que en muchos casos esta infravalorado, pero ya digo, por desconocimiento.

Venga, unas mini criticas, que siempre son todo piropos!

En el fondo ya es rizar un poco el rizo, y no se si son requisitos de vuestro sponsor, pero los colores en general los veo un poco tristones, como muy oscuros/apagados (que igual es el efecto que queriais darle eh). Y en la primera imagen las plataformas parecen parte del fondo, que entran dudas sobre si te vas a poder apoyar o no en ellas.

Por contra me gusta mucho el diseño del personaje. De hecho se me recuerda a los dibujos de cuando te mandaban acostarte hace años: http://i89.servimg.com/u/f89/12/09/81/39/famili10.jpg jejeje

Un saludin!

yo creo que es alguien del foro con otra cuenta para tomarnos el pelo....

[Duda 1]

Buenas,

Como ya he puesto en varios post, estoy empezando con OpenGL ES 2.0 y son nuevos para mi todos los conceptos de shaders, y demas, y tengo alguna duda respecto. A ver si me podeis ayudar.

Duda 1
Mas o menos tengo clara la funcion tanto del vertex shader como del fragment shader. Pongo los pasos en Android para el uso de los mismos, y luego os planeteo mi duda:

int vertex_shader = GLES20.glCreateShader(GLES20.GL_VERTEX_SHADER);  
GLES20.glShaderSource(vertex_shader , vrtxShaderCode);
GLES20.glCompileShader(vertex_shader );

int fragment_shader = GLES20.glCreateShader(GLES20.GL_FRAGMENT_SHADER);  
GLES20.glShaderSource(fragment_shader , frgmntShaderCode);
GLES20.glCompileShader(fragment_shader );

mProgram = GLES20.glCreateProgram();            
GLES20.glAttachShader(mProgram, vertexShader);  
GLES20.glAttachShader(mProgram, fragmentShader);
GLES20.glLinkProgram(mProgram);

maPositionHandle = GLES20.glGetAttribLocation(mProgram, "vPosition");

Pues bien, esos pasos, los hace en una función de carga previa al pintado de la escena. Luego ya en la tipica funcion loop de pintado antes de dibujar el polígono, usa esto:

GLES20.glUseProgram(mProgram);

Entiendo todo el código, por ahi no van mis dudas. El caso es, si yo tengo varios Shaders, ¿lo normal es cargarlos todos y luego en funcion a que "objeto" voy a pintar hacer un glUseProgram de ese Shader? ¿Hay limite de shaders a tener cargados? No se si van cargados en la GPU o que, y eso pueda conllevar en problemas. Vamos, que mi duda es cual es el uso real que se le da a los shaders, porque básicamente los ejemplos que veo son para 1 shader (de cada) y pintar 1 poligono, y no se como se manejaría todo en una situacion con varios Shaders, con diferentes elementos usando cada uno de ellos.

Me estoy haciendo unas clases (Shader y ShaderProgram) para manejar todo este tipo de elementos. En la primera cargo, compilo y demás el shader, y en la segunda asocio 2 Shader (vertex & fragment) , creo el programa y obtengo los handle a los atributos/uniforms.

Luego por otro lado tengo una clase Drawable, de la que heredan los elementos dibujables. Dicha clase tiene asociado un ShaderProgram. De esta manera cada vez que lanzo un draw() de la clase Drawable (o sus heredadas), su ShaderProgram hace un glUseProgram.

Con esto estoy haciendo un glUseProgram por cada entidad que dibujo, lo cual no se si es muy eficiente. En fin, si alguien puede explicarme cual es el uso tipico que se le suele dar a esto....

Por otro lado, no se que uso se le da a los shaders (supongo que por desconocimiento aun, que estoy aprendiendo), mas alla de especificar posicion y color/transparencia. Ni que efectos puedo conseguir, o que sean aprovechables en 2D, que es lo que yo estoy usando.

Y ahora, la segunda duda.

Duda 2

Es probable que esta duda sea de tarjeta roja, porque incluso yo me he extrañado de como no tengo claro aun esto, pero aun así la pregunto.

Suponed un vertex shader asi:

   private final String vertexShaderCode =
        "uniform mat4 uMVPMatrix;   \n" +
        "attribute vec4 vPosition;  \n" +
        "void main(){               \n" +
        " gl_Position = uMVPMatrix * vPosition; \n" +
       "}  \n";

En los ejemplos que yo veo, obtienen un handle de uMVPMatrix por una parte y otro handle a vPosition por otro lado. Por otra parte aplican las transformaciones necesarias (rotaciones, escalados, etc) multiplicados por la matrix de cámara y por la de la proyeccion (como siempre). Al final lo que se tiene es en uMVPMatrix la matriz de las transformaciones ya calculada, y en vPosition el vector por cada vertice del poligono. Con ello conseguimos en gl_Position la posicion transformada de dicho vértice en coordenadas de la proyeccion.

Hasta ahi bien. Pero ayer me surgio la duda a la hora de mover un cuadrado por la pantalla. Y es que si el movimiento de dicho cuadrado lo baso en transformaciones del tipo glTranslate, al final lo que tengo es que en uMVPMatrix tengo transformaciones acumuladas, que van haciendo que vPosition vaya cambiando de posicion (en funcion a los parametros que le pase al glTranslate por asi decirlo), pero en vPosition siempre tendre las coordenadas iniciales, porque esas no se van actualizando. Es decir, si al cabo de 1 minuto de ver mi maravilloso cuadrado dar vueltas por la pantalla, decido ver sus coordenadas para comprobar una colision por ejemplo, tendre las coordenadas iniciales, porq en ningun momento he cambiado directamente las coordenadas de los vertices, sino que les he aplicado una transformacion en el shader para que se vea reflejada simplemente.

Entonces he pensado, bueno, pues cuando quiera mover el cuadrado, actualizo la matriz de sus vertices con el desplazamiento, y la paso al shader, siendo en este caso vPosition el vector del vertice con las coordenadas ya transformadas, y en uMVPMatrix la matriz de camara y de proyeccion (ya multiplicadas) para transofrmar dichas coordenadas a las propias de la proyeccion.

Con este método siempre tengo las coordenadas actualizadas de donde esta el objeto, pero por contra estoy cargando a la CPU de operaciones (por entiendo que las operaciones del shader se hacen en GPU). Ademas de que cada vez que pinto el objeto, tengo que crear un buffer para asociarlo con vPosition. En el primer caso, como las coordenadas locales nunca cambiaban, creaba el buffer 1 vez, y siempre usaba el mismo, en la segunda opcion, como cambio las coordenadas, tengo que crear un buffer cada vez para pasarlo al shader, lo cual debe ser costoso. El buffer lo creo asi:

       ByteBuffer vbb = ByteBuffer.allocateDirect( squareCoords.length * 4);
       vbb.order(ByteOrder.nativeOrder());
       squareVB = vbb.asFloatBuffer();
       squareVB .put(squareCoords);  
       squareVB .position(0);

Siento si es algo confuso, me explico muy mal a veces. Y siento el mega post (no queria abrir 2 post para temas tan relacionados), que a mas de 1 le dara pereza leer :P

Muchas gracias de antemano cracks :)

un saludin

Vamos, que da igual de cuanto haga la proyección no? Ya que luego se ve reflejada en toda la pantalla?

Es que mi duda era: si tengo una pantalla 400x200 y otra 500x200. Y hago la proyección ortho en función a las medidas de cada pantalla (para guardar la relación de aspecto) y coloco un objeto en la posición 450x150 por ejemplo, en el primer móvil no se vera ese objeto.... pero en el segundo si. Luego no se que dimensiones poner a la proyección para que sea correcta en todas las pantallas.

Igual sigo dándome cabezazos contra una pared, pero no veo como.

Buenas!

Estoy peleandome (si, es la palabra correcta) para aprender un poco con OpenGL ES 2.0 para Android. Si ya habia tocado poco en ordenador, encima lo habia hecho con versiones anteriores a la 2.0, asi que estoy mascando el "nuevo" pipeline y sus shaders.

La duda que tengo es mas de conceptos generales, pero bueno, alla va.

Tengo una proyeccion ortho, establecida con esta funcion:

    public void onSurfaceChanged(GL10 unused, int width, int height)
    {       
       GLES20.glViewport(0, 0, width, height);
       
       float ratio = (float) width / height;

       Matrix.orthoM(mProjMatrix, 0, -(width/2), (width/2), -(height/2), (height/2), -1.0f, 1.0f);
       //Matrix.orthoM(mProjMatrix, 0, -ratio, ratio, -1, 1, -1.0f, 1.0f);
       
       muMVPMatrixHandle = GLES20.glGetUniformLocation(mProgram, "uMVPMatrix");
       Matrix.setLookAtM(mVMatrix, 0, 0, 0, 1, 0f, 0f, 0f, 0f, 1.0f, 0.0f);
    }

(notese que tengo comentada una linea, ya que he probado diferentes dimensiones)

Para la pantalla de mi móvil, tiene de estas dimensiones:

En modo vertical: Ancho: 480 - Alto: 724
El modo "landscape" (de lado): Ancho: 800 - Alto:404

Luego va cambiando la proyeccion, en funcion del modo (como es normal), al igual que pasaba en una app de ordenador, si redimensionabas la pantalla. No me preocupa mucho, ya que trabajaré en uno u otro modo, y limitare la app a eso. La duda que me corroe es relativa a las diferentes resoluciones en los diferentes móviles.

Mi duda es:
A la hora de distribuir los "objetos" por la pantalla, ¿que coordenadas le pongo? A ver si me explico, si quiero colocar algo en la esquina superior izquierda, pues en mi móvil se las coordenadas son unas, diferentes a las de otro móvil (el punto X:0 Y:0 esta en el medio de la pantalla). Podría mover el eje para que el (0,0) este en la esquina superior izquierda, y colocar las cosas basandome en ese punto, pero aun asi tendria problemas porque algunos móviles tendran resolucion mayor, y colocar una cosa en el (100,100) no se vera en igual posicion en un movil con resolucion 400x200 (ejemplo), que en uno mas moderno con 560x280 (otro ejemplo inventado).

Lo único que se me ocurre es trabajar en torno a una resolucion fija, y si la resolucion es mayor (otro móvil) calcular la posicion mediante una regla de 3, asi como el tamaño de los elementos....

Seguro que todo esto es una perogrullada, pero son conceptos que nunca me hicieron falta, porq siempre "trabaje" con ventanas de tamaño fijo, fijado por mi, y que no variaba.

------

Por otro lado, según veo por ahi, y volviendo al código que puse arriba (la línea comentada):
Matrix.orthoM(mProjMatrix, 0, -ratio, ratio, -1, 1, -1.0f, 1.0f);

Usando una proyeccion asi, soluciono el problema vertical, ya que trabajo en un rango fijo (-1,1), pero en horizontal vuelvo a tener el mismo problema, ya que ratio depende de la resolucion de la pantalla.....

No se si quedo claro, porq a veces me explico como el culo.

Muchas gracias :)

Un saludin

Muchas gracias a ambos!

Si, así es, es un poco de interés por conocer la estructura de un engine y falta de organización por mi parte, muchas veces porque no se marcar la linea divisoria de que es engine y que es juego (básicamente pongo particularidades del juego en lo que debería ser el engine, y al final tengo una chapuza no reutilizable en muchos casos).

Echare un ojo a esos enlaces! gracias a ambos por vuestros consejos.

Un saludin

Si, si en parte tienes razón. Como manera de aprender la estructura de un motor es un buen paso supongo. El tema es que en este caso como os puse, estoy empezando con programacion gráfica para Android (para pc y use SDL bastante y OpenGL algo menos), y me gustaría ver como hacer las cosas (para aprender) desde su mas bajo nivel, sin una capa por encima. De ahi que quiera evitar usar un motor ya hecho (AndEngine tiene buena pinta ya dicho de paso).

En cualquier caso, no descarto bajarme los fuentes para cotillear un poco como han organizado las cosas.

Gracias :)

Buenas!
No se si soy el único o no, pero me pasa que siempre que hago algún desarrollo (personal) de algún jueguillo, hago tal lío de funciones/clases, con particularidades especificas de ese juego dentro de ellas, que al final me resulta bastante complicado reutilizar grandes partes del código sin tener que andar haciendo criba d que es juego y que es "engine". No se si me explico.

Tengo pensado meterme en el mundillo de juegos para Android y aprovechando vengo de novato, empezar a hacer las cosas ordenadas desde un principio. Es decir me gustaría montarme un conjunto de clases, a modo de engine, que me sirvan como base para cualquier desarrollo futuro, y así tener diferenciada la parte del juego del motor, por así decirlo, sin tener que empezar prácticamente desde 0 en cada desarrollo.

Entiendo que hay mil maneras, y/o que cada uno lo hace a la suya.

¿Conocéis de alguna documentación,ya sea en formato Web, o como libro, que expliquen bien como estructurar un motor desde 0? Da igual el lenguaje, la plataforma, o la librería gráfica(dx, ogl), solo necesito una guía de como estructurarlo.

He buscado y he visto alguna entrada en algún blog, además de algún libro por amazon. Pero o bien es bastante escaso en explicaciones, o no me quiero arriesgar a comprar un libro que luego no sea lo que estoy buscando. Igual vosotros sabéis de algo :)

Gracias!

Un saludin

votado! suerte :)

youtubeando un poco (verbo hermano de googlear), y basandome en la respuesta de The_Dragon_Ladis he visto este video http://www.youtube.com/watch?v=o2HCS2jCVZo para que te hagas una idea de que se puede hacer con Qt.

Ademas he visto que tiene un menu arriba de Engine -> Run. curioso :D

Es un post de hace 5 años eh, solo queria recordar como estaban las cosas por aquel entonces, vaticinando el futuro :P