-
Notifications
You must be signed in to change notification settings - Fork 2
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
Limit color selection to what is supported by a target system. #73
Comments
I like this proposal. I'd like to add, how about presets for specific consoles and their resolutions as well? Not just limiting the colors, but also limiting the available space depending on if you want to build tiles or sprites. I think that could complement things nicely. P.D: Are you using the Neutral Dark theme? |
I think that for 8 and 16 bit, size limitations for tiles and sprites may not make much sense. Hardware sprites are very commonly grouped together to form larger objects onscreen, and tileset size tends to be entirely decoupled from tile mapping plane sizes. All of this depends too much on the game being developed, not just the target system. And yes, I'm using neutral dark theme :) |
Good theme you're using! I was thinking about resolution actually. Screen resolution, though since, as you said, this varies from hardware to hardware and the way they are being developed, this may not make a lot of sense. How would you handle the topic of the PC Engine though? That's a bit of a problematic console because its only "palette" so to speak comes from an RF signal. And variants on TV made it difficult to trace an "official" palette so to speak, see: https://pcengine.proboards.com/thread/979/improper-colors |
I didn't know much about the PC Engine so I had to read up on in. Perceptually there may be differences in color rendering by the composite video encoder. If it was important to simulate that in an art pipeline, there could be some sort of "tonemapping" when preparing the colors for display or when exporting. As I see it, this would be a separate feature from color selection. |
Yeah, I agree a tonemapping feature is a bit out there, probably an alternate proposal may be required for this. As I said, this proposal sounds rather interesting. It'd also help a lot those who are planning to do ROMhacks of old games as well too |
So, I am working on a Sega MegaDrive game. I always hated how I had to ensure my palette colors were at least close to what is representable by the system. Very often, I'd recompile all the resources only to realize that the color I had chosen came out too different to what was actually intended.
It came to me that maybe I could have LibreSprite help me, by either:
I ended up creating a hardcoded hack to do just that, for my purposes. And it turned out, for me, it works great! It's everything I hoped for and more. Here it is.
Since I had never seen the codebase before (which is amazingly organized and pretty clear to read, kudos to all) I didn't even consider trying to make this generic or an actual feature.
But it came to me, maybe this idea could be useful to a lot more people. To make this more generic, there could be a function that applies color limitations based on:
So, what do you think?
The text was updated successfully, but these errors were encountered: