Saludos por estas tierras!
Llevo ya como un mes con mi nuevo juego, usando el editor de mapas que programe, y me surge un gran problema!
Los mapas están basados en tiles. Cada tile está formado por una estructura padre y dos hijas:
TYPE tp_celda
int pos_x; //pos x de la celda
int pos_y; //pos y de la celda
tp_tile graf_suelo; //grafico del suelo
tp_tile graf; //grafico objeto o unidad
byte tiene_pj = FALSE; //tiene un pj encima
int id_pj = 0; //id del pj encima
byte tiene_muerto = FALSE; //tiene un pj muerto encima
int id_muerto = 0; //id del pj muerto
byte zona_segura = FALSE; //si en esta zona se puede pegar a un pj
END
TYPE tp_tile
byte tipo; //tipo de grafico terreno, objeto etc
short grafico = 0; //nº grafico en el fpg
byte traspasable = TRUE; //si se puede traspasar
byte es_proceso = FALSE; //si es un proceso
byte tipo_proceso; //tipo de proceso que es
byte respawn = FALSE; //a sido invocado ya?
int color; //color en el minimapa
byte es_borde = FALSE; //si es borde con otro tipo de terreno
byte tipo_borde; //tipo de borde
END
Como veis, he intentado reducir el tamaño usando tipos de dato pequeños, pero no me es suficiente...
De momento andaba probando con un mapa de 128x128, pero se queda extremadamente pequeño. Probé con un tamaño mayor, y el problema es que cuanto más grande es la matriz, mas tarda en arrancar el programa. Con una matriz de 1024x1024, que sería lo ideal, el programa tarda horrores en compilar. Imagino que es por el tamaño de los types.
Mi pregunta es, hay alguna manera de solucionar esto? Otro método para cargar mas rapido la matriz del mapa? Otro sistema para hacer un mapeado de tiles? o tendre que conformarme con un mapilla de 256x256 o 512x512?
P.D. en un futuro, mi plan era hacer mapas multinivel (varios pisos), pero por el momento lo veo irrealizable por este motivo :(
Muchas gracias por todo!
Por el titulo pense que el problema era otro ;D
La verdad no entiendo nada del codigo que pones, o no entiendo bien tu explicacion...
veamos, a ver si me explico mejor jeje^^
TYPE tp_celda
int pos_x; //pos x de la celda
int pos_y; //pos y de la celda
tp_tile graf_suelo; //grafico del suelo
tp_tile graf; //grafico objeto o unidad
byte tiene_pj = FALSE; //tiene un pj encima
int id_pj = 0; //id del pj encima
byte tiene_muerto = FALSE; //tiene un pj muerto encima
int id_muerto = 0; //id del pj muerto
byte zona_segura = FALSE; //si en esta zona se puede pegar a un pj
END
TYPE tp_tile
byte tipo; //tipo de grafico terreno, objeto etc
short grafico = 0; //nº grafico en el fpg
byte traspasable = TRUE; //si se puede traspasar
byte es_proceso = FALSE; //si es un proceso
byte tipo_proceso; //tipo de proceso que es
byte respawn = FALSE; //a sido invocado ya?
int color; //color en el minimapa
byte es_borde = FALSE; //si es borde con otro tipo de terreno
byte tipo_borde; //tipo de borde
END
Esas son las estructuras que uso para formar la matriz del mapa:
tp_celda tablero[SIZE_X_TAB][SIZE_Y_TAB]; //crea una matriz de tamaño x e y
Realmente lo que representan los datos en los TYPES no tiene importancia. Mi problema viene cuando al declarar por ejemplo
tp_celda tablero[512][512]; tarda como 2 o 3 minutos en compilar, hasta que sale la pantalla del juego vamos.
La pregunta es si hay alguna manera de reducir ese tiempo de compilacion.
Si quereis probar lo que quiero decir, crear un .prg con este codigo y compilar. Cuanto más grande sea el array, mas tardará en compilar
PROGRAM prueba_rendimiento;
import "mod_video";
import "mod_screen";
TYPE tp_tile
byte tipo; //tipo de grafico terreno, objeto etc
short grafico = 0; //nº grafico en el fpg
byte traspasable = TRUE; //si se puede traspasar
byte es_proceso = FALSE; //si es un proceso
byte tipo_proceso; //tipo de proceso que es
byte respawn = FALSE; //a sido invocado ya?
int color; //color en el minimapa
byte es_borde = FALSE; //si es borde con otro tipo de terreno
byte tipo_borde; //tipo de borde
END
TYPE tp_celda
int pos_x; //pos x de la celda
int pos_y; //pos y de la celda
tp_tile graf_suelo; //grafico del suelo
tp_tile graf; //grafico objeto o unidad
byte tiene_pj = FALSE; //tiene un pj encima
int id_pj = 0; //id del pj encima
byte tiene_muerto = FALSE; //tiene un pj muerto encima
int id_muerto = 0; //id del pj muerto
byte zona_segura = FALSE; //si en esta zona se puede pegar a un pj
END
GLOBAL
tp_celda tablero[128][128]; //CAMBIAR ESTO POR VALORES MAS ALTOS, ENTONCES SE REALENTIZA (512,768,1024..)
BEGIN
set_mode(800,600,32,MODE_WINDOW);
LOOP
FRAME;
END
END
Espero haber aclarado algo!
Un saludo!
Me imagino por la dimensión, por lo que veo estas creando un tablero enorme y cada uno de los 512 va tener su gráfico, eso a vista rápida es lo que me parece. Yo que haria tiles de otra forma, creo que te estas aprofundizando más de lo necesário, no se para que necesitas crear matrizes para poner tiles, te bastarian coordenadas y indicar los graficos de los tiles...
primero, no uses byte o tipos menores a 32bits... lo hace mas lento.
donde lo estas compilando, a mi me tarda 0 segundos en compilar tu ejemplo.
Quote from: SplinterGU on January 14, 2010, 02:19:37 AM
primero, no uses byte o tipos menores a 32bits... lo hace mas lento.
donde lo estas compilando, a mi me tarda 0 segundos en compilar tu ejemplo.
¿No importa, pues, desaprovechar memoria ram? Ya se sabe que hoy en día es casi infinita, pero a mi siempre me enseñaron que los tipos debían de ser acorde al tamaño del dato que queríamos guardar...Pero vaya, da lo mismo supongo.
El problema de las matrices GORDAS a mí también me pasa en ocasiones, si el tablero tiene proporciones bíblicas (p. ej. 1024x1024), aunque sea de simples int ya tenemos 4Mb. Si además tienes varios campos puedes tener un tablero de unos 40Mb en memoria, que es bastante, después de compilar observa los bytes usados en GLOBAL data y verás lo que te digo.
Eso que comentas lo he sufrido estos días con mi Mundo3D al cual le podéis echar un vistazo porque es curioso de ver :P
Yo he estado planteando hacer un tablero dinámico que se vaya generando a medida que se usa... Puedes hacerlo 100% dinámico con mem_alloc, cosa que sería un trabajo curioso, o bien puedes tener una info "resumida" de todo el tablero y otra info extendida de la parte visible en pantalla...
De todas formas una vez compilada la cosa debería ejecutarte rápido, ¿No?.
Prg hace una cosa muy curiosa, que es tener varios .dcb compilados e ir invocándolos, quizás puedas dejar el tablero en un .dcb ya compilado para evitar la tediosa espera cada vez que haces un cambio y compilas.
En fin, espero que te sirva de algo :P
Quote from: SplinterGU on January 14, 2010, 02:19:37 AM
primero, no uses byte o tipos menores a 32bits... lo hace mas lento.
donde lo estas compilando, a mi me tarda 0 segundos en compilar tu ejemplo.
jeje, tarda 0 segundos con un tablero de 128x128. Por lo menos en mi caso, cuando el tablero es de 512x512 o mayor, la cosa empieza a realentizarse. Probare usando int en vez de byte, lo hacia por reducir el tamaño del fichero final al guardar el mapa.
Quote from: Windgate on January 14, 2010, 10:36:20 AM
Yo he estado planteando hacer un tablero dinámico que se vaya generando a medida que se usa... Puedes hacerlo 100% dinámico con mem_alloc, cosa que sería un trabajo curioso, o bien puedes tener una info "resumida" de todo el tablero y otra info extendida de la parte visible en pantalla...
De todas formas una vez compilada la cosa debería ejecutarte rápido, ¿No?.
Prg hace una cosa muy curiosa, que es tener varios .dcb compilados e ir invocándolos, quizás puedas dejar el tablero en un .dcb ya compilado para evitar la tediosa espera cada vez que haces un cambio y compilas.
En fin, espero que te sirva de algo :P
En memoria dinamica estoy completamente pez :S. Cuando pinto pinto solo la info de los tiles que aparecen en pantalla, pero de todos modos la info de los demas tiles tambien debe existir :S
Despues de compilado, la cosa va sin problemas. El problema está en los minutos que tarda en compilar antes :P
Lo de tener varios .dcb puede ser una solucion.. aunque tengo dudas. Podría compilar un programa que solo declarase el tablero? Como invoco desde mi programa a otro .dcb? en esas cosas voy bastante pez tambien..XD
Muchas gracias y un saludo!
Quote from: osk on January 14, 2010, 02:28:29 AM
Quote from: SplinterGU on January 14, 2010, 02:19:37 AM
primero, no uses byte o tipos menores a 32bits... lo hace mas lento.
donde lo estas compilando, a mi me tarda 0 segundos en compilar tu ejemplo.
¿No importa, pues, desaprovechar memoria ram? Ya se sabe que hoy en día es casi infinita, pero a mi siempre me enseñaron que los tipos debían de ser acorde al tamaño del dato que queríamos guardar...Pero vaya, da lo mismo supongo.
La cosa es que los actuales procesadores manejan mejor el alineamiento de acorde a el tamaño de palabra del procesador, en la mayoria de los casos 32 bits... por eso va mas rapido...
ahora voy a probar ponerle 2048x2048 a ver que pasa
Hombre, ten en cuenta que cuando hagas el programa/juego, el DCB lo vas a pasar ya compilado, así que si te tarda 3 minutos en compilar y 0 en ejecutar, no habría problema.
Es como compilar una Gentoo (desde que me hicieron aquella gracia, siempre la uso de ejemplo): puedes tirarte tres horas esperando, pero luego tienes un SO super-eficiente para tu máquina.
Como soluciones, mmm, podrías intentar simplificar un poco los campos, desechando variables que no uses o que puedas averiguar mediante otras. Puedes unir variables en un tipo de dato más grande y usar máscaras para leer los datos (como los flags pero con más bits)...
Supongo que estamos hablando de la estructura que almacena los datos, ¿no? no de la representación.
Para mirar el tema de punteros, tienes el extenso tutorial de OSK (recomendado) o los tutoriales de Windgate (creo que ha tratado ese tema ¿no?). Si no, tienes una ligera introducción que hice hace tiempo en un hilo:
http://forum.bennugd.org/index.php?topic=988.0
Espero que te sirva.
el problema no es solo la compilacion, es la grabacion, son 188mb de dcb... :P
a 2048x2048 me tardo 4 segundos...
WHAAAAAATTTT?????????
¿0'1 Gigowatios?.... digooo ¿188MB de DCB? ¿Están bien las funciones de reserva de memoria? juer, amigo, ve pensando en cambiar la forma de almacenar los datos ;D ;D ;D
De todas formas, 2 o 3 minutos para compilar me parece excesivo (aunque claro, con el maquinón que gasta Splinter tampoco podemos comparar ;D) a menos que tu PC funcione mediante un hamster corriendo en una rueda.
Tambien puedes pensar (se me olvidó decírtelo antes) en usar varios arrays para almacenar la información. En mi sistema de tiles uso dos mapas: uno con los valores de los graphs y otro para las durezas, cada uno permite varias capas y va todo super bien.
maquinon el mio??? dualcore (ni core 2 duo) de 1.66mhz con linux a 32bits (ni siquiera el lindo 64 bits)... eso es un maquinon???
A ver... Yo tengo ahora mismo un i7 de esos y las matrices GORDAS tardan en compilar MUCHO xD
El maquinón es lo de menos.
Lou, lo de tener varios .dcb es una "magia" que conoce Prg, mándale un privado para que se una a este hilo, yo también quiero aprender sobre el tema.
Sobre usar memoria dinámica, para cosas así de grandes sería lo ideal, pero no lo "agradable", con Bennu he usado memoria dinámica y funciona que da verdadero placer, pero programar así no es algo que se haga por gusto... Desgraciadamente ahora mismo no hay NADA sobre ello en mis tutoriales... Pero es una buena sugerencia, lo tendré en cuenta.
Quote from: Drumpi on January 14, 2010, 11:35:27 PM
Hombre, ten en cuenta que cuando hagas el programa/juego, el DCB lo vas a pasar ya compilado, así que si te tarda 3 minutos en compilar y 0 en ejecutar, no habría problema.
Eso es lo que tenia pensao. Aunque me muera cada vez que tenga que compilar el programa yo, cuando lo pase por ahi debería ejecutarse rapido.
COMPROBADO. Una matriz de 1024x1024 me a tardado en compilar como 4 o 5 minutosXD, pero luego al ejecutarla a tardado -1.
Quote from: Drumpi on January 14, 2010, 11:35:27 PM
Como soluciones, mmm, podrías intentar simplificar un poco los campos, desechando variables que no uses o que puedas averiguar mediante otras. Puedes unir variables en un tipo de dato más grande y usar máscaras para leer los datos (como los flags pero con más bits)...
Supongo que estamos hablando de la estructura que almacena los datos, ¿no? no de la representación.
Lo de simplificar los datos lo tengo ya pensao, estoy en ello:P, quitar varios booleanos y comprobar con otras variables, me quito como 5 o 6 int por campo.
Lo de las máscaras imagino que se haria a traves de código, asi que lo que gano en tiempo de compilacion igual lo pierdo en tiempo de ejecucion asi que, por el momento, lo dejo en la lista de posibles.
La estructura solo almacena datos, el programa es el que se encarga luego de pintar por pantalla lo que representan esos datos.
Quote from: Drumpi on January 14, 2010, 11:35:27 PM
Para mirar el tema de punteros, tienes el extenso tutorial de OSK (recomendado) o los tutoriales de Windgate (creo que ha tratado ese tema ¿no?). Si no, tienes una ligera introducción que hice hace tiempo en un hilo:
http://forum.bennugd.org/index.php?topic=988.0
Espero que te sirva.
Le echaré u ojo. Gracias!:D
Quote from: Drumpi on January 14, 2010, 11:58:55 PM
Tambien puedes pensar (se me olvidó decírtelo antes) en usar varios arrays para almacenar la información. En mi sistema de tiles uso dos mapas: uno con los valores de los graphs y otro para las durezas, cada uno permite varias capas y va todo super bien.
Con eso no estaríamos en las mismas? es decir, si en vez de usar una matriz tocha, uso dos o tres matrices menos tochas, no tendría que compilar lo mismo, y por tanto, tardar lo mismo?
Quote from: Windgate on January 15, 2010, 02:52:53 AM
Lou, lo de tener varios .dcb es una "magia" que conoce Prg, mándale un privado para que se una a este hilo, yo también quiero aprender sobre el tema.
Ahora el mando un MP y le digo a ver si nos ilumina un poco ^^
Muchas gracias a todos!
lo de varios dcb no es mas que la propuesta que hice hace tiempo para el launcher del apagame... no es mas que ejecutar desde un dcb otro bgdi con otro dcb como parametro...
nada mas... no es un secreto, esta el codigo que yo hice en el foro...
Veamos si entiendo el concepto:
Compilo, por ejemplo:
program tablero;
global
int tablero[1024][1024];
begin
loop
frame;
end
end
Luego, ese .dcb, lo ejecuto desde mi programa principal (ya buscare como por el foro:P), entonces podría usar la matriz tablero en mi programa principal? si es asi, me soluciona el problema completamente, sino es asi, tendre que seguir buscando..
Muchas gracias!:D
por que no deberia funcionar? si te referis a varios dcb, no, claro que no funciona... cada dcb es un mundo separado.
Esa es la idea Lou, pero... Lo que ahora no sé decirte es si un .dcb en ejecución puede acceder a las GLOBAL de otro .dcb invocado... Ahora que lo recuerdo Prg usaba varios .dcb para diferentes opciones de su editor FPG, pero no eran "tareas" que se relacionen entre sí... Dile por privado a ver :P
no, no se puede...
Quote from: SplinterGU on January 14, 2010, 11:33:44 PM
Quote from: osk on January 14, 2010, 02:28:29 AM
Quote from: SplinterGU on January 14, 2010, 02:19:37 AM
primero, no uses byte o tipos menores a 32bits... lo hace mas lento.
donde lo estas compilando, a mi me tarda 0 segundos en compilar tu ejemplo.
¿No importa, pues, desaprovechar memoria ram? Ya se sabe que hoy en día es casi infinita, pero a mi siempre me enseñaron que los tipos debían de ser acorde al tamaño del dato que queríamos guardar...Pero vaya, da lo mismo supongo.
La cosa es que los actuales procesadores manejan mejor el alineamiento de acorde a el tamaño de palabra del procesador, en la mayoria de los casos 32 bits... por eso va mas rapido...
...
Entonces ganas performance al usar datos de 32 bites...
aunq desperdicias memoria...
Esto no importa tanto si es para PC, pero si es para digamos la Wiz, si importa ese uso de memoria extra...
exacto... ganas mas velocidad en wiz tambien...
gracias por las respuestas!
Bueno, si no es posible tendre que conformarme con hacer un mapa no demasiado grande, y esperar un poco al compilar...
Ahora me asalta otro problema, a la hora de guardar las partidas... si no consigo solucionarlo pronto me tendreis por aqui rogando de vuestra sabiduria.. otra vez XD
Un saludo!
Quote from: osk on January 14, 2010, 02:28:29 AM...
pero a mi siempre me enseñaron que los tipos debían de ser acorde al tamaño del dato que queríamos guardar...Pero vaya, da lo mismo supongo.
en mi caso tmb me enseñaron a usar los datos segun lo q se necesitara guardar
En el caso de trabajar con estructuras de datos estas se acomodan para formar bloques de 32 bit??
por ejemplo una estructura de 4bytes es igual a 1 int...
perdon que moleste con esto, pero necesito saber como tener un rendimineto aceptable usando la menor cantidad de memoria posible...
osea sin irme al extremos de usar solo datos Int Dword Float y string
Si se obtiene mayor velocidad con esos tipos de datos, para que existe los otros??
a ver... esto ya se explico, pero vamos de nuevo...
si tenes 4 elementos de tipo byte el problema no esta en lo que ocupa sino en el acceso, para el acceso al valor, al procesador le resulta mas rapido que este alineado a 32 bits... (procesador y modos 32bits)
los otros datos existen porque existe un mundo exterior mas alla de nuestra aplicacion, y muchas veces podemos necesitar interfacear o comunicarnos con este... y por ende, tenemos que ser capaces de hablar el mismo lenguaje... por ejemplo, un mensaje tcp a alguna aplicacion, levantar un archivo de datos (por ejemplo, algun archivo grafico), etc.
o simplemente, no nos importa la velocidad pero si el espacio.
ademas de que algunos datos internos son bytes (como las paletas de 8 bytes, o los rgb)
Una vez mas impera el conflicto "memoria vs CPU" ;D
Por cierto, Splinter, te tenía que reportar algo acerca de un array de tipo BYTE o algo así que no me leía bien Bennu, y que al pasarlo a INT ya iba bien, pero no encuentro el código. Creo que es del propio Doggy, de un array bidimensional dentro de una struct. No se si podré reproducirlo y aislarlo, pero lo intentaré. Lo comento por si a alguien más le pasa.
No habia pensado en la comunicacion con el exterior :P
Quote from: Drumpi on January 19, 2010, 01:30:47 AM
Una vez mas impera el conflicto "memoria vs CPU" ;D
...
En algun momento toca eso...
Despues te das por vencido y terminas usando solo datos de 4bytes
jajjaja
Quote from: Drumpi on January 19, 2010, 01:30:47 AM
Una vez mas impera el conflicto "memoria vs CPU" ;D
Por cierto, Splinter, te tenía que reportar algo acerca de un array de tipo BYTE o algo así que no me leía bien Bennu, y que al pasarlo a INT ya iba bien, pero no encuentro el código. Creo que es del propio Doggy, de un array bidimensional dentro de una struct. No se si podré reproducirlo y aislarlo, pero lo intentaré. Lo comento por si a alguien más le pasa.
cuando lo recuerdes me lo comentas con un ejemplo, estaremos atentos por si le pasa a alguien mas, gracias.