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) ...
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
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.
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.
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).
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!
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.
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.
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.
... 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.
_jash: SLG= Silly Lunatic Games/
Feb 2, 2023 19:04:13 GMT
tron: I hate strictlylimitedgames jash even more so when they get the rights for physical release of anything by taito.
Feb 5, 2023 11:22:34 GMT
spenoza: It occurs to me that this same limited physical release approach has hit other hobbies as well, like tabletop role playing games. Companies in that space that aren't Hasbro are all small and so they tend to do limited prints of books and then lean on pdfs.
Mar 8, 2023 20:23:43 GMT