Tengai Makyou Zero translation project

[Tom]

I only showed the good pictures. Like I said to Gideon, there's a ton of hacking left to do. Don't let those pictures fool you. Here are some messier ones.





Even these pictures may not convey how much needs to be done.

Whoever takes up this project might as well think of this as starting a brand new project, dialogue aside. It's not just a matter of restructuring the menus. There are fundamental changes that need to be made to be able to change the date for the real-time clock, and how strategy names are displayed, along with a ton of graphical changes.

P.S. By the way, my seems the translation for the calendar entry appears to be slightly off. "Worldwide AIDS Day" should just be "World AIDS Day." That's the official English name. I just changed it in the script now.

[ddstranslation]

.

[Tom]

Thanks for showing your work, ddstranslation!

Lost Templar is very busy with real life at the moment, and he also has another project that he wanted to do in addition to that. He seems to have too much on his plate (much like Gideon Zhi)!

I'm sure Lost Templar WANTS to do it. Just like byuu and Gideon.

But the old thread that some guy from youtube posted before made me think... If I keep waiting on the people who brought the project to where it is now, someone else is bound to just write it off as a lost cause and translate it themselves.

So I changed my mind and opened it up to others.

ddstranslation, if you're not sure about the game, why not give it a look? You'll be able to see the date-entry right at the start. Notice that you're not able to enter the current date... (I think the cut-off is 2014...) The game is able to display the date past that... But it won't let you enter a date beyond that.

Do some digging. If you think you can get around that, let me know.

In the meantime, I'll keep the offer open to other hackers, just in case any of them also want to throw in their hat for an attempt at the hacking. I figure if we assemble a lot of people who are interested in hacking the game here, we can all work out together who'll take up the reigns officially. I want this to be settled publicly. I don't want it just to be my own decision.

I've heard some good things about Nightcrawler, Bongo, and Magno. I don't know much about any of them, but they may not know about this thread yet. I'll give them (and any others) a while longer to post here before we all settle on a hacker.

[ddstranslation]

.

[Tom]

Wow, that didn't take you long to figure out. I'm impressed. You just might be the one for the job! It doesn't seem like anyone else is interested, in any case... To anyone else reading this thread: What's your opinion? And to anyone else who wanted to hack it: do you want to make an offer, or will you give ddstranslations your blessing?

Considering the small number of people watching this thread, I guess it's safe to say that if nobody speaks up by the time the weekend's over, it'd be a good idea to let ddstranslations have a go at it.

By the way, I can confirm that the game recognizes the date past 2014. It just doesn't let you initialize the clock past 2014... My current save shows the proper date, December 2, 2016... So I'm pretty sure it would work properly with this hack, too. That's good news.

If you can make progress that quickly, this project may not take very long at all. How confident are you about graphics editing?

Look at this image here:


There are plenty of little signs and things like this that need to be redone in English. Do you know someone who's good with that sort of thing?

[FlashPV]

If you're able to extract the graphics I'll be glad to help.

[Tom]

Can you show some examples of your work, FlashPV?

[DougRPG]

I think the challenge with the RTC is adjusting all the events. Bypass the 2014 limit is like 1% of the trouble, assuming that the RTC chip accepts date past 2014 (probably yes).
They put a 2014 limit for some reason, so problably there are no triggers for events after 2014.
And for what I read this game has several events, so find out all the the events, dates and triggers should be a lot of work.

Tom, do you have the list of events and the dates? Ddstranslation will need this information.

But if the events are triggered by the week day, or someway independent of the year number, then this modification made by ddstranslation should be enough. Let's hope so.

The problem with the graphics decompression is that it uses the SPC7110, so there is no "decompression routine" to debug. You need to extract using the SPC7110 algorithm. Probably there are decompressors, but the problem is recompressing. And you'll need to expand the rom.
This should work only on Bsnes for now, where you can create a custom manifest. And to debug probably using the Bsnes Plus or Bsnes v086 (Laevatein).
Tom, did LostTemplar already expand the Rom? What emulator do you use to play this translation?

[Tom]

2014 is only the oldest date that you can enter as an initializing point. It doesn't mean that the game stops tracking at 2014. It just means that you can't initialize the date later than that.

Events still trigger perfectly fine after 2014, as far as I can tell. There are no "events" that rely on the year...

-There are 11 big monthly events at the shrines. (There are no big events in November.) These events can only be triggered after saving the divine beasts, though.
-There are also "minor" events at the shrines, on weekends, I think.
-Some shops are only open on certain days.
-Some events only occur at certain times of day.
-There's also one instance in which a character tells you to come back in an hour, and it triggers a flag to lock that event from happening until an actual hour later.

So you have events relating to date, month, day, hour, and time spent since flag triggered.

(The only thing I'm not sure about is how the game might handle a leap-year birthday.) But all in-game events still work past 2014. Of that much, I can assure you.

I don't think the rom is expanded... Byuu was talking about that, I think. He said that needed to be done.

Here's what byuu said to me in an e-mail...

There's a lot of special considerations on this game that make it harder than most, too:
* the special memory mapper
* adapting the RTC system since you can't even set the current date in-game anymore ( I know, I took way too long ;_; )
* the special coprocessor compression algorithm that will need to be decompressed/recompressed or bypassed
* expanding the game will be a special case (I'll help explain how to do this to whoever you choose; and I'll coordinate with Snes9X to get it supported there too)

And yes, it can only be played in bsnes. It also needs some xml file that Lost Templar gave me (which I believe is related to the font?) with the same name as the rom file added to the folder.

[FlashPV]

In fact I've done mostly some title screen graphics.
You can see most of my work on my profile.
http://www.romhacking.net/community/1637/

[Tom]

Looks good to me! 

Thanks for the offer, and welcome to the team!

Once the graphics are dumped, I'll provide you with a translation for each bit, and you can work your magic.

Be warned, there's more than just a title screen! (But I think you can handle it.)

[FlashPV]

No problem PM me when you are ready.

[DougRPG]

And yes, it can only be played in bsnes. It also needs some xml file that Lost Templar gave me (which I believe is related to the font?) with the same name as the rom file added to the folder.

The original game has 5MB. What's the size of your translated game? If LostTemplar gave you a manifest (this Xml) than probably it's already expanded. If the Rom size is 6MB or more than it's already expanded. (The Manifest is a file with the memory mapper for a particular game. You need to manually create this manifest in more complex cases because the emulator heuristics can't predict the memory map).
Byuu changed the manifest format a few times, so if you have a .xml manifest than probably you are using v092 or below, right? I think after v094 it changed to .bml.
Anyway, if the game is already expanded than it's less work, and the game should have space for new graphics and other stuff.

[Hiei-]

Nice to see the heavily hard to modify rtc as been easily hacked 

(From what he said, events still work fine after 2014, it's probably just the programmers never thought some people would still play the game post 2014 so probably limited the year entry screen just because of that).

Looks good to me! 

Thanks for the offer, and welcome to the team!

Once the graphics are dumped, I'll provide you with a translation for each bit, and you can work your magic.

Be warned, there's more than just a title screen! (But I think you can handle it.)

-Tom

FlashPV is da man when it come to graphic edits 

The problem with the graphics decompression is that it uses the SPC7110, so there is no "decompression routine" to debug. You need to extract using the SPC7110 algorithm. Probably there are decompressors, but the problem is recompressing. And you'll need to expand the rom.

Would just require to store the graphics uncompressed and see if the game can handle them uncompressed (modifying the reading/loading graphics routine)

And without decompressors, wouldn't it be possible to get the graphics uncompressed directly from the VRAM? (as it should decompress it before displaying it in-game).

[Tom]

The original game has 5MB. What's the size of your translated game? If LostTemplar gave you a manifest (this Xml) than probably it's already expanded. If the Rom size is 6MB or more than it's already expanded. (The Manifest is a file with the memory mapper for a particular game. You need to manually create this manifest in more complex cases because the emulator heuristics can't predict the memory map).
Byuu changed the manifest format a few times, so if you have a .xml manifest than probably you are using v092 or below, right? I think after v094 it changed to .bml.
Anyway, if the game is already expanded than it's less work, and the game should have space for new graphics and other stuff.

6,144KB for the translated rom... So it's already expanded. I'm using v087-32 bit bsnes to run it. In addition to that, the RTC workaround seems to be all but settled, thanks to ddstranslations.

That leaves only two challenges left in byuu's list, if I'm not mistaken:

* the special memory mapper
* the special coprocessor compression algorithm that will need to be decompressed/recompressed or bypassed
December 02, 2016, 10:09:35 AM - (Auto Merged - Double Posts are not allowed before 7 days.)

Nice to see the heavily hard to modify rtc as been easily hacked 

(From what he said, events still work fine after 2014, it's probably just the programmers never thought some people would still play the game post 2014 so probably limited the year entry screen just because of that).

Yes, this was long before emulation was in effect. They must have figured that everybody would have initialized the cart times by then, since you only have to do it once, when the game first gets set up. 2014 is actually surprisingly generous, if you think about it that way.

FlashPV is da man when it come to graphic edits

You can say that again!

And without decompressors, wouldn't it be possible to get the graphics uncompressed directly from the VRAM? (as it should decompress it before displaying it in-game).

Who knows? But that would require you to see the graphics in-game, right? There are some graphics that are very hard to come across...

[DougRPG]

* the special memory mapper
* the special coprocessor compression algorithm that will need to be decompressed/recompressed or bypassed

The memory mapper is this .xml Lost Templar created. It expand the rom, so it's already done. Now the rom has the free space needed by the translation and it's already working in the emulator.

Besides the compression/recompression for the graphics you need all the menus done, and it's a lot of work. Byuu's goal was to put a vwf font in the menus, and it's a lot of work.
So you have these 2 main goals.

Tom, and what about the items translation, enemies, etc? They are already translated?

Would just require to store the graphics uncompressed and see if the game can handle them uncompressed (modifying the reading/loading graphics routine)

The problem with that should be timing. I think SPC7110 can decompress very quickly, so do it using the Cpu may not work, but who knows.
A better approach is to study the SPC7110 and see if it has more than one mode. Maybe there is a dummy mode where the recompression is very simple (with no or little compression).

And without decompressors, wouldn't it be possible to get the graphics uncompressed directly from the VRAM? (as it should decompress it before displaying it in-game).

Yes, but the problem is the recompression, because this SPC7110 seems to be a little complex.

[Tom]

Besides the compression/recompression for the graphics you need all the menus done, and it's a lot of work. Byuu's goal was to put a vwf font in the menus, and it's a lot of work.
So you have these 2 main goals.

Crazy! That's great!

I saw this Youtube video a while back... About 22 seconds in, it shows a menu screen hacked with a VWF. The translation isn't that good. (A dollar sign? Really?) But the small vwf font looks very clean. Almost too clean. Not sure who did it:
https://www.youtube.com/watch?v=FDqLyccgrto

Tom, and what about the items translation, enemies, etc? They are already translated?

Everything is translated, but Lost Templar made some "exceptions" for them in the patcher, so that they are not inserted and the menus remain in Japanese, for the most part. He did this so I could still play through the game and check the script, instead of having everything in the menu being an unplayable mess.

The system check stuff that happens at the initial bootup is neither dumped nor inserted, but I've recreated all of that text (a small amount) in a separate text file and translated it ahead of time. I think the only things I haven't translated and documented are some of the graphics, like signs above inns and weapon shops, but we'll cross that tiny bridge when we come to it.

Enemy names and skill names are displayed with the standard font, so they're display well enough, mostly... Longer names sometimes become invisible, or leave parts on the screen even after they're supposed to have disappeared... But that's for a hacker to clean up, not me.

Yes, but the problem is the recompression, because this SPC7110 seems to be a little complex.

That's kinda scary...

[DougRPG]

I saw this Youtube video a while back...

The video is clearly fake. The guy is referring to your translation at the time LostTemplar begun to work on the game some years ago. He says while the game is not finished people can play the Arabian Night patch. After that he shows a "sample" of a menu supposedly made by the feoez team. Just ignore.

[Tom]

The video is clearly fake. The guy is referring to your translation at the time LostTemplar begun to work on the game some years ago. He says while the game is not finished people can play the Arabian Night patch. After that he shows a "sample" of a menu supposedly made by the feoez team. Just ignore.

I thought it was fake. That font looked way too clean to be running on the SNES. It must be a mockup that somebody made.
December 04, 2016, 01:38:22 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
Well, I guess enough time has passed. I guess most hackers were too busy.

I've sent things over to ddstranslation.

[DougRPG]

Hi Tom, today I tried to change some graphics and I was able to do some stuff:



To this particular example I used Hiei- advice of using the decompressed graphics from Vram. So I got the graphic and edited it using photoshop (you can see some artifacts in the logo. I' m not a graphics editor and I did this edtion very fast).
The problem was the reinsertion, because the SPC7110 has 3 algorithms, and they are a little complex to understand and to create a compressor in a short time, at least for me.

So I studied the SPC7110 and tried some approachs.

1-) After some study I found that the SPC7110 put the decompressed data in $50:0000. So the game asks the chip to decompress the graphics and after the decompression is done it reads from $50:0000 and, after some work, send to Vram (more of that later).
So my first approach was, after the chip decompression (we can know when the data is ready), to overwrite the decompressed data in $50:0000 with my new translated graphics. This way the game should work as usual but showing the new graphics, and the solution would be very simple.
But seems that writing to $50:0000 is not allowed, at least in Bsnes. I tried to change Bsnes code to allow this write but it is cheating, so I gave up this idea. But I don't know if the real chip doesn't allow this writing to $50:0000, or if it was a Byuu's decision, assuming that it's not the supposed way to work.
So this approach didn't work.

2-) My next approach was find some register inside SPC7110 that allowed a "uncompressed mode". After some read I found that $480b could do the job, at least according to no$cash and neviksti:

480Bh - Decompression Mode
Reportedly:
  00 - manual decompression, $4800 is used to read directly from the data rom

  02 - hardware decompression, decompressed data is mapped to $50:0000,
       $4800 can be used to read sequentially from bank $50

Seems that Feoez only uses $02 to $480b, so I tried to use this $00 mode, but Bsnes v086 doesn' t implement this behaviour. I searched in the last Higan version and seems that $480b is used in some places, but for what I understood it's not related to this "uncompressed mode" we was looking for. Again, I don' t know if it's still an unsuported feature that could work on the real chip.

3-) My last approach was to change the code that send the decompressed data to Vram and change it to send my translated graphics. After some debugging I saw that the game uses some kind of DMA queue, and in some moment it sends the data to Vram in blocks of 0x20 bytes.
So first I changed the routine that send the decompression command to SPC7110. In the beggining of this function we have some kind of pointer to the compressed graphics, and this pointer the game sends to the chip. So if the pointer is the intro logo pointer I set a flag in some Ram position (I had to find some unused Ram space, but it's just for now). With this flag enabled I changed the DMA queue routine to send my data, instead of the SPC7110 decompressed data, to Vram, based on this flag.
This way I could take this picture with the graphics inserted.

This worked, but I faced a lot of problems.

a-) I had to find a unused Ram space, specifically 3 bytes. The region I used ($7ffff0) was unused in the part I tested, but who knows if later in the game this region is used. I tried to use Sram, but the Sram usage is weird because you have to set a register to map the Sram, and seems that this change broke the memory map when I tried to use.

b-) The tile order of the decompressed graphics isn' t in the same order when it is sent to Vram. So I had to reorder the tiles in the image to show it properly.

c-) My last solution doesn' t have a big impact in timing because I'm only changing the Dma address by a new address, so the only impact is my new code. But I don' t know if "not using the uncompressed data" could do some harm in some situations, because inside SPC7110 there are some counters that are decremented when you read the data through $4800. But seems to work as far I can tell.

d-)The SPC7110 has 3 compression modes, and seems that the game follows different paths based on the mode. So I only changed the mode used by this intro logo.

And that is it Tom. I hope you enjoyed. But don't think I can work in this game. My romhacking skills are only intermediary. I'm not an experienced romhaker like LostTemplar and Ddtranslation, even less a guru like Byuu and Nightcrawler. And I'm working in other projects right now. I did this little debugging only for fun and as a proof of concept showing that we can change the graphics in this game. The idea is encourage other people to work on this game.

PS: I can share my code and feel free to ask any details if you (or you team) need.