Problems with palettes

[mulambo]

About my issue I've sprited a dog that has brighter / more intense red, but it shows darker and less intense red, as you see there's two different shades of red and I would like the dog to show its own palette (as I've customized the sprites palette to have those shades of red). I've tried to remap, etc... but nothing worked, maybe I coded it wrong or I don't know .... I've read the official manual, but I haven't managed to fix this problem properly 
Also the stage seems to have the same problem, the original sprite has less saturated colors, while in game it appears like... more orange or yellow
Is there a way for sprites to depend on their own palette, instead of depending on a fixed palette that seems to influence every sprite?

 

[Bloodbane]

I've checked the dog's palette and I'm surprised. How did exactly you made its palette? it has colors that it doesn't use (at least in idle frame)

I can't check stage's background palette from screenshot. I can only say not to use dithering

Can you post both dog's original image and stage's original background?

 

[mulambo]

about the dog sprite: it's the one I've already attached
about the bg: it's been fixed days ago so there is no problem anymore. about dithering: it's the only way to make the stage "fit" the colors of palette without having too flat shades (which look even worse)... otherwise it's just a stylistic choice (some may like it, some others don't :/ )
well, yeah, this palette thing is probably the more frustrating problem for me as I don't know everytime what is wrong with things. I have not clearly understood how palettes work in OpenBOR
both in GIMP and PaintShopPro the palette looks with the right colors, but in game they switch to a palette I don't where the engine takes it from.. and I don't know exactly why and how the engine remaps the sprites to it. It's like working with a useless limitation over and over... really frustrating.  :-\

 

[O Ilusionista]

I have not clearly understood how palettes work in OpenBOR

They work exactly on the same way they work in Mugen. You can even use .act if you want to.

I don't know exactly why and how the engine remaps the sprites to it. It's like working with a useless limitation over and over.

Probably you are trying to use REMAP instead of ALTERNATEPAL. Remap is a pretty old function which comes from the very early days of BOR (not OpenBOR), in 8bits.
It's a very old method and ALTERNATEPAL is way easier to work with - I never used remap, for example. We had an discussion about removing it from the engine last year, but we let it thanks to backward compatibility.

My advice is: forget about REMAP and use ALTERNATEPAL. The instructions are on the manual.

Can I be honest with you? I do not even want to start a discussion or have an interest in it, but I see some wrong behavior that some users insist they have and then complain that they are ignored when they ask for help: Blame the engine for their own errors.

Instead of blaming the engine, users should read the manual, because a lot (I believe 95%) is documented there - and I say that because I am one of those responsible for updating it. If you have any questions, just ask here in the forum.  There may be errors in the engine. But when that happens, such errors should be reported on GitHub - and developers will take a look at it.

But putting the blame on the engine, without the person knowing what he is talking about, is a very badly seen behavior here. And these users end up being ignored by most other users - including the official team.

Please, don't do this.

 

[mulambo]

I can't say if it's the same of MUGEN. MUGEN only requires 256 colors images which sometimes are linked to char's palettes declared in the DEF file (and such sprites are normally depending on the palette), but some other times there's free palette system (example: explods can have "ownpal" and screenpacks/stages sprites can rely to their own palette too)...
I've just not understood how palettes are linked to sprites in OpenBOR, I asked for clarification here, not "blamed" the engine actually. Or did I unvoluntarily ? 
I tried adding custom sprites, but they show with artifacts (white pixels or stuff like that) so I'm forced to load the palette of a working sprite on any new sprite then correct the artifacts as they show. I haven't clearly understood why :/

 

[O Ilusionista]

Or did I unvoluntarily ?

You did it involuntarily on this topic and other topics. But let's move on.

I can't say if it's the same of MUGEN. MUGEN only requires 256 colors images which sometimes are linked to char's palettes declared in the DEF file (and such sprites are normally depending on the palette), but some other times there's free palette system (example: explods can have "ownpal" and screenpacks/stages sprites can rely to their own palette too)...

Now I understand your confusion: the palettes doesn't work the way you think they work even in Mugen. There are many error on that sentence, let me clarify:

"MUGEN only requires 256 colors images which sometimes are linked to char's palettes declared in the DEF file"
They aren't sometimes linked - unless you use PNG24bits, they are ALWAYS linked to a palette. When you import an image to the sff, unless its a 24bit png, it will create a new index for that palette.

In SFF1, you have an option to use Shared palette images and non-shared palettes (they need to be after the shared ones). But they always have a palette.
In SFF2, this isn't true anymore, you just need to check if the image uses the same palette, or it will create a different index.

Which led us to the next point
explods can have "ownpal"
This is not true at all. OWNPAL is for palfx, which means the explod or projectile won't be affected by palfx/allpalfx, as the Mugen manual says

ownpal = bvalue (boolean)
Set ownpal = 1 to give the explod its own copy of its palette. This is desirable if you want to keep temporary changes to the player's palette (e.g. from using the PalFX controller) from affecting the color of the explod. Defaults to 0 if omitted.

This doesn't mean the explode/projectile will have a different and unique palette. You have to use remap for it (and it was added only in Mugen 1.1 if I am not wrong).

Now about this

I've just not understood how palettes are linked to sprites in OpenBOR

It works like this:
Whenever you load an sprite in OpenBOR, unless its a PNG24 (which works in some cases), it will load the palette the image have (because it have one).
It will do it for every image you load. Once an image was loaded with a palette, even if you use PALETTE NONE (something you should use only in specific cases), the image will be shown using the palette it was loaded with.

So, you set a palette using the PALETTE command
palette path/to/palette (which can be .gif, .pcx, .png, .act)

And it will be show using that palette, even if the image has a different one. The color index on the color table needs to be same (like in Mugen).
To use a different palette, you can use ALTERNATEPAL for it. Works on the same way.

I tried my best to explain it.

 

[mulambo]

sorry O Ilusionista, I know you're trying the best to explain the palette thing to me, it just takes some time to understand, or I'll probably just adapt my sprites to the current palette and just fix them if any problem shows.
About the explod (this is offtopic, just saying to clarify it first), actually I was right: http://www.elecbyte.com/mugendocs/sctrls.html#explod (you can see "ownpal" in there, when you use " ownpal = 1 " the engine uses the same sprite's palette, doesn't link the sprite's index to the char's active palette... but again this is offtopic, it's just to clarify that I say the truth, check the "Explod" tab, you'll see the "ownpal" parameter.). My English may be not perfect, but I don't say lies... and I don't enjoy polemics at all. It's sad that everytime I say something, offtopic arguments appear, threads go hijacked or somebody gets upset for something I'm not aware of. Once, again, I'm speechless and I don't know what to do.

Anyway I realize I got to understand it on my own, until I got it right...currently I'm not in the mood or have no energy to "challenge" the palette system,  thanks anyone anyway, I'll read it when I'll have the right focus and see if I can manage to accomplish what I want ... for now I'll just adapt the sprites to the palette and... whatever, it's ok anyway, even if the colors are not exactly what I expect. I'll move on

 

[O Ilusionista]

Its quite offtopic, really, but I need to explain it to avoid wrong information to be spread.

About the explod (this is offtopic, just saying to clarify it first), actually I was right:

errr no, read it again:

ownpal = bvalue (boolean)
Set ownpal = 1 to give the explod its own copy of its palette. This is desirable if you want to keep temporary changes to the player's palette (e.g. from using the PalFX controller) from affecting the color of the explod. Defaults to 0 if omitted.

Ownpal is, EXCLUSIVELY, to bypass the effects of palFX / allpalFX in Mugen, and not to change its palette or assign a new one until Mugen 1.1
This is the REMAP function work, which was implemented for Explods and Projectiles just in 1.1, take a look:

http://www.elecbyte.com/mugendocs-11b1/sctrls.html#explod

ownpal = ownpal_flag (int)
If ownpal_flag is 0, the explod color will be affected by subsequent execution of the player's PalFX and RemapPal controllers. This is normally the default.

If ownpal_flag is 1, the explod color will not be affected by subsequent execution of the player's PalFX and RemapPal controllers. This is the default if the anim is from fightfx.air.

remappal = dst_pal_grp, dst_pal_item (int, int)
Forces a palette remap of the explod's indexed-color sprites to the specified palette. This parameter is used only if ownpal_flag is non-zero and a fight.def anim is not used. If dst_pal_grp is -1, this parameter will be ignored. Defaults to -1, 0.

 

[mulambo]

I don't know, dude, honestly we're dragging this far too long, I guess it's become a useless confrontation.    :-\
If there are any further misunderstandings due to language or lack of accuracy (to an extreme point I'm not interested in), I think this has become another "NO U" argument and I don't know if this is legit or not.... or useful for both of us.  :-\

I consider the problem/topic solved, don't know what to think about anything else that showed up in the topic (beside the main one).