|
Post by TrekkiesUnite118 on Apr 5, 2019 2:27:35 GMT
Ah ok, that explains it. Any suggestions on common patch formats that could work for that? I have no idea, patching CD games has always been problematic. Ripping the ISO track only works, but then you specifically need a multi-track format CD image... and if the game in question uses multiple DATA tracks, then you may have more issues - specifically, if your first data track gets larger after patching, because the sector links to the 2nd data track will be pushed out of alignment. I'm not sure if Grandia itself uses multiple data tracks, but many late Saturn games do. Luckily Grandia seems to only have 1 Data Track on both discs. So using the method of ripping the ISO Data Track out of the image should work.
|
|
|
Post by TrekkiesUnite118 on Apr 5, 2019 1:29:14 GMT
|
|
|
Post by TrekkiesUnite118 on Apr 5, 2019 0:33:25 GMT
Those hashes are irrelevant because audio offsets will make the data different on every different CD drive used to rip the disc. You can't really get around that unless you rip the data track separately, or use something that uses audio offset correction (very few things do). With that in mind, you should set up your patcher so it only affects the data track area, not the audio. Things get wilder if you need the data part padded out, though. Ah ok, that explains it. Any suggestions on common patch formats that could work for that?
|
|
|
Post by TrekkiesUnite118 on Apr 5, 2019 0:07:45 GMT
|
|
|
Post by TrekkiesUnite118 on Apr 4, 2019 13:17:26 GMT
Well done Trekkies, we are certainly getting closer to playing Grandia on the Saturn in English. Thanks for the hard work I wonder if someone could use something like a Rhea/Pheobe to play the patched ISO on real hardware, could certainly be interesting They probably could, as burning it to a Disc does work on real hardware. It's just that there's still the possibility that an incorrect control code is still in the script in parts from the PS1 version which could cause a crash. Which if that happens it's harder to share things like screenshots, save files, RAM dumps, etc. from real hardware than it is on an emulator.
|
|
|
Post by TrekkiesUnite118 on Apr 4, 2019 5:28:25 GMT
Ok everyone, I believe I have all the event flags figured out. So with that out of the way I think we're ready for Disc 1 play testing. The image I've used for this is a Rip from my personal copy of the game, so hopefully the patch will work for the rest of you if you rip your own copy using ImgBurn like I did. If not we'll cross that bridge together. The patch is in xdelta format, so you'll need to use a program like DeltaPatcher or DeltaPatcher Lite to apply it. I've provided a patch for both the BIN and CUE file, but in the event the CUE file patch doesn't work, simply use SegaCueMaker to generate a new one. This is a very early release that is intended for Beta testing only. The goal here is to catch any hard crashes or severe bugs in the game, as it's still likely that could happen. While I've caught a few myself, I don't really have the time to fully play through all of Disc 1 multiple times trying various different things. Hence why I'm releasing this early patch. So if you want to Beta test, download the patch and apply it to your image of the game. I would refrain from burning this to a disc just yet as crashes are still very likely, and I wouldn't want anyone to waste good quality CD-Rs. For now I'd stick to emulators. The emulator of choice for this is Mednafen. It seems to behave the closes to a real Saturn. SSF is a good second, though there are instances where a real Saturn and Mednafen crash, while SSF doesn't. If you encounter a crash or bug, please provide the following information in this thread: - What exactly happened? (Game Crashed, Typo, Garbled Text, etc.)
- Screenshots or Videos if possible.
- What where you doing when it happened?
- Where in the game where you when it happened?
- A copy of your save file from your emulator.
Aside from the possible crashing, the following issues are known: - Voice Audio is horribly out of sync during voiced dialogue.
- The words "Ambushed" and "Your Initiative" in battle are out of alignment.
- Battle Menu Icon text is not translated. This is actually Graphical data that needs to be decompressed and edited.
- Some Post Battle text is untranslated for similar reasons.
- All but the first Map Screen are untranslated. The text in these screens gets scaled by VDP1 which ended up looking very poor. As a result I have not touched the others until I can figure out a better way to do this.
- FMVs are untranslated. The format used for these is still unknown so these most likely wont be subtitled for a while.
- Menu Selections are misaligned (Yes/No on Save Screen, etc.)
If this thread becomes too cluttered, I'll create a testing thread. The patch can be downloaded here:
|
|
|
Post by TrekkiesUnite118 on Mar 10, 2019 16:33:05 GMT
So while I am still working on Grandia, I've been curious about Phantasy Star Collection for some time and decided to poke around the disc for a bit today. And while I may jump into this once I finish up Grandia, I thought I'd post my findings if anyone else wants to take a crack at it. The 4 games seem work like this: - Each game has it's own dedicated EXE (PS1.EXE, PS2.EXE, PS3.EXE, and PS4.EXE)
- Each game has it's own directory, PS1, PS2, PS3, and PS4. These hold PCM files for the games sound effects and music, as well as the original game ROM.
- Phantasy Star 4 is the one special snowflake since it's ROM is too big to fit into RAM, so the game is broken up into different files.
- When each game is running, the EXE is loaded into HWRAM and the original Game ROM is loaded in it's entirety into LWRAM, again PS4 being the exception here.
- The EXE has multiple pointers in it that point to specific LWRAM offsets for data from the game's rom.
So what looks like was done is that the games were ported to the Saturn hardware similar to Sonic Jam, but instead of having the data there in individual files, the original ROMS are used instead for the game data. So it should be possible to translate these games by swapping out the ROMs and then updating the pointers in the EXEs to point to correct offsets in the English ROM. To test this theory I tried it out with Phantasy Star II and got the following results: Unfortunately the game crashed at this point, but it still proves that this should work as I probably missed an offset or changed something incorrectly. tl;dr, this shouldn't be too hard for a team of people to do if they have a good understanding of the original Genesis ROMs and how the English and Japanese versions differ. Phantasy Star IV would be the special snowflake however that would require some extra work.
|
|
|
Post by TrekkiesUnite118 on Feb 26, 2019 14:28:21 GMT
Ah, just got home and was able to watch a video and realize which parts actually needed translating. Good to find out my translations of the stuff you didn't need were accurate though, haha. Anyway, if there are any other things along these lines you need someone to look at just let me know. Thanks none the less. The red text wasn't translated for the US release so that's at least helpful. I think I've finally got the bugs worked out of my code that causes the game to load the new MDT files when the right events happen, however I still need to figure out the actual scenario flags for the later areas. If you or anyone else who feels up to it want to help, one thing that would be really helpful here is game saves to use with Mednafen or possibly Yabause. I need saves before, during, and after the following events: 1) Feena gets kidnapped in New Parm 2) The Rain Event in Dight before Typhoon Tower 3) A save around Gumbo after the Twin Towers events. 4) Sue get's Sick in Dight If I can get saves before, after, and during these events it would be really helpful in figuring out the scenario flags. Otherwise I have to play through the game myself to find them. Which I don't mind doing that, but it is time consuming. So if others already have saves at those points or can get there quickly that would be great.
|
|
|
Post by TrekkiesUnite118 on Feb 25, 2019 5:00:05 GMT
Trekkies, I've been following your progress on SegaXtreme but don't have the privileges over there to comment on how much I've appreciated your efforts and how excited I am to see all the progress you've made. Keep up the great work, we're all rooting for you! This is a kind of trifling suggestion, but if you don't have the space to write "(n) Exp. Points Received", why not just go with "(n) EXP Received"? It's a common enough abbreviation in RPGs that I'd think it should be fine. Not that "Won" is bad or anything, but I think it'd look more natural. As for Grandia Digital Museum, if anyone can dump the Japanese script for that game (easier said than done, I know) I could translate it. I understand that it couldn't be implemented using the PlayStation code as we've seen on this project, but I think if and when Trekkies can release a translation of the full game it might attract enough interest that someone with the know-how could take the initiative to implement the translation into the code. I've been living in Japan for three years, have done J-E translation work professionally, I have plenty of friends over here who could double-check my work. Plus GDM is of a manageable size. I'd have to hand it off or hope someone else would pick up the programming side of things for me, but the translation itself is totally doable for me. Trekkies, do you know the full-width Japanese character / half-width English character limit for Grandia's text boxes? To be honest I haven't really spent a lot of time playing with the BIN files for some of these to see if I can have a little more control over the tiles to fit better wording. But using EXP Received is one I did think of trying, I just wanted to try and keep things more in line with the English Script and what it uses in it's hints if possible. If Digital Museum uses the same file formats as the main game, then the tools I've made should be able to dump the script, someone would just need to put together a character table. I stopped working on that a while ago as it wasn't really needed. Though there is one floating around for the English PS1 version that appears to be compatible with the Saturn version, it just doesn't have the Japanese characters in it. As for the text box limits, I haven't actually done any testing as I haven't had to. Looking at gameplay though it looks to be about 24 8x16 characters per line, and 3 lines per box. So that would come out to 12 16x16 characters per line. One thing that would be nice though if you don't mind, some of the text graphics weren't translated in the PS1 version. They just got rid of them instead. I took a guess on some of them but a proper translation would be nice. These are mostly on the Win screens. For example the one I translated to LOOT! as a guess since it's in the box that shows all the items and gold you won, but it would be nice to know exactly what those things say.
|
|
|
Post by TrekkiesUnite118 on Feb 21, 2019 5:03:36 GMT
So I may have a work around for the issue of the PS1 version having more files due to a bigger script. I found out where the game determines what map to load next. It reads a value from a table in the MDT file, which is at the offset found at 0x30 in the MDT Header. That value tells it which map to load. However instead of updating every MDT file, I decided to take a stab at adding some code to the game, as it looks like this is what the PS1 version did as it's MDT files are unaltered at those offsets. For the time being I've added code that will check what file the game is loading. If it's loading any of the files that have clones for more script, it's going to check the scenario table which lives at 0x06021DC0. If the value is greater than or equal to the bare minimum for the overflow file, the code will change the file name to the new file. Otherwise it will continue loading as normal. So far I've tested this with success on the first new MDT file, 2001.MDT. This file should be used in Parm starting the day after you get back from the Sult Ruins. Using Debug mode to change the flags, I've able to confirm that this code works correctly, and so far no unexpected bugs have arisen from it. I have the code ready to go for the other files, I just need to find out what Scenario flags need set and what values they need set to and it should be good to go. Next, the remaining battle text that needs translated is not actually stored as text at all. It's actually graphics that need edited. However it looks like the data for those tiles is compressed. I've tracked the data down to MGDAT.BIN file in the BATLE directory, but I'm not experienced enough to really identify if it's a common compression format or not. This data encompasses the text for the icons in the circular battle menu, the text for the headers in the Items, Magic, and Skills windows, as well as the AI windows. However, I have done some work on translating the post battle screens which had their tile data stored uncompressed in the ENDW.DAT file: Some of the tiles I didn't touch yet though as I didn't feel skilled enough to make something that looked good, nor could I find a font I found acceptable. So if someone wants to take a shot at that feel free to do so. I was a bit limited in space though, hence why it says EXP Points Won instead of Earned. The way the tiles are stored I couldn't get the lower case e to turn out right as the game is hardcoded to read the tiles in a specific way, and I haven't had the time to look into modifying that. Finally, I've also looked at editing the text in the Map screen. This is also graphics instead of text, and it's stored in the AMAP#.ADD files in the FIELD directory. However I think I'll need a graphics artist to deal with this. This text is drawn as VDP1 scaled sprites. I tried using a 32x32 font I found from Pokemon Stadium on ROMHacking.net, but no matter what I tried it turned out looking like crap when VDP1 scaled it. It looked fine in the tile editor though. You can see how it looked here: I think though that once I get the other scenario flags sorted out, I should be close to at least having a beta version patch for Disc 1 ready for people to play test, as the remaining things while nice aren't something that would keep you from being able to play or something that would cause a crash.
|
|
|
Post by TrekkiesUnite118 on Feb 9, 2019 19:52:23 GMT
So I did some more digging and I have at least found what the game uses to know which MDT file to load when you change areas. At offset 0x06029A00 there's a table that lists all the files on the CD, with a value for what sector it's at, and how many bytes it is. The game references this when it wants to load a new file. How it knows which file to get out of this list though I don't know yet. However, I have been able to play around and have the game load different areas for me by changing the values for one MDT file to be that of another. So by doing this I was able to go from the Port of Parm to New Parm and test out the magic shop screen: Unfortunately this screen got modified in the English PS1 version, so some of those translations either wont fit or don't make sense, so I've had to improvise a bit here. I also tested out the buy screen and found I missed a word in the trade screen: Finally, just for fun I took Sue on a date to the Pirate Island. The game went a bit bonkers, I can only imagine because characters that should be in the party weren't there, and characters that shouldn't be in the party were there. The game eventually crashed when invisible Feena tried to speak after Justin spoke on behalf of a mermaid: EDIT: I realized I forgot to post some battle screenshots: I'm absolutely stunned by the quality of this project - it really is great to know that one of the Saturn's best RPGs will no longer be hidden away behind a language barrier, and I'm sure you'll get plenty of coverage in online retro gaming circles for your efforts! This might seem like a strange request, but would you also consider tackling the Digital Museum disc, and do you know if the planned US version of the main game was used to help produce the eventual PS translation? I have been asked about Digital Museum but I don't own that one to be honest. I'd imagine if the file formats are similar the tools I've made should be applicable. However you do need to keep in mind that the only reason this is progressing so quickly is because the file formats are so similar between the PS1 and Saturn versions. So I've been able to literally just copy pasta the script from the PS1 version into the Saturn version with minimal issues. As a result I've been able to bypass the need to make a Kanji table, dump the script, translate, etc. With Digital Museum those things would need to be done as there is no existing English Translation to use.
|
|
|
Post by TrekkiesUnite118 on Feb 9, 2019 5:03:25 GMT
So I figured I'd post an update. I've still been working on this and I've now successfully translated the following: - All Menus (Save/Load, Config Options, Items/Equip/Magic/Moves/Status, Shops, Item Get, etc.)
- All Items
- All Monsters and their attacks.
These have been done by pulling the data out of the Playstation version and injecting it into where it needs to go into the Saturn version. For the items this wasn't too hard as I just needed to put the English data into the file and adjust the pointers. For the monsters it was a bit more painstaking as there was no consistent pattern and all 200+ monsters had to be manually changed. Menus I was able to somewhat automate it with a tool that looked for pointers/offsets in the BIN files for those screens, and then updated those values based on the new data I wanted to put in to replace the Japanese text. This worked successfully for the most part, with only a few files needing hand adjustments afterwards. I'll be committing these tools to github after I take some time to clean the code up a bit. Here's some screenshots to show the progress: However I have hit a snag. It seems that the English PS1 version created additional MDT files for some areas where the text was too big to fit into RAM. Basically the created a duplicate file from a parent MDT file, and put the overflow text into that one. This new file then takes the place of the original after certain story events have happened. I've looked into the possibility of recombining these files but I'm not sure if it will work as we may hit the same problem. So I'm curious if it's possible to do the same thing the PS1 version did and create these clone files and find a way to make the game use them. However that's probably going to take some time to figure out.
|
|
|
Post by TrekkiesUnite118 on Nov 5, 2018 5:22:36 GMT
So I was able to fix the Text Box bugs that were visible in the previous video. Basically for the smaller text boxes the game does a calculation based on the number of characters in it to determine it's size. The game was still acting like the font was 16x16 instead of 8x16 which was causing the boxes to be bigger than they should. This was resulting in some having an overflow and bugging out. I did some digging and found that when the game read the 0x03 control code, it calls another subroutine for these text boxes that sets a value at the memory location of 0x06001ECC. For 16x16 font this value is set to 0x00, for 8x16 it should be set to 0x01. I was able to find where this value was coming from in the SCNRL.BIN file and make it so it permanently is set to 0x01 which has fixed the text boxes as you can see in the below picture: With that out of the way I think I have the bulk of the issues ironed out with the main script. What remains to be done for the main script is the following: 1) Fix any other bugs that come about through play-testing (I'm expecting more to crop up that were similar to the fade-in issue with Parm). 2) Fix the audio synchronization issue. The first will need to be done on a case by case basis as issues are discovered through play testing. The latter though is going to be tricky to figure out. One thing that really makes it hard is that emulators like Mednafen seem to draw faster than a real Saturn. So the audio synchronization is different between emulators and real hardware. On Real hardware the audio for the most part always plays, and the text severely lags behind in speed. So I'm thinking it may be an issue of text speed. I've reached out to the creator of the UnDub PS1 patch for help and they've been giving some suggestions to look at. For now though I'm thinking of shifting focus onto the menus and what not as what remains with the main script isn't as pressing of an issue I'd say.
|
|
|
Post by TrekkiesUnite118 on Oct 31, 2018 3:57:38 GMT
So it's been a while since I've posted an update, but I've finally solved the palette bug I'd been having with the automated conversion. Turns out the offsets in the MDT header 0x180 & 0x1F4 specify how many sectors need to be copied over from the CD for the file's data. This wasn't being updated so the game wasn't copying over all of the data. I've updated the tools to account for this and properly update the values when reconstructing the MDT files.
So with that out of the way I can move on to fixing some of the more minor issues that seem to be related to control codes. Basically audio isn't syncing as expected, and some of the text boxes aren't being positioned correctly or cleaning up correctly. I'd imagine this is probably some subtle difference between control codes across the Saturn and PS1.
Now, for something a bit more fun. I thought you guys might like to see some footage of the translated text in action. So here's a small bit I recorded from Mednafen:
Now to reiterate, this isn't perfect yet and there are bugs. So you'll get to see all of those as well.
|
|
|
Post by TrekkiesUnite118 on Oct 16, 2018 5:28:41 GMT
So I'm still working on trying to figure out the Palette bug in some of the areas. It seems to be related to file size expansion, but it's kind of odd. Basically the offset in the MDT file header at 0x0D8 seems to be the entry that points to this data. And while the offset was updated in the file, it seems the game is only partially obeying it. Basically the game is still starting the read of the data from the correct spot in when it writes it into RAM. However it's stopping at what would be the originally stopping point for the original offset prior to the file size changing. The size of this data hasn't changed and it's still correct in the header. As a result of this, old data from the previous MDT file is still in RAM and is being copied over as Palette data, which isn't correct and is causing the partial graphical corruptions I'm seeing. So I'm not entirely sure why this problem is happening. The only explanation is that it must be getting the value for where to stop reading from somewhere else. But where it's getting that info I haven't been able to track down yet. In other news, I've put the code for the tools I've been writing up on GitHub: github.com/TrekkiesUnite118/GrandiaTranslationThe tools are written in Java and hopefully should be easy to figure out. I'll be putting more info on the file formats as well as how to use the tools in the next few days when I have time. If anyone wants access as a contributor so they can add code/make changes let me know and I can add you.
|
|