Norbert wrote:
./pr -f --resource=pop2.xml --export=/home/norbert/test/resources PoP2/ROOFTOPS.DAT
Running this gets stuck:
[...]
Running this finishes successfully:
./pr -f --resource=pop2.xml --export=resources PoP2/ROOFTOPS.DAT
So, the only difference is the export path?
That's odd.
This is what PR does for me on Windows: (with the --verbose option)
[...]
pop2decompress: 679, 22
pop2decompress: 580, 21
pop2decompress: 674, 22
pop2decompress: 655, 21
pop2decompress: 4016, 232
pop2decompress: 1786, 45
pop2decompress: 688, 26
Error in file shap04166.bmp (code -26)
Error in file shap04167.bmp (code -26)
pop2decompress: 9037, 122
pop2decompress: 2557, 32
pop2decompress: 1003, 34
pop2decompress: 325, 54
pop2decompress: 366, 54
pop2decompress: 364, 54
pop2decompress: 355, 54
pop2decompress: 11767, 320
pop2decompress: 13667, 320
pop2decompress: 16957, 298
Result: 131 files successfully exported (131)
The problem is that those two resources are almost empty in PoP2 v1.0, they contain only two bytes: 00 00.
The game interprets this as a zero-height image (the first two bytes store the height), and does not try to process it further.
PR, however, does not skip these.
I added them as bitmaps to pop2.xml because PoP2 IR *does* have actual images with these resource IDs.
What should PR do when it finds a zero-height bitmap?
Should it export them as a 0×0 BMP? (Is that even valid?)
Or just don't export them at all?
Either way, most PoP2 (and PoP1) DAT files have plenty of such resources.
Would it be a good idea to mark them as bitmaps instead of binary in the XMLs?
Norbert wrote:The -4 value looks suspicious.
That is the "remaining" size of the 2-byte resource after subtracting the 6 bytes of the header.
Norbert wrote:(All of this might be related to
this?)
The palettes? I don't think so.
EDIT: For now, I chose not to export them at all:
https://github.com/NagyD/PR/commit/010c ... 25b8f582ed
Please try if it works for you.