Author Topic: Correct PCE color values?  (Read 1068 times)

Black Tiger

  • Hero Member
  • *****
  • Posts: 11242
Correct PCE color values?
« on: October 26, 2016, 07:22:21 AM »
Has anyone ever figured out more or less what the exact RGB color values are for PC Engine?

Everything I've read says that they're "close enough" to values of 36, but after seeing how far off Genesis shades get on the lower and upper end, I'd love to know if PCE shades aren't consistent either.
http://www.superpcenginegrafx.net/forum

Active and drama free PC Engine forum

Gredler

  • Guest
Re: Correct PCE color values?
« Reply #1 on: October 26, 2016, 07:53:41 AM »
If they are divisible by 36 it should show up in game exactly the same, is what Rover told me a while back. The value range per channel is 36, 72, 108, 144, 180, 216, 252.


This is handy when trying to go up or down a shade of a specific color (so 36, 0 0 for darkest red, then 72, 0, 0 for brighter red, and 72, 36, 36 for even brighter red that is slightly less saturated)


Edit: here is an image Paul had up on the free forums chat site, it was a dead link but I just put it up on imgur, and if it's a problem having it up I will take it down.


The color of the font for the numerical value represents the channel of that color [RGB]


« Last Edit: October 26, 2016, 08:41:05 AM by Gredler »

ccovell

  • Hero Member
  • *****
  • Posts: 2245
Re: Correct PCE color values?
« Reply #2 on: October 26, 2016, 12:13:27 PM »
The correct interval between RGB shades should be (255/7),  or 36.42857.

However, if you look at the PCE through composite video, the colours will ramp up differently anyway due to its kinda weird digital composite encoder

Black Tiger

  • Hero Member
  • *****
  • Posts: 11242
Re: Correct PCE color values?
« Reply #3 on: October 26, 2016, 02:17:25 PM »
Gredler: I'm comfortable working with values of 36 and don't sample palettes like that anymore, but here's the one I found most useful, which Tom put together a long time ago:









I try to push uneven values to get subtler shades or more interesting coloring. Like upping an RGB value which is at 0 during a gradient asap and twisting an overall color into different directions. Something like starting blue and quickly turning from purples to mostly "hot" reds can looking much nicer than steady straight jumps in each value of a particular red. (I also try to avoid using pure black or pure white).

A good example is the marble base in the hallway scene of Henshin Engine. The similar part in SotN is a boring monochromatic gradient of brown-grays. In Henshin Engine, it goes from black to blue to purple to gray, until finally beginning the true beige palette. It may be working around the limits of 9-bit color, but doing so can still look much nicer than a lot of the unimaginative stuff devs bitd did while having unlimited shades to choose from on other hardware.

It's gotten to the point now, where I don't waste time thinking through exactly how I'll color something before pixelling it out. Now I usually just pick any old color and do a boring straight gradient until it's more or less finished being sculpted. Then I begin playing with the values of each shade to try to do something interesting and if I get enough room from subtler shades, I add in extras if I can, while keeping the scene balanced.

Sometimes tossing in a color which breaks the existing transitioning or even clashes with the rest can make something look or work much nicer.







In this scene I was trying to use as few tiles as possible and it was tough balancing the color of the building texture so that it worked for for the distinct parts and not having too sharp of contrast, so that it wouldn't stand out more than the layer which goes in front of it. It only sort of clicked into place finally when I tweaked a few colors near the dark and light ends so that they clashed with what look like the purple shades. It kept the shading subtle enough to work and the clashing works as texturing, while blending well with the overall background scene, which uses sort of parallel colors. The thing is, if you sample the pink and peach looking colors on the building, they're actually fairly normal looking purples. It just creates an illusion which works much better than colors that technically blend smoothly.

The roof tile does the pixelart equivalent of this. Since I couldn't get any kind of shingle pattern to tile correctly in a 16 x 16 pixel swatch, I purposely broke the pattern and shaded parts of it darker in a way which created the diagonal striping. At a glance it looks fine, but up close you can see that it has those alternate shades in each stripe every 16 pixels, technically creating a horizontal seam. It was the only way to differentiate the shingles in those spots, otherwise there'd be a splotch of the same color. If I had added another shade, then it would look too dark or light on one end.

I've started getting better results pushing the 9-bit palette by trying things like this which seem counter intuitive, but only after I stopped sampling everything from that palette sheet and started playing with values. Porting graphics from other hardware to PCE color for fun in my spare time is what helped me the most. I purposely looked for stuff which should be impossible to pull off in 9-bit color. It also helped me get a feel for balancing the overall contrast and making certain elements stand out more or less, depending on their role in a scene.





The correct interval between RGB shades should be (255/7),  or 36.42857.

However, if you look at the PCE through composite video, the colours will ramp up differently anyway due to its kinda weird digital composite encoder


Thanks a lot. :) I figured that it was consistent and I was hoping that Tom's comments about what the colors really look like was more based on what stock hardware ends up outputting.

The Genesis' shades don't get too dark or bright on either end, while the middle is closer to PCE integers. I had trouble matching some of the funkier looking colors for a project and was surprised how some of the shades of certain colors look more like SMS coloring.
http://www.superpcenginegrafx.net/forum

Active and drama free PC Engine forum

Gredler

  • Guest
Re: Correct PCE color values?
« Reply #4 on: October 26, 2016, 06:37:13 PM »
Yeah when I first started I was mostly using pauls palettes, and picking from there, but every since I learned the /36 rule (~36.429 - thanks Chris!) I abandoned the palette apart from looking at how various colors blend into each other for shading.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Correct PCE color values?
« Reply #5 on: October 27, 2016, 03:55:02 AM »
I've noticed a handful of PCE games uses colors that align with the digital artifact/stepping of the PCE's digital rgb->composite conversion. I mostly noticed this in cool blues, greys, and cool purples - where they all within range and blend much better on the real system that using RGB mod on the real system (or svideo mods, which are just RGB to an encoder). But there is one shade of blue that is nearly indistinguishable from its nearest counter parts in RGB, but stands out on PCE composite. I notice this because Rayforce used this color. Matter of fact, all of Rayforce graphics in their PCE games (SO2, Star Breaker, etc) tend to look better on PCE internal digital composite conversion than in plain RGB format.

Gredler

  • Guest
Re: Correct PCE color values?
« Reply #6 on: October 27, 2016, 04:46:36 AM »
I am not sure if it was the rendering engines, but ps3 had a hard time displaying reds and a lesser extent blues, and wii has a horrible time with reds. We often would tint colors towards green on pc to get a true red on wii. Nintendos games looked decently, but the games we worked on had bleeding and banding with reds if we went to a harsh red tint. Quirky systems ;P

I haven't noticed any artifcating with my duo r, I haven't tried my tg16 with custom software, but it might be a fun experiment. My duo r is usually hooked up with RCA and turbokon modded it a while back. My turbo from childhood never got s booster so it's just RF, but I'm getting curiousor and curiousor ;p
« Last Edit: October 27, 2016, 12:05:36 PM by Gredler »

ccovell

  • Hero Member
  • *****
  • Posts: 2245
Re: Correct PCE color values?
« Reply #7 on: October 27, 2016, 11:01:41 AM »
I haven't noticed any aeridacrinf...

... is this Welsh?

Gredler

  • Guest
Re: Correct PCE color values?
« Reply #8 on: October 27, 2016, 12:07:23 PM »
I haven't noticed any aeridacrinf...

... is this Welsh?

:) Should always proofreed my mobile posts, sorry! That should read as "artifacting" as in color inconsistency between what I attempt on pc and what shows up on pce.

Tv to TV and monitor to monitor you'll be hard pressed to get the same exact color twice, but generally it's the same.

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Correct PCE color values?
« Reply #9 on: October 27, 2016, 01:32:48 PM »
If you want to see the artifacting most clearly, run Ccovell's black and white demos, where they show a lot more grey shades than the typical 3bit R/G/B eight grey shades. Some of his grey scale shades can be attributed to chroma cross talk (even with the phase filter), but IIRC there are genuinely 32 distinct levels of grey (or Y stepping values) in the composite signal. It won't show you the color differences, but it'll show you proof they RGB to composite has unique 'stepping' in the YUV components (which U and V are modulated and combined together to form C, but this is done outside of the VCE).

The artifacting is in the stepping of the Y and the U/V values. There DACs are only 5bit each to create each channel and that's not enough precision to convert from 3bit channel R/G/B (you need something like 7-8bit channel on the Y/U/V receiving side).  The digital conversion is done as in internal rom translation table (it's precalculated). The patents only show the first few and last entries, but you can see that it has very specific rounding errors. I wrote a program that created an RGB map (for use with mednafen) of the internal VCE rom conversion that seemed to match the Y stepping, but I didn't have a way test U/V scaling/stepping.

 I forget the RGB value, but here's the color blue that I was talking about: (click to enlarge)


 That's recorded from my capture card (also verified from the SDTV). While TVs setting, and even monitors vary from set to set, off tint, red-push (which tint control doesn't fix), incorrect grayscale, etc, the difference is still relative inside the video signal itself. Play the game on an emulator and look for that color (or RGB modded system), and that color will almost be invisible.

I also found that the PCE composite signal is slightly deficient in red side of things (on a calibated TV), or rather it's slightly on the cool side of things for the whole range, but almost all crt TV sets of that era had "red-push" to make flesh tones more warmer - so it's not really noticeable on an uncalibrated set.

« Last Edit: October 27, 2016, 01:41:17 PM by Bonknuts »

elmer

  • Hero Member
  • *****
  • Posts: 2153
Re: Correct PCE color values?
« Reply #10 on: October 27, 2016, 02:20:47 PM »
This is all cool stuff to read about, thanks guys!  8)

Phase

  • Sr. Member
  • ****
  • Posts: 356
Re: Correct PCE color values?
« Reply #11 on: March 18, 2017, 04:09:26 PM »
I've updated Paul's palette sheet Gredler posted.

http://www.ektophase.com/TG16/PCEPalette_v2.png
Dark Version http://www.ektophase.com/TG16/PCEPaletteD_v2.png

So whats changed?
The image now only contains 512 colors, no anti aliasing text or absolute whites
Fixed one of the swatches that was incorrect I think it was 180 72 216 in the second row
Got rid of the duplicate color clusters
Rearranged and made the image smaller
Made a dark version

Also I made a swatch file for Photoshop

http://www.ektophase.com/TG16/PCEPalette_PsSwatches.zip
Go to your Photoshop folder then /Presets/Color Swatches. paste the .aco file

Let me know if there are any problems.

I noticed Ps can be a bit picky when you manually use the color slider, fill something than sample it again. it will alter the color numbers slightly( example 72 36 0) will change to 73 37 or something. I think this only happens in the default 8bit (rgb) mode and appears to not happen if you switch to 16bit or over to indexed. Anyone else have this problem?

Gredler

  • Guest
Re: Correct PCE color values?
« Reply #12 on: March 18, 2017, 08:10:19 PM »
Thanks for the swatches!

nodtveidt

  • Guest
Re: Correct PCE color values?
« Reply #13 on: March 19, 2017, 02:32:06 AM »
We use steps of 36 because it's "close enough". It would be closer to use 36.43 stepping, but I've never had a problem with the toolchain correctly converting colors in steps of 36 so I just stick with it. If you want to be dead-on, a closer list would be:

0 36 73 109 146 182 219 255

but these would be converted the same as doing steps of 36.

EDIT: One thing I noticed is that some Genesis emulators make colors that seem a bit too dark. Maybe I don't know enough about the Genesis hardware or something, but in some emulators, I'll see pure white represented as 224 rather than 255, which suggests to me that they are going in steps of 32. The version of Fusion I have does this. Dunno if it's been changed or not since the build I have, but I always found that to be a bit strange. Some emulators will output pure white as 255. I have a whole mess of old Genny emu screenshots stored away somewhere; I'll have to dig 'em up and check to see which ones are which.
« Last Edit: March 19, 2017, 02:42:44 AM by The Old Rover »

Black Tiger

  • Hero Member
  • *****
  • Posts: 11242
Re: Correct PCE color values?
« Reply #14 on: March 19, 2017, 03:01:17 AM »
Genesis actually has funky color values, which is why some of the coloring looks kind of garish in games.

0 52 87 116 144 172 206 255

You can't do smooth even shading and the jump from pure black or white to anything else is steep. It feels likely an expanded SMS palette when working with it. Those neon green colors in Sonic can't be done on PCE. You'll end up with greens which blend too well or are too far off from each other. It pretty much relies on games not concentrating too many colors, which often occurs anyway from trying to stretch four palettes.
http://www.superpcenginegrafx.net/forum

Active and drama free PC Engine forum