Hola a todos:
Una vez más, uno de mis fallos tontos.
Resulta que estoy usando un scroll por el que se mueve un protagonista (sólo hacia la derecha), y tengo puesto que:
scroll[0].camera=prota_info.id;
Vale, pues quiero que el prota no se vea centrado en pantalla, así que he creado una región de movimiento y se la he asignado al scroll:
define_region(1,0,0,100,240);
scroll[0].region1=1;
Pero el prota sigue centrado en todo momento. El tamaño de la pantalla es 320x240
De paso he hecho otra prueba que me ha hecho cosas raras: he cambiado la region por
define_region(1,100,0,220,240);
Y lo que ha hecho ha sido que el personaje se ha movido hasta salir por el lado derecho de la pantalla, y de golpe, el scroll se ha vuelto a centrar sobre él.
¿Qué he pasado por alto esta vez? :S
fijate el ejemplo que este en el link de mi firma
Pues no lo entiendo, porque he hecho lo mismo ???
A ver si esta tarde, dentro de un rato te pillo por el msn, y de paso me haces un favorcito ;)
No lo he acabado de entender... quieres que el scroll NO se centre sobre el protagonista? Entonces sobre que se centra? Es automatico? Quieres que siga al prota pero solo para adelante?
Puedes poner un ejemplo de un juego existente que tenga el mismo scroll que tu quieres realizar?
Saludos!
Yo le asignaría la camara a un proceso que persiga al personaje, en lugar de al personaje.
Si lo sigue unos pixeles a la izquierda el personaje se verá más a la derecha, etc..
Se puede atribuir un id a un proceso ? Otra cosa, estaba matando el proceso padre y los hijos no morian, esto no era así en DIV ?
Quote from: FreeYourMind on June 29, 2010, 11:47:49 AM
Se puede atribuir un id a un proceso ? Otra cosa, estaba matando el proceso padre y los hijos no morian, esto no era así en DIV ?
El ID del proceso se asigna automáticamente, creo que lo puedes cambiar, pero eso podría provocar ejecuciones bizarras y crashes en cualquier momento porque revientas la jerarquía de procesos.
Para que un proceso al morir mate a sus hijos deberías usar la signal S_KILL_TREE que mata a todo el árbol.
@Drumpi: En cuanto al movimiento del scroll, recuerda que tienes que poner a 0 el valor de ratio, y que no debe haber ningún proceso asignado en camera. Lo he hecho mil veces y nunca ha dado problemas si tienes eso en cuenta.
Ya se que se asigna, pero quiero matar por ejemplo sólo un proceso por su id (y no arvol de procesos con el mismo nombre, usando type por ejemplo).
Grácias, ya ni me acordaba del s_kill_tree.
Si matas a un proceso, los hijos quedan huerfanos y pasan a depender del proceso main (miradlo en la ventana de debug).
Al final he hecho lo que dice Bomber, otro proceso sin gráfico actuando de cámara (cualquier juego de desplazamiento lateral no se centra en el prota, sino que va un poco por delante para ver lo que se avecina con antelación).
De todas formas, anoche lo estuve hablando con Splinter, y no se si es que realmente hay un comportamiento errático en el scroll o es que es así, pero creía recordar desde tiempos de DIV que scroll.region1 servía preciasmente para esto. Montaría un ejemplo, pero no tengo tiempo, y menos para cambiar de SO.
Creo que te equivocas con el comportamiento de Region1 en este caso.
Manual original DIV:
Region1 - Ventana de scroll automatico.Region de bloqueo de scroll,por defecto su valor es -1,lo que implica que no hay ninguna region de bloqueo.Si se define previamente con la funcion define_region() ,entoces el sistema no movera el scroll mientras el proceso camara permanezca en la misma.
Ahora bien, si el scroll es ciclico,su mayor parte del tiempo el proceso camara estará centrado en la region del juego , pero si no lo es ,el proceso camara solo estará centrado en la region del juego,mientras no se llegue a los limites mapa/scroll.
Lo suyo seria,como te ha comentado tu compañero que crees otro proceso para la camara.
Yo lo que hago es en los juegos tipo naves es el scroll automatico,para mover la nave libremente por la region y en tipo plataformas el que sigue al personaje,aun asi Drumpi muy pero que muy pequeña tienes que hacer la ventana del juego para no ver a la vecina....digo lo que se te avecina ^^.
Quote from: BoMbErLiNk on June 29, 2010, 08:47:14 AM
Yo le asignaría la camara a un proceso que persiga al personaje, en lugar de al personaje.
Si lo sigue unos pixeles a la izquierda el personaje se verá más a la derecha, etc..
asi lo hicimos anoche bomber... :)
un proceso dummy sin grafico que vaya por delante del proceso camara, con un speed=2 para que no haga muy brusco el centrado y no 1 para que no quede retrasado. Al menos debe ser 2 de speed.
Quote from: FreeYourMind on June 29, 2010, 11:47:49 AM
Se puede atribuir un id a un proceso ? Otra cosa, estaba matando el proceso padre y los hijos no morian, esto no era así en DIV ?
Quote from: Windgate on June 29, 2010, 12:09:59 PM
El ID del proceso se asigna automáticamente, creo que lo puedes cambiar, pero eso podría provocar ejecuciones bizarras y crashes en cualquier momento porque revientas la jerarquía de procesos.
Para que un proceso al morir mate a sus hijos deberías usar la signal S_KILL_TREE que mata a todo el árbol.
@Drumpi: En cuanto al movimiento del scroll, recuerda que tienes que poner a 0 el valor de ratio, y que no debe haber ningún proceso asignado en camera. Lo he hecho mil veces y nunca ha dado problemas si tienes eso en cuenta.
wind, ratio es la velocidad relativa del 2do plano y para que el scroll sea automatico debe existir camera asignado, lo que vos estas diciendo es un scroll manual.
Quote from: FreeYourMind on June 29, 2010, 11:47:49 AM
Se puede atribuir un id a un proceso ? Otra cosa, estaba matando el proceso padre y los hijos no morian, esto no era así en DIV ?
free aca tampoco es asi, estas usando la funcionalidad tree del kill.
Quote from: Drumpi on June 29, 2010, 01:23:27 PM
Si matas a un proceso, los hijos quedan huerfanos y pasan a depender del proceso main (miradlo en la ventana de debug).
Al final he hecho lo que dice Bomber, otro proceso sin gráfico actuando de cámara (cualquier juego de desplazamiento lateral no se centra en el prota, sino que va un poco por delante para ver lo que se avecina con antelación).
De todas formas, anoche lo estuve hablando con Splinter, y no se si es que realmente hay un comportamiento errático en el scroll o es que es así, pero creía recordar desde tiempos de DIV que scroll.region1 servía preciasmente para esto. Montaría un ejemplo, pero no tengo tiempo, y menos para cambiar de SO.
los procesos huerfanos son eso, huerfanos, no pertenecen a nadie.
te lo explique anoche, el problema es que se intenta centrar cuando la diferencia a centrar es demasiado grande.
el scroll esta funcionando bien.
Quote from: DjSonyk on June 29, 2010, 02:38:53 PM
Creo que te equivocas con el comportamiento de Region1 en este caso.
Manual original DIV:
Region1 - Ventana de scroll automatico.Region de bloqueo de scroll,por defecto su valor es -1,lo que implica que no hay ninguna region de bloqueo.Si se define previamente con la funcion define_region() ,entoces el sistema no movera el scroll mientras el proceso camara permanezca en la misma.
Ahora bien, si el scroll es ciclico,su mayor parte del tiempo el proceso camara estará centrado en la region del juego , pero si no lo es ,el proceso camara solo estará centrado en la region del juego,mientras no se llegue a los limites mapa/scroll.
Lo suyo seria,como te ha comentado tu compañero que crees otro proceso para la camara.
Yo lo que hago es en los juegos tipo naves es el scroll automatico,para mover la nave libremente por la region y en tipo plataformas el que sigue al personaje,aun asi Drumpi muy pero que muy pequeña tienes que hacer la ventana del juego para no ver a la vecina....digo lo que se te avecina ^^.
exacto, lo que pasa es que el juego de drumpi, no se mueve hacia atras, ni hacia los costados, SIEMPRE va hacia adelante, entonces siempre esta en el limite borde, y por ende se centra automatico "siempre", o sea, siempre esta fuera de region.
es lo que intentaba explicarle.
pero bueno, ya esta solucionado con un proceso camara dummy sin grafico que va por delante del proceso protagonista, sin region1 y con un speed=2.
Sí, el proceso fantasma es lo mejor, incluso se le puede aplicar un seno a su movimiento para hacer efectos de ondas en la "cámara" y otras cosas así.
Cualquier ejemplo siempre es de agradecer Drumpi, si tienes tiempo, claro.
en el caso del juego de drumpi, tiene que ir recto, solo unos 150 pixels adelante del proceso sobre la coordenada x, no es un juego de naves.
tambien puede hacerse el movimiento del scroll manualmente, ¿no?
segun yo era modificando, lo hice en humos.
scroll.x
scroll.y
si, pero la idea en este caso es que no sea manual.
Yo añado al "si" de Splinter ,que el scroll manual no tiene como camara nada,vamos que no hay que asignarle un proceso como camara , para los mas despistadillos.... Y para los mas despistadillos ,manualmente se hace sumando/restando las coordenadas de scroll.x/scroll.y .
Scroll.x0+=4;
Scroll.y0-=4;
pense que habia dicho que no tenia camera, quizas se me escapo.
Bueno, sólo por no abrir otro hilo, pregunta tonta:
¿Es normal que el juego se cierre de forma "salvaje" (sin notificación de error ni nada, sólo la ventana de "¿desea enviar a m$ información acerca de este error?") si se descargan los gráficos de un scroll y se hace un frame sin hacer un STOP_SCROLL?
Supongo que sí, pero como en muchos casos hay cierto "control de errores"...
normal, es, ahora correcto, no.
lo que pasa es que en fenix era muy lento tener que ir a buscar el bitmap a cada rato, entonces se optimizaron ciertas cosas, pero ahora en bennu se podria poner el chequeo, ya que ahora el tema esta resuelto mejor.
pero por ahora tenes que hacer las cosas ordenadamente.
No, si yo sé que es lógico. Lo que no entiendo es que ni un segmentation fault, ni un mensajito, sólo crash y se acabó.
Si comprobar que existe el gráfico consume tiempo, pues se deja así (o al menos, que se de un aviso, como con demasiados textos, menos mal que tengo todo más o menos organizado y pude ver el error :P).
Creo que a eso mismo te ha dicho Splinter,como no funcionaba bastante rapido se quito esa Excepcion para compensar la velocidad...
Yo no se que pensará Splinter, pero mi opnion es que las captaciones de los errores sean solo en el la compilación y las demas excepciones dentro de la ejecucción del programa se encargue el programador,esto que puede parece una tonteria,muy engorroso,ect,es la forma natural en casi ,por no decir en todos ,lenguajes de programación,en otro hilo pregunta nuestro compañero free,por algo parecido,el tema es quiere saber cuantos procesos hay en cada momento,meter unas funciones para eso me parece un poco "bobo" pudiendo tener una variable que vaya mostrando en todo momento cuantos procesos hay,esque veo que ha este paso tenemos un lenguaje con un millon de sentencias , y tampoco es eso, es lo que pienso...
Lo de captar excepciones en ejecucion Drumpi,que ademas mas de una vez e leido, "y los que tenemos un pc muy modesto",a ellos les puede perjudicar...
Lo que si se puede es hacer un prg,como se a echo con lo de Key_Dow,Key_Press,ect,que capte las excepciones y cada vez que uno encuentre una excepcion nueva lo añada al prg y/o avise...¿que os parece?
Quote from: Drumpi on July 10, 2010, 12:59:53 PM
No, si yo sé que es lógico. Lo que no entiendo es que ni un segmentation fault, ni un mensajito, sólo crash y se acabó.
Si comprobar que existe el gráfico consume tiempo, pues se deja así (o al menos, que se de un aviso, como con demasiados textos, menos mal que tengo todo más o menos organizado y pude ver el error :P).
muchacho, para poder dar un aviso hay que buscar el grafico, o sea, que es lo mismo que tener el control que se quiere evitar...
Quote from: DjSonyk on July 10, 2010, 03:02:19 PM
Creo que a eso mismo te ha dicho Splinter,como no funcionaba bastante rapido se quito esa Excepcion para compensar la velocidad...
Yo no se que pensará Splinter, pero mi opnion es que las captaciones de los errores sean solo en el la compilación y las demas excepciones dentro de la ejecucción del programa se encargue el programador,esto que puede parece una tonteria,muy engorroso,ect,es la forma natural en casi ,por no decir en todos ,lenguajes de programación,en otro hilo pregunta nuestro compañero free,por algo parecido,el tema es quiere saber cuantos procesos hay en cada momento,meter unas funciones para eso me parece un poco "bobo" pudiendo tener una variable que vaya mostrando en todo momento cuantos procesos hay,esque veo que ha este paso tenemos un lenguaje con un millon de sentencias , y tampoco es eso, es lo que pienso...
Lo de captar excepciones en ejecucion Drumpi,que ademas mas de una vez e leido, "y los que tenemos un pc muy modesto",a ellos les puede perjudicar...
Lo que si se puede es hacer un prg,como se a echo con lo de Key_Dow,Key_Press,ect,que capte las excepciones y cada vez que uno encuentre una excepcion nueva lo añada al prg y/o avise...¿que os parece?
En realidad, en fenix nunca se quito nada en este aspecto, solo que se hizo asi para ganar velocidad, pero ahora las busquedas de grafico son muy rapidas, aunque es cierto que pueden tener un overhead, aunque minimo.
Luego coincido con vos, tanto en lo de la variable como en las cosas que pudiendose hacer desde el lenguaje se pide una funcion en C.
Ojo, que no es el mismo caso: se puede detectar el número de procesos porque se ralentiza el sistema, porque se ven en el debuger o porque los puedes contar, se puede detectar demasiados textos en pantalla porque te lo dice el error, se puede detectar la lectura fuera de memoria de un array o puntero merced a un segmentation fault y posterior lectura de los valores de las variables.
Pero no un error de lectura interno a la función del scroll, eso sólo lo sabes si sólo has cambiado algo en la carga/descarga del scroll y poco más.
Pero sí, estoy de acuerdo con vosotros: es responsabilidad del programador controlar estas cosas, así que mejor no cambiar nada y listo, sólo era por saber, nada más.