| Home | Forums | What's new | Resources | |
| Translating Grandia 1.1.1 |
| TrekkiesUnite118 - Sep 9, 2018 |
| < Prev | 1 | ... | 18 | 19 | 20 | 21 | 22 | ... | 48 | Next> |
 |
samson7point1 | Sep 28, 2019 | ||||
Just to close the loop on this, I went back to re-verify my results. TLDR; I can get matching checksums from my original rips now. I made the faulty assumption that the data would be equivalent when extracted by different tools, and therefore the erroneous statement that I followed the process in your README exactly. I stopped using ISOBuster years ago because I had other tools that did ostensibly the same thing but didn't limit functionality or constantly nag me to pay for a license. I was getting different file sizes and checksums because I originally used the 7zISO plugin to checksum and extract the data track. When I re-ripped everything I decided to dig up an old copy of ISOBuster I had lying around and compare what it was producing vs 7zISO. When I extracted the data with ISOBuster suddenly I got the checksums in your readme, but I knew 7zISO worked because I've successfully used it to extract and write back tracks with other projects. HxD gave me this when I compared the ISOs:  FWIW, these are the sums I got with 7zISO for Disc 1 Track 1: CRC32: F84B3738 MD5: 062b7ef1dbe261002c5f87e76cdd0345 SHA-1: 38da4c1a55aba4ce5418d4fc35d83e7c04855c80 Size: 540,094,464 bytes If 7zISO was doing something silly like extracting the ISO in 2352 instead of 2048, I would expect to see extra data (and for the size difference to be closer to 76MB rather than 1.5MB), likewise if it was zero-padded. Both are valid files, and based on this, I *think* the patch would work just fine even though the sums don't match because the offsets would all presumably be the same. Anyway, PEBKAC error sorted! | ||||||
 |
nanash1 | Sep 28, 2019 | ||||
Ok. I will look into it when I'm back home from the weekend. | ||||||
 |
TrekkiesUnite118 | Sep 28, 2019 | ||||||
Thanks. In the mean time I've put up a video showing the progress made on the battle menus and the result screen. I think I have everything except the compressed bit I mentioned earlier:
| ||||||||
|
nanash1 | Sep 29, 2019 | ||||
Nice work! I fixed the bug in the compression tool. The first problem was that the offset wasn't correct. The correct offset for disc 1 is 0x25ebc. The second problem was that this image file starts on table compressed data. This case wasn't handled in my tool until now. | ||||||
|
TrekkiesUnite118 | Sep 29, 2019 | ||||
Thanks! I'll give this a try and see what I can do. | ||||||
 |
bmn | Oct 5, 2019 | ||
Not sure if this is a bug/known etc. In the first Alent boss Hydra, the enemy Hot Head is instead called SUDNDEATH (one of the moves another enemy in the same boss performs). I don't think there's anything else up with this boss. #s | ||||
|
TrekkiesUnite118 | Oct 6, 2019 | ||||
Was probably a copy paste mistake. I have it fixed and it will be in the next patch release. | ||||||
 |
plat | Oct 7, 2019 | |||
|
@nanash1... Just thought I'd mention that compiling your compression tool on Linux (glibc) fails with this error:
Code:
Doing as it says and using To check for any other portability issues, I ran scan-build and cppcheck static analyzers. While there didn't appear to be any, they did pick up a few possible issues. I've included their reports and warning output from clang in the attachment if you're interested in them; all you should need to do to view them is open the index.html files inside the cppcheck and scan-build report directories and the clang_warnings.txt file. I also included the generic Makefile I modified for this tool which produces a debug-friendly binary. For what it's worth, this used v090 since v095 source isn't available. | |||||
|
nanash1 | Oct 7, 2019 | ||
| Well, to do a proper Linux version you'd have to check the systems endianess and determine if the use of byteswap is necessary in the first place since afaik Linux isn't always little endian. | ||||
|
TrekkiesUnite118 | Oct 7, 2019 | ||||
So if it's not too much trouble, if you comment your code really well so I can easily follow what's going on (mainly because my C/C++ is very rusty/poor), I can see if I can convert it over to Java and then in theory it would be platform independent. | ||||||
|
nanash1 | Oct 7, 2019 | ||
| If everything is working with the last update I could refactor a few things, improve the comments and push the version to 1.0. I didn't included the source in the latest version, because my quick bug fix used the evil goto statement. | ||||
 |
nando | Oct 7, 2019 | ||
| Would you be open to make it a GitHub repository? People could fork it from there to whatever platform/language they liked. It seems to me that it's an interesting enough tool, even outside of the Grandia translation project. | ||||
|
nanash1 | Oct 8, 2019 | ||||
I've never used github before, but I can look into it. However, it'll be a while since I'm currently away on vacation. | ||||||
 |
Drazham | Nov 1, 2019 | ||
| Reading the thread about the proccess on dumping the english traduction directly on the ROM, would it be possible to do the same on Grandia Ditigal Museum? Just only talking about the texts on the menu and combats, believing that it will use the same code or a similar one. | ||||
 |
votemarvel | Nov 2, 2019 | ||
| I've registered just to say thank you for working on this patch. I own the game for my Playstation but it is going to be nice having it in English for my Saturn as well. | ||||
 |
themadhaxor | Nov 4, 2019 | ||
Looking forward to the next patch release  Any news from behind the scenes? | ||||
|
TrekkiesUnite118 | Nov 5, 2019 | ||||
I'm still working on it. I've just been busy helping out with some of the issues the Sakura Wars team has been having lately. For Grandia though I do have the compressed battle graphics ready to go, the problem is they need to go into every BBG file in the game. So I need to write a tool to break those files down and rebuild them so I can insert the new data more easily and with less chances to screw something up. Also digging more into the FMVs, it's looking like they may actually be a very early variant of CRI's MPEG Sofdec codec. So if we can figure out how to get the Quick Time containers off of them, it shouldn't be to hard to use existing tools to decode and re-encode them I'd imagine. However this is still a lot of speculation. | ||||||
 |
Ardiloso | Nov 5, 2019 | ||
|
I'm liking the patch delay because real life hit me hard and I don't have time to resume my playthrough. @TrekkiesUnite118... when you figure out the fmv compression/decompression, I can provide you with the much superior fmvs from the HD remaster if you want/can use them to compress back into the game since I've bought it on steam. | ||||
 |
darknior | Nov 6, 2019 | ||
|
Thanks a lot for all your work, it's really amazing | ||||
| < Prev | 1 | ... | 18 | 19 | 20 | 21 | 22 | ... | 48 | Next> |