Today I made progress in discovering some of the unknown values for the HG-3 format while working with the Grisaia Trilogy and friends.
First
The header is only 12 bytes long, the first unknown value is the header size I presume because it's always 12 bytes. Second unknown value is still unknown.
Second
Before each tag/stdinfo combo, there are two 4-byte values, the first value is used to determine the offset of the next entry when added to the current position of the stream before reading the tag/stdinfo combo. The second value is unknown.
In asmodean's code, the skipping of 8 bytes after each entry was just skipping the values needed to know the next offset. Now you may be wondering why these values are necessary. Well in rare cases, the beginning of the tag/stdinfo entry likes to be aligned to 8 bytes, so these offsets are necessary for later frames.
I'm wondering how you ended up skipping 12 bytes after the tag/stdinfo entries instead of 8. If it's working for you, there may be a difference in the format between the games we were testing on.
Third
There are some discovered previously unknown values in the stdinfo tag.
unknown[0] - Likely a 4-byte boolean stating if the image uses transparency. I still need to do more research on this one.
unknown[1] - The horizontal center of the image.
unknown[2] - The vertical center (or baseline) of the image.
These later two values are used in Grisaia for determining where to draw sprites. By default, the baseline is where the sprite should be drawn from the bottom of the screen.
Code Examples
Here are the two primary files to help explain what I'm doing when navigating the HG-3 format.
I've made further progress on deciphering the HG-3 format so this information is all correct, but can be added on if this ever gets worked on again. If it does then I can link newer code files.
Today I made progress in discovering some of the unknown values for the HG-3 format while working with the Grisaia Trilogy and friends.
First
The header is only 12 bytes long, the first unknown value is the header size I presume because it's always 12 bytes. Second unknown value is still unknown.
Second
Before each tag/stdinfo combo, there are two 4-byte values, the first value is used to determine the offset of the next entry when added to the current position of the stream before reading the tag/stdinfo combo. The second value is unknown.
In asmodean's code, the skipping of 8 bytes after each entry was just skipping the values needed to know the next offset. Now you may be wondering why these values are necessary. Well in rare cases, the beginning of the tag/stdinfo entry likes to be aligned to 8 bytes, so these offsets are necessary for later frames.
I'm wondering how you ended up skipping 12 bytes after the tag/stdinfo entries instead of 8. If it's working for you, there may be a difference in the format between the games we were testing on.
Third
There are some discovered previously unknown values in the stdinfo tag.
unknown[0]
- Likely a 4-byte boolean stating if the image uses transparency. I still need to do more research on this one.unknown[1]
- The horizontal center of the image.unknown[2]
- The vertical center (or baseline) of the image.These later two values are used in Grisaia for determining where to draw sprites. By default, the baseline is where the sprite should be drawn from the bottom of the screen.
Code Examples
Here are the two primary files to help explain what I'm doing when navigating the HG-3 format.