2d - isoplano - Dibujando mundos de juego isométricos

isometricos en autocad

Question

¿Cuál es la forma correcta de dibujar mosaicos isométricos en un juego 2D?

He leído referencias (como esta ) que sugieren que las teselas se renderizan de forma que zigzagueen cada columna en la representación en 2D del mapa. Imagino que deberían dibujarse más en forma de diamante, donde lo que se dibuja en la pantalla se relaciona más con lo que se vería en la matriz 2D, simplemente giraba un poco.

¿Hay ventajas o desventajas para cualquiera de los métodos?

Answer 1

De cualquier manera hace el trabajo. Supongo que por zigzag te refieres a algo como esto: (los números son orden de renderizado)

.. .. 01 .. ..
.. 06 02 ..
.. 11 07 03 ..
16 12 08 04
21 17 13 09 05
22 18 14 10
.. 23 19 15 ..
.. 24 20 ..
.. .. 25 .. ..

Y con el diamante te refieres a:

.. .. .. .. ..
01 02 03 04
.. 05 06 07 ..
08 09 10 11
.. 12 13 14 ..
15 16 17 18
.. 19 20 21 ..
22 23 24 25
.. .. .. .. ..

El primer método necesita más teselas renderizadas para que se dibuje la pantalla completa, pero puede hacer fácilmente una comprobación de límite y omitir las fichas totalmente fuera de la pantalla. Ambos métodos requerirán un cierto número de crujidos para averiguar cuál es la ubicación del mosaico 01. Al final, ambos métodos son aproximadamente iguales en términos de matemática requerida para un cierto nivel de eficiencia.

Answer 2

El verdadero problema es cuando necesitas dibujar algunos mosaicos / sprites intersectando / abarcando dos o más fichas diferentes.

Después de 2 (duros) meses de análisis personales del problema, finalmente encontré e implementé un "dibujo de renderizado correcto" para mi nuevo juego cocos2d-js. La solución consiste en mapear, para cada mosaico (susceptible), qué sprites están "adelante, atrás, arriba y detrás". Una vez hecho esto, puede dibujarlos siguiendo una "lógica recursiva".

Answer 3

La respuesta de Coobird es la correcta y completa. Sin embargo, combiné sus sugerencias con las de otro sitio para crear código que funciona en mi aplicación (iOS / Objective-C), que quería compartir con cualquiera que venga aquí buscando tal cosa. Por favor, si te gusta / votas esta respuesta, haz lo mismo con los originales; lo único que hice fue "pararse sobre los hombros de los gigantes".

En cuanto al orden de clasificación, mi técnica es un algoritmo de pintor modificado: cada objeto tiene (a) una altitud de la base (llamo "nivel") y (b) una X / Y para la "base" o "pie" de la imagen (ejemplos: la base del avatar está a sus pies, la base del árbol está en sus raíces, la base del avión es la imagen central, etc.) Luego clasifico el nivel más bajo al más alto, luego el más bajo (más alto en la pantalla) a la base más alta Y, luego la base-X más baja (más a la izquierda) a la más alta. Esto hace que las fichas sean como cabría esperar.

Código para convertir pantalla (punto) a mosaico (celda) y volver:

typedef struct ASIntCell { // like CGPoint, but with int-s vice float-s
int x;
int y;
} ASIntCell;
// Cell-math helper here:
// http://gamedevelopment.tutsplus.com/tutorials/creating-isometric-worlds-a-primer-for-game-developers--gamedev-6511
// Although we had to rotate the coordinates because...
// X increases NE (not SE)
// Y increases SE (not SW)
+ (ASIntCell) cellForPoint: (CGPoint) point
{
const float halfHeight = rfcRowHeight / 2.;
ASIntCell cell;
cell.x = ((point.x / rfcColWidth) - ((point.y - halfHeight) / rfcRowHeight));
cell.y = ((point.x / rfcColWidth) + ((point.y + halfHeight) / rfcRowHeight));
return cell;
}
// Cell-math helper here:
// http://.com/questions/892811/drawing-isometric-game-worlds/893063
// X increases NE,
// Y increases SE
+ (CGPoint) centerForCell: (ASIntCell) cell
{
CGPoint result;
result.x = (cell.x * rfcColWidth / 2) + (cell.y * rfcColWidth / 2);
result.y = (cell.y * rfcRowHeight / 2) - (cell.x * rfcRowHeight / 2);
return result;
}

Answer 4

Si tienes fichas que superan los límites de tu diamante, te recomendamos que hagas un dibujo en profundidad:

...1...
..234..
.56789.
..abc..
...d...

Answer 5

Actualización: Algoritmo corregido de renderizado de mapas, agregado de más ilustraciones, cambio de formato.

Quizás la ventaja de la técnica de "zig-zag" para mapear los mosaicos en la pantalla se puede decir que las coordenadas y la losa se encuentran en los ejes vertical y horizontal.

"Dibujando en un diamante" enfoque:

Al dibujar un mapa isométrico usando "dibujo en un diamante", que creo que se refiere a simplemente renderizar el mapa usando un bucle anidado sobre la matriz de dos dimensiones, como en este ejemplo:

tile_map[][] = [[...],...]
for (cellY = 0; cellY < tile_map.size; cellY++):
for (cellX = 0; cellX < tile_map[cellY].size cellX++):
draw(
tile_map[cellX][cellY],
screenX = (cellX * tile_width / 2) + (cellY * tile_width / 2)
screenY = (cellY * tile_height / 2) - (cellX * tile_height / 2)
)

Ventaja:

La ventaja del enfoque es que se trata de un bucle anidado simple con lógica bastante directa que funciona de manera uniforme en todas las fichas.

Desventaja:

Una desventaja de este enfoque es que las coordenadas y de los mosaicos en el mapa aumentarán en líneas diagonales, lo que puede dificultar el mapa visual de la ubicación en la pantalla del mapa representado como una matriz:

Sin embargo, va a haber una trampa para implementar el código de ejemplo anterior: el orden de renderizado hará que las teselas que se supone que están detrás de ciertos mosaicos se dibujen en la parte superior de las teselas al frente:

Para corregir este problema, el orden interno for -loop debe invertirse, comenzando por el valor más alto y representando el valor más bajo:

tile_map[][] = [[...],...]
for (i = 0; i < tile_map.size; i++):
for (j = tile_map[i].size; j >= 0; j--): // Changed loop condition here.
draw(
tile_map[i][j],
x = (j * tile_width / 2) + (i * tile_width / 2)
y = (i * tile_height / 2) - (j * tile_height / 2)
)

Con la corrección anterior, la representación del mapa debe corregirse:

Enfoque "Zig-zag":

Ventaja:

Quizás la ventaja del enfoque de "zig-zag" es que el mapa renderizado puede parecer un poco más verticalmente compacto que el enfoque de "diamante":

Desventaja:

Al tratar de implementar la técnica de zig-zag, la desventaja puede ser que es un poco más difícil escribir el código de representación porque no se puede escribir tan simple como anidado for -loop sobre cada elemento en una matriz:

tile_map[][] = [[...],...]
for (i = 0; i < tile_map.size; i++):
if i is odd:
offset_x = tile_width / 2
else:
offset_x = 0
for (j = 0; j < tile_map[i].size; j++):
draw(
tile_map[i][j],
x = (j * tile_width) + offset_x,
y = i * tile_height / 2
)

Además, puede ser un poco difícil tratar de determinar la coordenada de un mosaico debido a la naturaleza escalonada del orden de representación:

Nota: Las ilustraciones incluidas en esta respuesta se crearon con una implementación Java del código de representación de mosaico presentado, con la siguiente matriz int como el mapa:

tileMap = new int[][] {
{0, 1, 2, 3},
{3, 2, 1, 0},
{0, 0, 1, 1},
{2, 2, 3, 3}
};

Las imágenes de mosaico son:

• tileImage[0] -> Una caja con una caja adentro.
• tileImage[1] -> Una caja negra.
• tileImage[2] -> Una caja blanca.
• tileImage[3] -> Una caja con un objeto gris alto en ella.

Una nota sobre los anchos y alturas de los azulejos

Las variables tile_width y tile_height que se usan en los ejemplos de código anteriores se refieren al ancho y la altura de la tesela en la imagen que representa el mosaico:

El uso de las dimensiones de la imagen funcionará, siempre que las dimensiones de la imagen y las dimensiones del mosaico coincidan. De lo contrario, el mapa de mosaicos podría representarse con huecos entre los mosaicos.