PR 1.3.1 pre-release
PR 1.3.1 pre-release
I attached the new version to this post. In contains both the source and a pr.exe.
Changes since PR 1.3:
First, the long awaited:
- Fixed wave exporting and importing. Now PR knows about the wave header in DAT files, and sets the WAV header accordingly (and vice versa). See viewtopic.php?f=73&t=1674
And some small fixes:
- Fixed a long-short mismatch in the BMP reader that caused a crash under Ubuntu. See viewtopic.php?p=13749#p13749
- Fixed all warnings that appear only in debug mode (-Wall -pedantic). Replaced //... with /*...*/, added some #include lines, commented out unused code, moved declarations above statements.
- Fixed a bug that crashed PR if a resource had an address beyond the end of file. See viewtopic.php?p=13789#p13789 (1.)
- Fixed a bug that caused PR not to export RLE-compressed images if their data is too long. See viewtopic.php?p=13789#p13789 (2.)
- PR now accepts BMP files with bigger headers. (For example, those saved with GIMP 2.8.) See viewtopic.php?p=13694#p13694
- PR now shows if there were errors during import. See viewtopic.php?p=13694#p13694
- Renamed some wav and midi files in resources.xml. See viewtopic.php?p=13855#p13855, but there are many more changes.
Changes since PR 1.3:
First, the long awaited:
- Fixed wave exporting and importing. Now PR knows about the wave header in DAT files, and sets the WAV header accordingly (and vice versa). See viewtopic.php?f=73&t=1674
And some small fixes:
- Fixed a long-short mismatch in the BMP reader that caused a crash under Ubuntu. See viewtopic.php?p=13749#p13749
- Fixed all warnings that appear only in debug mode (-Wall -pedantic). Replaced //... with /*...*/, added some #include lines, commented out unused code, moved declarations above statements.
- Fixed a bug that crashed PR if a resource had an address beyond the end of file. See viewtopic.php?p=13789#p13789 (1.)
- Fixed a bug that caused PR not to export RLE-compressed images if their data is too long. See viewtopic.php?p=13789#p13789 (2.)
- PR now accepts BMP files with bigger headers. (For example, those saved with GIMP 2.8.) See viewtopic.php?p=13694#p13694
- PR now shows if there were errors during import. See viewtopic.php?p=13694#p13694
- Renamed some wav and midi files in resources.xml. See viewtopic.php?p=13855#p13855, but there are many more changes.
- Attachments
-
- PR-1.3.1-prerelease.ZIP
- (351 KiB) Downloaded 390 times
Re: PR 1.3.1 pre-release
Thanks for all the improvements and fixes.
Pre-release; that's because it needs testing, or?
Pre-release; that's because it needs testing, or?
Re: PR 1.3.1 pre-release
Yes, it needs testing; also there are some things that could be added:Norbert wrote:Pre-release; that's because it needs testing, or?
- Currently only PoP1 waves are supported. PoP2 waves have a different header. See: viewtopic.php?p=4926#p4926
- The loop flag is not handled yet. 0x80 is added to the type byte of sounds if they are meant to be looped. In PoP1 it is set only in "level door opening" (10015).
Ideally, WAV should have some means of keeping this information, but if it doesn't, then maybe put it into resources.xml.
- Some WAV files have different layout than those that are written by PR. This means that there are extra chunks before or after the "data" chunk.
The most frequent extra chunks are "fact" (it is present only in compressed WAVs, which we don't support anyway) and "LIST" (usually author info).
PR currently signals an error if there are any extra chunks.
Code: Select all
ok=ok&& ((int)ChunkSize == (int)(4 + (8 + SubChunk1Size) + (8 + SubChunk2Size)) );
FFmpeg and SoX output waves without extra chunks, so maybe this is not so important.
- PR currently rejects WAV files if they are not 8-bit. Maybe convert 16-bit waves to 8-bit instead of rejecting? (PoP1 supports only 8-bit waves.)
- Speaking about import errors, they usually say that "'filename.ext' has errors, skipped". It would be better to have separate messages for each error.
Re: PR 1.3.1 pre-release
Okay, I'll use it for my next mod and will wait with 'announcing it' (Facebook/Twitter/front pages) until it's no longer pre-release.
Re: PR 1.3.1 pre-release
Maybe I misunderstand what you write here, but...David wrote:- Fixed all warnings that appear only in debug mode (-Wall -pedantic).
"TYPE = Debug" gives me:
Code: Select all
lib/compression/rlec_uncompress.c: In function ‘expandRleC’:
lib/compression/rlec_uncompress.c:46:6: warning: variable ‘done’ set but not used [-Wunused-but-set-variable]
lib/layers/dat.c: In function ‘mWriteCloseDatFile’:
lib/layers/dat.c:613:22: warning: variable ‘flags’ set but not used [-Wunused-but-set-variable]
lib/object/image/image2.c: In function ‘objImage2Read’:
lib/object/image/image2.c:140:6: warning: variable ‘bits’ set but not used [-Wunused-but-set-variable]
lib/object/image/image16.c: In function ‘objImage16Create’:
lib/object/image/image16.c:366:6: warning: variable ‘bits’ set but not used [-Wunused-but-set-variable]
lib/object/image/image256.c: In function ‘pop2decompress’:
lib/object/image/image256.c:269:21: warning: variable ‘aux2’ set but not used [-Wunused-but-set-variable]
lib/object/image/image256.c: In function ‘objImage256Create’:
lib/object/image/image256.c:347:6: warning: variable ‘bits’ set but not used [-Wunused-but-set-variable]
Code: Select all
In file included from /usr/include/string.h:638:0,
from lib/object/palette/pop1_4bit.c:39:
In function ‘memcpy’,
inlined from ‘paletteGetColorArrayForColors’ at lib/object/palette/pop1_4bit.c:230:9:
/usr/include/i386-linux-gnu/bits/string3.h:51:3: warning: call to __builtin___memcpy_chk will always overflow destination buffer [enabled by default]
Re: PR 1.3.1 pre-release
I'm running into a problem with the attached drinking.wav when importing DIGISND3.DAT.
I don't know if the above information is useful?
Code: Select all
*** Error in `/home/norbert/PR-1.3.1-prerelease/src/bin/pr': free(): invalid pointer: 0xb776d470 ***
Code: Select all
#0 0xb77ae424 in __kernel_vsyscall ()
#1 0xb7604b1f in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0xb76080b3 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0xb7641ab5 in ?? () from /lib/i386-linux-gnu/libc.so.6
#4 0xb764c7e2 in ?? () from /lib/i386-linux-gnu/libc.so.6
#5 0xb764d530 in ?? () from /lib/i386-linux-gnu/libc.so.6
#6 0x080587ef in objWaveRead ()
#7 0x08055820 in readObject ()
#8 0x0804ea0c in import_full ()
#9 0x08049a61 in prImportDatOpt ()
#10 0x0804937c in main ()
- Attachments
-
- drinking.zip
- drinking.wav
- (12.57 KiB) Downloaded 252 times
Re: PR 1.3.1 pre-release
1. PR does not accept this wav file.
The length of "data" is odd, so it is followed by a padding byte.
However, PR expects the following: (src/lib/formats/wav.c)
I replaced SubChunk2Size with (SubChunk2Size+1&~1) and it seems to solve the problem.
When exporting, the padding byte should be written after odd-length data.
Replace writeWav with this:
Of the original sounds, mirror.wav, prince crashing into the floor.wav and skel alive.wav have odd length.
When I exported the original sounds and imported them back, the two bugs canceled each other, so PR accepted the wavs created by itself.
2. In src/lib/object/sound/sounds.c
If the wav file was not accepted, the line free(o->samples.data); tries to free an uninitialized pointer.
- Set it to NULL after o is allocated: o->samples.data = NULL;
- Check it before freeing: if (o->samples.data) free(o->samples.data);
(I don't remember seeing those. Maybe we're using different versions of gcc?)
The length of "data" is odd, so it is followed by a padding byte.
However, PR expects the following: (src/lib/formats/wav.c)
Code: Select all
((int)ChunkSize == (int)(4 + (8 + SubChunk1Size) + (8 + SubChunk2Size)) )
When exporting, the padding byte should be written after odd-length data.
Replace writeWav with this:
Code: Select all
int writeWav(const char* file, tWave* snd, int optionflag, const char* backupExtension) {
FILE* target;
int ok;
unsigned char wav[]=WAVE_HEADER;
int sndsize = snd->samples.size;
int sndsize_pad = sndsize+1&~1;
int riffsize = sndsize_pad+36;
int samplerate = snd->samplerate;
ok=writeOpen(file,&target,optionflag);
wav[4]=(unsigned char)(riffsize&0xFF);
wav[5]=(unsigned char)((riffsize>>8)&0xFF);
wav[6]=(unsigned char)((riffsize>>16)&0xFF);
wav[7]=(unsigned char)((riffsize>>24)&0xFF);
wav[0x18] = samplerate & 0xFF;
wav[0x19] = (samplerate >> 8) & 0xFF;
wav[0x1A] = (samplerate >> 16) & 0xFF;
wav[0x1B] = (samplerate >> 24) & 0xFF;
wav[0x1C] = samplerate & 0xFF;
wav[0x1D] = (samplerate >> 8) & 0xFF;
wav[0x1E] = (samplerate >> 16) & 0xFF;
wav[0x1F] = (samplerate >> 24) & 0xFF;
wav[40]=(unsigned char)((sndsize)&0xFF);
wav[41]=(unsigned char)(((sndsize)>>8)&0xFF);
wav[42]=(unsigned char)(((sndsize)>>16)&0xFF);
wav[43]=(unsigned char)(((sndsize)>>24)&0xFF);
ok=ok&&fwrite(wav,sizeof(wav),1,target);
ok=ok&&fwrite(snd->samples.data,snd->samples.size,1,target);
ok=ok&&fwrite("",sndsize_pad-sndsize,1,target);
ok=ok&&(!writeCloseOk(target,optionflag,backupExtension));
return ok?PR_RESULT_SUCCESS:PR_RESULT_ERR_FILE_NOT_WRITE_ACCESS;
}
When I exported the original sounds and imported them back, the two bugs canceled each other, so PR accepted the wavs created by itself.
2. In src/lib/object/sound/sounds.c
If the wav file was not accepted, the line free(o->samples.data); tries to free an uninitialized pointer.
- Set it to NULL after o is allocated: o->samples.data = NULL;
- Check it before freeing: if (o->samples.data) free(o->samples.data);
Now I fixed those in my copy.Norbert wrote: "TYPE = Debug" gives me:
...
"TYPE = Release" gives me:
...
(I don't remember seeing those. Maybe we're using different versions of gcc?)
Re: PR 1.3.1 pre-release
Thanks, I'll give it another try after applying those changes.
Re: PR 1.3.1 pre-release
The following is somewhat related to PR, therefore I'm posting it here.
I've always wondered whether the two gate segments that are being exported as black/white have anything to do with the black area that shows up if gates get stacked.
See: http://i.imgur.com/jOBTEZo.png (mirror)
That black area shows up even when PR hasn't been used, so maybe it's a resource bug in the original game?
I've always wondered whether the two gate segments that are being exported as black/white have anything to do with the black area that shows up if gates get stacked.
See: http://i.imgur.com/jOBTEZo.png (mirror)
That black area shows up even when PR hasn't been used, so maybe it's a resource bug in the original game?
Re: PR 1.3.1 pre-release
I changed that image to fully black, but nothing happened.
Then I changed it to fully white, and a black rectangle appeared at non-stacked gates.
So this image is not used at all with stacked gates!
Then I changed it to fully white, and a black rectangle appeared at non-stacked gates.
So this image is not used at all with stacked gates!
Re: PR 1.3.1 pre-release
David, in your pop2.xml, it says:
I have two questions related to this. The first is: since PoP2 has only 14 levels, which appear to be ____02000.bin through ____02013.bin, do you know what ____02020.bin through ____02033.bin are? Second is: are you willing to implement PoP2 level importing? The best thing would be a PLV v1.0 compliant implementation (probably lots of reusable code from the PoP1 variant), but 'just' putting the .bin files back into PRINCE.DAT would already help me out. You have a lot more knowledge of the PR code base. Also, in theory I may be just smart enough to pull it off myself, but in practice it would probably take me 'forever'. I hope you don't mind this request so soon after you've ported apoplexy 1.9b to Windows... There is no rush.
Code: Select all
<!-- resources 2000-2033 are levels, but PR can't import them currently, so I'll leave them as binaries for now. -->
Re: PR 1.3.1 pre-release
__02020.bin through ____02033.bin are the "extra" levels or as they call it gameplay levels.
-- Michael, the boy who makes Shaw's Nightmare.
Visit here to download Shaw's Nightmare: http://shawsnightmare.ucoz.com
Visit here to download Shaw's Nightmare: http://shawsnightmare.ucoz.com
Re: PR 1.3.1 pre-release
I don't know what that means, extra/gameplay levels...musa wrote:__02020.bin through ____02033.bin are the "extra" levels or as they call it gameplay levels.
Do you have any extra information?
Re: PR 1.3.1 pre-release
No that's pretty much it.
But you can play them with the GAMEPLAY command line.
But you can play them with the GAMEPLAY command line.
-- Michael, the boy who makes Shaw's Nightmare.
Visit here to download Shaw's Nightmare: http://shawsnightmare.ucoz.com
Visit here to download Shaw's Nightmare: http://shawsnightmare.ucoz.com
Re: PR 1.3.1 pre-release
Ah, interesting, I never knew that.musa wrote:But you can play them with the GAMEPLAY command line.
Most of those levels appear to be easier. They feel like demonstration levels, to show off the main cut-scenes and other stuff to the management.