Author Topic: FF7 field info (PS)  (Read 4120 times)

Micky

  • *
  • Posts: 300
    • View Profile
FF7 field info (PS)
« on: 2005-12-31 12:16:43 »
The programmer of the field graphics format wins the price for most complicated format! Definitely management material!
- when decoding the MIM files it is worth copying them into the positions in VRAM that are set in the MIM file, because the texture pages sometime start at different positions.
- the second section of the dat file contains the tiles. It starts with 4 32-bit offsets, then follows some kind of display list. The first offset points to tile descriptions with 8 byte per entry (X/Y/U/V/attributes), the third offset points to tile descriptions with 12 byte per entry. The second entry seems to start with the texture page and hicolour entries required (like the PS texture page register)
- Now it gets complicated, and I haven't decoded everything, yet: there seem to be three kinds of codes:
[16-bit depth?, 16-bit start tile, 16-bit tile count]
[0x7FFE, 16-bit index (into the table of texture page/hicolour entries), 16-bit 0]
[0x7FFF]
The texture page info covers the MIM file correctly, but I'm not sure how the entries are selected correctly. Very strange.
I'll post the code once I've got it working, but I just thought others are interested as well. Is anyone updating Gears, now that Halkun is busy?

Cyberman

  • *
  • Posts: 1572
    • View Profile
FF7 field info (PS)
« Reply #1 on: 2005-12-31 18:18:20 »
I haven't looked a lot at section 2 and 4 of the background information yet.
What I have are 4 sub sections that deal with the background
Code: [Select]
typedef struct
{
  UINT32  BackGroundTiles; // static tiles
  UINT32  ZZ0; // some sort of number exists here?
  UINT32  SpriteTiles;// animated tiles
  UINT32  ZZ1; // as described by Mickey I guess :)
} TileInformation;


Sprites are maped as such (so far)
Code: [Select]
typedef struct
{
  INT16  tX, tY;  // tile location in virtual background
  UINT8  sX, sY;  // location in tile palette
  UINT16 Attr, ZZ0, ZZ1, ZZ2;
} SpriteTile;

Sprites are in groups if you look at ZZ0 I think this indicates the frame they are in.
ZZ2 appears to be the Masked layer (it has bits set depending on the sprite group).
The number of sprite tiles is easy to determine, figuring out sprite groups requires more work, I think.  The attribute selects any sections of the tile map that have not been  associated with the background.  Sprites consist of static parts of the display and animated parts of the display.  The problem is there DEPTH, I was thinking section 4 might be the depth information in relation to the walk mesh.
I've almost figured out how to consistantly guess the palette settings.  I've noticed one has more palettes than one needs (hmmm).  In addition to all this, here is something you must consider. ALL palette pages are at X and Y sections.  These X and Y sections are determined by WORD location.  These are playstation Texture Pages basically.  Fun huh? :D

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
FF7 field info (PS)
« Reply #2 on: 2006-01-02 23:22:12 »
The 0x7FFE and 0x7FFF appear to be PSX GPU opcodes. Take a look at my PSX doc to see if you can decrypt the arguments.

Cyberman

  • *
  • Posts: 1572
    • View Profile
FF7 field info (PS)
« Reply #3 on: 2006-01-04 18:34:49 »
Quote from: halkun
The 0x7FFE and 0x7FFF appear to be PSX GPU opcodes. Take a look at my PSX doc to see if you can decrypt the arguments.

Well if they are they would be
Sprite 16x16, texture mapped, semitransparency on.  The remaining bits would be a mystery. I thought GPU opcodes were 32 bits with the MSB being the 'decision making' code? :)  Technically speaking it would be
MSB to LSB
0x7E B G R
So the lower bits would mean nada (since it's a sprite operation).
hmmm basically it would be
0x7E X X X
Y X
CLUT V U

Cyberman

  • *
  • Posts: 1572
    • View Profile
Update on Field map Palettes
« Reply #4 on: 2006-03-06 17:54:52 »
As you may have guessed this has been a bit of a difficulty for a while. Well no longer :)
The reason it's been a difficulty has to do with HOW they decided to do things.

The attribute WORD for the tile map does select the palette.  Wow this is so obvious! However what is NOT so obvious is how the tiles are grouped.  The are grouped in texture palettes. This means that from left to right, the MIM data file is loaded in in tile groups.  Reading the Tile information is done by thinking of how the tile maps would be 'piled' together if done by an automated tool. The first 512 Tileblocks are set for 2 palette and 2 sections only.  From then on each additional tileset is 128 blocks each with the remaining tiles filling the final block.  Going from left to right in the MIM file. SPRITE (animated or image data in from of people) data then continues beyond that (if there is any sprite data).  The palette information in the attribute is the same for the sprite data (just there can be multiple frames of data for it etc.).  ALSO there are different things you must do if there  are <= 256 tile blocks.  You must check the number of palettes THEN decide what to do :D.  You can have actually 2 palettes for background data and 1 for sprite data (Example 4SBWY_1). In other words like everything FF7 they have strange little things they did :)

Anyhow I've figured out the proper palette information finally. So sprites are next.

My next post will include some code and more detailed information.

Cyb