hola, quisiera saber como guardar graficos,sonidos y cosas asi en archivos .dat, he visto varios juegos q todo sus datos se encuentran en .dat como se hace?
Los archivos .dat suelen ser paquetes comprimidos con todos los recursos del juego. Pueden estar en formatos similares al zip, rar, o formatos propios.
Introducción al tema:
http://www.lemonteam.com/html/tutorials/sp...anish/zpack.htmY el código de la semana sobre ello:
http://www.stratos-ad.com/forums/index.php...=ST&f=28&t=1897Hay algunas librerias concretas para empaquetar/desempaquetar archivos, pero normalmente la gente acaba usando un fichero .zip renombrado a .dat u otra extensión.
entonces supongamos q guardo mis graficos y sonidos en un .dat entonces como haria el compilador para leerlos ya q cuando programe el juego coloco los graficos y sonidos individuales y al colocarlo asi no me los leeria no?
¿Y para qué quiere el compilador realmente "leer" graficos o sonidos ?
Lo que tu comlilarias serian las rutinas necesarias para abrir esos paquetes en tiempo real , lo que haya dentro de esos paquetes , al compilador le importa mas bien poco .
Si me equivoco que alguien me corrija B)
pero es asi cuando programo un juego....incluyo todos los graficos por ejemplo load_image: bota.bmp, ok al comprimir estos archivos por ejemplo con szlib, me crea un zpk, entonces con mi ejecutable y el zpk en una carpeta no me corre el juego porq no hay graficos o algo estoy haciendo mal????
Como bien te han dicho el compilador no tiene por ke leer los graficos ni ningun recurso de los archivos .dat, .pak, .pk3, .zip, etc.... es el programa kien tiene ke leer los recursos. Para cargar los recursos primero tendrias ke leer el archivo o extraerlo del pakete al disco duro y desde ahi leerlo, un ejemplo en pseudocodigo seria asi:
Extraer_Recurso("C:\mi juego\datos.dat", "/gfx/fondo.jpg", "C:\mi juego\fondo.jpg")
Cargar_Recurso("C:\mi juego\fondo.jpg")
Salu2...
creo q no me explique desde el principio, pues bien yo lo q quiero es esto supongamos q hga mis sprites,modelos,musica,ect para q no me los roben y los copien lo q quiero es guardarlos en un .dat para q me los roben no si me entiendan, he visto juegos y sus grrafiso esta empaquetados en un .dat al igua lq la musica
Te explicastes bien, y nosotros te hemos respondido a tu duda. Para utilizar los archivos de un .dat o el formato ke kieras usar (yo uso el formato sencillo PAK del Half-Life, sin compresion ni encriptacion ni nada) primero tienes ke extraer el archivo del pakete al disco y cargarlo con la funcion ke use tu juego para cargar sprites o lo ke kieras cargar. Ahi el compilador no pinta nada. Tu cuando cargas los archivos desde el disco duro, como estas haciendo actualmente, los cargas con la funcion ke usa tu juego, tu programa, no el compilador. El compilador solo crea el ejecutable de tu programa, no crea el programa con los graficos dentro ni nada parecido.
Salu2...
intenta construirte un manejador de "bibliotecas"
no es muy difícil (tampoco es fácil)
Esta biblioteca no sería más que un montón de archivos copiados tal cual dentro de otro archivo, junto con algo de información extra
necesitas 2 estructuras de datos: una será el encabezado principal de tu archivo y otra será un encabezado para cada archivo/recurso incluido en la biblioteca. algo como esto:
typedef struct
{
char LibID [10]; //Identificador de librería. Podrías guardar algo como "LibFile1.0" o algo así
char Version [6]; //Identificador de versión, por si piensas ampliar el formato en el futuro;)
int NumFiles; //Cuantos archivos hay en esta biblioteca
char Comments[256]; //Siempre es bueno gardar espacio para comentarios
//Tal vez quieras poner un "int ReservedBytes [algo]" para reservar bytes para versiones futuras
} LIB_HEADER;
Al momento de cargar un archivo de recursos primero leerías este cabezado del archivo y comprobarías si LibID == "LibFile1.0" o cualquier cosa que se te ocurra y también comprobarías la Versión, así te aseguras que no habrá incompatibilidad.
Ahora, esta estructura por sí sola no ayuda para nada, necesitarás otra estructura la cual se incluirá ANTES de cada archivo que agregues a la biblioteca y la cual contendrá información que describe a ESE archivo que sigue
muestro ejemplo:
typedef struct
{
unsigned int OffsetNext; //Este indica en qué posición está el header del siguiente archivo
int Type //Se usaría para saber si este archivo es una imagen, un sonido o cualquier otra cosa
char Name [64] //Algún nombre para identificar este recurso.
//Y cualqueir otra cosa que ocupes iría por aquí
} FILE_HEADER;
ahora, nuestro archivo de biblioteca quedaría estructurado algo como esto:
parte 1:
-bytes 0 a sizeof (LIB_HEADER): Información vital; indica si es o no es nuestro tipo de biblioteca, su versión, cuantos archivos tenemos, etc
parte 2:
-desde sizeof (LIB_HEADER) hasta sizeof (FILE_HEADER): Información sobre primer archivo
-Enseguida: el primer archivo en si. Estos son los bytes del archivo original tal cual
-a partir de OffsetNext: el FILE_HEADER del siguiente archivo
parte 3:
Repeticiones de la parte 2 tantas veces como archivos hay en la biblioteca (indicado en NumFiles del encabezado principal)
mmm....
espero que con esa explicación se entienda la idea :P
Es muy similar al formato PAK del Quake/Quake2/Half-Life, es senicllo y muy facil de usar.
Salu2...
Si bajas el codigo de allegro completo incluye las herramientas de empaquetado y ejemplos sencillos de como utilizarlo. Extraído de mi juego (a su vez copiado de un código que me prestaron):
// definicion del acceso
typedef enum {FNT01, FNT02, FNT03, FNT04} TFont;
typedef struct {
...
TFont font;
...
} opt2File;
....
// ejemplo uso
opt2File options;
options.font = FNT01;
DATAFILE* fntdat = NULL;
fntdat = load_datafile("data/misc/broers_fnt.dat");
font =(FONT*)fntdat[options.font].dat;
unload_datafile(fntdat);
// es decir, que tras cargar el archivo cada recurso se accede con un numero
// fntdat[0] es una fuente
// fntdat[1] es otra fuente
// fntdat[2] es una tercera fuente
Lo que tienes que hacer tú es una función load_datafile propia, con la compresión y formatos que quieras como te han dicho, ya que ahí arriba se encarga Allegro de ello. Toda la información sobre el compresor a dat y el gabbrer de allegro está en un txt, tan explicativo como largo, que se encuntra traducido al español en la dirección:
http://ftp.softnet.tuc.gr/ftp/linux/docs/L...ajo/grabber.txty del que puedes sacar alguna idea interesante si tienes tiempo de leerlo XD.
Bueno, para no dificular las cosas no ha de ser comprimido. Algunos formatos usados con el png traen su formato comprimido, aunque claro, en grupos de estos archivos se ganaría bastante espacio libre. Échale un vistazo a las zlib que creo que son para compresión de ese tipo y a los files de C que son muy utiles para esto y no están nada mal.
Cita de: "dbtoke"hola, quisiera saber como guardar graficos,sonidos y cosas asi en archivos .dat, he visto varios juegos q todo sus datos se encuentran en .dat como se hace?
physlibrary o algo asi, guena guena. en sf
1000€ y hablo +
Hay una posibilidad mucho más simple: Ofrece tus recursos de forma libre y así te aseguras de que no te los van a robar, porque ya los regalas tú.
Tú no pierdes nada y los demás tampoco. Todos ganan.
Ojalá tuviera el suficiente tiempo y nivel para ayudar a todos los que necesitan una canción, un sprite, un personaje o un escenario.
Cita de: "Mars Attacks"Ojalá tuviera el suficiente tiempo y nivel para ayudar a todos los que necesitan una canción, un sprite, un personaje o un escenario.
(genial) Hey!, yo te tomo la palabra de todo eso. Tendrás noticias mías :D
(offtopic del mes).
Yo lo de empaquetar lo veo muy bien porque:
1º/ Las cosas están más recogidas
2º/ Si añades compresión el gasto de disco es menor
Ahora bien, lo de hacer eso para que no te roben los gráficos o lo que sea pues la verdad, no está entre esas razones. Además supongo que en ese caso no tendrás la intención de permitir al resto crear contenido para tu juego (o al menos no empaquetando los recursos). :)
Saludos.
Utilice un sistema de empaquetado porque se le puede sacar bastante jugo al sistema, a parte, no me gusta ver mil ficheritos por ahi sueltos(creo q desde los pcfutbol, epoca msdos .... cogi mania a tener mil ficheros sueltos jaja), me gusta mas ver algo organizado (ojo, q es una mania mia eh?) en plan... fichero_graficos.dat, fichero_sonidos.dat y demas.... . Luego ademas, si usas compresion... ahorraras espacio en disco y ... aceleras la carga!!! Y bueno, funcionalidades extra...en el editor q me hice(q ahora se puede descargar y utilizar), puedes controlar parametros como el colorkey, alpha y demas propiedades... asi que... un editor y el empaquetado de recursos da mucho juego :)
Cita de: "dbtoke"pero es asi cuando programo un juego....incluyo todos los graficos por ejemplo load_image: bota.bmp, ok al comprimir estos archivos por ejemplo con szlib, me crea un zpk, entonces con mi ejecutable y el zpk en una carpeta no me corre el juego porq no hay graficos o algo estoy haciendo mal????
Bueno, por tu forma de hablar creo que estás un poco verde para lo que te están explicando aguí. Creo que te estamos liando más. Lo que tienes que entender es que no puedes usar load_image para leer imagenes que has convertido a otra cosa que no sea un BMP.
saludos
Tambien le podrias hechar un ojo al sistema que usa allegro, que es capaz de comprimir en archivo distintas imagenes, sonido, datos, etc. comprimidos o no ( tu lo eliges) e incluye documentación.
tambien se podria usar el propio fopen de c/c++, se abren todos los graficos y luego se guardan en .dat al igual con todo lo demas
dbtoke, es mejor hacerse una estructura de datos ke contenga informacion sobre el pakete tal como numero de archivos contenidos, posicion de lectura de cada archivo dentro del pakete, tamaño de cada archivo, path virtual del archivo dentro del pakete (como si de un disco virutal se tratase), etc... o utilizar sistemas ya creados como los anteriormente mencionados en vez de meter todos los archivos dentro de otro sin saber posiciones de lectura ni tamños si quiera.
Salu2...