Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sort Pokemon and trainer sprite palettes, with Makefile-specified exceptions #1137
base: master
Are you sure you want to change the base?
Sort Pokemon and trainer sprite palettes, with Makefile-specified exceptions #1137
Changes from all commits
5a9bfb4
f99f0e6
c0173db
4783fff
56f20b2
97f7888
900ce2d
4d462e9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please break up this line, and while I believe these numbers, do you have any source/explanation for them? I've never looked into this, and I would've just naïvely summed the colors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the standard conversion from RGB to Y (luminance), used by jpeg encoding and probably lots of other things.
I use the exact same coefficients here, for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What breakup do you have in mind? It's the same function I've used in a few Python helper scripts:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, actually I didn't notice at first that you are squaring each color component. That is not the standard luminance conversion used by jpeg etc. But it's probably the standard somewhere! I've just never seen it before. I'd be curious to hear the benefits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've used it for many years, quoting from some source that defined luminance as the sqrt of sum of squares (i.e. a Euclidean distance) but omitting the sqrt when it's unnecessary (e.g. for comparisons).
Google leads to https://stackoverflow.com/questions/596216/formula-to-determine-perceived-brightness-of-rgb-color leads to https://alienryderflex.com/hsp.html which looks familiar (and IMO based on the StackOverflow illustrations is the best choice of the given options).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the algorithm of
white + reversed?(colors) + black * (1 + (max_colors - num_colors))
would make this cleaner, something likeThis is less verbose and I like the option of expanding this for more colors/maybe gen3 in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this a lot harder to understand and grasp "when my input was such-and-such, what order will my colors be in?" I think the current verbose code is useful for being able to point users to it and show just how this new approach works.
Extending it to support 4bpp is a cool idea, but that would involve more rewriting than just this section, and it's a short enough file that I don't think we need to future-proof it like that already. (YAGNI; a gbapal.c tool will be its own thing, not much harder to write than this was.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did consider this, but it would be error-prone. Imagine a front sprite that uses one or two colors, and a back sprite using zero, just black+white. Each one gets gbapal.c run on it, so the back sprite now has two gray colors... and then generating normal.gbcpal fails because there are too many combined colors.