Wouldn't the better option be that you can specify a user defined palate? What happens when someone wants to use it with some other remap colour.

I did think of that, but I didn't think of an elegant way to add it to the sprite entry of a sprite list manifest.

You could just provide a 1x256 bitmap of your colours. I think that would work.

that is a good idea

I have to agree with @duncanspumpkin I don't think this is practical doing it this way, user defined palettes would avoid adding code for every specific case.

We also have an option to use the raw indices that are stored in .png file. This is faster and would allow you to use any colour, because the game would only use the raw byte index for each pixel rather than using a colour lookup table.

I know that, but the tools to create 8-bit images elude me, and this was the easiest option.

Wouldn't the better option be that you can specify a user defined palate? What happens when someone wants to use it with some other remap colour.

I should point out that every other tool in existence uses green as the primary remap instead of orange. As such, I think building it in makes more sense in this case.

Since I’m not a fan of adding another parameter for the green remap, I have done a refactor which should make it easy. See here: #16601

After that one is merged, this PR should be updated to use it. Additionally, since palette: keep and this are mutually exclusive, the green palette should be triggered by palette: green, IMO.

Wouldn't the better option be that you can specify a user defined palate? What happens when someone wants to use it with some other remap colour.

I should point out that every other tool in existence uses green as the primary remap instead of orange. As such, I think building it in makes more sense in this case.

As that is not true that is the reason why i suggested having the ability to provide any palette.

As that is not true that is the reason why i suggested having the ability to provide any palette.

Ok, can you name a tool that doesn’t use green for primary remap? The Object Editor, Trigger’s tools and the RCT2 GUI Editor all use that palette.

As that is not true that is the reason why i suggested having the ability to provide any palette.

Ok, can you name a tool that doesn’t use green for primary remap? The Object Editor, Trigger’s tools and the RCT2 GUI Editor all use that palette.

Landmark editor uses an alternative palette. I vaguely recall one other, but I don't remember its name or what it did.

I'm looking to suggestions on making the command line parsing less bad, as well as setting the actual data of each PaletteBGRA. And open to suggestions on removing the new header file. I added it because I added the palette as an optional parameter which has to be declared above the function declaration, and I didn't know how to do that without moving the declaration 256 lines of data above the declaration or moving them into a header.

As that is not true that is the reason why i suggested having the ability to provide any palette.

Ok, can you name a tool that doesn’t use green for primary remap? The Object Editor, Trigger’s tools and the RCT2 GUI Editor all use that palette.

Landmark editor uses an alternative palette. I vaguely recall one other, but I don't remember its name or what it did.

Do you have a link? I tried Googling, but didn’t see anything that looked like a RCT sprite editor/exporter.

Do you have a link? I tried Googling, but didn’t see anything that looked like a RCT sprite editor/exporter.

https://www.nedesigns.com/index.php?app=core&module=attach&section=attach&attach_id=25880

From the NEDesigns website. IIRC there are two links, one of them worked when I tried it and one of them didn't. I don't remember where the other link is.

I found an issue with the example palettes, the 0th pixel is 255 255 255 255 instead of 0 0 0 0. I'm not in a position to fix it right now, so if there's any danger of this PR being merged in the next several hours, please hold back until they are fixed.

I found an issue with the example palettes, the 0th pixel is 255 255 255 255 instead of 0 0 0 0. I'm not in a position to fix it right now, so if there's any danger of this PR being merged in the next several hours, please hold back until they are fixed.

This issue has been resolved. I think the PR is ready for review, less any suggestions regarding what I asked about earlier.

I have been thinking about OpenRCT2's palette collisions with sparkling water and I wanted to see if any tools do not have palette collisions. It appears none of the tools avoid palette collisions, I think because no scenery actually uses all of the animated water colors.

I've written more of my findings here: #16611

As far as the effect on this PR, since there is no standard on which to base these colors on, I think this PR is an opportunity to create a new standard for animated water pixels and apply it to both the RCT2 and OpenRCT2 palette.

I do not have a plugin that uses custom images to test against.

@spacek531

• https://github.com/OpenRCT2/title-sequence-editor/releases/tag/v1.2
• https://github.com/OpenRCT2/OpenRCT2/files/8346277/image-api-demo.zip

The image api demo works fine in this branch. Please can this be merged before any other changes are made?

The image api demo works fine in this branch. Please can this be merged before any other changes are made?

Before which other changes?

Any others that affect image import code that I have to work around and require another review and delay things further until the next change that affects image import code that I have to work around and require another review that delay things further and so on.

I've tested all the functionality and I am happy with it. Is there anything else left before this PR can get merged?

Is this PR now defunct since libsawyer is being created? I wish there was better communication.

@IntelOrca ?

These changes can be ported now to gxc in libsawyer.
I guess there is an argument for this still existing in object and plugin, but it looks like we are heading more into embedding GX files now for best performance.

It feels like I'm missing something critical in libsawer... I've poked around but I have yet to find where the sprite functions are actually used.

It feels like I'm missing something critical in libsawer... I've poked around but I have yet to find where the sprite functions are actually used.

I am not sure what you are looking for.

Here's two color table files for the palette index. OpenRCT2 is default gxc, OpenRCT2 green is the green palette used here. You can easily convert between the two by just swapping the index.

Palette color tables

This pull request has been marked as stale and will be closed in 14 days if no action is taken. To keep it open, leave a comment or remove the stale-pr label. If you're awaiting feedback from a developer, please send us a reminder (either here or on Discord).

Keep this open please.

This pull request has been marked as stale and will be closed in 14 days if no action is taken. To keep it open, leave a comment or remove the stale-pr label. If you're awaiting feedback from a developer, please send us a reminder (either here or on Discord).

Keep this open please.

This pull request has been marked as stale and will be closed in 14 days if no action is taken. To keep it open, leave a comment or remove the stale-pr label. If you're awaiting feedback from a developer, please send us a reminder (either here or on Discord).

This pull request has been closed due to inactivity. If you want to continue with this, or are awaiting a review, don't hesitate to reach out to a developer. We'll gladly re-open this PR! You can tag us here, or send us a message on Discord.