Hello
I am having a big problem here.
first, I am really beginner and changing colors is a really problems and I can't find some solutions.
second, When I try to change some pal files and recolor some picture even with the old colors pr skips that and don't pack them again.
third, I am having this weird problem with Prince.dat file this happens every time I try even with exporting and importing the original POP1 file without any changes.
Prince.dat
Prince.dat
Check out my first ever mod and rate it it is Journey in Mystery I hope I will improve next time, thank you
Re: Prince.dat
My guess is that the image gets saved as RGB instead of indexed, but PR can import only indexed images.
Could you post one of those edited images here?
Also, what program do you use to edit the images?
Are you using PRINCE.DAT from PoP 1.0?
It does not contain those two resources, "res65535.bin" and "level color variations.pal".
So PR can't import them, but that's not a problem.
Re: Prince.dat
I am not able to post them it says invalid extention .bmp but
I use GIMP as Norbert told me before and I edited all the palace and dungeon the same way I just recolor the pictures with the index colors without changes and here is the only place I find this error as well as SKEL.DAT but what is suprising me in these potions that the small ones work perfectly and both big are no accepted and even trying to reopen them wih GIMP he tells me invalid format even when I just take the old picture recolor and overwrite it
yes I am but now I took the dat file from 1.4 thank you for that
Check out my first ever mod and rate it it is Journey in Mystery I hope I will improve next time, thank you
Re: Prince.dat
These BMPs contain color space information.Sting wrote: ↑November 11th, 2020, 5:57 pm I am not able to post them it says invalid extention .bmp but
base.rar
I use GIMP as Norbert told me before and I edited all the palace and dungeon the same way I just recolor the pictures with the index colors without changes and here is the only place I find this error as well as SKEL.DAT but what is suprising me in these potions that the small ones work perfectly and both big are no accepted and even trying to reopen them wih GIMP he tells me invalid format even when I just take the old picture recolor and overwrite it
When you save a BMP from GIMP, you need to enable the "Do not write color space information" option: viewtopic.php?p=13697#p13697
To fix these BMPs, assuming you're on Windows, just open them in MS Paint and save them without any changes.
This will remove the color space information from them.
By the way, back in 2013, GIMP had a bug, it opened indexed BMPs with color space information as RGB images.
In GIMP 2.10.18 (or earlier) it was fixed, GIMP could open BMPs with color space information and you could resave them without it.
However, GIMP 2.10.22 (latest version) saves BMPs with color space information in a different format which it cannot read back at all!?
This might be related: https://gitlab.gnome.org/GNOME/gimp/-/issues/4155
Re: Prince.dat
Ok this is working right now I will search how to fix settings in GIMPDavid wrote: ↑November 14th, 2020, 7:52 pm
These BMPs contain color space information.
When you save a BMP from GIMP, you need to enable the "Do not write color space information" option: viewtopic.php?p=13697#p13697
To fix these BMPs, assuming you're on Windows, just open them in MS Paint and save them without any changes.
This will remove the color space information from them.
Yhank you.David wrote: ↑November 14th, 2020, 7:52 pm
By the way, back in 2013, GIMP had a bug, it opened indexed BMPs with color space information as RGB images.
In GIMP 2.10.18 (or earlier) it was fixed, GIMP could open BMPs with color space information and you could resave them without it.
However, GIMP 2.10.22 (latest version) saves BMPs with color space information in a different format which it cannot read back at all!?
This might be related: https://gitlab.gnome.org/GNOME/gimp/-/issues/4155
By the way sir David I tried to use that data directory in SDLPoP to make some changes but I didn't know how to open .pal files usually I open that with bloc note and edit them but those appearing in SDLPoP are showing me things like this: ?? ?! ????:,?5&>.,*** >.?5&?:,8ú\8ú\8ú\8ú\ÁÿxÝý‡÷ÁÿxÝý‡÷ÁÿxÝý‡÷ÁÿxÝý‡÷
Check out my first ever mod and rate it it is Journey in Mystery I hope I will improve next time, thank you
Re: Prince.dat
They are in a PoP-specific format, the same format as in the DAT files. (See also here.)Sting wrote: ↑November 14th, 2020, 10:50 pm By the way sir David I tried to use that data directory in SDLPoP to make some changes but I didn't know how to open .pal files usually I open that with bloc note and edit them but those appearing in SDLPoP are showing me things like this: ?? ?! ????:,?5&>.,*** >.?5&?:,8ú\8ú\8ú\8ú\ÁÿxÝý‡÷ÁÿxÝý‡÷ÁÿxÝý‡÷ÁÿxÝý‡÷
You don't need to edit SDLPoP's palettes, as SDLPoP uses the palette within the images.
Re: Prince.dat
It turns out the reason PR and GIMP reject those files is not the size of the header, but the compression method field (offset 0x1E).David wrote: ↑November 14th, 2020, 7:52 pm By the way, back in 2013, GIMP had a bug, it opened indexed BMPs with color space information as RGB images.
In GIMP 2.10.18 (or earlier) it was fixed, GIMP could open BMPs with color space information and you could resave them without it.
However, GIMP 2.10.22 (latest version) saves BMPs with color space information in a different format which it cannot read back at all!?
This might be related: https://gitlab.gnome.org/GNOME/gimp/-/issues/4155
Looking at GIMP's error message again, it indeed says "Unrecognized or invalid BMP compression format.".
This field should be 0 for non-compressed BMPs.
But in the files saved by GIMP 2.10.22 with color space info, it's 3.
According to Wikipedia, compression method 3 means BI_BITFIELDS, which means RGBA in a BMP with header V3 or later (these files use V5).
I have no idea why is an indexed image marked as RGBA. Maybe its palette has alpha channel?
MSDN says something else, that BI_BITFIELDS means "the color masks for the red, green, and blue components of each pixel are specified" and "is valid when used with 16- and 32-bpp bitmaps.".
The masks are indeed specified in these BMP files at offsets 0x36..0x45, but they make no sense in a paletted bitmap.
So setting the compression method to 3 might be a bug in GIMP.
Anyway, here is my fix for PR: https://github.com/NagyD/PR/commit/8b51 ... 4f2b4be06f
I should make a compiled release someday...