rres
rres 1.2.0
rres es un formato de archivo simple y fácil de usar para empaquetar recursos
rres ha sido diseñado para empaquetar recursos del juego (imágenes, fuentes, texto, audio, modelos...) en un formato integral simple e independiente, fácil de leer y escribir, diseñado para cargar datos de una manera rápida y eficiente.
rres está inspirado en los siguientes formatos de archivo: XNB (utilizado por XNA/MonoGame), RIFF, PNG y ZIP.
rresFileHeaderrresResourceChunkrresResourceChunkInforresResourceChunkDatarresResourceDataTyperresCentralDir Simplicidad : la estructura rres es simple, un encabezado de archivo y múltiples recursos uno tras otro. Aún así, cada recurso tiene un pequeño encabezado de información de recurso (32 bytes) con múltiples opciones disponibles.
Facilidad de uso : la biblioteca rres para leer archivos .rres es pequeña y solo tiene las funciones mínimas requeridas para leer datos de recursos desde su identificación. Sólo utiliza un pequeño conjunto de funciones de la biblioteca C estándar. Se proporciona una herramienta rrespacker con GUI/CLI para crear y ver fácilmente archivos .rres .
Flexibilidad : el formato rres admite cualquier tipo de archivo de entrada; si los datos no se clasifican como un tipo de datos básico, pueden empaquetarse simplemente como datos de archivo sin formato.
Portabilidad : el formato de archivo rres no está vinculado a un motor específico, la biblioteca base simplemente lee los datos de recursos tal como están empaquetados y esos datos se pueden asignar a cualquier estructura del motor. Se ha proporcionado un ejemplo de uso con la biblioteca auxiliar rres-raylib.h que asigna datos rres a estructuras raylib.
Seguridad : rres admite compresión y cifrado por recurso si es necesario. Aún así, a pesar del soporte proporcionado por el formato de archivo, depende del usuario implementarlo en la herramienta rres packer y en la biblioteca de mapeo del motor. rres no fuerza ningún algoritmo de compresión/cifrado específico por diseño
Extensibilidad : el formato de archivo rres es extensible y admite nuevos tipos de datos, nuevas funciones y datos personalizados si es necesario.
Gratis y de código abierto : rres es una especificación abierta y una biblioteca gratuita y de código abierto. Se puede utilizar con la herramienta proporcionada ( rrespacker ) o se puede implementar un empaquetador/cargador personalizado para cualquier motor . La descripción del formato también se puede utilizar como material de aprendizaje para cualquiera que desee crear su propio formato de archivo de empaquetado de datos.
Hay algunas razones importantes para empaquetar los datos de los recursos del juego en un formato como rres ; aquí hay algunas buenas razones para hacerlo.
Organización : evita miles de archivos distribuidos en cientos de directorios en la versión final del juego. Todos los datos de los archivos del juego se pueden organizar en uno o varios archivos .rres . Mantiene el directorio del juego limpio y bien estructurado.
Rendimiento : mantener todos los archivos necesarios para un nivel/mapa en un único archivo .rres reduce la necesidad de identificadores de archivos para acceder a varios archivos; Los identificadores de archivos son un recurso del sistema operativo y el costo de abrir un archivo no es insignificante, puede causar retrasos en el juego. Los tiempos de acceso a los datos dentro del archivo .rres también son importantes y dependiendo de cómo estén organizados los archivos también podría mejorar los tiempos de carga.
Seguridad : Evite exponer todos los recursos del juego directamente al usuario para copiarlos o modificarlos fácilmente. Los datos empaquetados en un archivo .rres serán más difíciles de extraer y modificar para la mayoría de los usuarios; proteja los activos con derechos de autor de su juego. rres también admite la compresión y el cifrado de datos por recurso, lo que agrega un nivel adicional de seguridad cuando es necesario.
Tiempos de descarga : si es necesario acceder a los datos desde un servidor y descargarlos, los activos empaquetados en uno o varios archivos .rres mejoran los tiempos de descarga, en comparación con descargar cada archivo individualmente.
rres ha estado en desarrollo desde 2014 . Comencé este proyecto con el objetivo de crear un formato de archivo empaquetado similar a XNB para raylib. En los últimos 8 años el proyecto ha sufrido múltiples rediseños y mejoras junto con un proceso de aprendizaje de formatos de archivo. En ese tiempo implementé cargadores/grabadores para más de 20 formatos de archivos diferentes y también creé más de 12 formatos de archivos personalizados para múltiples herramientas personalizadas de raylibtech.
El formato de archivo rres ha pasado por al menos 4 grandes rediseños :
El primer diseño del formato se limitó a empaquetar un recurso tras otro, cada recurso constaba de un encabezado de información del recurso seguido de un conjunto fijo de cuatro parámetros posibles y los datos del recurso. Junto al archivo .rres , se generó un archivo de encabezado .h que asigna el rresId con un nombre de archivo de recurso (generalmente el nombre de archivo original de los datos no procesados). Este modelo era bastante simple e intuitivo, pero tiene algunas desventajas importantes: no consideraba piezas de datos complejas que pudieran requerir múltiples fragmentos y no había forma de extraer/recuperar archivos fuente originales (o similares).
El segundo diseño fue mucho más complejo e intentó abordar las deficiencias del primer diseño. En el segundo diseño, cada recurso podría incluir múltiples fragmentos de datos en una especie de estructura de árbol. En realidad, ese diseño era similar al formato de archivo RIFF: cada fragmento podía contener fragmentos adicionales, cada uno con su encabezado y datos. También se agregaron algunas opciones de recursos adicionales, pero el formato se volvió bastante complejo de entender y administrar. Finalmente, se descartó la implementación de pruebas y se investigó una alternativa más sencilla.
El tercer diseño fue un retorno al primer diseño: simplicidad pero manteniendo algunas de las opciones para los recursos individuales. El problema de múltiples recursos generados a partir de un único archivo de entrada se resolvió utilizando un campo de desplazamiento simple en el encabezado de información del recurso que apunta al siguiente recurso vinculado cuando sea necesario. Los recursos se cargaron como una serie de fragmentos de recursos. Se agregó un fragmento de recurso opcional del Directorio central para mantener las referencias de los archivos de entrada. El formato era bueno, pero aún requería implementación y mayor investigación, debía ser independiente del motor y aún dependía de las estructuras y funcionalidades de raylib.
Se realizó un cuarto diseño a lo largo de la implementación; casi todas las estructuras y campos se revisaron y cambiaron de nombre para lograr coherencia y simplicidad. Se ha creado una biblioteca separada ( rres-raylib.h ) para asignar los datos de recursos cargados a una biblioteca personalizada/tipos de datos de motor; se ha eliminado cualquier dependencia de raylib, lo que lo convierte en un formato de archivo completamente independiente del motor. Se han implementado varios ejemplos de uso de raylib para ilustrar la conexión biblioteca-motor de rres y se han implementado múltiples tipos de carga de recursos. La herramienta rrespacker se creó desde cero para generar archivos rres , admite una agradable interfaz GUI con soporte para arrastrar y soltar, pero también una potente línea de comandos para el procesamiento por lotes. La implementación de compresión y cifrado se ha trasladado a la implementación de la biblioteca del usuario para alinearla con la herramienta de empaquetado y mantener el formato de archivo rres más limpio y simple.
Ha sido un proyecto de 8 años , trabajando en él de forma intermitente, con muchos rediseños y revisiones pero personalmente estoy muy contento con el resultado final. rres es un formato de archivo de empaquetado de recursos al nivel de cualquier formato de paquete de motor profesional , PERO gratuito y de código abierto , disponible para cualquier desarrollador de juegos que quiera usarlo, implementarlo o crear una versión personalizada.
El formato de archivo rres consta de un encabezado de archivo ( rresFileHeader ) seguido de una serie de fragmentos de recursos ( rresResourceChunk ). Cada fragmento de recurso tiene un encabezado de información de recurso ( rresResourceChunkInfo ) que incluye un código de tipo de datos FOURCC e información de datos de recurso. Los datos del recurso ( rresResourceChunkData ) contienen un pequeño conjunto de propiedades para identificar datos, según el tipo y podrían contener algunos datos adicionales al final.
Fig 01. Estructura de archivos rres v1.0.
NOTA: los rresResourceChunk se generan a partir de archivos de entrada. Es importante tener en cuenta que los recursos no se pueden asignar a archivos 1:1, un archivo de entrada podría generar múltiples fragmentos de recursos. Por ejemplo, un archivo de entrada .ttf podría generar un fragmento de recurso de imagen (tipo RRES_DATA_IMAGE ) más un fragmento de recurso de información de glifo de fuente (tipo RRES_DATA_FONT_GLYPHS ).
rresFileHeader ( 16 bytes )
Signature Id ( 4 bytes ) // File signature id: 'rres'
Version ( 2 bytes ) // Format version
Resource Count ( 2 bytes ) // Number of resource chunks contained
CD Offset ( 4 bytes ) // Central Directory offset (if available)
Reserved ( 4 bytes ) // rresFileHeader La siguiente estructura C define rresFileHeader :
// rres file header (16 bytes)
typedef struct rresFileHeader {
unsigned char id [ 4 ]; // File identifier: rres
unsigned short version ; // File version: 100 for version 1.0
unsigned short chunkCount ; // Number of resource chunks in the file (MAX: 65535)
unsigned int cdOffset ; // Central Directory offset in file (0 if not available)
unsigned int reserved ; // | Campo | Descripción |
|---|---|
id | Identificador de firma del archivo, deben ser los cuatro caracteres: r , r , e , s . |
version | Define la versión y subversión del formato. |
chunkCount | Número de fragmentos de recursos presentes en el archivo. Tenga en cuenta que podría ser mayor que la cantidad de archivos de entrada procesados. |
cdOffset | Desplazamiento absoluto del Directorio Central dentro del archivo, tenga en cuenta que CDIR es solo otro tipo de fragmento de recurso, el Directorio Central puede estar presente en el archivo o no . Se recomienda colocarlo como el último fragmento del archivo si se implementa un empaquetador rres personalizado. Consulte la sección rresCentralDir para obtener más detalles. |
reserved | Este campo está reservado para futuras adiciones si es necesario. |
Tabla 01. Descripción y detalles de los campos rresFileHeader
Consideraciones:
rres están limitados por diseño a un máximo de 65535 fragmentos de recursos ; en caso de que sea necesario empaquetar más recursos, se recomienda crear varios archivos rres .rres utilizan desplazamientos de 32 bits para abordar los diferentes fragmentos de recursos; en consecuencia, no se pueden abordar más de ~4 GB de datos ; mantenga los archivos rres con un tamaño inferior a 4 GB . En caso de que se requiera más espacio para empaquetar recursos, cree varios archivos rres . rresResourceChunk El archivo rres contiene varios fragmentos de recursos. Cada fragmento de recurso representa un paquete de datos autónomo. Los fragmentos de recursos se generan a partir de archivos de entrada en la creación de archivos rres mediante la herramienta rres packer; Dependiendo de la extensión del archivo, la herramienta rres packer extrae los datos necesarios del archivo y genera uno o más fragmentos de recursos. Por ejemplo, para un archivo de imagen, se genera un fragmento de recurso de type RRES_DATA_IMAGE que contiene solo los datos de píxeles de la imagen y las propiedades necesarias para leer esos datos desde el archivo de recursos.
Es importante tener en cuenta que un archivo de entrada podría generar varios fragmentos de recursos cuando se crea el archivo rres . Por ejemplo, un archivo de entrada .ttf podría generar un fragmento de recurso RRES_DATA_IMAGE más un fragmento de recurso RRES_DATA_FONT_GLYPHS ; También es posible simplemente empaquetar el archivo como un tipo de fragmento de recurso simple RRES_DATA_RAW , en ese caso el archivo de entrada no se procesa, solo se empaqueta como datos sin procesar.
Al crear rres , rres packer podría crear un fragmento de recurso adicional de tipo RRES_DATA_DIRECTORY que contenga datos sobre los archivos de entrada procesados. Podría ser útil en algunos casos, por ejemplo, relacionar el nombre del archivo de entrada directamente con la identificación del recurso generado y también extraer los datos en una estructura de archivo similar a la de entrada original.
Cada fragmento de recurso se divide en dos partes: rresResourceChunkInfo + rresResourceData .
rresResourceChunkInfo La siguiente estructura C define rresResourceChunkInfo :
// rres resource chunk info header (32 bytes)
typedef struct rresResourceChunkInfo {
unsigned char type [ 4 ]; // Resource chunk type (FourCC)
unsigned int id ; // Resource chunk identifier (generated from filename CRC32 hash)
unsigned char compType ; // Data compression algorithm
unsigned char cipherType ; // Data encription algorithm
unsigned short flags ; // Data flags (if required)
unsigned int packedSize ; // Data chunk size (compressed/encrypted + custom data appended)
unsigned int baseSize ; // Data base size (uncompressed/unencrypted)
unsigned int nextOffset ; // Next resource chunk global offset (if resource has multiple chunks)
unsigned int reserved ; // | Campo | Descripción |
|---|---|
type | Un código FourCC e identifica el tipo de datos de recursos contenidos en rresResourceChunkData . Enum rresResourceDataType define varios tipos de datos; se pueden agregar otros nuevos si es necesario. |
id | Un identificador de recurso global, se genera a partir del nombre del archivo de entrada utilizando un hash CRC32 y no es único. Un archivo de entrada puede generar múltiples fragmentos de recursos, todos los fragmentos generados comparten el mismo identificador y se cargan juntos cuando se carga el recurso. Por ejemplo, un .ttf de entrada podría generar dos fragmentos de recursos ( RRES_DATA_IMAGE + RRES_DATA_FONT_GLYPHS ) con el mismo identificador que se cargarán juntos cuando se solicite su identificador. Depende del usuario decidir qué hacer con los datos cargados. |
compType | Define el algoritmo de compresión utilizado para los datos del fragmento de recurso. La compresión depende de la biblioteca intermedia entre rres y el motor, rres.h simplemente define algunos valores de algoritmo útiles que se utilizarán en caso de implementar la compresión. La compresión siempre debe aplicarse antes del cifrado y comprime el rresResourceData completo ( Property Count + Properties[] + Data ). Si no se aplica ningún cifrado de datos, packedSize define el tamaño de los datos comprimidos. |
cipherType | Define el algoritmo de cifrado utilizado para los datos del fragmento de recurso. Al igual que la compresión, el cifrado depende de la biblioteca intermedia entre rres y el motor, rres.h simplemente define algunos valores de algoritmo útiles que se utilizarán en caso de implementar el cifrado. El cifrado debe aplicarse después de la compresión. Dependiendo del algoritmo de cifrado y el modo de cifrado, podría requerir que se adjunte algún dato adicional a los datos del recurso (es decir, MAC de cifrado), esto depende de la implementación y la herramienta rres packer/la biblioteca intermedia rres para los motores son responsables de administrarlo. datos adicionales. Se recomienda simplemente agregarlo a los datos de recursos y considerarlo en packedSize . |
flags | Reservado para banderas adicionales, en caso de que la implementación las requiera. |
packedSize | Define el tamaño empaquetado (comprimido/cifrado + datos de usuario adicionales) de rresResourceChunkData . Los datos empaquetados pueden contener datos de usuario adjuntos al final, después de los datos comprimidos/cifrados, por ejemplo, nonce/MAC para los datos cifrados, pero depende de la implementación, administrado por la herramienta rres packer y la biblioteca del usuario para cargar los datos de los fragmentos. estructuras del motor objetivo. |
baseSize | Define el tamaño base (sin comprimir/sin cifrar) de rresResourceChunkData . |
nextOffset | Define la dirección de posición global del archivo para el siguiente fragmento de recurso relacionado ; es útil para archivos de entrada que generan múltiples recursos, como fuentes o mallas. |
reserved | Este campo está reservado para futuras adiciones si es necesario. |
crc32 | Calculado sobre el fragmento completo rresResourceData ( packedSize ) y está destinado a detectar errores de corrupción de datos. |
Tabla 02. Descripción y detalles de los campos rresResourceChunkInfo
rresResourceChunkData rresResourceChunkData contiene los siguientes datos:
Property Count : número de propiedades contenidas, depende del type recursoProperties[] : propiedades requeridas de datos de recursos, dependen del type de recursoData : datos sin procesar del recurso, dependen del type de recurso NOTA: rresResourceChunkData podría contener datos de usuario adicionales; en esos casos, se debe considerar un tamaño de datos adicional en packedSize .
rresResourceDataType El type de recurso especificado en rresResourceChunkInfo define el tipo de datos y la cantidad de propiedades contenidas en el fragmento de recurso.
Aquí están los tipos de datos actualmente definidos. Tenga en cuenta que algunos archivos de entrada podrían generar múltiples fragmentos de recursos de múltiples tipos. Se podrían agregar tipos de recursos adicionales si fuera necesario.
// rres resource chunk data type
// NOTE 1: Data type determines the properties and the data included in every chunk
// NOTE 2: This enum defines the basic resource data types, some input files could generate multiple resource chunks
typedef enum rresResourceDataType {
RRES_DATA_NULL = 0 , // FourCC: NULL - Reserved for empty chunks, no props/data
RRES_DATA_RAW = 1 , // FourCC: RAWD - Raw file data, input file is not processed, just packed as is
RRES_DATA_TEXT = 2 , // FourCC: TEXT - Text file data, byte data extracted from text file
RRES_DATA_IMAGE = 3 , // FourCC: IMGE - Image file data, pixel data extracted from image file
RRES_DATA_WAVE = 4 , // FourCC: WAVE - Audio file data, samples data extracted from audio file
RRES_DATA_VERTEX = 5 , // FourCC: VRTX - Vertex file data, extracted from a mesh file
RRES_DATA_FONT_GLYPHS = 6 , // FourCC: FNTG - Font glyphs info, generated from an input font file
RRES_DATA_LINK = 99 , // FourCC: LINK - External linked file, filepath as provided on file input
RRES_DATA_DIRECTORY = 100 , // FourCC: CDIR - Central directory for input files relation to resource chunks
// TODO: Add additional data types if required
} rresResourceDataType ; Los types de datos actualmente definidos constan de las siguientes propiedades y datos:
| tipo de recurso | cuatrocc | accesoriosContar | accesorios | datos |
|---|---|---|---|---|
RRES_DATA_NULL | NULL | 0 | - | - |
RRES_DATA_RAW | RAWD | 4 | props[0] : tamañoprops[1] : extension01props[2] : extension02props[3] : reservado | bytes de archivo sin formato |
RRES_DATA_TEXT | TEXT | 4 | props[0] : tamañoprops[1] : rresTextEncodingprops[2] : rresCodeLangprops[3] : código cultural | datos de texto |
RRES_DATA_IMAGE | IMGE | 4 | props[0] : anchoprops[1] : alturaprops[2] : rresPixelFormatprops[3] : mapas mip | datos de píxeles |
RRES_DATA_WAVE | WAVE | 4 | props[0] : frameCountprops[1] : tasa de muestraprops[2] : tamaño de muestraprops[3] :canales | datos de muestras de audio |
RRES_DATA_VERTEX | VRTX | 4 | props[0] : vérticeCountprops[1] : rresVertexAttributeprops[2] : componenteCountprops[3] : rresVertexFormat | datos de vértice |
RRES_DATA_FONT_GLYPHS | FNTG | 4 | props[0] : tamaño baseprops[1] : glifoCountprops[2] : glifoPaddingprops[3] : rresFontStyle | rresFontGlyphInfo[0..glyphCount] |
RRES_DATA_LINK | LINK | 1 | props[0] : tamaño | datos de ruta de archivo |
RRES_DATA_DIRECTORY | CDIR | 1 | props[0] : entradaCount | rresDirEntry[0..entryCount] |
Tabla 03. Valores y detalles definidos rresResourceDataType
NOTA: RRES_DATA_RAW contiene la extensión del archivo empaquetado como parte de sus propiedades, la extensión char se convierte en un valor unsigned int de 4 bytes, que comienza con un punto. es decir, ".png" => 0x2e706e67 . En caso de que la extensión no fuera relevante, la implementación del usuario podría decidir establecer esas propiedades en 0 .
rres.h define las siguientes enums para facilitar la asignación de algunas de las propiedades:
rresTextEncoding : define varias codificaciones de texto posibles, el valor predeterminado es 0 (UTF-8)rresCodeLang : Define varios lenguajes de programación, útil en caso de incrustar archivos de código o scripts.rresPixelFormat : define múltiples valores de formato de píxeles para los datos de píxeles de la imagen.rresVertexAttribute : define varios tipos de atributos de vértice para mayor comodidad.rresVertexFormat : define varios formatos de datos para datos de vérticerresFontStyle : define varios estilos de fuente (regular, negrita, cursiva...), el valor predeterminado es 0 ( RRES_FONT_STYLE_DEFAULT ).rresCentralDir El fragmento de recursos Central Directory es un fragmento especial que puede estar presente o no en el archivo rres , almacena información sobre los archivos de entrada procesados para generar múltiples fragmentos de recursos y podría ser útil para:
Haga referencia a los recursos por su nombre de archivo original. Esto es muy útil en términos de implementación para minimizar los cambios de código requeridos si el empaquetado rres se realiza sobre un proyecto existente o al final del desarrollo de un proyecto, si toda la carga de archivos se realizó usando los nombres de archivo directamente.
Extraiga algunos de los recursos a un archivo de entrada similar. Sólo será posible si el archivo de entrada no ha sido procesado de forma destructiva. Por ejemplo, si se procesó un archivo .ttf para generar un atlas de imágenes de glifos + información de datos de glifos, no será posible recuperar el archivo .ttf original.
rres proporciona algunas estructuras útiles para tratar con datos de fragmentos de recursos Central Directory :
// rres central directory entry
typedef struct rresDirEntry {
unsigned int id ; // Resource id
unsigned int offset ; // Resource global offset in file
unsigned int reserved ; // reserved
unsigned int fileNameSize ; // Resource fileName size (NULL terminator and 4-byte alignment padding considered)
char fileName [ RRES_MAX_CDIR_FILENAME_LENGTH ]; // Resource original fileName (NULL terminated and padded to 4-byte alignment)
} rresDirEntry ;
// rres central directory
// NOTE: This data represents the rresResourceChunkData
typedef struct rresCentralDir {
unsigned int count ; // Central directory entries count
rresDirEntry * entries ; // Central directory entries
} rresCentralDir ;NOTA: Las entradas de nombre de archivo del Directorio central están alineadas con un relleno de 4 bytes para mejorar los tiempos de acceso a los archivos.
rres.h proporciona una función para cargar Central Directory desde el archivo rres cuando esté disponible: rresLoadCentralDirectory() y también una función para obtener identificadores de recursos de su nombre de archivo original: rresGetIdFromFileName() .
En caso de que se genere un archivo rres sin Central Directory , se debe proporcionar un archivo de encabezado secundario ( .h ) con las referencias de identificación de todos los recursos, que se utilizará en el código de usuario.
rres está diseñado como un formato de archivo independiente del motor que se puede utilizar con cualquier motor de juego. Los desarrolladores que adoptan rres pueden implementar una biblioteca personalizada y una abstracción personalizada para asignar datos genéricos rres a las estructuras de datos de sus propios motores y también herramientas de empaquetado rres personalizadas .
El siguiente diagrama muestra una implementación de muestra de rres para la biblioteca raylib .
Fig 02. Implementación de muestra de rres: bibliotecas y herramientas de motor personalizadas.
La implementación rres consta de varias partes:
rres.hrres-raylib.hrrespackerrres.h La biblioteca base rres está a cargo de leer fragmentos de recursos de archivos rres en una estructura de recursos genérica, devuelta al usuario. La estructura de recursos expuesta por el usuario rresResourceChunk sigue la estructura de especificaciones rres ( rresResourceChunkInfo + rresResourceChunkData ). Se proporcionan las siguientes estructuras:
rresResourceChunk contiene un único fragmento con información y datos requeridos por el usuario: rresResourceChunkInfo + rresResourceChunkDatarresresourceChunkInfo contiene la información sobre el fragmento de recurso cargadorresResourceChunkData contiene los datos reales del recurso: las propiedades requeridas y los datos sin procesar. Es importante tener en cuenta que en el caso de que los datos hayan sido comprimidos/cifrados, depende de la biblioteca del usuario ( rres-raylib.h ) procesar esos datos; en esos casos, chunk.data.raw contiene los datos comprimidos/cifrados y chunk.data.propCount = 0 y chunk.data.props = NULL ; Depende de la biblioteca del usuario completar las propiedades después de la descompresión/descifrado.rresResourceMulti contiene múltiples rresResourceChunks para un archivo de entrada procesado // rres resource chunk
typedef struct rresResourceChunk {
rresResourceChunkInfo info ; // Resource chunk info
rresResourceChunkData data ; // Resource chunk packed data, contains propCount, props[] and raw data
} rresResourceChunk ;
// rres resource chunk info header (32 bytes)
typedef struct rresResourceChunkInfo {
unsigned char type [ 4 ]; // Resource chunk type (FourCC)
unsigned int id ; // Resource chunk identifier (generated from filename CRC32 hash)
unsigned char compType ; // Data compression algorithm
unsigned char cipherType ; // Data encription algorithm
unsigned short flags ; // Data flags (if required)
unsigned int packedSize ; // Data chunk size (compressed/encrypted + custom data appended)
unsigned int baseSize ; // Data base size (uncompressed/unencrypted)
unsigned int nextOffset ; // Next resource chunk global offset (if resource has multiple chunks)
unsigned int reserved ; // Se puede cargar un único rresResourceChunk desde el archivo .rres con la función proporcionada: rresLoadResourceChunk() y descargarlo con rresUnloadResourceChunk() .
Se puede cargar un rresResourceMulti completo desde el archivo .rres con la función proporcionada: rresLoadResourceMulti() y descargarlo con rresUnloadResourceMulti() .
rres-raylib.h La biblioteca de mapeo incluye rres.h y proporciona funcionalidad para mapear los datos de los fragmentos de recursos cargados desde el archivo rres en estructuras raylib . La API proporcionada es simple e intuitiva y sigue las convenciones raylib :
RLAPI void * LoadDataFromResource ( rresResourceChunk chunk , int * size ); // Load raw data from rres resource chunk
RLAPI char * LoadTextFromResource ( rresResourceChunk chunk ); // Load text data from rres resource chunk
RLAPI Image LoadImageFromResource ( rresResourceChunk chunk ); // Load Image data from rres resource chunk
RLAPI Wave LoadWaveFromResource ( rresResourceChunk chunk ); // Load Wave data from rres resource chunk
RLAPI Font LoadFontFromResource ( rresResourceMulti multi ); // Load Font data from rres resource multiple chunks
RLAPI Mesh LoadMeshFromResource ( rresResourceMulti multi ); // Load Mesh data from rres resource multiple chunks
RLAPI int UnpackResourceChunk ( rresResourceChunk * chunk ); // Unpack resource chunk data (decompres/decrypt data)
RLAPI void SetBaseDirectory ( const char * baseDir ); // Set base directory for externally linked data Tenga en cuenta que la descompresión/descifrado de datos se implementa en esta biblioteca personalizada, UnpackResourceChunk() se proporciona a los usuarios. rresResourceChunk contiene valores de identificador de cifrado/compresor para mayor comodidad. El soporte de compresores y cifrados depende de la implementación del usuario y debe estar alineado con la herramienta de empaquetado ( rrespacker ).
El formato de archivo rres es independiente del motor, se pueden crear bibliotecas y herramientas para cualquier motor/marco en cualquier lenguaje de programación.
rrespacker rrespacker es la herramienta de empaquetado rres encargada de procesar todos los archivos de entrada y crear el archivo rres , siguiendo la especificación. En caso de que se admitan algunos algoritmos de compresión/cifrado, esta herramienta debe implementarlos y la biblioteca de mapeo debe admitir los mismos algoritmos, en nuestro caso rres-raylib.h .
Fig 03. Herramienta rrespacker, interfaz GUI, también admite CLI para procesamiento por lotes.
rrespacker se puede utilizar en línea (o descargar) desde itch.io.
Las especificaciones de formato de archivo rres , la biblioteca rres.h y la biblioteca rres-raylib.h tienen licencia MIT. Consulte LICENCIA para obtener más detalles.
Copyright (c) 2014-2024 Ramón Santamaría (@raysan5)
