Vennobennu Posted November 10, 2013 Share Posted November 10, 2013 (edited) I've been making edits to Fe11 using DSLazy and Nintenlord's LZ77 compressor, and have run into an issue with re-compressing the file for chapter 14's units - bmap014. After uncompressing the file for editing, recompressing, and assembling the .nds with the edited bmap014, the game hangs when loading Chapter 14. This happens even if no changes are made to bmap 014. Looking at the original and recompressed bmap014 in HxD, the two files are very diferent (not sure how to explain, but many bytes are not the same), and the recompressed file is two bytes larger. I'm thinking the bmap014 file is supposed to be fixed-length, and NL77C's (de)compression is producing a file that is larger than it ought to. ...But I'm not sure how to make it work properly. Any ideas? Edited November 13, 2013 by Vennobennu Link to comment Share on other sites More sharing options...
Crimson Red Posted November 12, 2013 Share Posted November 12, 2013 Uhhh it might be LZ11 compression. Try a program called Puyo Tools (link or search on google). Check the first bytes (the header) of the file using a hex editor to determine the type (e.g. "standard" LZ77 has an 0x10 somewhere near the beginning, I've forgotten exactly), then edit it after. It can't be too hard since I've edited those files before (IIRC they include unit data or something though I'm not sure since once again, it's been way too long and I didn't do much of this to start with). Link to comment Share on other sites More sharing options...
Vennobennu Posted November 13, 2013 Author Share Posted November 13, 2013 I'm 99% sure it uses LZ77 compression; all of the other bmap files I've edited are LZ77 compressed and I've made small changes to them just fine. The data decompresses to an understandable format (ie is structured like the doc says, and is consistent with ingame); it's just this particular one which causes problems so far. The file has a 0x10 byte right at the beginning like the other files. And yeah, they deal with unit data and AI. Link to comment Share on other sites More sharing options...
Celice Posted November 13, 2013 Share Posted November 13, 2013 Just as a precautionary, have you tried recompressing the file using another tool, and/or recompiling the ROM with a different program? Link to comment Share on other sites More sharing options...
VincentASM Posted November 13, 2013 Share Posted November 13, 2013 NL's compressor is great, but it's not 100% accurate--the early version(s) of it at least. Haven't had any issues using BatchLZ77 for the duration of the FE12 translation project. Link to comment Share on other sites More sharing options...
Vennobennu Posted November 13, 2013 Author Share Posted November 13, 2013 Using BatchLZ77 seems to work perfectly. Thanks for the advice! Link to comment Share on other sites More sharing options...
johnsonjeven Posted October 12, 2016 Share Posted October 12, 2016 LZF is conceptually very similar to LZ77. Generally speaking most modern compression algorithms give roughly the same compression, and with regard to the number of cores that you can use at once, it is up to you to decide how many you want to use. Generally speaking (unless you are creating large archives) there is no reason to need more than one though. In addition, with multiple cores doing the compression, the bottleneck may become the hard drive. Legacy zip compression is akin to the Deflate method in 7-zip, and will offer the most compatibility between different compression software. John Link to comment Share on other sites More sharing options...
Recommended Posts