ayuda please,graficos en 2 planos

[Neodreamer]

Hola, tengo una duda y no se donde hayar respuesta.
En un juego de aventura grafica o tipo resident evil, como hago para q mi personaje pase delante de un objeto(normal siendo el proceso principal tapa el resto de fondos, ejemplo un sillon) y para q pase x detras de el objeto(x ejemplo en unas escaleras de caracol, al pasar por detras de una columna o cosas asi.)
Por favor ayudadme a ver como se haria, xq se q con deteccion de colisiones conseguiria q no los traspasara, pero al pasar por detras(o paso por encima es decir, parte alta del objeto, o lo bordea pero no lo pasa por detras siendo el prota tapado de forma parcial).
gracias
1saludo

[Hokutoy]

Has de usar la variable z=numero
Así como la X y la Y definen las cordenadas de la posicion del objeto, la Z determina su "profundidad".
Prueba a poner una Z a los objetos diferente a los del prota para que estos queden en primer plano o en segundo.

Byes

[Neodreamer]

por lo q me dices deduzco q cada objeto q pretenda usar para dar sensacion de profundidad ha de ser tratado como un proceso independiente del fondo y asi variar las zetas de el jugador y de dichos objetos?
creo q no debe ser muy complicado pero si q engrosara la memoria asik tratare de q sean pooks los objetos y q cada habitacion sea un fpg o algo asi para aligerar la ram.
gracias
1saludo

[bulbastre]

Qué juego vas a hacer?

[Darumo]

añadiendo a lo que dice Neodreamer, divide los objetos en FPG segun su uso, los objetos que mas se repitan en las pantallas en uno (es una tonteria descargar de ram y meter otro fpg con la mitad de los objetos repetidos, seria un despedicio de espacio y un aumento de tiempo en las cargas), y los exclusivos de cada pantalla y su fondo en otros aparte.

[Segata Sanshiro]

Buenas,

En mi engine esto funciona así:



process objeto(graph,x,y);

begin
z=-y;
loop;
frame;
end
end


Así, como Z puede ir de 1000 (más debajo) a -1000 (más arriba), y por lógica, un objeto que esté en unas coordenadas Y más bajas (más alto en la pantalla) estará más por debajo. Puede sonar lioso pero en la práctica funciona. Una vez hecho eso, el código del prota debe llevar una sentencia:


y=-z; dentro de un loop. Javac tiene mi engine, creo :confused: xDDD

[Neodreamer]

segata, q me pones?
una cosa, a ver si tiene q ver con el codigo expuesto.
He pensado q lo de la z y lo de tratarlo como proceso esta bien, pero como hago para q tenga una profundidad cuando paso x delante y otra cuando paso x detras?
Es q supongo q si le pongo situado x delante del personaje, estara ahi siempre.
Poneros de ejemplo una columna en medio de una habitacion a la q quiero dar vueltas o un sillon o algun objeto.
otra cosa, no entiendo eso de q le pase -y a z desde el prota....me lo podrias explicar un poko mejor?

gracias a todos
1saludo

p.d: en principio queria hacer el juego con graficos un poko especiales( a lo mejor gustan a lo mejor no) usandome de personaje y retokando fondos fotorealistas. Sera algo como poko curioso. El tema seria algo asi como el estado de emergencia de ps2 pero con zombies en una mansion o centro comercial u hotel.

[Hokutoy]

Aunque al principo me he quedado igual con la explicacion de Segata (no lo pillaba) al final he empezado a entenderlo.
Basicamente, haciendo como lo dice Segata, si la Y de tu personaje es inferior al del objeto (sillon en medio de la habitacion) el personaje pasará por detras. Si la Y del prota es mayor, este pasara por delante del sillo. Y si la Y es parecida, pues haces (con collision por ejemplo) que no lo pueda atravesar.

No se si te ha servido de ayuda, con codigo no te lo puedo explicar... a ver si Segata desarrolla mas la idea que a mí tambien me interesa.
THX

[Segata Sanshiro]

A ver si lo entendéis con este esquema, según el código que he puesto, la escena quedaría así: (el gris es el obstáculo y el rojo es el protagonista).

PD: Las colisiones no se hacen con collision(), sino con un mapa de durezas, aunque eso es otra historia.

[Darumo]

mira, mas o menos por lo que me parece entender es que funciona segun la altura del personaje, vamos que en una vista en la que el suelo se vea ligeramente inclinado, el muñeco segun su altura se le pasaria como una profundida (al fin al cabo el estar el muñeco mas al fondo tambien es que el muñeco este mas arriba)

http://www.iespana.es/darumo2000/otros/ejemplo.gif

si pones Z=Y deberia verse el muñeco como en la segunda imagen, ya que la Y del muñeco es menor que el de la mesa, y al igualarla la Z a su Y queda en que el muñeco tiene una Z menor que el de la mesa (esta tambien debe tener su Z=Y correspondiente) y por lo tanto queda ordenado por detras.

[Locke]

Para mi eso tiene el problema de los diferentes angulos de camara, por ejemplo, para una vista desde arriba no se si seguiria sirviendo... (no lo se, porque tampoco me he puesto a entender bien la idea). Ademas, no tengo muy claro como funciona el fenix, pero supongo que la Y es la coordenada del borde superior del sprite...


De todas maneras, yo tambien andaba dandole vueltas a un engine de este tipo. Pienso que los fondos prerenderizados son una manera de ir introduciendo las 3D en la consola, ya que se mueven muy poquitos poligonos...

[Neodreamer]

Muchisimas gracias a todos, es como pensaba q decia segata.
A ver ahora si sale algo decente de lo q no avergonzarme y se lo paso a anarchy para q lo ponga x aqui.
1saludo y seguid poniendo experiencias q siempre viene bien.
gracias de nuevo

[Neodreamer]

Segata, la z del prota se deberia inicializar con algun valor en especial? Se inicia junto a la x e y verdad? la del objeto la toma directamente de la coordenada y inicial no?

digamos q el ejemplo seria asi?

------------------------------------------------------------
process prota();

begin
graph=1;
x=20;
y=20;
z=10; // como sabemos la profundidad q nos da este valor?
// o es solo una referencia de comparacion?

loop
y=-z;
x=mouse.x; // ejemplo para pc con raton.

//aqui es donde me pierdo....
// si la y varia segun -z....
// como controlo la y del prota desde el raton (o gp32)?
// seria con z=mouse.y; ????
frame;
end
end

process sillon(30,30);

begin
graph=2;
z=-y;
loop;
frame;
end
end

// todo lo referente al objeto es facil x no tener
//movimiento sino coordenadas fijas.

---------------------------------------------------------------------------

gracias como siempre.
1saludo

[Neodreamer]

Segata, me temo x lo q he leido q la solucion q has dado tenia logica pero esta mal....te cuento para ver si hayamos otra solucion.

Las z en fenix van desde el fondo de pantalla q usa la z=512, los modos 7 con z=256, nuestro prota normal z=0; los textos en pantalla z=-256 y por ultimo el cursor del raton en z=-512.
Esto nos crea el conflicto de q en una pantalla de 640x480 por poner un ejemplo, cuando la y llegue a la coordenada 300, z valdria en tu ejemplo -300 asik taparia marcadores de vidas y cosas asi....(creo).

Creo q seria mas facil simplemente poner una linea o rectangulo de color rojo en la base del sillon u objeto, hacer un get_pixel para la dureza y asi solo reducir una unidad por encima o debajo de la z original del objeto.

Me explico. Si la z de el prota es 0, le ponemos de origen al sillon -1 para q al pasar x encima de la base del objeto pasemos por detras y al bajar esa linea, le pasamos el valor de z del sillon a 1 para q el prota pase por delante.....

Es mucha la burrada q propongo? es q es una simple teoria pero no la he probado y ademas no se bien como pasaria la variable desde un proceso a otro......seria con id_ o algo asi?

Asi creo q evitariamos q el rango q tomase z variase tanto.

1saludo, ya me direis q os parece.

gracias

p.d: Con el grafico se ve mejor, incluso me he aclarado yo en q la z del objeto no ha de variar nunca sino la del prota en 1 unidad.

[Darumo]

getpixel a lo mejor seria lento, y tambien dudo que sea eficaz lo que dices para mas de 1 objeto en la pantalla, si la Y fuera tan grande como para que al igualarla a Z se metiera en marcadores y demas como tu dices pienso que un simple Z= -Y /2 lo solucionaria, solo que en vez de ordenarse por pixel de altura lo haria cada 2.

[Neodreamer]

Creo q me he equivocado en mi teoria, pero es q el codigo q puso de ejemplo segata me dejo un poco KO.
A ver si es error suyo o me lo explicais para q lo entienda:
Cuando dijo de poner en el proceso prota la linea
y=-z;
No deberia ser realmente:
z=-y;
para q como deciamos entre todos, al superar por debajo o por encima al objeto, la z se actualice segun la cordenada de y manteniendo la z del objeto y saber asi si esta delante o detras.
Pongo su codigo a ver si me explico mejor....

code:-----------------------------------------------------------------------------
process objeto(graph,x,y);

begin
z=-y;
loop;
frame;
end
end
------------------------------------------------------------------------------------

(proceso prota)
code:-----------------------------------------------------------------------------

y=-z; //Esto es lo q digo q va al reves: z=-y;
------------------------------------------------------------------------------------

[Darumo]

si, el se referia a poner Z= -Y , si miras mis primeros ejemplos veras que pone Z= Y un fallo mio por que no sabia bien como iba el sistema de profundidad de Z que en el siguiente ya corregi como Z = -Y, ademas de que indique que tambien se podria poner Z = -Y /2 , asi saldria numeros de Z mas pequeños y poder controlar mejor de que no se pongan en una prioridad mayor que la de los marcadores.

[Segata Sanshiro]

Sip, creo que me he equivocado xD Es siempre z=-y;

Lo que hay que utilizar es un map_get_pixel(); Lo normal es que por un lado tengamos el mapa que se ve en pantalla, que es grande y que ocupa mucha memoria. Para no tener que enguarrar ese mapa con colores para las durezas, se suele tener un mapa más pequeño dentro del fpg, y que está dedicado totalmente a guardar las durezas. Es muy necesario ahorrar memoria en GP32, así que dependiéndo de la reducción que apliquemos a este mapa de durezas, al meter las coordenadas x e y habrá que dividirlas por cierto número. Así, si el mapa es la mitad del que se ve en pantalla, será x/2 e y/2.

Por cierto que para ahorrarse problemas, recomiendo cambiar el punto de control 0 (el que indica la x y la y del gráfico y que normalmente está en el centro exacto del mismo) a la parte de abajo y centrado.

[Segata Sanshiro]

Sip, creo que me he equivocado xD Es siempre z=-y;

Lo que hay que utilizar es un map_get_pixel(); Lo normal es que por un lado tengamos el mapa que se ve en pantalla, que es grande y que ocupa mucha memoria. Para no tener que enguarrar ese mapa con colores para las durezas, se suele tener un mapa más pequeño dentro del fpg, y que está dedicado totalmente a guardar las durezas. Es muy necesario ahorrar memoria en GP32, así que dependiéndo de la reducción que apliquemos a este mapa de durezas, al meter las coordenadas x e y habrá que dividirlas por cierto número. Así, si el mapa es la mitad del que se ve en pantalla, será x/2 e y/2.

Por cierto que para ahorrarse problemas, recomiendo cambiar el punto de control 0 (el que indica la x y la y del gráfico y que normalmente está en el centro exacto del mismo) a la parte de abajo y centrado.

Y sed generosos con las durezas, que más vale que se choque el protagonista con una pared inexistente que ver cómo las traspasa.

[Neodreamer]

Gracias tio, te has portado!!!!
1saludo

[Segata Sanshiro]

Nada, tranquilo, pronto se me cruzarán los cables.

[nazca]

Nada, tranquilo, pronto se me cruzarán los cables.

Tio, eso suena a algo serio. Yo conozco a algún que otro profesional que podría ayudarte en estos casos.

PD: Es brooooma ;)