Acerca de las Z

Drumpi · October 03, 2009, 03:24:20 PM

Hola a todos:

Se me ha planteado una duda bastante curiosa. Como sabeis, estoy liado con el motor de scroll tileado, y ya sólo me queda solucionar el tema de las z, que me trae por la calle de la amargura.
De momento, lo que hago es que cada fila horizontal de tiles tiene una z que vale -2 que la de arriba, y le resto otros 2 por cada tile que subimos en el eje z. Uso el 2 como base para intercalar los sprites en medio.
El problema lo tengo en las esquinas, porque a poco que el personaje sea ancho en los pies se me tapa con el tile de la fila de abajo. Así que he pensado otro método que requeriría usar z aun mayores a las que ya uso.

Las z tienen el mismo límite que un int ¿no? tanto positivo como negativo. ¿Podría suponer un problema con el resto de "objetos" que tienen una z predefinida? (scrolls, textos...) no hablo sólo para el lenguaje, sino a vosotros, como programadores, por tener que modificar sí o sí la z de los textos.

PD: No he encontrado nada acerca de X, Y y Z en el wiki, no están ni en la lista de variables locales predefinidas.

FreeYourMind · October 03, 2009, 04:55:39 PM

Y porque los tiles tienen distintos valores de Z ?

Windgate · October 03, 2009, 06:09:28 PM

Cierto... En principio no debería haber diferencia de Z en las diferentes horizontales de tiles del mismo scroll... ¿No?

Aún no me he puesto a hacer un proyecto de semejante en-verga-dura como para tener una seria preocupación por las Z, pero tengo claro que llegado el caso habrá que hacer un "mapa de z" que dictamine qué elementos tienen qué rangos de Z y programar en consecuencia.

Mientras dejes claro qué rango de Z usas o cómo puede cambiarse no creo que vaya a haber problema Drumpi.

DjSonyk · October 03, 2009, 11:54:46 PM

Buenas Drumpi,enteoria si la Z deverian de tener el mismo rango que un INT que me imagino que NO sera un INT UNSIGNED,ya sabes que su valor es de -32.768 a 32767...
Por otro lado deverias tener una capa entera con la misma Z en todos sus Tiles,otra capa con la misma Z para sus Tiles ,pero mas arriba o mas abajo que la anterior,y porsupuesto mas profunda que todo ser "Viviente " del juego para que no les oculten,el que se tapen los pies al personaje seguramente es porque esa fila de Tiles es menos profunda que el propio personaje ,pero como te digo para una capa entera pueden tener el mismo valor,cambiar la Z porque este un tilde mas arriba no es "Correcto",lo es ,pero no tiene sentido ;).

Drumpi · October 04, 2009, 12:35:48 AM

En un scroll tileado normal bastaría usar una Z por cada capa y punto.
Pero estoy hablando de un scroll isométrico, que simula 3D, por lo tanto tengo que trabajar con profundidades. Si el suelo fuese liso no habría problema, pero cuando cada tile es un cubo, tienes diferentes alturas y demás, tienes a unos procesos tapando a otros que están más lejos o por debajo.
A eso súmale los personajes moviéndose por pantalla: imagina una sala vacía con un cubo en medio, si tengo un sprite con una 'Y' (de pantalla) menor se debe mostrar detrás del cubo, al estar más lejos, si hay otro sprite con una 'Y' (de pantalla) mayor que la del cubo, se debe mostrar delante. No tengo que explicar lo que pasa si el prota está en el hueco entre dos cubos o cuando tenemos más de dos o tres plantas.

Por eso, cada linea horizontal tiene una Z distinta, y las capas tienen otras.
La duda viene por si dotar a cada capa de un rango de Zs exclusivo (por ejemplo, el suelo usa capas de 0 a -10, la primera planta de -11 a -20...) que sería lo suyo, o simplemente que las plantas superiores tengan la misma Z que la planta de abajo -1, que ahorraría valores de Z.

Todo el día liado y no consigo que el personaje se oculte bien tras los cubos, tengo un error por ahí de medio tile que me tiene amargado.

DjSonyk · October 04, 2009, 02:31:54 AM

Humm ...
Recordando esos buenisimos juegos,batman,Head Over Heels,ect, me trae a la mente como estaban "codificados"...
yo lo que haria seria hacer al menos para el suelo diseños planos,y los que serian los primeros añadirles otros planos que seria el canto vertical,con lo que el suelo lo podrias tener todo con una Z,pues como te digo segun el "FlashBack"que tengo de ese tipo de juego, claro esta que tambien lo puedes hacer con las plataformas o las plantas como las llamas,pero seria mas trabajo,esas las dejaria cubicas y daria menos profundidad a las que estuvieran mas cerca de "ti" y menos a las que estuvieran al fondo pero mas que al suelo,y al personaje le tendrias que dar mas que el suelo,si lo que quieres es ahorra Zs,seria hacerte una funcion o proceso que las asignara automaticamente ^^.De todas formas si me pasas el codigo te ayudo o te ayudaria mas ^^.

Windgate · October 04, 2009, 10:06:01 AM

Sobre las z, ojo con el ctype del proceso "tile" y del proceso "jugador", en su día comprobé que procesos con ctype=C_SCROLL tienen una z "más profunda" que profesos con ctype de pantalla. ¿Ya lo sabías no? :P

Drumpi · October 04, 2009, 12:58:03 PM

DjSonyk: si, eso es lo facil, adaptar las Z en función de lo que hay en pantalla, pero el problema es que esto es un scroll genérico, que debe funcionar en todos los programas posibles, por lo que hacer una personalización de las capas es muy complicado. Además, ten en cuenta que en un momento dado nos podemos juntar fácilmente con cientos de procesos en pantalla y gestionar las Z sería muy lento, por eso en el código recurro a cálculos ya hechos. el código lo tienes en la seccion de proyectos, en el scroll tileado 3.2

Windgate: si, se que los scrolls, modos7 y demás se situan en una z más alejada, pero eso no debería ser problema. Modifico las z de los procesos, así que siempre van a estar en las profundidades que les digo, otra cosa es que el que lo use controle la Z de sus procesos (aunque por eso cree la función que lo situa en pantalla, para que no se tenga que preocupar de ello.

SplinterGU · October 04, 2009, 03:11:27 PM

mira, actualmente la z del scroll normal es de 512 (atras), la del mouse es -512 (se puede modificar), no hay limites de Z solo lo que pueda procesarse en un entero con signo...

Drumpi · October 04, 2009, 05:47:43 PM

Gracias, Splinter, es justo lo que sospechaba :)

Drumpi · October 07, 2009, 10:10:54 PM

Bueno, día de descanso y resulta que doy un paso enorme hacia atrás.
Me he dado cuenta de que con el actual sistema de Zs, si un personaje mide dos tiles de altura o sube, será tapado por cualquier tile que esté una "planta" por encima (digo planta porque ancho y alto los uso para referirme al plano horizontal).

Así que necesito volver al sistema primitivo, pero me surge un par de ideas, y como debo tener el cerebro totalmente simétrico o algo así, pues no me decido.
Os comento: en el espacio isométrico, cuanto más abajo se pinte el tile, más cerca está de la cámara y menor será su Z ¿correcto? bien. Cuando queremos poner un tile a una altura superior, este debería tener la misma Z que los tiles que hay en su vertical, pues su distancia a la cámara es la misma.
Pues eso no debe ser así, porque los tiles de mayor altura deben tapar a todos los tiles que hay por debajo, por lo que deberían tener una Z menor.

Y aquí surge el problema: ahora tengo al personaje que mencionaba antes, de dos tiles de altura, y cuando está más cerca de la cámara debería verse por encima de ambos tiles, por lo que su Z es aun menor que la del tile de más altura. En teoría creo que puedo implementar este sistema, pero debería dejar varios valores de Z entre fila y fila de tiles, y esta diferencia dependería de la altura del mayor gráfico que vayamos a usar (y para no pillarme los dedos debería ser del número de filas que cabe en pantalla + 1). Es un sistema complejo pero no tiene el inconveniente del siguiente.

El otro es hacer que todos los tiles de la misma vertical tengan la misma Z. Lo bueno de este sistema es que entre fila y fila puedo dejar una diferencia de 2 unidades de Z para que estén los procesos moviéndose, y simplifica mucho el código. La pega es esa, que todos los tiles de una "columna vertical" tienen la misma Z, y se vería el flickering o como se llame a la superposición aleatoria de ambos procesos, y sería trabajo del diseñador impedir que dichos tiles se solapasen; no es nada difícil pero sería una cosa bastante importante a tener en cuenta, y al usar más tiles no se podría aprovechar el mismo mapa como durezas sin complicar demasiado el código, necesitarías cargar otro mapa (hacerlo es sencillo, el problema es ocupar más memoria).

Así que esas son mis dos alternativas, creo que en la primera puedo hayar algo que me simplifique algunos cálculos, pero quiero saber vuestra opinión, y qué creeis que valoraría más el novato que quiera usar el motor de tiles.
Gracias.

TYCO · October 08, 2009, 06:06:37 PM

Quote from: Drumpi on October 07, 2009, 10:10:54 PM
El otro es hacer que todos los tiles de la misma vertical tengan la misma Z. Lo bueno de este sistema es que entre fila y fila puedo dejar una diferencia de 2 unidades de Z para que estén los procesos moviéndose, y simplifica mucho el código. La pega es esa, que todos los tiles de una "columna vertical" tienen la misma Z, y se vería el flickering o como se llame a la superposición aleatoria de ambos procesos, y sería trabajo del diseñador impedir que dichos tiles se solapasen; no es nada difícil pero sería una cosa bastante importante a tener en cuenta, y al usar más tiles no se podría aprovechar el mismo mapa como durezas sin complicar demasiado el código, necesitarías cargar otro mapa (hacerlo es sencillo, el problema es ocupar más memoria).

Mmm esto no podrías solucionarlo con "priority"??? creo que te serviria para que no te den problemas los procesos con misma, y así sería la solución con código más simplificado para quien quiera usarlo.

Drumpi · October 08, 2009, 08:29:28 PM

Mmmm, añadir priority a la lista de cosas a tener en cuenta no me gusta. De todas formas, use el método que use, el que quiera hacer un scroll tileado con mi motor no tendrá que preocuparse de calcular la Z (eso lo hace esta función que tantos problemas me está dando), sólo de que textos y otros procesos que deban ir por encima del scroll tienen que decrementar su Z si hay demasiados tiles :D

Windgate · October 08, 2009, 08:41:32 PM

Para lo que comentas de los pisos:

Se me ocurre que mantengas en una variable el número de planta en el que se encuentra el personaje.

Todo piso en planta superior tendrá una z mínima, por ejemplo -256 y pisos superiores -257, -258...

Y todo piso en planta inferior tendrá una z máxima, por ejemplo 255 y los pisos inferiores 254, 253...

Es una forma de asegurar que toda planta superior tape cualquier tile bajo ella y que toda planta inferior siempre sea tapada por cualquier tile sobre ella...

¿Problemas? He determinado como z mínima -256 y todo iría bien salvo que aparezcan 256 tiles verticalmente en pantalla... Siempre podría hacerse menor esa "z mínima"...

Si te sirve de inspiración pues me alegro xD

Drumpi · October 09, 2009, 12:04:47 AM

Ese es el método actual... si lo he entendido bien.
Cada planta tiene unas Z asignadas, por ejemplo, la primera desde 0 a "numero de lineas verticales" * 2, la siguiente desde ("numero de lineas verticales" * 2)+2 a ("numero de lineas verticales" * 2)+2+("numero de lineas verticales" * 2)... todo esto en negativo.
Suponiendo 10 lineas, la planta 0 tendría Zs con valores de 0 a -18, la planta 1 de -20 a -38, la planta 2 de -40 a -58, etc.

El problema es cuando, por ejemplo, el prota mide dos tiles de altura. Imagina dos cubos apilados, y el prota se pone delante, o sea, más cerca. El prota tapa al cubo de la parte inferior por estar en la misma "planta", pero el de arriba, al tener 20 Zs menos le tapa la cabeza.

Básicamente la duda es si debo romperme la cabeza con el método ya pensado o no hacerlo y obligar al usuario a crear tiles que no se solapen, nada más.