Concepto de escenarios pre-renderizados

[Barduck]

Siempre tuve esta duda y si alguno con experiencia en el tema me puede explicar... juegos como el gran Commandos I o el Diablo I, Baldurs Gate, entre otros, son juegos en 2D pero con escenarios muy atractivos que aparentan estar en 3D.
No estan hecho con un sistema de tiles (al menos no aparentan por su variedad grafica), por eso es que no llego a entender su implementacion.

Me refiero a que el fondo seguramente este hecho en un programa 3D y sea una imagen, pero como es la tecnica para las colisiones, y tambien, para las superposiciones? acaso se utilizan multiples capas? las colisiones son "invisibles"?

PD. No se si puse el post en el lugar correcto, no estaba seguro donde colocarlo.

[fjfnaranjo]

Hombre, no se, eso se lo tendrás que preguntar a los programadores  :P

En el caso del Commandos original, la sensación que yo tenía es que el escenario estaba integro renderizado y se copiaba a la pantalla, probablemente dando margen en los bordes para desplazar la camara sin esperas, si alguién del foro curró en el Commandos que nos lo confirme. De todas formas, hay cosas que no se podrían renderizar de esta forma, como los objetos que se pintan por encima de los personajes (cables que sobrevolaban y tal), pero los renderizarían a parte.

Luego, para el Diablo, la sensación que me da es que está construido por celdas. Esto es, como el Commandos, sólo que en vez de renderizar el escenario completo en una imagen, renderizas partes del mismo. En el Diablo da esa sensación porque los escenarios tienen un cierto rasgo de aleatorización que apunta a esto, siendo algunos patrones del suelo reconocibles entre diferentes partidas (me viene a la memoria la explanada donde te cargas al chaman verde, el que resucita a otros chamanes). Aparte, también hay objetos que se pintan por encima del personaje.

Para cosas más complejas, podemos por ejemplo ver el Commandos II, donde los interiores son 3D completo, pero el exterior más bien parece como las capas que digo para el Diablo pero para objeto por separado.

En fin, no estoy seguro, son ideas que me vienen.

[tamat]

para esos juegos se generaban renders con imagenes gigantes para los edificios y demás, luego se montaba la imagen por capas para evitar solapamientos.

ademas el sistema tenía información 3d muy simplificada de la geometria de la escena, y es la que utilizaba para temas de colisiones, campo de vision de las entidades, etc.

realmente tecnologicamente no tiene mucho misterio, lo complejo es construir todo el arte y que encaje bien en la pantalla.

[[EX3]]

Si alguno trasteo con el Div Game Studio en su dia recordara el juego Tokenkai, que venia su primer y segundo nivel con el codigo fuente y demas recursos, era un buen ejemplo para hacerse una buena idea de como funcionaban motores de los juegos mencionados ya que se asemeja mucho con lo comentado aqui por fjfNaranjo y Tamat.

Salu2...

[TrOnTxU]

...
ademas el sistema tenía información 3d muy simplificada de la geometria de la escena, y es la que utilizaba para temas de colisiones, campo de vision de las entidades, etc.

...

¿Estas seguro? A mi me suena que en el Comandos se pintaban las colisiones, sectores, etc en photoshop en una capa encima de la imagen ya renderizada, esta capa se exportaba aparte y se utilizaba como mapa  de "durezas" (como lo llamaban en el Div). Digo me suena, por que me lo contaran asi, yo NO he currado en Pyro.

De este modo las coordenadas del personaje se pueden mantener 2D(x,y) y no hace falta tener la representacion 3D(x,y,z) y tener que ir pasandola a 2D para situar el sprite a renderizar (esto quizas seria mejor para un estilo Marble Madness en "isometrico puro").

El mapa de durezas (MD) puede tener cualquier representacion parecida a una imagen (matriz NxM), aunque al no tener que dibujarse (excepto por casos de depuración) deberia estar en RAM de CPU para realizar las comprobaciones (aunque actualmente se podrian trabajar con modelos de shader > 3 y con las texturas en memoria de tarjeta).
En un ejemplo de color indexado a 256 colores tenemos un byte para cada pixel del MD, del que podemos utilizar por ejemplo 3 bits(8valores) para indicar el nivel de z (como orden de dibujado respecto a otros elementos), tres mas para el tipo de terreno (bloqueado, hierba, nieve, agua,  ...) y nos quedan dos bits que podemos utilizar para cualquier flag.

Otra cosa es que tampoco necesitas la resolución de la imagen de visualizacion, asi que podemos tener un mapa un 25% más pequeño(por ejemplo), y para encontrar la correspondencia del mapa de render con el de durezas solo tenemos que dividir por cuatro:

Código [Seleccionar] Expand

// (suponiendo que utilizamos valores enteros como coord 2D)
xdurezas = (xscreen + xscroll) >> 2; ydurezas = (yscreen + yscroll)>> 2;

Tambien debes tener en cuenta que los sprites que esten dentro del mismo z (orden de dibujado) se deben dibujar segun su coordenada Y (que deberia de estar en el "bottom" o pies del objeto/sprite), de modo que el "personaje" que tenga los pies con mayor Y (más abajo) se pintará después que el que los tenga más "alto".

Por ultimo opino que los pathfinding (A*, crash&turn, etc) pueden funcionar mejor (mejor tiempos de ejecución, y mayor facilidad de implementación)  con esta representación que con representación 3D.

Pero es solo una opinión.
¿Alguien se le ocurren otras implementaciones o porque seria mejor utilizar representacion interna 3D de las coordenadas y pasarlas a 2D solo al dibujar?

Salu2

[[EX3]]

¿Estas seguro? A mi me suena que en el Comandos se pintaban las colisiones, sectores, etc en photoshop en una capa encima de la imagen ya renderizada, esta capa se exportaba aparte y se utilizaba como mapa  de "durezas" (como lo llamaban en el Div). Digo me suena, por que me lo contaran asi, yo NO he currado en Pyro.

No he jugado a Comandos (teneis permiso para flagelarme por hereje :P) pero me he hartado de ver a amigos viciarse "in extremis". Si mi memoria no me falla, en Comandos 1, en los niveles que recuerdo, no habia zonas superpuestas transitables (diferentes pisos o niveles superpuestos por donde manejar al jugador). Si es asi tendria mas sentido que hubieran usado un mapa de durezas que un sistema de colision con informacion 3D.

Salu2...

[Buffon]

Si no recuerdo mal, en comandos1 no habían pisos, pero en el 2 sí.

[TrOnTxU]

Si no recuerdo mal, en comandos1 no habían pisos, pero en el 2 sí.

En el uno podias ir navegando por el agua con la barca justo debajo de un puente por el que podias ir andando si no recuerdo mal. Esto serian "pisos", pero se podria solucionar si un bit indica si es "walkable", y otro si es "navegable". El dibujar el puente por encima o no se solucionaria con la info de z(orden de dibujado).
Con más información se podria indicar un rango de altura actual en la posicion en el mapa de durezas, y limitar el paso de una altura a otra, etc.
Tambien se podrian tener mapas de "sectores" para diferentes pisos y zonas del mapa, y hacer "links" entre ellos.

No sé, son ideas.

Salu2

[tamat]

en el 1 no lo recuerdo pero en el 2 había un modo en el que podias ver la mesh simplificada y los conos de vision, era un modo debug que dejaron activado.