Advice Wanted

Hi, Guys!

I'm new in this subject so I need your advice. I love FF series a lot and have a huge interest to know as much as possible about these games, including minute details like crazy fanatic. I always wonder how people find out such things as damage calculation and stuff like that.

I ignited desire to see a source code of a game and learn to navigate in it. But I don't know what should I begin with? I guess I need to know assembler good enough. Well I learn something in my university, but I took a rest for a year at the moment, so I haven't got in-depth knowledge.

I am confused, I don't even sure I write English correctly, help me please! ='(

You can go in the ''Resources and links'' section and download the different disassemblies (source code) of the game. There are comments in the code which makes it easier to navigate.

• Bank C0 deals with event commands among other core elements.
  
• Bank C1 is graphic oriented and deals with the combat window (from what I know).
  
• Bank C2 deals mainly with the combat system (there you will find your damage calculation).
  
• Bank C3 deals with the field menu and some mysterious ending game routines.
  
• Bank C5 deals with the music.
  

There are other disassemblies such as bank 7E, D4 and EE.

If you want a good resource for opcodes (65816 instructions) here is a good link: http://www14.brinkster.com/assassin17/thegun.htm
Here is also a nice list with the hex values of the opcodes: http://www.defence-force.org/computing/o.../annexe_2/

You can also find online small tutorials about SNES assembly (65816) and even books (one is linked in Resources and Links section). Check also romhacking.net for documentation.

I've got a question.
Where can I get information about tiles?

I don't understand how it works. Well I see that in 1 byte there are 2 pixels (4bpp), but how do tiles create? This is how I guess it works: we've got random palette with 16 colors, 1 byte corresponding to 2 pixels going in the row, 8x8 tiles (32 bytes in each) and each tile may contain 16 different colors max. And when I open ROM in Tile Layer or Tile Molester I can find tiles which containing looks of characters, so how is it happened? If these programs compare bytes with pixels from the beginning of ROM file there would be 1/32 chance that 8x8 tile will display correctly (bytes would be displaced), am I wrong?

OK, second. I thought tile consist of 32 bytes going in the row, and after one tile has been created only then we go to the next...smth like that =) But in The Molester there are buttons "Byte Forward" and "Byte Back" and when I click it I do not understand what's going on...so how is it work?

Thanks in advance

I don't understand how it works. Well I see that in 1 byte there are 2 pixels (4bpp), but how do tiles create? This is how I guess it works: we've got random palette with 16 colors, 1 byte corresponding to 2 pixels going in the row, 8x8 tiles (32 bytes in each) and each tile may contain 16 different colors max. And when I open ROM in Tile Layer or Tile Molester I can find tiles which containing looks of characters, so how is it happened? If these programs compare bytes with pixels from the beginning of ROM file there would be 1/32 chance that 8x8 tile will display correctly (bytes would be displaced), am I wrong?

You got most of it right. If I understand your question, the code will read the tile data from a starting offset that is exactly where the tile is starting. A tile is nothing more than 32 consecutive bytes and the game construct a 8x8 bitmap or graphic with those bytes.

OK, second. I thought tile consist of 32 bytes going in the row, and after one tile has been created only then we go to the next...smth like that =) But in The Molester there are buttons "Byte Forward" and "Byte Back" and when I click it I do not understand what's going on...so how is it work?

Usually graphics strat at a round offset (0x20, 0x40, 0x60, etc..). This is perfect because Graphics viewers like TileMolester scroll down in jumps of 0x20, 0x80 , 0x100 depending which button you press. If you got a tile starting at 0x00005E, the graphic will look disrupted and by click on the byte forward (or backward) you can get exactly on 0x00005E and the graphic will then look normal. These two buttons can be handy sometimes.

Thanks!


But now I've got some other questions))

In Tile Editor max offset is 2FE00 (last row of 16 tiles) but in Hexpose I can obtain 2FFFFF offset, why so?

Can it be, that some tiles may be disrupted even if I see a lot tiles which look normal? By the way, I didn't find graphic that displays text, well I found some letters, but there is no complete alphabet. And I couldn't find dialogue font, is it compressed?

And how exactly stored graphic in that 32 bytes? For example, I changed 1 pixel in a left top corner of certain tile and I got two bytes changed: first 06->86 and 17th 00->80. I tried experiment with it but didn't get how it works...<_<

In Tile Editor max offset is 2FE00 (last row of 16 tiles) but in Hexpose I can obtain 2FFFFF offset, why so?

Normally a tile editor will display the whole ROM, meaning a 2FFFFF offset or 3001FF offset if the SNES ROM has a header. I don't know which editor you are using. I suggest you try YY-CHR.

Can it be, that some tiles may be disrupted even if I see a lot tiles which look normal? By the way, I didn't find graphic that displays text, well I found some letters, but there is no complete alphabet. And I couldn't find dialogue font, is it compressed?

For the first question, read my answer about the ''Byte forward button'' in the previous post. As for the small and big font graphics in FF3us, they are stored here in 2bpp format:

Code:

0481C0    0491BF    FONT    No    "Small Font Graphics Data (8x8x2, 16 bytes each)"
0492C0    04A6BF    FONT    No    "Large Font Graphics Data (16x11x1, 22 bytes each, range 0x20-0x7F)

And how exactly stored graphic in that 32 bytes? For example, I changed 1 pixel in a left top corner of certain tile and I got two bytes changed: first 06->86 and 17th 00->80. I tried experiment with it but didn't get how it works...

here is the detailed 4bpp SNES format: http://smwc.hostzi.com/SMWiki/wiki/SNES_...ormat.html

Thank you very much!

Now I see how SNES 2bpp and 4bpp work.

For the first question, read my answer about the ''Byte forward button'' in the previous post.

I meant if I already have a some tiles, which looking normal (for example, when I open ROM file with Tile Editor character sprites are looking normal), can I be sure that I don't need to push these buttons for the purpose of finding other tiles that look disrupted. Or I have to look through the ROM file 32 times to be 100% sure that I don't miss anything (if 4bpp).

Code:

0481C0    0491BF    FONT    No    "Small Font Graphics Data (8x8x2, 16 bytes each)"
0492C0    04A6BF    FONT    No    "Large Font Graphics Data (16x11x1, 22 bytes each, range 0x20-0x7F)

I found "Small font" in 2bpp format


But didn't get how to see "Large font"...and actually didn't understand what mean decimals in brackets.

And in addition, I can't find dialogue font by Relative Search...

I meant if I already have a some tiles, which looking normal (for example, when I open ROM file with Tile Editor character sprites are looking normal), can I be sure that I don't need to push these buttons for the purpose of finding other tiles that look disrupted.

Data or code would never look like disrupted graphics so if you see a disrupted region it's graphics so you just have to change the offsets by a few bytes to see them clearly.

Data or code would never look like disrupted graphics so if you see a disrupted region it's graphics so you just have to change the offsets by a few bytes to see them clearly.

Hmm...I think I can't write my thoughts correctly or I don't understand something. I'll try this way, you told that graphics usually start at a round offset (0x20, 0x40, 0x60, etc..), so may it happened that one graphic start at round offset 0x000020, for example, and another at 0x000A7D in certain color depth?

And please could you help me, why relative search don't give result when I try to find dialogue text?

so may it happened that one graphic start at round offset 0x000020, for example, and another at 0x000A7D in certain color depth?

Yes and it's exactly why they will look disrupted.

And what do you mean by relative search for text?