A forum for the translation project of Ys vs Sora no Kiseki.
flamethrower
Programmer
Posts: 995
Joined: Mon Mar 09, 2015 3:03 pm

Preta requested me to add one track that isn't used in game (but is present in the rom) so let's start with that.
By the way, the unused track is USRDIR\bgm\vs_f0200.at3 , which is a different version of the "Childlike Eyes" track.

Okay, now we need to get it in-game, in the material collection section.
Data for that is stored in USRDIR\text\matec.csv, here is what it looks like:

So not too hard. But to add more music, we need to understand:
Where the BGM_FIELD_101 -like names are coming from.
How the game understands what those names mean.

I first looked at USRDIR\text\bgmtbl.tbl and USRDIR\text\bgmtbl.tbl .
bgmtbl.tbl is human readable, it looks a little bit like source code. I needed to rule it out, so I deleted the file and rebuilt the game and it functions normally which means this file isn't used. The content could still be interesting, though:

So it also has those weird music IDs. It also has file names and data needed for looping a track which isn't important for our purposes. LOOP is a flag that specifies looping or not.

Next I looked at USRDIR\text\bgmtbl.tbb .
Based on my experience with other Falcom games, and this game, this file should have the contents of bgmtbl.tbl in machine-readable format. And always compressed. This is a solved problem already, but let's take a look anyway:

The first four bytes are a little endian 32-bit integer. It specifies how many tracks there are (a whopping 183 of them, that's 0xB7 converted to decimal). The next part is the FALCOM3 header. It goes compressed size, uncompressed size and number of chunks (all 32-bit integers). After that is the start of the first chunk. Based on compressed size and file size there is only one FALCOM3 stream in this file (some file types have more than one).

So I decompressed it. You can get the tool I use to do this in the PSP section.

So we have 24-byte entries. Actually 184 of them, there is a dummy entry at the end of the file.
0x0: Loop start
0x4: filename
0x10: ID number (more on this later)
0x12: Loop flag
0x14: Loop end

That gets that out of the way. But we still haven't solved it.

After messing around a lot with the debugger I determined the game is loading and using USRDIR\inc\music.h which I did not expect because I've never seen that before.

Code: Select all

//;曲番号定義

//	BGM_MAX		160				// 現在プログラムで定義している数

enum{
BGM_Nothing	=	0,		// 無音

// テスト用らしい
BGM_FIELD_200,

// システム系

BGM_WIN,			// 	■戦闘勝利（全モード共通）
BGM_LOSE,			// 	■戦闘敗北・引き分け（全モード共通）
From watching the game run, I saw that it is assigning a number to each track. It also assigns a number, zero, to BGM_Nothing, which is not actually a track. And then in order, ending on 184.

So putting the solution together (haven't tried it yet) it goes like:
1) Add to music.h a new music file ID. We can call it whatever we want, so we'll call them BGM_ADD_001, etc... We have to be sure to be 11 characters or less on this ID.
2) Add to bgmtbl.tbb data on our new music file.
As for data, all we really need is the file name, and the track's number. We can actually number it just whatever, but we'll just number it 185. And then we need to disable looping, which just means putting zeros for loop start, loop end, and loop flag.
3) Add to matec.csv data on our new music file.
We need the music ID from (1) and the track and album names that display when we play in in-game.

### Who is online

Users browsing this forum: No registered users and 0 guests