Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Micky on 2012-07-01 10:52:21
-
I was curious if any useful data about the structure of a field or how they were created could be extracted from the way tiles are grouped into strips. So I added a simple UI to my own extraction tool:
(http://bin.mypage.sk/FILES/fielddebug.jpg)
Unfortunately it's nothing useful. They seem to be mostly grouped by which palettes they share. Well, if anyone else is curious, this saves you the time! :)
-
I think palettes is the only reason they're grouped together, each image block only has 256 colors after all.
-
I think palettes is the only reason they're grouped together, each image block only has 256 colors after all.
A few blocks are using 15-bit colour directly. I was really hoping it would reveal a more technical or logical grouping.
With a good colour palette algorithm they could've displayed the whole image with a single 256 colour palette... and it makes me think, the jpeg screenshot above (highly compressed though) is a lot smaller than the compressed MIM file. They could've packed things a bit better if they used the DCT decompression hardware for field screens as well.
-
A few blocks are using 15-bit colour directly. I was really hoping it would reveal a more technical or logical grouping.
With a good colour palette algorithm they could've displayed the whole image with a single 256 colour palette... and it makes me think, the jpeg screenshot above (highly compressed though) is a lot smaller than the compressed MIM file. They could've packed things a bit better if they used the DCT decompression hardware for field screens as well.
Speed/size tradeoff. The tile data is tiny compared to the video data on the disk, and they needed to DMA it to the framebuffer quick. The PSX had no direct access to VRAM and the transfer is slow. That and the tile has to sit somewhere and it's bad enough that it has to be placed three times in VRAM (Texture cache, and the two framebuffers)
Keep in mind that the PSX can display multiple bit depths on the screen at the same time. You can have a 8-tile next to a 4-bit one next to a 15-bit one. That's your memory saver there. The size on the disk is irrelevant compared to how much VRAM you need.
-
Speed/size tradeoff. The tile data is tiny compared to the video data on the disk, and they needed to DMA it to the framebuffer quick. The PSX had no direct access to VRAM and the transfer is slow. That and the tile has to sit somewhere and it's bad enough that it has to be placed three times in VRAM (Texture cache, and the two framebuffers)
Keep in mind that the PSX can display multiple bit depths on the screen at the same time. You can have a 8-tile next to a 4-bit one next to a 15-bit one. That's your memory saver there. The size on the disk is irrelevant compared to how much VRAM you need.
You're right, of course, the size on disk doesn't matter that much. I thought one of their design goals was optimising loading times as well, though.
But then again, it is quite possible that the MDEC hardware was not exposed outside of the video library while FF7 was written.
-
Where might we find a copy of this tool?
-
The PSX had no direct access to VRAM and the transfer is slow.
DMA transfers from/to VRAM are actually fast, very fast, way faster than regular RAM access from the cpu.
-
Where might we find a copy of this tool?
On my hard disk. :)
This is in part of my testbed of apps I use to tinker with the FF7 data. You're not missing anything, though, I assume Akari's tools in q-gears are more complete by now.