{"id":90,"date":"2024-06-17T06:34:56","date_gmt":"2024-06-17T06:34:56","guid":{"rendered":"https:\/\/blogs.scummvm.org\/kunxl\/?p=90"},"modified":"2024-06-17T11:25:08","modified_gmt":"2024-06-17T11:25:08","slug":"more-resource-loading","status":"publish","type":"post","link":"https:\/\/blogs.scummvm.org\/kunxl\/2024\/06\/17\/more-resource-loading\/","title":{"rendered":"More Resource Loading"},"content":{"rendered":"

This week\u2019s work revolved around loading resources from data files and developing the splash screen. I’ve previously discussed the splash screen in detail, so feel free to refer to my earlier blog post <\/a>if you\u2019re curious about my approach.<\/p>\n

Loading the QML file<\/h2>\n

The first task was to load the QML file. Interestingly, the contents of the QML file are stored in a tree data structure. This tree contains all the necessary information required to load the game, ranging from screen sizes to resource file paths.<\/p>\n

Re-writing qdFileManager and qdFilePackage Classes<\/h2>\n

The next task was to re-write the qdFileManager<\/code> and qdFilePackage<\/code> classes to use our zip utilities. These two classes are crucial for loading .pak<\/code> files, which are frequently used in games to “pack” all the resources together. In this re-write, we changed the internal of the class methods to detect pack files and use are zip utilites to unpack them. Refer to these commits for a detailed understanding of the changes.<\/p>\n

This led to the method qdFileManager::instance()::open_file(Common::SeekableReadStream *fh, const char *fname)<\/code> working with Common::SeekableReadStream which made it easier to read buffers from here on.<\/p>\n

Using readUint32LE() instead of read()<\/h2>\n

While making all these refactors, Sev explained the concept of Endianness and highlighted its importance in our codebase. Endianness in simple terms is the order in which multi-byte data is stored in memory. There are two systems in Endianness, Little Endian and Big Endian. In a system that follows Little Endian, the least significant byte is stored in the smallest address of memory, while in a Big Endian system, it is the complete opposite, the most significant byte is stored in the smallest address of memory. So let’s say you have a number 0x01. In the two systems it would look something like this.<\/p>\n