Saga Frontier

[Eroneous]

By request, my sprite findings for Saga Frontier.

In the MCHR folder, you've got all yer ahh, well, CHR data, obviously. I don't know what most of it means, but I know sprite data is in there somewhere.

I've been using TileMolester for this, but there may be a better alternative (considering TM doesn't make them line up right by default, anyway.)

Settings: canvas size="2x48"; codec="4bpp linear, reverse-order"; mode="2-dimensional"

So now, you've got sprites... sort of. What's that? Palette's nonexistent? Everything's misaligned? Yep! Palette's easy:

Palette --> Format --> 15-bpp BGR (555)
Palette --> Import From --> This File... (Obviously, you'd pick the same file you're opening, e.g. MCHR/CHR00.BIN for Emelia)

New dialog box comes up:
Offset: 2560
Size: 16
Format: 15 bpp BGR (555)
Byte Order: Intel

Umm.... so yeah. That kinda tells you what format the sprites are stored in, and palettes. I got that mostly through trial-and-error, honestly, and not through a lot of personal knowledge, though it DID teach me a bit. Location-wise, the palettes are at the end of the MCHR files (from, obviously, 2560 (decimal) onward.)

Oh! These sprites are the in-battle 'standing by' animation, as I recall. I haven't been able to find monster form sprites just yet, unfortunately, although I know monster data is in the--gasp! shockandawe--M_DATA folder. (Wow, Waylay, how'd you EVER guess THAT one?! I didn't, JusticeZero at the GameFAQs boards did if I remember correctly, but don't quote me on that.) IN THEORY that would be a logical place to look for sprites, but I haven't come up with anything yet.

The primary issue with TM in this case is the initial misalignment. While it doesn't take much Paint work to resolve that, it's still a minor annoyance. But, it could be a lot worse.

 

[VanishedOne]

Continuing from t'other thread--

Okay... I haven't listed my notes on field script opcodes (PM me if you need them) because they're just so full of things that need further checking, and with all the notes on which bits those are, they're rather resistant to editing into ready legibility.

Note: these notes are incomplete and in many cases not thoroughly checked; they may omit details on things like headers, other IMG subsections, etc.  where I haven't got around to making notes on those.

* TEX files: 4-byte header, followed by 16x16 tile data, 8bpp. (Palettes are in the corresponding IMG files.) Header generally begins 0x08, 0x40; then the other 2 bytes are (length of file after header in bytes/0x10).


* IMG files: header consists of 10 four-byte offsets to sections.

Section 0 - seems to give frame attributes for background animations: I was able to manipulate one of the neon signs in Koorong here (where the animation is basically a palette variation). (Generally 0x808080 seems to be a telltale sign of colour tinting to be applied to a base palette; in sect. 9 it definitely is.) I never got around to exploring these very well, but the second byte after the 808080 seems to be duration, since it affects anim. speed.

Section 1 - NPC attributes? This and the next section I've looked at only briefly. 0x808080 turns up again in the attribute data; where those are bytes 1-3 of an NPC's attribs., the 10th is clipping (00 = solid, FF = walk-through), and the 12th and 13th are the number of the field script routine to execute when the NPC is interacted with.

Section 2 - unknown. Also seems to affect NPC reactions.

Section 3 - attributes for map transitions. Presumably SGF has an involved way of doing these because of the extra complexity the inter-region interstitials cause. There's a possible section header that generally seems to be 0x00000000A0007800 (no idea), then transition details as follows:

VV WW MMMM XXXX YYYY [Each letter = 1 hex digit, i.e. a letter pair = 1 byte.]

V - unknown; it can affect visual rendering, but I don't know just what it does.
W - music to play on target map; FF is 'keep playing what was already playing'.
M - target map ID.
X,Y - entry co-ords. (Incidentally, the origin is the bottom-left.)

Section 4 - field script: basically SHIFT_JIS with the ASCII subset replaced by opcodes, so there's no separate text table. There's a section-header with 16-bit pointers to the script routines. (Its first 2 bytes are the length of the rest of the header.)

Section 5 - sound, judging by the AKAO strings.

Section 6 - appears to be NPC sprite data, but I never got around to extracting any; I haven't examined this section much.

Section 7 - collision data. FF = wall, 00 I think = open space; I don't know about the other numbers.

Section 8 - unknown

Section 9 - starts with a 12(?)-byte section header, 0x0C (header length?) followed by 16-bit relative offsets to subsections (?), ending with a 32-bit relative offset for the end of the sections and hence of the file.

In the first subsection (after what seems to be a set of general map attributes) are attributes for tilemap objects, in lists as follows (the numbers are numbers of bytes used):

1 Red tint
1 Green tint
1 Blue tint
1 Palette ID
2 X-position, offset from default position.
2 -Y-position, offset from default position.
2 +Y-position, offset from default position.
2 Unknown
1 Unknown.
1 Distortion in X axis (stretching)
1 Unknown
1 Flying height: changing this lets the object move vertically above its normal position (not below).
1 Ripple (01 gives a weird floating animation (SFX, not a sprite anim routine). Higher numbers just made the object I tested with vanish.)
1 Unknown. (Visibility? Anything other than 00 made the test object vanish.)

Since objects are normally at 'normal' brightness, the RGB bytes tend to appear as that telltale 0x808080.

EDIT: I had another look at the tile arrangements in the 2nd subsection.
????????XXXXYYYYAAAABBBB, followed by tile IDs as UINT16s, in columns, left to right (length (A/0x10) * (B/0x10) * 2)
X - X-position, absolute. [Origin seems to be top-left for these.]
Y - Y-pos.
A - Width in pixels
B - height in pixels

The palette subsection seems to have a 6-byte header: it usually starts 0x00, 0x01, and then the third byte is the number of palettes. Palettes are like the ones for sprites, but 512 bytes (256 colours) long.


* MESG*.BIN files: field script to be accessible anywhere, 1 file per protagonist. Mostly taken up by the debug menu; also generic lines for obtaining items, etc.

* MCHAR8.BIN - more menu PC sprites, I think for the memory card menu.

* TITLE.OUT and EMU_TITL.OUT feature the SQUARESOFT logo image from boot-up--view at 8bpp linear, 2-dimensional in TM.

* I spent ages puzzling over the title screen background in TITLE.RL, trying to work out why there were extra bytes strewn through it, only to discover... that there's a version without them in TITLE.ARC. (Real colour lines 320px long, 16bpp ARGB.) Title screen sprites are in HERO.ARC.