PR 1.3.1 pre-release
Re: PR 1.3.1 pre-release
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?
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?
Re: PR 1.3.1 pre-release
An easy solution is to create one extra file for 1.3, and check for its existence during importing (access() function).David wrote:[...], but how to decide which header format should PR use on importing?
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.
Re: PR 1.3.1 pre-release
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.
- 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.
Re: PR 1.3.1 pre-release
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.
It has been in pre-release for almost a year.
Re: PR 1.3.1 pre-release
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)
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)
Re: PR 1.3.1 pre-release
Fixed. PR will always round down RGB values.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).
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);
Fixed.- Checksum bytes are not written when doing a partial import.
Code: Select all
src/lib/actions/import.c
- mWriteFileInDatFileIgnoreChecksum(&res);
+ mWriteFileInDatFile(&res);
Code: Select all
src/lib/actions/import.c
newRes is not initialized!
+ newRes = res;
o=readObject(repairFolders(vFileext),&newRes,&result);
Fixed.- PR crashes if I give a directory name without a trailing backslash.
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>
- In a partial export, an image will have wrong colors if you don't export its palette.
Re: PR 1.3.1 pre-release
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?
Any idea how can I get the colors for the guards in this case?
Re: PR 1.3.1 pre-release
Looks like another bug in PR.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).
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 */
}
* 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
Re: PR 1.3.1 pre-release
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.
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.
Re: PR 1.3.1 pre-release
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: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.
* 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 ?
Re: PR 1.3.1 pre-release
Yes.lvcabral wrote:* Question: Does SDLPoP support mods ?
You can either copy *.DAT files to the main folder (where the EXE is), or you can change the files in the data/ folder.
In that case, you need to bitwise-and those bytes (or just all bytes) with 0x3F instead.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)
Re: PR 1.3.1 pre-release
It worked, thanks again David!David wrote:In that case, you need to bitwise-and those bytes (or just all bytes) with 0x3F instead.
Re: PR 1.3.1 pre-release
I don't know if my previous rename suggestions in this thread have been implemented (didn't check (yet)), but here are a couple more issues I found with resources.xml.
The first is just for consistency/clarification:
- - - - -
It has
<item value="236" path="closer base.bmp"/>
and
<item value="236" path="closer base pressed.bmp"/>
Maybe change one of those to match the other.
- - - - -
The second is a fix:
- - - - -
From
<item value="235" path="opener left unpressed02.bmp"/>
to
<item value="235" path="closer right pressed.bmp"/>
- - - - -
I was also thinking about adding this to the vpalace floor panels, but apparently it doesn't exist:
<item value="348" path="opener left unpressed02.bmp"/>
The first is just for consistency/clarification:
- - - - -
It has
<item value="236" path="closer base.bmp"/>
and
<item value="236" path="closer base pressed.bmp"/>
Maybe change one of those to match the other.
- - - - -
The second is a fix:
- - - - -
From
<item value="235" path="opener left unpressed02.bmp"/>
to
<item value="235" path="closer right pressed.bmp"/>
- - - - -
I was also thinking about adding this to the vpalace floor panels, but apparently it doesn't exist:
<item value="348" path="opener left unpressed02.bmp"/>
Re: PR 1.3.1 pre-release
I have done the first two: https://github.com/NagyD/PR/commit/febd ... 362d7a4429Norbert wrote: I don't know if my previous rename suggestions in this thread have been implemented (didn't check (yet)), but here are a couple more issues I found with resources.xml.
For the first, I chose to always include whether the button (floor panel) is pressed.
That is used only in the dungeon: https://github.com/NagyD/SDLPoP/blob/ma ... 008.c#L586Norbert wrote: I was also thinking about adding this to the vpalace floor panels, but apparently it doesn't exist:
<item value="348" path="opener left unpressed02.bmp"/>
The dungeon graphic set has two images for the left half of an unpressed opener button, the palace has only one.
Re: PR 1.3.1 pre-release
Perhaps Mechner didn't like the dotted line for the palace raise button in any of the available colors.
I think none of the options look as good as what the color-combo looks like in the dungeon.
I think none of the options look as good as what the color-combo looks like in the dungeon.