PR 1.3.1 pre-release

About PR usage and development, and about the POP format.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

Norbert wrote:Second is: are you willing to implement PoP2 level importing?
It seems to me that it works since PR 1.3.
PR 1.2, however, had broken level importing for both PoP1 and PoP2.

Replace those lines with these:

Code: Select all

<!-- resources 2000-2033 are levels -->
	<!-- regular levels -->
		<item path="____02000.plv" type="level" number="1" value="2000" index="" />
		<item path="____02001.plv" type="level" number="2" value="2001" index="" />
		<item path="____02002.plv" type="level" number="3" value="2002" index="" />
		<item path="____02003.plv" type="level" number="4" value="2003" index="" />
		<item path="____02004.plv" type="level" number="5" value="2004" index="" />
		<item path="____02005.plv" type="level" number="6" value="2005" index="" />
		<item path="____02006.plv" type="level" number="7" value="2006" index="" />
		<item path="____02007.plv" type="level" number="8" value="2007" index="" />
		<item path="____02008.plv" type="level" number="9" value="2008" index="" />
		<item path="____02009.plv" type="level" number="10" value="2009" index="" />
		<item path="____02010.plv" type="level" number="11" value="2010" index="" />
		<item path="____02011.plv" type="level" number="12" value="2011" index="" />
		<item path="____02012.plv" type="level" number="13" value="2012" index="" />
		<item path="____02013.plv" type="level" number="14" value="2013" index="" />
	<!-- levels that you can play with the GAMEPLAY command line option -->
		<item path="____02020.plv" type="level" number="1" value="2020" index="" />
		<item path="____02021.plv" type="level" number="2" value="2021" index="" />
		<item path="____02022.plv" type="level" number="3" value="2022" index="" />
		<item path="____02023.plv" type="level" number="4" value="2023" index="" />
		<item path="____02024.plv" type="level" number="5" value="2024" index="" />
		<item path="____02025.plv" type="level" number="6" value="2025" index="" />
		<item path="____02026.plv" type="level" number="7" value="2026" index="" />
		<item path="____02027.plv" type="level" number="8" value="2027" index="" />
		<item path="____02028.plv" type="level" number="9" value="2028" index="" />
		<item path="____02029.plv" type="level" number="10" value="2029" index="" />
		<item path="____02030.plv" type="level" number="11" value="2030" index="" />
		<item path="____02031.plv" type="level" number="12" value="2031" index="" />
		<item path="____02032.plv" type="level" number="13" value="2032" index="" />
		<item path="____02033.plv" type="level" number="14" value="2033" index="" />
And while at it... PoP2 resources have no meaningful names and they are not categorized into folders (except by the names of the DAT files). Yet another thing to fix...
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

Thanks, those PLV files with type="level" work fine.
I can already edit PoP2 levels with apoplexy, I'm now busy figuring out all available tile modifiers (because those aren't yet exhaustively documented; 4 bits for PoP2).
Lots of fun. (Not meant sarcastically.)

Anyways, maybe for ____02020.plv through ____02033.plv, offset 9 (the Level Number; UC) could be changed from 1-14 to 15-28.
I already have a workaround implemented (I look at the filenames), but it would be easier and probably better if PLV files contain unique level numbers.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

Norbert wrote:I can already edit PoP2 levels with apoplexy, I'm now busy figuring out all available tile modifiers (because those aren't yet exhaustively documented; 4 bits for PoP2).
I guess you meant 4 bytes. :)
They are shown in the drop-down lists in my level editor, and in RoomShaker2.
(Although it seems to me that RS2's lists are incomplete.)
A thing to watch out for is that some modifiers contain multiple things together, in bitfields.
For example, in ruins levels, the floor's modifier 1 controls two things: bits 0-3 are the cracks, bits 4-5 are the snake signs.
(In RS2, these bitfields can't be independently set, only together. And lots of combinations are missing.)
Norbert wrote:Anyways, maybe for ____02020.plv through ____02033.plv, offset 9 (the Level Number; UC) could be changed from 1-14 to 15-28.
I already have a workaround implemented (I look at the filenames), but it would be easier and probably better if PLV files contain unique level numbers.
Just change the number in number="..." in resources.xml.
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

David wrote:I guess you meant 4 bytes. :)
Yeah, typo. :)
David wrote:A thing to watch out for is that some modifiers contain multiple things together, in bitfields.
I'm documenting everything and I'm using the decimal values, so this shouldn't be a problem.
I've almost finished the documentation about the cavern levels.
One of the modifiers there is about both the tile bottoms and stalactites, I think that's another example of what you mean.
I'll publish the first version of the new document I'm working on soon.
I'm working on it per level type and decided to start with the caverns.
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

Norbert wrote:I'll publish the first version of the new document I'm working on soon.
On second thought, I'm going to finish apoplexy 2.0 first.
By the way, Pr2LevEd is proving to be quite helpful for that task.
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

These two images appear to be the same:
- - - - -
<folder path="CAVERNS" file="CAVERNS.DAT" [...]
[...]
<item path="shap03557.bmp" value="3557" />
<item path="shap03558.bmp" value="3558" />
- - - - -
Not sure if that's valid.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

Yes, those two images are actually identical. This is not a bug in PR.
It's more like the author of the graphics made a mistake. (But, because the flame images are used in random order, nobody noticed this.)
It seems to me that the PoP2 caverns flames were made from the PoP1 flames.
The corresponding images are: 151->3555, 152->3553, 153->3554, 154->3556, 155->3557 and 3558, 156->3559, 157->3560, 158->none, 159->3561
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

There are problems with some of the WAV files that the 1.3.1 pre-release exports.
I ran into this while improving the WAV files that apoplexy uses; while removing the header ticks.
Below is a summary of my findings. See the suggestions at the bottom.

Image
(mirror)

By the way, 11,025 Hz is a pretty common sample rate, so maybe everything should be 11,025 Hz?
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

Chomper:
Looks like I already renamed chopper.wav to chomper.wav in my copy. The other would be something chopped -> chomped.

Footstep:
According to the unofficial debugger DOSBox (http://ykhwong.x-y.net/safe.php), that sound is actually played with 8264 Hz.
However, this is not the biggest difference.
According to the Spectrogram view of Audacity (see screenshot below), the version exported by PR goes up to only ~5 kHz. DOSBox's version goes above 10 kHz.
Indeed, DOSBox's version sounds a bit more high-pitched, while PR's version sounds as if it went through a low-pass filter.
The question is: from where does DOSBox get the high-pitch components?
Attachments
Spectrogram view of footstep sound
Spectrogram view of footstep sound
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

Level door opening:
* hangs:
I tried with the version of MPlayer that I have, but it didn't hang. (It's an old version, though: 1.0rc2-4.2.1, from 2007)
VLC (2.1.3), however writes an error message into its messages window: "main error: too low audio sample frequency (2750)".
* does not sound correctly:
Interestingly, the debugger DOSBox says the sound is played (by the game) with "freq 9345".
I think I know why.
According to the source of digiplay, the sample rate is given to Sound Blaster as: (*)

Code: Select all

	time_constant = 256 - 1000000 / freq;
	speakeron();
	writedsp(0x40);
	writedsp(time_constant);
That is, 2750 becomes 256 - 1000000 / 2750 ~= -107, which is truncated into a byte and becomes (256-107=) 149. (Integer overflow!)
Applying the reverse of the formula gives: 1000000 / (256 - 149) ~= 9345 Hz.
So this is not a PR bug, but a limitation of Sound Blaster (and a bug in the SB driver of PoP).

(*) For completeness, here is the same thing from the PoP disassembly:

Code: Select all

seg011:03B1                 mov     dx, 0Fh
seg011:03B4                 mov     ax, 4240h       ; 0F4240h = 1000000
seg011:03B7                 mov     cx, [bp+samplerate]
seg011:03BA                 div     cx              ; unsigned divide -> max. rate is 65535
seg011:03BC                 mov     cl, al
seg011:03BE                 neg     cl              ; -x = 256-x
seg011:03C0                 mov     dx, sound_blaster_port
seg011:03C4                 add     dl, 0Ch
seg011:03C7                 mov     al, 40h ; '@'
seg011:03C9                 call    wait_and_out_byte
seg011:03CC                 mov     al, cl
seg011:03CE                 call    wait_and_out_byte
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

Hm... there's an additional problem with the new WAV files (those without the header ticks), namely that - at least under Linux - they end up being just distorted noise inside apoplexy.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

Which sound and which version of SDL produces this problem?
That is, is this the already known resampling bug, or something different?
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

David wrote:Which sound and which version of SDL produces this problem?
That is, is this the already known resampling bug, or something different?
All WAV files exported with PR 1.3.1 pre-release, in apoplexy that uses SDL2, and with the workaround for SDL bug #2274 in place ((dlen * cvt.len_mult) + 1).
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Post by David »

I could reproduce this with "tile crashing.wav".

I inserted this line into PlaySound():

Code: Select all

printf("[DEBUG] cvt.len_cvt = %d\n", cvt.len_cvt);
And it displayed:

Code: Select all

[DEBUG] cvt.len_cvt = 99425
This is an odd number of bytes, which is wrong for 16-bit sound.

So this is the non-8-bit resampling bug that we already know: https://bugzilla.libsdl.org/show_bug.cgi?id=2389
By the way, it looks like (to me) that nobody is going to fix that, unless I do that.
Today I fixed the sdlgenaudiocvt.pl file in question, but it needs testing. After that I will post the fix in the bugzilla.
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: PR 1.3.1 pre-release

Post by Norbert »

David wrote:By the way, it looks like (to me) that nobody is going to fix that, unless I do that.
Unfortunately, it looks that way. Sam asked Ryan (Ryan C. Gordon; icculus) to look into it, in that bug thread, but Ryan has an endless stream of games to port to Linux, plus piles of bugs for things he ported in the past. He's very skilled at what he does, but he's just one person... Surely they'll be happy that you're looking into the bug. I know I am.
Post Reply