Acercandose a la camara

[Futu-block]

Drumpiiiiiiiiiiiiiiiiiiiiiiiiiii

a ti mas que ná por el motor de tiles que tienes...

La cuestion es que tengo un escroll enorme y quiero que cuando el enemigo esté a tal distancia, se cree y si no se destruya o se congele o pause, como consuma menos recurso

¿como se haria? ¿es mu coñazo? ¿en verdad no hay una funcion especifica como ''scroll chamera'' o cualquier pamplina de eso? ¿que sabeis?


Los que no sois drumpi tambien podeis responder, je je je

[Drumpi]

No me queda claro si lo dices por el motor de tiles o no, pero bueno, te respondo a ambas:

En un scroll normal, la única forma que existe es que tengas un proceso encargado de vigilar si el enemigo u objeto está cerca de la cámara, y en caso afirmativo, crearlo o despertarlo (dependiendo si lo tenías creado o no), y que sea él mismo el que compruebe la distancia de la cámara para dormirse o morirse.
La mejor forma que se me ocurre es que tengas una lista enlazada (o un array de un tipo que te crees tú) en el que venga la información de todos los enemigos y objetos del nivel (posición, tipo de enemigo u objeto, comportamiento...). A cada frame, el proceso de control compruebe uno a uno los elementos de la lista para ver si están lo suficientemente cerca, y entonces crearlos  y sacarlos de la misma (o marcarlos como ejecutados). Si el enemigo sale de pantalla, se vuelve a meter en la lista (puedes hasta cambiar la posición del scroll en la que estaba), el orden dentro de la lista daría igual.

En el caso del motor de scroll tileado, el ejemplo lo tienes en el Echo, en el fichero add_tile.inc: lo modifiqué para que, si el tile a mostrar tenía un gráfico inferior a 150, se ejecutase de forma normal, pero si no, crease el enemigo/objeto necesario, así es el propio motor el que se encarga de generar los objetos. Eso sí, con el gráfico indico el enemigo, y el mapa de durezas me indica su comportamiento o algo especial, y además, el propio enemigo debe modificar el mapa de tiles para poner su posición como "no hay tile ni enemigo ni na de na" para que no se vuelva a crear.
Lo que pasa es que en el Echo, una vez creado el enemigo, este no se elimina ni se congela, es una de las cosas pendientes de las próximas dos releases.

En ambos casos, es importante sincronizar los enemigos con algo (un timer, un contador de frames...), o te puede pasar como en la 4ª pantalla del primer nivel del Echo, con el pasillo de los soles, que va cada uno a su bola.

[Futu-block]

vale, me has echo ver la luz...
je je

una ultima pregunta, ¿que es mas comodo o menos pesado, crear y destruir o congelar y descongelar?
¿un proceso se auto congela y auto despierta??

[Windgate]

A ver si me entero:

Si quieres que el proceso se congele cuando esté fuera de pantalla y se descongele en otro caso tienes:

IF ( out_region ( id , 0 ) )
   signal ( id , S_FREEZE );
ELSE
   signal ( id , S_UNFREEZE );
END

Congelar es más costoso a nivel de memoria, pero matar es más costoso a nivel de procesador, o eso juraría :D

[Futu-block]

el problema es que la region debe de ser mas grande que la pantalla

¿hacerle un break es menos costoso que matarlo??

[Windgate]

BREAK no mata, BREAK sólamente rompe bucles e iteraciones.

[Fede]

¿Con hacerle un 'break' te refieres a que se mate él sólo o a matarlo con un signal?

[Futu-block]

me refiero que se mate solo, pero al parecer rompe el bucle y parece que desaparece el proceso y resulta que puede quedad residuos por ahí...

[Fede]

¿Si un proceso no se mata, sino que se acaba, quedan residuos?

[Futu-block]

no te extrañes, a ver que dicen los expertos que no lo tengo mu claro

[Drumpi]

A ver, por partes:

Crear/destruir procesos siempre es más costoso que congelar/despertar, porque se tiene que liberar memoria, reasignarla, añadirle un número de ID al proceso, reconfigurar el árbol de procesos... No he hecho pruebas exahustivas, pero calculo que hay un 10% de diferencia en rendimiento. La comodidad depende de cómo te plantées el código.

¿Un proceso se puede congelar a sí mismo? Sí, y dormirse, y matarse, e incluso a su propio árbol con las señales _TREE. Lo que no puede es despertarse sólo ¿por qué?, porque tendría que ejecutar la función "signal(id,s_wakeup)", y cuando está dormido/congelado, no ejecuta código ninguno.

No puedes tener una región más grande que la pantalla, es imposible por definición. Puedes tener un mapa, un scroll (tileado o no) o un escenario en general más grande, pero no una región: una región es una parte rectangular de pantalla.

BREAK no mata un proceso, sólo sale del bucle actual. Un proceso puede morir si:
-Termina de ejecutar su código.
-Otro proceso lo mata con una señal (S_KILL, LET_ME_ALONE(),...).
Una vez que acaba no quedan residuos. Lo que queda en memoria son los recursos que haya cargado, la memoria que se haya reservado con ALLOC, los ficheros que se hayan abierto... Por eso es recomendable:
-Que el proceso termine sólo, de forma que sus últimas instrucciones sea la descarga de recursos.
-Si es eliminado desde fuera, usar ON EXIT para liberar los recursos antes de terminar.
-Preferiblemente, que los recursos se carguen desde un proceso de control o desde el padre de todos los que vayan a usarlo, y se pasen como parámetro, de forma que sea el mismo el que los libere (podríamos llamarlo "principio de unificación de manejo de recursos" ;D).

[Fede]

Gracias Drumpi me has aclarado algunas dudas.  :D

[turco]

Gracias Drumpi, me a venido muy bien tu post para entender un poco mejor el funcionamiento de los procesos