Closed Hypexed closed 1 year ago
timfel
commented
7 years ago @Hypexed if you can open a pull request, maybe we can discuss on the code? I'd be very happy to get help to make the extractor work better. I have some work in the pipeline to get zerg creep and some other things working so that stargus os actually playable for skirmish games, but it's difficult to find versions that extract cleanly and that is a big impediment for new users
Hypexed
commented
7 years ago Hi and thanks for the reply. Although I must say this is a subject I least expected to get attention. ;-)
Yes I'd be happy to do that. I could see it wouldn't be too long before I started modifying official builds. Plus I managed to be a port of call for one particular PPC platform and from time to time get an email about issues.
A main FR I get is campaigns. I haven't checked on these lately. Anyway I'll make that pull request. :-)
Hypexed
commented
7 years ago Hi there. Just an update. I'm in the process of updating the code. I added a macro to read long ints from files. And any data read in needed to be reversed. Decode routines need data to be reversed back. Since sometimes it reads bytes that happens to be the LSB of a long word.
Most of that was trivial. Only because I knew where the problems parts were from experience. And it started working okay. However I soon found that the explode routine is somehow corrupting data, or so it seems. Because all extracts fine up to font12 then the font converter code crashes on a Segmentation fault. I am however using the Mac version of the MPQ file from Starcraft Archive if that affects it.
I don't want too but the explode routine looks similar to the huffman code replaced by StormLib. So it may need that code replaced with a cleaner routine in case that is breaking it. The current explode code is a mess. And doesn't look human written at all. Do you know where it came from? It looks reverse engineered.
ThibaultLemaire
commented
6 years ago The current explode code is a mess. And doesn't look human written at all. Do you know where it came from? It looks reverse engineered.
I'd like to know that as well!
pali
commented
6 years ago As mpq.cpp is slightly complicated it isn't too easy to fix it. Especially the cryptic code that looked like it was translated by an x86 ASM to C converter. But later revisions replaced some decompression code so hopefully that alleviates the work needed.
I guess that original code is reverse engineered too. Huffman decoding worked only on 32 bit CPU and I was not unable to fix it, so in past I rather replaced Huffman decoder with StormLib implementation... https://github.com/Wargus/stargus/commit/f3857488dfa937a3579120a1b0670a1411dd907a
This may be of less importance these days but Startool does not work on big endian systems. The top end code in startool.cpp is endian agnostic and is fine. The problem is with the bottom end in mpq.cpp which is LE only
As mpq.cpp is slightly complicated it isn't too easy to fix it. Especially the cryptic code that looked like it was translated by an x86 ASM to C converter. But later revisions replaced some decompression code so hopefully that alleviates the work needed.
From experience what I'd suggest is replacing the UInt32 fread() function with a macro that does the same thing but reverses the variable on BE. It could be called fread32LE(). This avoids extra code converting values and only changes output code for BE.
Next would be any 16 or 32 bit reads which would need a reversing macro. Hopefully the writing out can stay. But writing out LE is no trouble.
I have actually done this on an early version of the code. But in the process had to rip out a whole lot of decompression code and replace it with parts from MPQKit and StormLib including huff code like was done here. And the result was modified to the point that the code wasn't manageable. But duplicating the changes in a cleaner fashion now would be possible.