There are only nine more KERNEL.BIN sections left for me to encode (sans 2 & 3 still). That's the description sections and the battle text. This may sound like a lot, but it's really just means two nearly-identical overloaded functions remaining. That being said, I'm going to need testers for this version. I'd like people who can test the PC and people who can test the PSX sides of it. You don't need to be able to test both, but I need to know that both work. I think this will be ready to be tested before the week is over so PM me your email address if you're interested.
EDIT: An odd thing just happened... I was testing out KERNEL.BIN, putting the pieces back together and all, and before I started working on a encoding method that would implement the decoding method Akari mentioned in reply #85 I decided to rebuild it and see how big the KERNEL.BIN gets over the original. It didn't. It got smaller. The original KERNEL.BIN is 22,376 bytes with blocks 9-16 and 25 encoded and GZipped. Without these blocks encoded, the size is 21,337 GZipped. So in addition to making kernel2.bin smaller (which it is now becoming smaller than I reported a few posts ago), KERNEL.BIN is smaller too. Oh yes, and it works, of course.
This will prove to be no problem for the PC version since it doesn't use those texts, but I wondering about the memory issues of the PSX. Would it be worth it to encode these? GunZipped and left decoded these 9 sections are 17,898 bytes in size. GunZipped and encoded, they are 14,206 bytes. 3,692 bytes doesn't sound significant, but the PSX has limited RAM to begin with. I don't know how it loads it into memory. Does it decode it into memory or leave encoded text in memory and decode it on the fly? If the answer is decode into memory then the developers made a mistake in making the text encoded in the first place. I wouldn't put it past them, but if this is the case I'm not going to bother writing my own encoding function.
I REALLY need someone who can test this out on PSX hardware for this reason. It might be just as well emulated as long as the emulator keeps the same RAM size restriction that the original hardware has.
UPDATE: I have good news, but it's against the forum rules to double post (but someone else can post to bump this *hint*) so I'll have to say it like this:
The working beta is HOT and ready to be tested!!I did end up compressing the PSX text and finally got it to cooperate only to learn something odd. GZipping makes no sense. That's what I learned.
Once I compressed the PSX text for compiling I noticed that the raw files were smaller. If I just take the original KERNEL.BIN, which is 22,376 bytes, and decompress it, the pieces total 46,534 bytes. After WallMarket gets its virtual hands/claws/teeth on it and re-writes it/compresses it, KERNEL.BIN becomes 22,535 bytes and the pieces total 46,136 bytes. I'm dumbfounded how the loss of nearly 400 bytes of source actually make the compression nearly 160 bytes larger..... So weird.
Anyway, I have no way of testing if this new KERNEL.BIN works with the edited text pieces. I NEED a PSX tester for this. PM me your email address if you're interested.
