News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Constructing a TIM/TIM2/GIM file header  (Read 9625 times)

jjjewel

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
Re: Constructing a TIM/TIM2/GIM file header
« Reply #20 on: May 28, 2014, 10:22:20 am »
The "problem" was the 32x8.
32x8 is decimal 32x8 not hexadecimal if that's the problem you meant. ^_^

So pragmatically:
What made you change the width and height from there?
Did you just try all multiples of 4 for both width and height?
How did you decide what to try next from one attempt to the next?
The answer might be simpler than you expected. Because 8, 16, 32, 64, 128, 256, 512 are common graphic widths in DS so I just had a habit of checking these widths first. And PSP usually uses 4 bpp for font (at least for most games I have) so it was just the matter of finding the right width.)

BlackDog61

  • Hero Member
  • *****
  • Posts: 784
    • View Profile
    • Super Robot Wars A Portable translation thread
Re: Constructing a TIM/TIM2/GIM file header
« Reply #21 on: May 28, 2014, 02:16:44 pm »
The answer might be simpler than you expected. Because 8, 16, 32, 64, 128, 256, 512 are common graphic widths in DS so I just had a habit of checking these widths first. And PSP usually uses 4 bpp for font (at least for most games I have) so it was just the matter of finding the right width.)
Thanks!

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3502
    • View Profile
    • Aeon Genesis
Re: Constructing a TIM/TIM2/GIM file header
« Reply #22 on: May 28, 2014, 02:18:28 pm »
32x8 is decimal 32x8 not hexadecimal if that's the problem you meant. ^_^

Coming from an SNES perspective, things are usually either 8x8, 8x16, or 16x16. Having a 32x8 tile - something so wide, but not very tall - seems quite strange to me.

KC

  • Full Member
  • ***
  • Posts: 209
    • View Profile
Re: Constructing a TIM/TIM2/GIM file header
« Reply #23 on: May 28, 2014, 02:21:32 pm »
The width of tiles depends on the bit depth. 4bpp is 32x8, 8bpp is 16x8, 16bpp is 8x8. 32bpp is 4x8. As you can see, width*height*bitdepth is always constant.

jjjewel

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
Re: Constructing a TIM/TIM2/GIM file header
« Reply #24 on: May 28, 2014, 08:08:50 pm »
The width of tiles depends on the bit depth. 4bpp is 32x8, 8bpp is 16x8, 16bpp is 8x8. 32bpp is 4x8. As you can see, width*height*bitdepth is always constant.
Thanks for the info. This is new knowledge to me. :)

Coming from an SNES perspective, things are usually either 8x8, 8x16, or 16x16. Having a 32x8 tile - something so wide, but not very tall - seems quite strange to me.
Ah, I see.
By the way, did you check if the game has a list of those kanji's somewhere? From how they are arranged in the font, it's pretty obvious that this game uses non-standard table. (If you're lucky, these kanji's might be listed, like in a separate file or in Eboot.bin, so you don't have to identify them one by one.)

Gideon Zhi

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 3502
    • View Profile
    • Aeon Genesis
Re: Constructing a TIM/TIM2/GIM file header
« Reply #25 on: May 28, 2014, 09:05:19 pm »
By the way, did you check if the game has a list of those kanji's somewhere? From how they are arranged in the font, it's pretty obvious that this game uses non-standard table. (If you're lucky, these kanji's might be listed, like in a separate file or in Eboot.bin, so you don't have to identify them one by one.)

I honestly haven't had much time to poke at it. Text was easy enough to locate even with the nonstandard table though.

Dashman

  • Full Member
  • ***
  • Posts: 210
    • View Profile
Re: Constructing a TIM/TIM2/GIM file header
« Reply #26 on: June 04, 2014, 09:56:10 am »
I think I may as well use this topic to ask a couple of questions.

I've got to the point in which I can change the game's text in SRW GC and now implementing a VWF is in order. So far I've located the font in memory at address 0081baa0. The font is divided in 22 font files, one of them having a smaller set of characters (10x15). Each character seems to be stored in a 18x18 tile with two bytes at the beginning indicating the SJIS hex code of the character and effectively messing up how the font is displayed in CT2 (notice the 4 weird pixels in pretty much every tile except the one for ):



Here's the font block in memory: https://dl.dropboxusercontent.com/u/144016034/font.bin

So, I *think* the next step is finding an instruction in the ASM that points at the offset of either the font block or one of the tiles to locate the printing routine (this is the first time I try VWF). However, Dolphin's debugger ASM interface seems rather unhelpful: there's no search function and I can't even scroll up or down the code. I tried looking at the ASM in the memory dump using CT2, but the instruction set is different and there's a lot of unrecognized data.

How could I find the instruction I'm looking for? And when I find it in memory, how could I locate that same instruction in the ISO?

jjjewel

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
Re: Constructing a TIM/TIM2/GIM file header
« Reply #27 on: June 04, 2014, 10:32:54 pm »
@Dashman
If it's VWF or ASM hacking, it's beyond my knowledge, but have you tried changing the script and type something in it? (I'm assuming you're translating it to English. Did you try to type something in English and test how it output?)

Looking from the font, it has one with ASCII range. (@Offset 0x93334. You can set CT2's width x height to 10x18 GBA 4bpp and set byte jump to 2 to view it.) If the game doesn't accept ASCII (Ex. 0x20, 0x21, 0x22, etc.), then you can try 0x0020, 0x0021, 0x0022 instead. It might work. (Or maybe 0x2000, 0x2100, 0x2200. I'm not sure how the text is encoded.)

Dashman

  • Full Member
  • ***
  • Posts: 210
    • View Profile
Re: Constructing a TIM/TIM2/GIM file header
« Reply #28 on: June 05, 2014, 05:59:26 am »
Yes, the game does accept ASCII, although it looks like a smaller version of the SJIS font. For some reason it seems to need an even number of characters to display properly.



I actually extracted the ASCII font file from the main chunk before to try and see it properly and had come up with the 10x18 size already, but I had no idea about the byte jump thing, thanks! Now I can see all font files properly! :)

I still need to figure out how to locate the memory access in the ASM, though :P If anybody has a suggestion, it will be more than welcome!