BREVE INTRODUCCIÓN
Quiero imaginar que todos los que han llegado hasta aquí es porque verdaderamente han "sufrido en sus carnes" el problema del orden en la representación de tiles/sprites en un entorno isométrico 2.5D (para los más profanos http://es.wikipedia.org/wiki/2.5D).
También habreis podido deducir, y acertadamente, que "yo he sido uno de esos sufridores" pero os aseguro que no fue de una forma intencionada.
Mi historia en el mundo del videojuego se remonta a tiempos Z-80, M-68000 en los que ya existía ese problema y ya había soluciones implementadas. los más "viejos rockeros" se acordarán de juegos como: Batman, La Abadía del Crimen (un recuerdo para Paco Menéndez), etc.... :
También habreis podido deducir, y acertadamente, que "yo he sido uno de esos sufridores" pero os aseguro que no fue de una forma intencionada.
Mi historia en el mundo del videojuego se remonta a tiempos Z-80, M-68000 en los que ya existía ese problema y ya había soluciones implementadas. los más "viejos rockeros" se acordarán de juegos como: Batman, La Abadía del Crimen (un recuerdo para Paco Menéndez), etc.... :
En mi trabajo (de aquella) como programador de videojuegos la "tendencia" era la realización de juegos básicamente "de plataformas" que era lo que realmente el público solicitaba; o sea, 2D, si bien como digo, ya había "aventureros" que se atrevían con las 3D. En aquellas máquinas no había OpenGL, DirectX, ... ni nada parecido. Era 2D y listo.
Es por esto que es admirable la capacidad de aquel grupo de programadores que consiguió el propósito de simular escenas 3D con tiles/sprites 2D. Ya no solo por la "maestría" de implementar el algoritmo para el propósito, sino también por la capacidad de realizarlo teniendo en cuenta la limitada velocidad de proceso de aquellos "viejos engendros". Si bien es cierto que, por lo general, ya se encargaban de representar mundos muy pequeños (pantallas con poca cosa) y sobretodo, pocos "tiles/sprites" que yo denomino "flotantes" y que más adelante definiré con detalle.
Pues nada,... al tema.
Es por esto que es admirable la capacidad de aquel grupo de programadores que consiguió el propósito de simular escenas 3D con tiles/sprites 2D. Ya no solo por la "maestría" de implementar el algoritmo para el propósito, sino también por la capacidad de realizarlo teniendo en cuenta la limitada velocidad de proceso de aquellos "viejos engendros". Si bien es cierto que, por lo general, ya se encargaban de representar mundos muy pequeños (pantallas con poca cosa) y sobretodo, pocos "tiles/sprites" que yo denomino "flotantes" y que más adelante definiré con detalle.
Pues nada,... al tema.
el problema
En este tipo de representaciones isométircas 2.5D nos encontramos con dos aspectos:
1- Efecto visual "perverso"
El resultado de la representación 2D puede resultar "engañoso" a la vista del ojo humano. Ejemplos:
1- Efecto visual "perverso"
El resultado de la representación 2D puede resultar "engañoso" a la vista del ojo humano. Ejemplos:
Lamentablemente, este problema no tiene solución y debe ser tarea del diseñador de escenarios que este efecto no se produzca a base de establecer unas guías, .... para "guiar" la comprensión del entorno.
2- Orden de renderizado
Este es el verdadero problema que nos ocupa.
Teniendo en cuenta que a la hora de representar los tiles/sprites en pantalla solo tenemos 2 coordenadas de representación (X,Y) y que muchos objetos "interseccionan visualmente" en pantalla entre sí unos con otros (dada la perspectiva isómetrica), es obvio pensar que "habrá que cuidar el orden de dibujado".
Para explicar mejor el asunto pongo un ejemplo intuitivo:
Si tuviesemos recortados en papel los tiles/sprites" de la imagen (una vez la hubieramos impreso) e intentamos reproducir dicha imagen nuevamente sobre una mesa... En qué orden habría que colocar los tiles/sprites? O dicho de otra manera, sirve seguir cualquier orden de colocación?
La respuesta es, obviamente, NO!!! Pues este mismo problema es el que tenemos en "pantalla".
Y ahora viene la pregunta: como los ordenamos? o nos lo preguntamos de otra manera: con qué criterio/s lo hacemos?
2- Orden de renderizado
Este es el verdadero problema que nos ocupa.
Teniendo en cuenta que a la hora de representar los tiles/sprites en pantalla solo tenemos 2 coordenadas de representación (X,Y) y que muchos objetos "interseccionan visualmente" en pantalla entre sí unos con otros (dada la perspectiva isómetrica), es obvio pensar que "habrá que cuidar el orden de dibujado".
Para explicar mejor el asunto pongo un ejemplo intuitivo:
Si tuviesemos recortados en papel los tiles/sprites" de la imagen (una vez la hubieramos impreso) e intentamos reproducir dicha imagen nuevamente sobre una mesa... En qué orden habría que colocar los tiles/sprites? O dicho de otra manera, sirve seguir cualquier orden de colocación?
La respuesta es, obviamente, NO!!! Pues este mismo problema es el que tenemos en "pantalla".
Y ahora viene la pregunta: como los ordenamos? o nos lo preguntamos de otra manera: con qué criterio/s lo hacemos?
En las siguientes imagen se muestran las 2 problemáticas juntas:
Aparentemente las 2 imágenes son válidas. Todo depende de "en que coordenada Z está el objeto marrón". Es por tanto lógico pensar que debemos seguir un orden lógico determinado en el que mostrar los diferentes objetos.
Y para abrir boca, antes de continuar, os muestro un ejemplo "cocos2d-js" de mi solución al problema de ordenado: