[PS1]Ace Combat 3 Electrosphere: text replacement

Started by DragonSpikeXIII, January 31, 2014, 01:51:57 PM

Previous topic - Next topic


Well, it would have been faster to just attach the TIM files :laugh: Anyway, if these are all the variations you've found, I can see the only cases that have text for both CLUTs are the ones with white on black, which reduces the number of special cases I have to take into account.

I'll get to work on this tomorrow. I think I can have it ready for the night, unless something comes up.

As a fun note, if you open a TIM file that doesn't use the second CLUT to display text (like the one with black on teal) in a hex editor, you'll find that the part of the header that contains the palette has some sort of path written on it. That is, what seems to be random colours in the CLUT is actually text. For example, the one in 04.png reads as "1.005\BIN\MSWIN3~1;C:PE" after the four initial white colours. Even part of the first CLUT is used that way. This is one of the reasons why keeping the headers intact is important (because who knows if that's actually used for something...).

I had forgotten I have the BPB files myself too. I took a look at them and it seems the two layer trick is used for the three colour sets, so I updated the Text Editor with the option to use the CLUTs that would be used in the TIMs with two layers. It's just a couple of checkbuttons under the text area, check the leftmost one to have what would be index 1 and then the rightmost to get what would be index 2.


And here's the little program to merge single-layered TIMs into a double-layered one:


That being said, it's not all good news. Apparently I've done something really wrong with the CLUTs in the Text Editor. If you choose the CLUT for the secondary layer in a "white text on black" texture, the background is shown as blue, even though it's not a colour in the CLUT :o If I convert BMPs made with it using TimView+, the CLUTs are okay... for the first 4 colours. The rest are something else (which would explain why I'm getting that blue out of nowhere). This *might* not be as bad as it sounds, since there's still the step of replacing the header, which I haven't tried.

So here's a bit of homework for you:

1) Turns out I don't know how to extract 4-bit BMPs from TIMs, so please get a double-layered one, extract its "layers" and turn them into two separate one-layered TIMs *without* editing them. Now merge them with the Layer Merger and open the resulting TIM. If it looks like what it was originally, the Layer Merger is the best thing ever. If it does funny things, please show me (send me the TIMs you created).

2) Now edit those BMPs with the Text Editor, transform thsoe into TIMs, merge them AND replace the header with the original. Let's see what that does.


That was silly of me not going for the TIMs directly, hehe. And thanks for the software, I'll post my results by tomorrow afternoon.

I wouldn't worry about the color for now because if this proves functional, then we're on the right track.

In reply to note 1) I hope I haven't misread it but the way I do it is use timview+ to view the (extracted) BPB TIMs then click on "extract BMP from TIM"(Operations tab). The resulting BMP will appear in a folder called "for edit". Some TIMs are originally 4-bit ones, but most are 24-bit. Whenever I edit the BMPs, your ac3 editor will make a 4-bit BMP which I then convert to 24-bit with usenti when necessary, then make a TIM (w/ timviewer) from that.

It's the way I've been doing it until now, with positive results just as shown. Hope this is what you meant, hope this helps.

On to note 2) I'll get on that right away. Good thing we do have one double-layered TIM I can  test right now, if we are successful with this one, that will only mean good things when the time comes (hopefully) that I can move on to the testing the BPB TIMs.


Quote from: DragonSpikeXIII on March 10, 2014, 11:47:48 PM...the way I do it is use timview+ to view the (extracted) BPB TIMs then click on "extract BMP from TIM"(Operations tab). The resulting BMP will appear in a folder called "for edit". Some TIMs are originally 4-bit ones, but most are 24-bit.
Ah, that explains why I got these 255 KB files (instead of 33) when I tried to run the first test myself... Then when I tried to convert them with TimViewer, it said that their BPP was not supported. Hopefully the second doesn't pose any problem.

I managed to fix the issue with the CLUTs in the Text Editor, grab the new one here:



I was just about to come here and post my results, they were negative (very corrupt text in-game) but only because the CLUT data was off, the rest of the numbers (headers) were identical, though after merging both layers the colors became garbled.

I'll do it again with the new editor, let's see if it makes the game happy this time around.


Oh, I already tested that and nope, no luck. It's not an OR operation. I already tried with AND, XOR and adding both layers with similar results. In the process I think I spotted a mistake in the way the Header Fixer work, I'll post an update later. I'll have to make some more tests to figure out how to merge those layers, I'm sure it has to be a very simple trick.


Third test just done, mostly successful, you're on the right track.

I won't bother posting a picture this time, the only thing that didn't come out 100% were the final colors but I knew that right from the start as the merged TIM showed very clearly how they would be displayed in-game.

Background was grey, text was black and a little hard to read, not a proper replacement like the previous ones but DEFINITELY a good sign. All numbers are accurate and identical to the original, it's just a color thing.

I gotta say, you're on a roll here Dashman!

EDIT:  I wonder if the color thing is my fault. It always happens during the merging phase. Single TIMs are perfect, then I merge them and they change just like that. weird...


Oh no, it's not your fault. And hell yes, I'm on a roll!

Have a layer merger that actually works:


(I had forgotten all I said about how the indexed colours worked and just tried bitwise operations, stupid me...)

Here's a simple example I created using the text editor and the layer merger:


And the fixed header replacer:


I was ignoring 12 bytes after the CLUTs in the original files before and taking them from the edited ones, not sure if that could break something. Just to be sure, replace the headers of the files you created again with this new version. If you reinserted something, I recommend you do that again with the new versions (or just start again with a clean backup).


Fixing the 12 bytes seems to have been the reason for the text getting ever so slightly corrupt. Now it is perfectly readable just like it should be. Colors still go blargh during merging, don't know why. We're damn close now.

EDIT: no wait, I've checked and the merging is fine, it's the header fixer, that final file produced by the ac3hr is the one that goes awry, not during merging like I said before.


The colours go wrong? I've only tried replacing the header of a tim with black text on white, but the result was as expected. Make sure you're using the lastest version of each tool and that you're naming the files accordingly before replacing headers (maybe it's taking the header from the wrong file, getting the wrong colours?).

I'm guessing the screenshot you're showing was supposed to use a white text on black tim, right? If you don't find the problem, please upload the original, edited and header-replaced TIMs and I'll try to figure out what's wrong.


Double-checked and tried one more time with empty folders while using the header fixer, the end result was the same.

It's supposed to be a white on black image, somehow colors get re-assigned and it becomes black on gray.

Here's the TIMs you asked: http://www.mediafire.com/download/cjtsdeoqo32rohn/ACE3ES2.bin_188_G_4c_TIMS.rar


Argh, I see the problem. If you notice the CLUTs of the original and the edited files, the colours are inverted. That's "correct". The problem is that the TIM I checked as an example for a "white text on black" TIM had a CLUT with colours going from "white" to black ("white", light gray, dark gray, black), so all images of that type generated with the Text Editor will use that CLUT. However, your original TIM's CLUT uses the reversed order (black to white).

To explain it easily, instead of typical RGB data, each pixel in the image data is just a number from 0 to 15, which corresponds to a colour in the CLUT in use. If it's a 0, it says "draw colour 0". When you edited the BMP, colour 0 was "white", but when you recovered the original CLUT, colour 0 was black, hence the weird change of colours.

The solution is simply adding something to the text editor to give you the required CLUT. You'll have it for tomorrow ;)


Quote from: Dashman on March 11, 2014, 10:41:43 PM
The solution is simply adding something to the text editor to give you the required CLUT. You'll have it for tomorrow ;)

Awesome, I knew it wasn't anything to worry about. Looks like the first stage of the text replacement process is done, a lot of ground's been covered these last few weeks.

I've sent esperknight a message here on rh.net regarding the ever-present BPB extract/reinsert issue, here's hoping!


And here it is:


Now you can invert the colours of the palettes when using layers, you'll have to keep an eye open for the CLUT of the original TIM from now on, to make sure you're using the one that matches it best. I made this in a 15 minute break and haven't tested it, so please tell me if it works as it should.


I'll just leave this here...

Both layers tested successfully



I hope reinsertion doesn't pose too many challenges. Best of luck for the rest of this! :thumbsup:


Quote from: Dashman on March 12, 2014, 03:59:30 PM
I hope reinsertion doesn't pose too many challenges. Best of luck for the rest of this! :thumbsup:

I can't thank you enough, seriously. A lot of troubleshooting, program writing and fine-tuning had to be done this past month but not once did you come up short, even the crucial 2-layer part got owned pretty quickly!

Bottom line: You're awesome!

I also wanted to let you know that the project's been receiving a lot of positive feedback from those that have been following the project all these years and from the Ace Combat community. I've been in talks with the administrator of electrosphere.info, they're gonna write a series of articles on our project and there's even talk of interviewing our team members later on!

I know my decompressor still seemed to miss a few so I'm sure we'd have to track it down but at least 99% of it's known with what I did so a recompressor shouldn't be too hard (I say this now...).

esperknight, if you're reading, know that I could use your help now, let me know if such a recompressor program is feasible or not, if you're still available that is.

Of course, I have no objections if anyone else reading this would like to try, feel free post below as any input is wholeheartedly appreciated.

EDIT: info on compression: http://giphtbase.org/gipphe/ac3j/journal.php


Hey!  My apologies for the late reply but DragonSpikeXIII pmed me and reminded me about AC3.  I took a look again at it and figured out a very nice way of repacking it that made it quite easy and so here we are : Ace Combat 3 Toolkit.

The only thing missing from the toolkit is the cd image itself which must be in bin format and also renamed to ac3.bin and placed in the cd/orig folder.  Other then that it's ready to go.  Build is where the files are kept to rebuild the AC3.BPB file and are the ones that need to be changed for insertion.  Orig is the originals in case there needed.

I haven't worked on the compression piece just yet since it's a custom variation of LZSS and I need to think on how they're generating some of the needed values (and if I can do it generically).  I'm hoping that one could just replace the ULZ files with the decompressed TIMs and it should work... but not quite sure yet (I can test this later I realize by simply replacing them all ;)  So if anyone wants to build a compressor before I get to it I wouldn't mind ;)  The code I wrote to decompress it (I can't recall if I posted it....) is here : AC3 ULZ Decomp

Also for replacing the files, they just need to be in the same order.  Extension doesn't matter at all.  So essentially you could replace 000.ulz with 000.tim and it'll be all good :)

Here's the code for the repacker if anyone cares : AC3 Repack

Enjoy :)


Simply amazing :thumbsup:

I'll have to take a look at your code when I get some time, I've been wanting to learn a thing or two about compression for a long while now.


That's it, the floodgates are OPEN!

Almost perfect replacement, text got a little uglier after merging, which isn't supposed to happen. I'm gonna go try again and see what was the cause of that.


Problem fixed (had to do with the 'layered texture' check box), text looks better now, probably as good as it possibly can.  Tested using XEBRA, as always, so jaggies will be present. I'll try with ePSXe and super-duper settings to see how it looks some other time.

Bob Liu

Awesome to see your making good progress, can't wait to see more.