|
|
Post by turboxray on Oct 5, 2021 16:44:33 GMT
I have finally checked out the new Legend of Xanadu 2 maps from the English translation with the more-accurate palette, and the differences are small, but interesting to see. As drawn by Mednafen, using the old RGB-inspired palette ... View AttachmentAs drawn by Mednafen, using the new more-accurate palette ... View AttachmentHow do you access that in the game? I have a retrotink 5x and have been capturing PCE games in composite video over the past couple of weeks. |
|
|
|
Post by elmer on Oct 5, 2021 18:08:50 GMT
How do you access that in the game? I have a retrotink 5x and have been capturing PCE games in composite video over the past couple of weeks. IIRC, each map is only available a) if you've picked it up, and b) while you're in the area shown on the map (so you can't view a map once you've moved onto the next town/area/level). The maps are a part of your "item inventory". To see that, press the "pause" button, and move the "hand" cursor up into one of the top areas of the pause screen (the weapon & armor inventory) ... then press "right arrow" on your joypad. The screen will scroll over to the "item inventory". This existance of this extra "item inventory" screen is NOT obvious when you first play the game!  The untranslated version of that map looks more like this (with the new more-accurate palette) ...  |
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Nov 30, 2021 17:57:58 GMT
|
|
|
|
Post by turboxray on Nov 30, 2021 18:50:49 GMT
I made my own table dumper because he didn't have his up at the time: github.com/Turboxray/VCE-YUV-Dump I dumped my PAL TG and my Shuttle so far. No need to solder wires.. just hold a ground probe/pin to the top of designated pin on the VCE. But yeah I saw/retweeted that on twitter! It's a great write up  |
|
|
|
Post by elmer on Mar 31, 2022 19:12:28 GMT
For those who want to review the old RGB values versus Y/B-Y/R-Y lookup values in the 6260, versus the new calculated RGB derivatives of those, I assembled it all into a spreadsheet table, here: RGB-YUV-RGB' TableAll right gentlemen ... I'm confused!  The palette (with source code) that dshadoff posted on 26-Sep-2020 matches the one that turboxray posted on 11-Oct-2020. The palette that dshadoff references in the 11-Oct-2020 spreadsheet is different, but it does match the one that is currently in the github repository, dated 13-Aug-2021. OTOH, actually compiling and running the code that is checked into github outputs a palette that matches the earlier palette, and does not match the palette that is checked-in to github. Which one should I be using? Note ... one big difference is that the newer checked-in version doesn't max out the brightness, which might make some sense to me from composite signal POV. |
|
|
|
Post by dshadoff on Mar 31, 2022 19:45:12 GMT
OK... The October spreadsheet that I shared was a dump of RGB values, their corresponding YUV values from the decapped chip, and the calculated values which the standards police tell us should be used for calculating transforms for YUV back to RGB. This was done for illustrative purposes only, because it still doesn't quite match how the colors actually appear on screen (although it's closer than basic RGB).
If this was correct, it wouldn't have taken 6 weeks of additional work
And to be honest, the pce.pal which was posted separately, which is taken as 'definitive' at present, I'm pretty sure that turboxray and SamIAm still don't agree that it's definitive - although not so far off that it is top priority for them to fix
What we discovered was that the analog output section of the PC Engine has one of the outputs affecting the other outputs because they are not completely isolated - a bias is applied which affects colors to some degree. I believe that luma was being affected by one of the chromas more than the other, but I don't recall the details. This happens because they are 'mixed' through resistors before amplification, rather than first amplified, then mixed. The output driver strengths of the YUV signals on the Hu6260 chip appear to different driver strengths.
So the effects of these transforms have not been mathematically modelled via something like SPICE; they were instead measured by multiple test instruments in order to empirically understand the mathematical model, which Kitrinx did.
We used 512-color output ROMs which were written for the purpose, and measured them on vectorscopes; the points were skewed slightly from what was originally expected
Kitrinx estimated the types of offsets and made some transforms to the numbers, and ran them back through the virtual vectorscope she had written, in an attempt to most-closely approximate the 'true' image
it is important to note that different PC Engine equipment produced slightly different vectorscope images, so any amount of error introduced through Kitrinx's process would still put it within the realm of "real hardware", although it is arguable that it is still an approximation rather than an exact representation.
I hope that helps to explain.
Oh, by the way - Kitrinx made efforts to ensure that 100% white was at 255, 255, 255 (or as close as possible) which is another point where we don't all agree.
|
|
|
|
Post by elmer on Mar 31, 2022 20:05:18 GMT
Thanks for the explanation!  I've raised an "issue" on the github repository so that the updated palette.pal can be checked-in, or the difference documented, so that grumpy old folk like me don't get so confused! |
|
|
|
Post by turboxray on Apr 3, 2022 15:38:58 GMT
Yeah, so basically you have Y, R-Y, and B-Y output via the VCE. R-Y and B-Y are already amplitude modulated. When you sum them together, you get QAM. QAM basically decodes like this; amplitude is one axis and phase to the color carrier signal is the other axis. So you get a X,Y point into a 2D color plane. What happens outside the VCE is that resistors values for R-Y and B-Y aren't the same, so they aren't mixed equally. And thus you get both a shift and a skew/distortion for the final QAM. This is intentional. This is how they tweaked their YUV table to what they wanted.
This part of the color conversion from the YUV table, was done by hand and verified by eye. So that part of the conversion isn't as precise. It's close, but in this age of emulation accuracy, it could be closer. The steps of the amplitude aren't exactly linear either. So small things like that. But like Dave said, it's not exactly priority. Personally, I have used the retro-tink 5x to capture the colors from the PCE and have made my own palette. It's nice, because now I can give my SHDS3 pro this palette and it looks just like my console CVBS output.. but via RGB (and HDMI) output.
|
|
|
|
Post by dshadoff on Apr 3, 2022 15:44:45 GMT
It sounds as though elmer might be interested in comparing your "Tink5" palette against the "pce.pal" from 2020...
|
|
|
|
Post by elmer on Apr 3, 2022 16:37:58 GMT
Yep turboxray , I'd love to see that palette!  Getting something more-accurate, or at least more-pleasant-to-view, than the current reverse-engineered palette would be nice. But even then, important as that is for gamers ... my main interest is in art-production for the PCE. As I've posted elsewhere, we now know the RGB palette that Hudson used to display the 512 "approximated-PCE" colors on the PC-98 and IBM PC RGB monitors that their artists used to create the art for the PCE games that we know and love. Yes, I understand that those colors are not 100% accurate to the PCE's actual composite output ... but it is a *simple* scheme that does seem to visibly show the colors that were missing in the step-by-36 linear RGB palette that we all now recognize as flawed. Until/unless we write plugins for every major art package that modern PCE artists might use, to allow them to snap the current 24-bit PC palette to the closest measured-from-composite PCE colors ... then providing a *simple* alternative set of colors that they can use to create art would seem to have some value (IMHO). |
|
|
|
Post by spenoza on Apr 3, 2022 16:40:34 GMT
Too bad the Terra Onion guy has turned out to be a raging jerk face on Twitter to Krikzz while Krikzz had just escaped Ukraine. As long as we can fix the colors elsewhere, I guess.
|
|
|
|
Post by elmer on Apr 3, 2022 17:16:47 GMT
Also, just to go completely into "Devil's Advocate" mode ...  Which palette most-accurately represents game developers' (especially artists) intent when they created their games?  Is it the one that they saw on their PC-98 RGB monitors as they created the game art, using Hudson's own specifically-chosen set of RGB colors, or is it the best-approximation of those colours that the PCE hardware could cost-effectively achieve at that time when outputting an analog signal to a composite TV screen? Anyway, for anyone interested in seeing the RGB colors that Hudson chose, here's a palette for mednafen. Enjoy! pce.pal.hce80 (1.5 KB) Note: You need to rename this to "pce.pal" for use in mednafen! <EDIT> 2022-04-10 Modified the palette range to 80% to correspond with the PC-9801's 12/15 maximum. |
|
|
|
Post by dshadoff on Apr 3, 2022 17:37:06 GMT
When talking about “artistic intent”, I’m convinced that the early developers used the tools naively and didn’t think much about it
… whereas the later developers who targetted PCE directly for their work looked closely at how it appeared on the actual PCE output on a TV, as the user would.
And a third group - those who ported from, say, Amiga (Loriciel for example), just took existing RGB assets as-is, as much as possible.
|
|
|
|
Post by elmer on Apr 10, 2022 16:33:33 GMT
Continuing on from the MAPeD-SPReD thread ... I hadn't noticed that the spacing on your palette was equal except for the top two... I think you'll find (as we did in our investigation) that the bottom end should be "crushed" too. Please remember ... this isn't *my palette*, this is Hudson's own palette, that they used in the tool that gave to developers. Yes, I understand that the investigations showed that the PCE's actual NTSC palette is crushed at the bottom end too, but that's not the point of giving people Hudson's palette to look at. What are these 0,34,68,102,136,170,187,204 values??? Some some PC98+Monitor setup with an old archaic tool??? That's novelty best case, and confusing at worst. Novelty? Really? It was the tool that was used for developing the majority of game art for the PC Engine. Instead of assuming that Hudson were stupid, and congratulating ourselves on just how lucky we are to have affordable modern colorimeters, vectorscopes and voltage-meters to measure the output of the PC Engine's composite signal, perhaps we could look at what Hudson did, and try to understand *why* they didn't use a linear set of RGB values in their graphics tool, and whether we can learn anything useful from that. Okay wait.... I mean the PCE doesn't have official RGB output but RGB modded PCE should have linear voltage steps as that is how they are sourced from the pins (unless there's something wrong with your amp); that directly correlate to steps of 36.. as highly accurate and IS a good representation of the RGB analog levels. It's been measured multiple times, on multiple PCE systems. ... If you plan to work with PCE RGB, stick with linear steps of 36. I have difficulty understanding how you can say that homebrew-artists should do this after you've spent so much time being part of an effort to figure out why the use of a linear RGB-amplifier (step-by-36 on a computer) actually hides some colors that the PC Engine visibly differentiates! I know that you're a programmer, and not an artist, but you should be able to understand that it is useful, probably important even, for an artist to be able to visibly see colors changing onscreen when they alter the RGB values in their editing tool. That was just as true back in the 80s as it is these days. When looking at the output of a game such as Startling Odyssey 2, which seems to be where all this palette-investigation began, I find that I can see that the "missing" sky color shade is different on my modern LCD monitor when I use Hudson's palette, and I can't when using the linear step-by-36 palette. That suggests, at least to me, that Hudson's palette is a more-useful approximation to the PCE's palette for homebrew art-production than the linear step-by-36 approximation. They're both approximations, so why not pick the more-useful one, especially if it is the one that the console's own manufacturer thought was appropriate? You're welcome to feel differently, but I'm choosing to modify my PCE conversion tools to automatically recognize homebrew game-art that uses Hudson's palette, in addition to art that uses the linear step-by-36 palette ... it's not difficult to detect which of the 2 palettes is being used. 0,34,68,102,136,170,187,204 ... but typically in ProMotion I set the bit depth to 3bit per channel and the use color picker instead of hand typing values. This absolutely matches my experience with artists ... and in fact, with absolutely everyone involved in Game Developement. Typing 2 or 3 digit random-looking numbers into an editor's color-picker just isn't what artists (or anyone else) would call user-friendly. If they have a simple interface to change RGB values which results in visibly-different colors, that are close-enough to reality that the value that they pick really is the best choice for their purpose ... then for all practical purposes, any actual minute difference between the one on their editor's screen, and the one output on a TV, is totally irrelevent. Unless/until we can get every graphics-editor tool to use the same set of 512 screen-calibrated colors for PC Engine development, which is unlikely to ever happen, then this is *all* an approximation, including Kitrinx's work on the current pce.pal that we're currently recommending for emulators. Does your above value range fall under either 3bit or 4bit channel range, or is it unique? It's not unique, you just set the 4bit channel range, and then step-by-2 until you get towards the end ... i.e. you use the values 0,2,4,6,8,10,11,12 (out of 0..15) in the 4bit channel range. That's not quite as easy as just setting the 3bit channel range, but you'll probably find it worth using if it makes it clearer to see (on your PC's screen) the small changes that artists use in color gradients. |
|
|
|
Post by elmer on Apr 10, 2022 16:55:42 GMT
For folk to compare on their own PC's screens, here is the Startling Odyssey 2 background in both Hudson's, and the linear-step-by-36 palettes. Linear Palette ...  Hudson's Palette ...  |
|
