Problemilla al hacer scroll

[Licantropo]

Hola, ya voy avanzando en mi juego, pero me he enconrado con un problema. Cuando hago scroll con el proceso de desplazamiento del personaje me va bien, pero al meter un proceso de disparo que utiliza las coordenadas del de desplazamiento como punto de inicio, el disparo a veces sale desde donde es y otras veces el punto de inicio del disparo no coincide con las coordenadas del desplazamiento. Si no hago scroll las dos cosas funcionan perfectamente.
No se si me he explicao muy bien, pero a ver si alguien puede ayudarme.
Hasta luego y gracias.;)

[theNestruo]

Nota: Supongo que estás haciendo un juego de plataformas, RPG, o cualquiera que tenga un "mundo" definido (vamos, que te mueves por una especie de "mapa"). Si estás haciendo un juego de naves (que el fondo va pasando, pero no tienes un "mapa" propiamente dicho), este post te va a valer de poco.

No sé exactamente cómo lo estás implementando, pero lo ideal es tener las cordenadas relativas al mundo completo (digamos wx,wy), y no a la pantalla (sx,sy)... aunque lo mejor es tener los dos a la vez (ahora explico cómo).
¿Cómo se traduce esto a la hora de implementar? Pues utilizas wx,wy para todos los cálculos (que se van a reducir a colisiones y creaciones de nuevos objetos, principalmente).
Tienes que mantener también las coordenadas del marco de visualización (es decir, las coordenadas de la parte del mapa que se está viendo en la pantalla) en todo momento. Con mantener las coordenadas de la esquina superior izquierda te vale. Vamos a denominarlas scrLeft,scrTop.
Cuando crees un objeto o lo muevas, utilizarás wx,wy para todos los cálculos, y al final calcularás sx=wx-scrLeft; sy=wy-scrTop.
Cuando scrolles la pantalla (suponiendo que no se esté moviendo todo el rato) cambiarán los valores de scrLeft,scrTop, por lo que tienes que recorrer toda la lista de objetos recalculando sx,sy con la fórmula anterior.
Y a la hora de pintar, como no todos los objetos estarán presentes en la parte de la ventana que se ve, tienes que hacer:


if ((sx>=0) && (sy>=0) && (sx<320) && (sy<240)) {
/* Dibuja el sprite */
}

Aunque eso no dibujará los sprites que queden "a medias" de salirse de la pantalla por los lados izquierdo y/o superior. Con cambiar los ceros por el ancho y el alto del sprite debería valer.
Por otra parte, como el ciclo de dibujar todos los sprites posiblemente vaya dentro de un bucle for o while, el código de arriba se puede optimizar haciendo lo siguiente:


for (/*todos los sprites*/) {
if ((sx<0) || (sy<0) || (sx>=320) || (sy>=240))
continue;
/* Dibuja el sprite */
}

Que lo que hace es comprobar cuando no hay que dibujar el sprite y salta al siguiente. Ës más rápido porque deja de comprobar en cuanto falla una de las condiciones; en el caso anterior tiene que verificarlas todas.

Si no entiendes algo o tienes más dudas, no dudes en ponerte en contacto conmigo (en este mismo hilo o por mensajes privados; como prefieras).

[Licantropo]

Hola, la idea tuya la he cogido y puede que sea el problema por algo de ese tipo, pero como has dicho el juego es tipo naves (es un Mercs). El scroll lo hago sobre el personaje y el mapa es simplemente un fondo. Al mover el personaje se mueve el fondo.

Program
...
id_personaje=personaje();
start_scroll(0, 0, 102, 0, 0, 0);
scroll[0].camera=id_personaje;
End

Process personaje()
Private
Int actualizado;
Begin
ctype=c_scroll;
posicion=1;
actualizado=0;
x=xp;
y=yp;
multidisparo();
Loop
xp=x;
yp=y;
actualizado=0;
graph=posicion;
Frame;
...
//Toda la movida de desplazamiento si se pulsa tal tecla (se
//modifica x e y)
End (Loop)
End(Process)

Process disparo_per(angle)
Begin
//aqui coloca las coordenadas de inicio del disparo
x=xp;
y=yp;
Loop
Frame;
...
//para mover el disparo (usoadvance)
End
End

Procces multidisparo()
...
//Lo unico que hace es llamar a disparo con una serie de
//condiciones
End

El problema se que esta en que en xp e yp no esta guardado el valor que yo quiero y eso se debera a que el scroll hace algo con
con las coordenadas del sprite. Pero no se realmente como modifica el scroll las coordenadas del sprite sobre el que se ejecuta. Esa es mi duda.
Creo que ahora queda mas claro.

Gracias por contestar, la idea tuya es buena pero tal y como lo he programado no sabria como aplicarla. Si descubro como modifca el scroll las coordenadas del process al que se le aplica el problema estara solucionado.

[Segata Sanshiro]

No falta el ctype=c_scroll; en los procesos de disparos? Igual es eso, que a mí esos errores me daban un mal rollo que no veas xDDDD

[Licantropo]

Si, era eso. Joe muchas gracias, eres la maquina. Ya tira bien, supongo que me surgiran mas dudas, porque llevo solo dos dias con el juego (por lo menos ya tengo el personaje que se mueve por el mapa y dispara). (Es el segundo juego que voy a hacer, el primero era bastante mas sencillo, el pong sport, ahi por ahi un hilo). Venga, hasta luego.

[theNestruo]

Cuando incluyas código mételo entre [ CODE ] y [ /CODE ], y así podremos leerlo mejor. :)

Volviendo al meollo de la cuestión:
- Si es de naves, el fondo no interactúa con el juego, por lo que puedes "olvidarte" de que está animado/scrollado: hacer todo el juego como si no hubiera scroll y únicamente aplicar el scroll al fondo.
- Si es tipo "mercs", el fondo sí que interactúa con el juego (hay zonas por las que se puede pasar y zonas por las que no: árboles, cajas, casas...), y entonces la mejor forma de hacerlo es con coordinadas relativas al "mundo", porque si no se complica mucho la cosa.

En tu caso (si lo he entendido bien) al mover wy del personaje, también se modifica scrTop, por lo que sy se queda constante. Si el mundo es igual de ancho que una pantalla, scrLeft es igual a cero siempre, y sx=wx, con lo que te ahorras unos cuantos cálculos.

No estoy familiarizado con el lenguaje que utilizas, así que no me he aclarado de lo que haces y en qué orden lo haces. Lo que se me pasa por la cabeza es que en tu código dispares primero y luego muevas al personaje, por lo que la bala saldría desde un lado o desde detrás del personaje. Si has puesto la rutina de disparo antes de la del movimiento, prueba a intercambiarlas, a ver si así sale mejor.

Un saludo, Nés.

Edit: ¡Habéis contestado (Segata y Licántropo) mientras escribía el post! De todos modos lo dejo, por si acaso alguna idea te viene bien.

[mortimor]

Te veo muy puesto Nestruo :D

Como va ese proyecto??? Yo no lo he presentao al final :(

A ver si podemos comenzar aquello que te comente cuando tengamos tiempo :)

Por otro lado... no veo por que han de complicarse las cosas si tiene que realizar calculos de colisiones, solo requiere tener una malla de colisiones que este sincronizada con el desplazamiento sobre el fondo.

Por norma general los calculos de colisiones son independientes de la representacion de los graficos y el renderizado de las escenas, tambien de la animacion. Si la escena se genera a partir de objetos, lo mas comun, puede que haya datos que coincidan, pero el procesamiento es totalmente independiente. Esto no funciona asi si estamos usando pixel-perfect o calculo de colisiones por buffer oculto como se hace en OpenGL normalmente, ambos casos son muy costosos: el primero por lo que todos sabemos de las mascaras y el segundo por que requiere renderizar las escenas dos veces por cada frame o keyframe si estamos ahorrativos.

En cualquier caso el Fenix es un mundo a parte :D;):D

[theNestruo]

¡Hola Mortimor! Mi proyecto sigue a su ritmo: es decir, a paso tortuga (me tendré que salir de una vez de la hostelería, ¡porque esto no puede ser! :) ). A ver si ahora que se acaba el veranito de marras consigo ponerme más en serio y para febrero me lo quito de encina.

Respecto a las complicaciones de calcular las cosas con sus coordenadas en pantalla... pues ahora que lo pienso, tienes razón: no se complican de más... en este caso. De todos modos, sigue siendo mejor tenes las coordenadas absolutas por un lado y las relativas a pantalla por otro: imagínate que rota la pantalla, que puedes hacer zoom, que puedes "mirar" (desplazar la pantalla sin mover al muñeco)... Si calculas todo con coordenadas relativas a la pantalla, a la hora de comprobar si un muñeco se puede mover (es decir, a la hora de comprobar su posición en el mapa, en el array de durezas, o en lo que estés usando) te toca volver a hacer todos los cálculos, pero a la inversa. Eso es lo que yo tenía en mente :) .

Pero como tú decías... Fénix es un mundo aparte. Parece ser que el problema venía de otro sitio totalmente distinto, así que mis parrafadas habrán conseguido, como mucho, levantar dolor de cabeza a más de uno. :D

Saludos.

[Slàinte]

conoces una funcion llamada get_real_point? seguro que te ahorra algun que otro quebradero de cabeza