Buenas.
En mi port de DIV1 a Bennu, tengo fallos en las animaciones, ya he dado con el origen del problema, parece que en Bennu no pilla bien valor del 'size of' tal cual lo hace DIV1:
Ejemplo:
Tengo esta animación con 12 frames:
andar[]= 5, 5, 5, 5, 4, 4, 4, 4, 3, 3, 3, 3;
La condicion de movimiento:
IF (Key(KLeft))
incx= -3;
graph= andar[Cont1];
flags= 1;
END
Y la actualización del contador, que falla y el sizeof no me devuelve el valor 12 (que es el tamaño de la animación):
Cont1++;
IF (Cont1 == sizeof(andar))
Cont1= 0;
END
La solución fue cambiar
IF (Cont1 == sizeof(andar))
por
IF (Cont1 == 12)
Que teneis a decir al respeto ?
Gracias.
Porque sizeof no te dice el número de elementos del array, sino lo que ocupa en memoria (si un elemento es de tipo int -por ejemplo-, ocupará 32 bytes; entonces, en un array de 10 elementos, sizeof devolvería 320).
Lo que tú quieres es una función tipo length de otros lenguajes...ahí sí que no te puedo ayudar...
La función que necesitas es Len :)
Vale gracias por aclararlo. Lo resolvi de la otra forma, poniendo en cada caso el numero de elementos del array. Curioso que una vez más, en DIV funcione de esa forma...
Quote from: PiXeL on October 17, 2009, 11:56:02 AM
La función que necesitas es Len :)
Lo he probado por curoseo, pero no funciona, te devuelve tamaño = 1, ya que es para tratamiento de textos:
mod_string.dll
INT LEN(STRING)
--------
IF (Cont1 == len(andar))
encima que necesito ese modulo para utilizar len(), y poniendo a pelo las dimensiones no la necesito :)
Sigo buscando, a ver si existe la equivalente en Bennu...
Puf, perdón, me sonaba que alguna vez lo había utilizado en Bennu, pero no. De hecho aún no he utilizado ninguna matriz dinámica en Bennu xD
sizeof(andar) / sizeof(andar[0])
es correcto en DIV devolvia el numero de elementos no el "sizeof" de la variable... algo un poco feo... pero funcionaba asi...
Y aun así, cuando querías usar xgraph tenías que indicar como primer elemento del array el número de posiciones que tenía dicho vector.
Apúntatelo como una posible solución para tu problema, FreeYourMind.
xgraph ?? No te entiendo :) Splinter vale muy bien que tambien lo aclares, pero lo que interesa es saber como obtenerlo en Bennu, y eso todavia no lo se :D
Por cierto, sobre otro tema anterior, en el que hacia un for para borrar sonidos en DIV, pues ahora ya los tengo todos cargados y me sigue petando en Bennu al pararlos con el mismo FOR:
FOR (typ = 0; typ <= 16; typ++)
stop_wav(typ);
END
typ es una variable local, y por lo que veo en el engorroso código es un entero y se utiliza en multitud de operaciones, no sólo para el sonido, pero mirando este caso para el sonido, parece que el autor queria parar 16 id's de sonido de golpe, lo mejor seria pararlos todos de golpe, enfin, de aqui no busco la solución ya que pienso que seria parar todos los sonidos con stop_wav(all_sound);
(por lo que me parece, puedo estar equivocado y igual seguirian tocando algunos despues de esto, tengo que mirarlo mejor).
La pergunta es más, porque en DIV no peta esto, ya me dijiste antes que si intentas parar sonidos con id's inválidos bennu peta, pero la pregunta es si petaria en Fenix tambien, ya que por lo que veo en Div no peta.
Ya se que soy insistente con DIV, siempre con la compatibilidad en la lengua ;)
Gracias.
Quote from: FreeYourMind on October 17, 2009, 04:27:03 PM
xgraph ?? No te entiendo :) Splinter vale muy bien que tambien lo aclares, pero lo que interesa es saber como obtenerlo en Bennu, y eso todavia no lo se :D
Ya te lo ha dicho:
sizeof(array)/sizeof(array[0])
Divides lo que ocupa el vector entero por lo que ocupa uno de sus elementos. Eso te da lo que quieres.
Gracias OSK.
Vengo com tres nuevos problemas ;(:
1 - El unload map parece que no funciona !!!!!
unload_map(mapa, 0);
Cargo un mapa al principio (o al empezar el juego), la carga funciona bien porque si no lo cargo no se enseña (o sea al principo o al empezar el juego, es igual), pero el unload_map no funciona, ya que si lo descargo antes de enseñarlo sigue enseñandolo...
2 - Por primera vez, me pilla id's distintos para la musica en el PC o en la Wiz.
Me entero que la musica del menu que toca en el pc (que es la correcta), al ejecutarlo en la Wiz me sale otra, con id distinto...
Tengo que revisarlo mejor, ya que la musica que toca es en realidad 3 ficheros wav, 2 voces y una musiquilla, las voces creo que tocan por random, haciendo una musica a lo remix en tiempo de ejecución :) (pero en la Wiz no me sale el remix de los 3 sonidos, me sale sólo un sonido y que es otro que se carga tambien en el juego).
3 - Esta es la peor sorpresa, y atención puede que sea originado por no funcionar el unload_map (ya que no se como hace el proceso que describo a continuación), si es originado por el entonces este punto desaparece, deja de ser un problema o bug:
Al compilar el .dcb con la opcion -a, o sea, el que mete los recursos del juego dentro del dcb, me entero y solo ahora, porque me estaba saliendo un .dcb gigantesco, que si vuelves a cargar el mismo recurso durante el juego (ni que hagas el unload antes), te lo vuelve a incluir en el dcb (o repetir que es lo mismo), y no lo deberia hacer, deberia identificar que ese mismo recurso ya estaba incluido en el dcb al intentar hacer el segundo include en el segundo load que apunta al mismo fichero.
Deberia apuntar al primero y no crearte otro repetido, ocupandote de nuevo la memória en el dcb.
Me imagino que haga una lista de ficheros a incluir en el .dcb sumando los load's que encuentra del principio hasta el fin del .prg, lo que faltaria seria comprobar antes de incluir el recurso en el .dcb que ese recurso ya habia sido incluido, y en lugar de volver a incluirlo, el segundo include (load del recurso en el programa) apuntaria al primero (al que ya estaba incluido, ya que es el mismo fichero).
Saludos y gracias especialmente a Splinter que se dedica siempre a fondo para resolver estas cosillas que le voy poniendo :)
1) la funcion funciona correctamente.
unload_map(0, mapa)
unload_map(fpg, mapa)
como es que se te ocurrio poner primero el mapa? :P
2) nunca hay que hacer suposiones con los id (handles que se crean al cargar algo)... estos no tienen por que ser siempre los mismos, incluso en la misma plataforma... pensar eso es un error...
3) what the fuck!!!!???? unload que tiene que ver con la compilacion? es una funcion de runtime.
por otro lado, no repite recursos, solo repite si la cadena que estas usando para referirte al archivo es diferente, esto es mayusculas minusculas, otro path, etc... si la cadena es identica, no repite.
y esto no tiene nada que ver con el unload... a menos que hayas mezclado las cosas y no se entienda claramente lo que estas diciendo...
Joer, con el unload ni me entere ;)
Yo comentaba lo del unload sobre el tema del dcb porque suponiendo que se incluian en el dcb mirando los load's pues ya que no me funcionaba el unload igual volvia a cargar los mismos, ya que en realidad el caso es el siguiente:
En el código se carga el mismo mapa 3 veces con variables distintas (la verdad no se porque lo hace, me imagino que con sólo una ya puede hacer las operaciones que quiera en distintos sitios, ya que los utiliza para el sistema de tiles):
ScrollMap = load_map("Map\Nivel.map");
FrontMap = load_map("Map\Nivel.map");
ColMap = load_map("Map\Nivel.map");
Despues de tener los 3 mapas cargados, hace esto al empezar el juego (código de DIV):
unload_map(ScrollMap);
unload_map(FrontMap);
unload_map(ColMap);
ScrollMap = load_Map("Map\Nivel.map");
FrontMap = load_Map("Map\Nivel.map");
ColMap = load_Map("Map\Nivel.map");
De esto tiro 2 cosas:
1 - No se para que hace unload seguidos de la nueva carga que es la misma que la inicial, yo le quite el unload y la segunda carga y el juego funciona igual, así que esto ultimo sobra.
2 - Como puedes ver las rutas de los 3 primeros loads son iguales a lo de los segundos, y te aseguro que si repito los 3 primeros load_map (o sea 6 en total), ya que el unload no estaba funcionando (pero que tampoco importa por lo que cuentas) el .dcb va tener 6 mapas (que en realidad es el mismo repetido 6 veces, ya que es el mismo mapa en las 3 variables).
Si quieres saber porque repite el mapa en 3 variables distintas, pues es para su sistema de tiles que utiliza, te pongo la funcion:
PROCESS PutTile(x, y, graf, tip)
BEGIN
IF (tip == 0)
Map_Block_Copy(TilesFile, ScrollMap, x- graphic_info(TilesFile, graf, g_x_center), y- graphic_info(TilesFile, graf, g_y_center),
graf, 0, 0, graphic_info(TilesFile, graf, g_wide), graphic_info(TilesFile, graf, g_height), 0); // Bennu
END
IF (tip == 1)
Map_Block_Copy(TilesFile, FrontMap, x- graphic_info(TilesFile, graf, g_x_center), y- graphic_info(TilesFile, graf, g_y_center),
graf, 0, 0, graphic_info(TilesFile, graf, g_wide), graphic_info(TilesFile, graf, g_height), 0); // Bennu
END
IF (tip == 2)
Map_Block_Copy(TilesFile, ColMap, x- graphic_info(TilesFile, graf, g_x_center), y- graphic_info(TilesFile, graf, g_y_center),
graf, 0, 0, graphic_info(TilesFile, graf, g_wide), graphic_info(TilesFile, graf, g_height), 0); // Bennu
END
END
No he cambiado todavia la función, pero casi apuesto que con el mapa en una sola variable se puede hacer lo mismo.
Que te parece ?
Saludos.
Si haces map_block_copy de un mapa cargado en una variable sobre el mismo mapa de tiles, debería ser cierto ésto:
Si en distintas variables se ha cargado el mismo mapa...Tanto da que uses una u otra.
Pero no veo la relación con sizeof ahora... Cierto es que con sizeof tuve una época de interrogantes, pero a base de mostrar por pantalla los tamaños de los arrays entendí bien como iba :P
El tema ya no tiene que ver con el sizeof....
es lo de siempre, los foros se mezclan entre dudas y dudas :)
Y por cierto haciendo pruebas, he generado un .dcb monstrusoso repitiendo esto hasta la saciedad:
ScrollMap = load_map("Map\Nivel.map");
FrontMap = load_map("Map\Nivel.map");
ColMap = load_map("Map\Nivel.map");
unload_map(ScrollMap);
unload_map(FrontMap);
unload_map(ColMap);
ScrollMap = load_Map("Map\Nivel.map");
FrontMap = load_Map("Map\Nivel.map");
ColMap = load_Map("Map\Nivel.map");
unload_map(ScrollMap);
unload_map(FrontMap);
unload_map(ColMap);
...
...
Lo que contrasta lo que decia Splinter de que 'no se repiten recursos en el dcb al menos que las rutas sean distintas'.
a ver... creo que aca hay una mezcla tremenda...
1) dcb (con recursos, parametro -a) incorpora al mismo 1 vez cada recurso... si el recurso tiene distintos paths o alguna letra que lo hace diferente, se considera un recurso diferente.
2) load_map, unload_map y runtime (o en tiempo de ejecucion)... no tiene nada que ver con el dcb...
ahora si vos haces varios load_map, es perfecto (y seria un error grave que asi no sea), que cargue el recurso tantas veces como load hagas... por que? porque uno asi lo esta indicando al hacer load y porque uno puede querer quizas alterar algun contenido de los mismos en memoria... o porque asi quiero hacerlo...
ahora, creo que dicho esto, y con nueva informacion que procesar... deberias organizar un poco las ideas de todo esto y replantear las dudas si es que sigues con ellas...
gracias por las preguntas... yo creo que muchos se topan con estas dudas y no se animan a preguntar...
A ver, te resumo tus puntos para no liarnos más :):
1)
Exacto, pero esto no esta ocurriendo, te he puesto el ejempo de varias cargas seguidas del mismo recurso con la misma ruta, el recurso 'Nivel.map' sólo deberia incluirlo una vez en el .dcb y lo esta incluyendo tantas veces como cargas hago de el.
2)
Si ya se que no tiene nada que ver, no volvamos a mezclar este punto con los demás, este lo cerramos.
3)
Ya se porque carga el mismo recurso con 3 variables distintas, en realidad es un mapa vacio, lo que hace dinamicamente es construir su contenido a traves de un engine de tiles, que se divide en 3 secciones, scroll y 2 más. Y utiliza cada variable para su respectiva sección de la fase que estan en memoria al mismo tiempo.
Esto esta bien, pero no por ello tendia que repetir el mapa en el .dcb, que lo haga en memória al hacer más loads del mismo recurso todo bien, pero no fisicamente en el .dcb.
Tienen la misma ruta y como dices no deberia repetirse pero si lo hace, prueba cargar un recurso seguido de unload, varias veces, y lo verás por ti mismo.
Gracias.
Curioso lo del punto 1...
Y me asalta una duda relacionada con el tema, Splinter dice que el .dcb con -a incluye los recursos...
¿Esto quiere decir que compilando con -a los FPGs, OGGs, etc. Pasan a formar parte del .dcb y no es necesario mantenerlos en subdirectorios? Me ha dado por probar la invocación de bgdc sin parámetros y veo la lista de opciones, hasta hoy no le había hecho mucho caso porque siempre compilo con el mismo .bat
También veo algo sobre automatic declare... ¿Eso es para poder usar variables sin necesidad de declararlas primero o algo así?
Siento mezclar aún más el tema, pero siendo tan puntual no merece la pena abrir nuevo hilo.
Si claro, yo lo hago siempre con esta opción por comodidad en la distribución y por seguridad tambien, pero no me habia enterado de este pequeño problema de repetición de ficheros, ya que las otras veces sólo los cargaba una vez durante el juego, ahora por casualidad como cargaba el mismo recurso más veces, al copiar el dcb quede petrificado, ya que en total los recursos ocupan poco más de 6 megas y actualmente el dcb ocupa mas de 11 megas por repetir la carga del mismo fichero 3 veces en variables distintas.
Lo de mezclar temas es inevitable, lo mejor es no darle mucha importancia, al fin y al cabo el tema es siempre Bennu :)
ahhh... wait... wait... creo que se lo que te pasa... los recursos .map, .fpg y cualquier otro de formato propio de bennu, cuando estan solos (no en el dcb) van comprimidos... cuando van en el dcb, ya no llevan compresion... por eso es que crees que el archivo se incluye 3 veces... pues no, no se incluye 3 veces... solo estas viendo el tamaño real que este ocupa...
por otro lado, no uses la barra "\", usa esta barra "/"... eso puede tambien hacer que se dupliquen...
cuidado con este modo, si lo adjuntas al ejecutable, eso puede afectar a la memoria consumida... ya que el ejecutable puede ser cargado por el sistema operativo completamente en memoria.
1)
No splinter y sabes porque, porque si incluyes el mismo recurso más veces (con load's y unload's seguidos por ejemplo), el tamaño del dcb sigue aumentando, y este tendria que ser siempre igual porque ya lo tenias incluido en el primer load (si ya he dicho esto varias veces :)) ;D
2)
Voy a probar lo de las barras, a ver si es esto que hace que se duplique....
3)
Lo del tamaño no es problema, porque en este juego no tengo problemas de memória ya que ocupa muy poco.
Más cosas para que te aclares en la resolución:
1 - Rescursos sueltos: 6,67 Mb
2 - Tamaño del .dcb con todos los recursos incluidos y Nivel.map cargado sólo una vez: 6,89 Mb
Como ves la diferencia es miníma, aparte que el dcb tiene tambien el código del prg incluido, con esto no me parece que los FPG cuando estan dentro del .dcb esten descompactados, apostaba que siguen comprimidos dentro del .dcb (o sea, en el mismo formato), pero si tu dices que no, tampoco lo questiono :)
3 - Nivel.map ocupa 2,28 Mb, cargando 3 veces este mismo recurso, el .dcb se queda con tamaño de 11,6 Mb, o sea, 2,28 * 3 = 6,84 Mb, así tendriamos que sumar 2 ficheros de 2,28 Mb (4,56 Mb) a los 6,89 Mb del dcb (el cual ya tiene un Nivel.map dentro), seria: 11,45 Mb, como puedes ver y salvando redondeos en los calculos ya que estamos sumando bits, parece que los calculos me dan la razón :)
Se estan duplicando ficheros 'Nivel.map' dentro del .dcb
bien, eso de comprimido y no, es real... puede que en tu caso estes con fpg/map sin compresion... pero normalmente estan comprimidos con gzip... o que la compresion este muy cercana al descomprimido... como sea, hay que tener en encuenta que puede pasarte eso...
caramba que a veces eres un poco duro... creeme cuando digo que hay compresion en los recursos y no en los dcb...
mas alla de eso, acabo de resolver el tema de las barras... por ahora usa la barra adecuada, no hare un nuevo ejecutable por esto... pero ya esta corregido, gracias por el reporte...
para datos adicionales, lo que se incluye en el dcb son todo aquello que esta en una string y se puede abrir como fichero al procesar dicha string... no tiene nada que ver los load/unload... olvidate de los load/unload.
gracias
karma por el reporte
aclaracion adicional, solo si usas el paremetro de stub (-s) junto al de mochila dcb (-a) puede que consuma mas memoria... la que ocupe el exe.
Ya me habia dado cuenta que con la barra al reves no ocurre. Gracias por corregirlo, de todos modos voy a poner las barras bien en todos los load's, me apunto lo de la correccion en futuras versiones.
Gracias.
:)
saludos...
vamos depurando y aclarando cosas a full... gracias...
Gracias por resolver el problema Splinter, karma++ para tí, no es mi caso pero sé por experiencia que al principio usamos \ y / indistintamente con mucha alegría.
La culpa la tiene Microsoft, sus barras son del tipo '\' y claro como yo programo en Vista y vosotros la mayoria en Linux... y Wiz tb se basa en Linux...
por suerte gracias al gcc se interpreta indistintamente las barras al momento de cargar/ejecutar...