PR 1.3.1 pre-release

About PR usage and development, and about the POP format.

Moderator: English Moderator Team

David
The Prince of Persia
The Prince of Persia
Posts: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Postby David » October 27th, 2014, 1:07 pm

I wanted to check the sound differences mentioned in PoP1 DAT Differences, but I ran into an error in PR.
PR won't export the DIGISND*.DAT files of PoP 1.3. (Unless --raw is given.)
The headers of waves in those DAT files are different from PoP 1.0. Actually they use the same format as PoP2.
I could make PR autodetect the header format on exporting, but how to decide which header format should PR use on importing?

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 2935
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: PR 1.3.1 pre-release

Postby Norbert » October 27th, 2014, 6:50 pm

David wrote:[...], but how to decide which header format should PR use on importing?


An easy solution is to create one extra file for 1.3, and check for its existence during importing (access() function).
More difficult would be to always create a file that contains text that indicates which header to use.
Even more difficult would be to alter the WAV files to include a RIFF info tag named ICMT that indicates which header to use.
Another solution is to start the names of the WAV files with text (or a number) that indicates which header to use, e.g. cheader_drinking.wav (or 13_drinking.wav); a similar solution would be to do this with the directory names.

[Edit:]
Of course, if people change WAV files, you lose the RIFF info tags.
And you could check for the existence of a directory (or file) that's already only present in 1.3 (like Mt32snd1.dat/) instead of creating your own extra file, but that only works if a full export exists.
Another option is to always create one extra text file whose name indicates which header to use, and if none of those variants exist default to 1.0.

David
The Prince of Persia
The Prince of Persia
Posts: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Postby David » November 22nd, 2014, 2:08 pm

Today I added these:
- When exporting, autodetect wave type, and write it into a wavetype.txt in the export directory (that is mentioned after -e).
- When importing, read wave type from wavetype.txt, or if it does not exist, use the PoP version of the DAT file.
(Deciding the current PoP version is not straightforward!)

And here is the next thing to do: Some PoP2 waves are compressed. PR should also extract those.
The decompression algorithm is already known. (See the end of this post: viewtopic.php?f=70&t=3299 )
EDIT: Done.

User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 2935
Joined: April 9th, 2009, 10:58 pm
Contact:

Re: PR 1.3.1 pre-release

Postby Norbert » November 22nd, 2014, 8:56 pm

Maybe it's time for PR 1.3.1 to be released in the near future?
It has been in pre-release for almost a year. :)

David
The Prince of Persia
The Prince of Persia
Posts: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Postby David » November 23rd, 2014, 1:05 pm

You're right... :)
But there still are unfixed bugs and missing features.
Plus lots of /*commented-out code*/ with sometimes unclear meaning...

- Import errors usually say that "'filename.ext' has errors, skipped". It would be better to have separate messages for each error.

- Checksum bytes are not written when doing a partial import.
viewtopic.php?p=15013#p15013
In import.c, full and partial import are handled in different but similar functions. Maybe they could be merged?

- Add TXT4 decoding/encoding. (Again, the algorithm is known: viewtopic.php?f=70&t=3299 )
- Maybe also add STRL decoding/encoding. There is no compression here.
STRL stores a list of zero-terminated strings, and the strings may contain newlines. How should I convert these to a text file?
A possible solution is to use two newlines as separator.

- PR crashes if I give a directory name without a trailing backslash.
pr -e. dat10 --> Crash
pr -e. dat10/ --> Crash
pr -e. dat10\ --> Result: Expected DAT file, but a directory was given (-3)

David
The Prince of Persia
The Prince of Persia
Posts: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Postby David » November 27th, 2014, 11:59 am

http://www.popot.org/documentation.php?doc=ChangingPoP1Images wrote:Unfortunately, certain versions of PR incorrectly round up the color values 254 and 255 to 256 (which is outside the allowed 0-­255 range).

Fixed. PR will always round down RGB values.

Code: Select all

src/include/palette.h:
-   #define convert24to18(x) (unsigned char)((x+2)>>2);
+   #define convert24to18(x) (unsigned char)((x)>>2)
src/lib/object/palette/pop2_4bit.c:
-   #define convert24to18(x) (unsigned char)((x+2)>>2);


- Checksum bytes are not written when doing a partial import.

Fixed.

Code: Select all

src/lib/actions/import.c
-   mWriteFileInDatFileIgnoreChecksum(&res);
+   mWriteFileInDatFile(&res);


Also fixed: In a partial import, no conversion is done!

Code: Select all

src/lib/actions/import.c
newRes is not initialized!
+   newRes = res;
   o=readObject(repairFolders(vFileext),&newRes,&result);


- PR crashes if I give a directory name without a trailing backslash.

Fixed.
lib/layers/disk.c wanted to use the custom port of dirent ("direntwin.h"), but the Makefile didn't link dirent.o to the executable.
The standard library contains functions with the same names, but the dirent structure is different.

Code: Select all

lib/layers/disk.c
-   #include "direntwin.h"
+   #include <dirent.h>


A newly found bug:
- In a partial export, an image will have wrong colors if you don't export its palette.

lvcabral
Vizier
Vizier
Posts: 86
Joined: March 11th, 2016, 10:34 pm

Re: PR 1.3.1 pre-release

Postby lvcabral » July 23rd, 2016, 2:53 am

I'm not being able to extract "guard palettes.pal" file from Prince.DAT of some of the Mods, for instance 149 (SNES) 156 (Princess).

Any idea how can I get the colors for the guards in this case?

David
The Prince of Persia
The Prince of Persia
Posts: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Postby David » July 23rd, 2016, 12:45 pm

lvcabral wrote:I'm not being able to extract "guard palettes.pal" file from Prince.DAT of some of the Mods, for instance 149 (SNES) 156 (Princess).

Looks like another bug in PR.

For Princess of Persia:

Export PRINCE.DAT with the --raw option.
You'll see that guard palettes.pal is 768 (0x300) bytes but it should be only 336 (0x150) bytes.

The other problem is that it contains a byte with value 0x40.
(This is probably the result of incorrect rounding, which was fixed, I think.)
Now, PR verifies if all the palette's bytes fall into the 0x00..0x3F range, and won't export the palette if it's not the case.

Code: Select all

int isA64kPalette(tBinary c) {
   while (c.size--) if (c.data[c.size]>>6) return 0; /* false */
   return 1; /* true */
}


Workaround:
* Export PRINCE.DAT with the --raw option.
* Open guard palettes.pal in a hex editor.
* Delete the end of the file from offset 336 (0x150).
* Find that 0x40 byte and change it to 0x3F.
* You can close the hex editor.
* Import PRINCE.DAT with the --raw option.
* Now export it normally, i.e. without the --raw option.
* Now you should have a guard palettes.pal in the usual JASC-PAL format.

For SNES Remnants, the problem is similar, although there are many more out-of-range bytes.
(Why?)

I propose this patch for PR:

Code: Select all

+#if 0 /* "Princess of Persia" and "SNES Remnants" have bugged palettes. */
    if (!isA64kPalette(cont)) {
       *error=-14; /* TODO FIX or assign error code */
       return NULL;
    }
+#endif

lvcabral
Vizier
Vizier
Posts: 86
Joined: March 11th, 2016, 10:34 pm

Re: PR 1.3.1 pre-release

Postby lvcabral » July 23rd, 2016, 10:25 pm

Thank's again David!

I have developed a tool to convert the bmp files exported from PR into the png sprites format I use on my Roku port, it's working nice with most mods, except for these ones with bugged palettes.

lvcabral
Vizier
Vizier
Posts: 86
Joined: March 11th, 2016, 10:34 pm

Re: PR 1.3.1 pre-release

Postby lvcabral » July 23rd, 2016, 11:36 pm

David wrote:Workaround:
* Export PRINCE.DAT with the --raw option.
* Open guard palettes.pal in a hex editor.
* Delete the end of the file from offset 336 (0x150).
* Find that 0x40 byte and change it to 0x3F.
* You can close the hex editor.
* Import PRINCE.DAT with the --raw option.
* Now export it normally, i.e. without the --raw option.
* Now you should have a guard palettes.pal in the usual JASC-PAL format.


I did the workaround you proposed with the SNES (the author of "princess" had already sent me the original palette for his mod), and here what happened:

* The file was already with the right size 336 bytes, so no need to truncate it
* As you mentioned there was several bytes higher than 0x3F so I changed all of them to 0x3F
* After getting the JASC-PAL file I generated the sprites for Guards with it.
* Most of the colors were ok, only the guards 6 and 7 got the colors scrambled (see image below)
* It makes sense, because most of the higher bytes are at the bottom.
* Question: Does SDLPoP support mods ?

Image

David
The Prince of Persia
The Prince of Persia
Posts: 1327
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: PR 1.3.1 pre-release

Postby David » July 24th, 2016, 10:36 am

lvcabral wrote:* Question: Does SDLPoP support mods ?

Yes.
You can either copy *.DAT files to the main folder (where the EXE is), or you can change the files in the data/ folder.

lvcabral wrote:* As you mentioned there was several bytes higher than 0x3F so I changed all of them to 0x3F
* Most of the colors were ok, only the guards 6 and 7 got the colors scrambled (see image below)

In that case, you need to bitwise-and those bytes (or just all bytes) with 0x3F instead.

lvcabral
Vizier
Vizier
Posts: 86
Joined: March 11th, 2016, 10:34 pm

Re: PR 1.3.1 pre-release

Postby lvcabral » July 25th, 2016, 9:41 am

David wrote:In that case, you need to bitwise-and those bytes (or just all bytes) with 0x3F instead.


It worked, thanks again David!

Image


Return to “Princed Resources (PR)”

Who is online

Users browsing this forum: No registered users and 1 guest