Post #1 · Posted at 2015-04-22 05:43:52pm 8.9 years ago
CLARIFICATION: This is in the graphics subforum, and not the programming subforum since while my use of the information is for programming, the question I had was graphics ripping related. 
So on the Aaron in Japan forums a while back, a user there named Catastrophe posted this tidbit of information on some graphics in the game - I believe the labels that appear on the songwheel itself.
Grab Extreme CS, get the FILEADATA.BIN file
- Skip the first 860958176 bytes (or jump to offset 0x33512DE0h)
- Read 111 TCB files of length (80+(96*32)+80) each and save them to disk
Now, if you have "000.tcb" - "110.tcb" write a TCB Viewer that does the following:
- Open a TCB file
- Ignore the 80 byte header. But if you like error checking the first three bytes should be "TCB"
- Load the next 3072 bytes into a 96x32 matrix
- Ignore the 80 byte footer
- Loop through the matrix:
-- For each x
--- For each y
---- Draw a pixel at (x, y) in the 24bit color (matrix[x][y] * 255)
If 000.tcb looks like A and 110.tcb looks like Max. (Period) then you win. wink.gif
Now someone with a CD-rip of the game or someone with a DVD burner who also has alot of time on their hands could also change these images too if they wanted to.
P.S. The offset for the MAX2US demo disk is 0x86f6980h and all 68 labels from the full game are right there! laugh.gif
I've noticed that the number of files with the TCB header in the game's filedata.bin is greater than the number of songwheel labels, leading me to believe this is the format used for more than just songwheel label graphics in the MAX-EXTREME/EXTREME 2 era games - perhaps being used for everything from menu graphics, to arrows gfx, to timing judgement graphics ("Perfect", "Great", "Good", etc), combo numbers, etc).
I've been using that info to write a program that will search for images in that format within whatever you throw at it - ISO, filedata.bin, or anything else you want to try - and display info about it (offset, size, width, height, etc). Eventually, once I get that working, I plan on adding support for previewing the extracted grahics, as well as the ability to export, and re-import them... custom gfx in DDRMAX-EXTREME era games, anyone?
My problem, however, is I've been looking in the header for file dimension information/data (height, width) - and I can't find it anywhere in the header.. has anyone else examined this data, and found something I am missing? I mean, that info has to be there, but I am lost in finding it. I used the dimension information posted in the quoted post's pseudocode as what to look for (in hexadecimal, obviously), searching in an area I know to be image data based on the quoted post's information, but so far all I'm batting on is getting a headache. >_<
I REALLY, REALLY, wanna get this working because of the MANY implications it could have - for Stepmania theming (easier extracting of graphics), for game modding (DDRMAX2 JP with ITG1/2 arrow graphics, anyone), etc.
TO CLARIFY: I tried using what I had previously thought were the offsets for the widths / heights in my algorithm for searching for the data, but it didn't give me correct results, which had me frantically searching again.
Never mind, I feel like a fucking idiot. It seems that the problem was not with my choice of which bytes I thought were the height and width values - that was actually, it seems, perfectly fine.... the problem was my algorithm - a byproduct of me being in a rush to get my ideas on paper before I get distracted by other things while being sleep deprived (and by that I mean REALLY, REALLY sleep deprived, like "I shouldn't drive anywhere, I'm so tired" sleep deprived). I tried it copying from the offset in filedata.bin to 9696 bytes (3 images), copying them into a new file, saving it, then running it through my program, which correctly found 3 images.
Now I gotta figure the best approach for traversing larger files (entire filedata.bin files, or entire ISO images) without causing a stack overflow... perhaps, since my problem occurs when I attempt to scan the loaded data (and not when I load the data into the array), splitting the array into subarrays, and scanning each one. But that's another story,...
So on the Aaron in Japan forums a while back, a user there named Catastrophe posted this tidbit of information on some graphics in the game - I believe the labels that appear on the songwheel itself.
Quote: "Catastrophe on the AIJ forums"
Grab Extreme CS, get the FILEADATA.BIN file
- Skip the first 860958176 bytes (or jump to offset 0x33512DE0h)
- Read 111 TCB files of length (80+(96*32)+80) each and save them to disk
Now, if you have "000.tcb" - "110.tcb" write a TCB Viewer that does the following:
- Open a TCB file
- Ignore the 80 byte header. But if you like error checking the first three bytes should be "TCB"
- Load the next 3072 bytes into a 96x32 matrix
- Ignore the 80 byte footer
- Loop through the matrix:
-- For each x
--- For each y
---- Draw a pixel at (x, y) in the 24bit color (matrix[x][y] * 255)
If 000.tcb looks like A and 110.tcb looks like Max. (Period) then you win. wink.gif
Now someone with a CD-rip of the game or someone with a DVD burner who also has alot of time on their hands could also change these images too if they wanted to.
P.S. The offset for the MAX2US demo disk is 0x86f6980h and all 68 labels from the full game are right there! laugh.gif
I've noticed that the number of files with the TCB header in the game's filedata.bin is greater than the number of songwheel labels, leading me to believe this is the format used for more than just songwheel label graphics in the MAX-EXTREME/EXTREME 2 era games - perhaps being used for everything from menu graphics, to arrows gfx, to timing judgement graphics ("Perfect", "Great", "Good", etc), combo numbers, etc).
I've been using that info to write a program that will search for images in that format within whatever you throw at it - ISO, filedata.bin, or anything else you want to try - and display info about it (offset, size, width, height, etc). Eventually, once I get that working, I plan on adding support for previewing the extracted grahics, as well as the ability to export, and re-import them... custom gfx in DDRMAX-EXTREME era games, anyone?
My problem, however, is I've been looking in the header for file dimension information/data (height, width) - and I can't find it anywhere in the header.. has anyone else examined this data, and found something I am missing? I mean, that info has to be there, but I am lost in finding it. I used the dimension information posted in the quoted post's pseudocode as what to look for (in hexadecimal, obviously), searching in an area I know to be image data based on the quoted post's information, but so far all I'm batting on is getting a headache. >_<
I REALLY, REALLY, wanna get this working because of the MANY implications it could have - for Stepmania theming (easier extracting of graphics), for game modding (DDRMAX2 JP with ITG1/2 arrow graphics, anyone), etc.
TO CLARIFY: I tried using what I had previously thought were the offsets for the widths / heights in my algorithm for searching for the data, but it didn't give me correct results, which had me frantically searching again.
Never mind, I feel like a fucking idiot. It seems that the problem was not with my choice of which bytes I thought were the height and width values - that was actually, it seems, perfectly fine.... the problem was my algorithm - a byproduct of me being in a rush to get my ideas on paper before I get distracted by other things while being sleep deprived (and by that I mean REALLY, REALLY sleep deprived, like "I shouldn't drive anywhere, I'm so tired" sleep deprived). I tried it copying from the offset in filedata.bin to 9696 bytes (3 images), copying them into a new file, saving it, then running it through my program, which correctly found 3 images.
Now I gotta figure the best approach for traversing larger files (entire filedata.bin files, or entire ISO images) without causing a stack overflow... perhaps, since my problem occurs when I attempt to scan the loaded data (and not when I load the data into the array), splitting the array into subarrays, and scanning each one. But that's another story,...