Yeah, this isn't exploiting chroma <--> luma interference like on many other "hi color" demos for multiple systems (Apple 2, CoCo 3, MD, etc). The Genesis/MD, for NTSC, gets blended colors simply because the Luma signal is almost twice the chroma signal, and it's difficult to separate (there's no alternative chroma burst mechanism). But obviously that doesn't work for PAL composite/RF output for Megadrive. It softened in the PAL signal, for MD, but it's visibly there. But I guess if you had a pretty low grade consumer TV, the CRT TVL resolution also helps blend things regardless of how sharp/crisp the signal is (even for RGB) - everyone likes to run with PVM or BVMs these days, but that wasn't realistic for gamers BITD.
I don't mean to disregard S/H mode on the Genesis, I just wanted to point out the dithering approach on NTSC Genesis/MD. I don't think anyone has made a decent converter for images using S/H.. at least not publicly.
The high-res blend down on the PCE method, works both in NTSC and PAL composite (I have a PAL TurboGrafx). Matter of fact, the NTSC version is
very crisp because of the PCE's alternating 180 degree color burst every other line, and inverted on the next frame. These images have no color fringing on NTSC composite. And the other side to this, is that for these images - I spent a
considerable amount of time making my own gui app that allows you to tweak all kinds of parameters for the image and dithering encoding (the error diffusion one is a variation of floyd-steinberg, but only the error distribution matrix - the rest of the dithering is completely different from standard floyd-steinberg).
What this means is that I don't simply treat the pixels in the image as a double pair pixel (you can, and that's easiest approach). But rather, I do the error diffusion dithering at 10.74mhz frequency; so on a perfect blend you get a 256px (5.37mhz) pixel clock with hi-color.. with 5.37mhz frequency dither, but when you look at it raw/zero-blend.. it's 512px (10.74) pixel clock with high res detail.
And so, think of it as a spectrum - as you go to one end you get hi color lower res, and as you go to the other end you get lower color with high resolution with more detail (but the high frequency dither pattern kicks in! So it still blends nice too). It's the best of both worlds! If it starts to "leak" higher res pixels (higher frequency detail) as the blending breaks down, then your image starts to show
more detail (become higher res) haha. It works
really well and I'm not actually dependent on a "perfect" blend. I've had people test it with RGB->Component converters and it looked amazing. Same with s-video. These are on higher end consumer CRTs too. (I suspect people are using SD video amps for the pce RGB mods that have a 8mhz low pass filter though).
Btw - these images in the video are specifically test images. I was exploring what
range was possible - not just
trying to throw as
much color as possible; that just happens to be a side effect haha. Most of them just happened to come out pretty good. What doesn't come through on the video, but does on the CRT, is the 'glowing light'. Some of the images simply look
stunning on a CRT because it looks like a real bright/hot light source in the images (like the floating astronaut against the blackhole with the event horizon). They also somehow look
higher res than 256px on the CRT too, while still perfectly blending. You really have to see it on a CRT for yourself haha. I'm still in awe at how some of these turned out.
If I were to use this in game though, I'd probably do a double pair pixel approach. Mostly so I could do some transparency effects with the blending. But it's not an either/or thing. I can do both.
Chilly Willy wrote: ↑Mon Dec 26, 2022 2:52 pm
iNCEPTIONAL wrote: ↑Mon Dec 26, 2022 12:36 am
Yeah, I saw your PC Engine examples, and they look truly amazing. Far beyond anything I've seen on Genesis, and, so far, much nicer than anything I've seen the SNES dev scene put out too, which is bonkers.
The single biggest problem with the Genesis display is the small palette. 3 bits per gun (BGR) is really not enough for high color quality. It's good for the kind of games the Genesis does, but that's about all. With careful use of hilite and shadow, you can improve on that, but not by much, and hilite/shadow is hard to apply as needed for making those kinds of images. It would have done so much better with 4 bits per gun like the Amiga. It's why Amiga games don't look quite as good on the MD as they do on the Amiga - the limited palette.
Even with the same 4 subpalette limitation in place on the Genesis, 4bits per element would have really helped! I know hindsight and all, but...
iNCEPTIONAL wrote: ↑Mon Dec 26, 2022 12:36 am
Now, regarding the direct colour mode on SNES, doesn't the stuff in the following link apply here, so it would actually be around 2304 colours even before any other things like colour math, HDMA gradients, raster tricks or whatever pseudo effects are applied, if I've understood it correctly:
https://forums.atariage.com/topic/34527 ... pablities/
First off, we need to split that 2304 number up. It's 2048 + 128 + 128, which 128 isn't correct.. it's 120 because of the reserved color slot in each subpalette. So focusing on the 2048 colors. The RGB direct value mode uses 3:3:2 (R:G:B) which gives you 256 colors - both for the palette and the total number of colors in that tile. 256 colors is great for
total number of colors in a single tile, but overall is
pretty crap of a palette (I mean, considering the SNES has a 32768 color palette). The reason why it magically turns into 2048 colors is because direct color mode doesn't need a palette in the tilemap to associate with the tile. So, cleverly, Nintendo allowed the reuse of those 3 bits in the tilemap, as the lowest bits of the 3:3:2. That means you get (3+1):(3+1):(2+1) => 4:4:3 or 11bit RGB color. You don't get pull from the 32k palette. AND those extra low bits are for the WHOLE 8x8 tile. That's why I said it was "lossy". And yes, you could attempt to mitigate that with a large tilemap, line interleaved on the screen with hDMA, so you have something like a 8x2 tilemap "palette association" to the tile (but instead the palette bits are the color bits) - which means every 8x2 row has the bits fixed. It's coarsely similar/analogous to HAM on the Amiga (but HAM is much superior). Honestly, for unique detailed images (where almost all tiles are unique) - I don't think that's very good for images. And you're limited to just 2048 colors fixed colors - not anything picked from 32k colors, you don't get to chose individually for each pixel for those 2048 colors. And on top of that, 8bpp eats vram for lunch - you won't have enough vram left for the 4bpp layer used to get the extra 128 colors.. or even sprites, for the final 128 colors.
That's why I said mode 4.. and use 256 "indexed" color mode. Start with the base: 256 colors out of 32k colors. Right there, 9.8 times out of 10 that's going to be a better option right there. The granularity of the master palette you're picking colors from.. matters! If I had to pick even against something like 512 colors out of 4k colors, I'd still pick 256 out of 32k colors. Anyway, using the 2bpp layer, and color math, duplicate those base 256 colors, out of 32k colors, as four intensity levels. So 1024 colors out of 32k colors, and it's not lossy and it's a "per pixel" freedom, and you don't need to do a large tilemap reposition with hDMA either. It's a far superior method for display hi color images with unique detail on the SNES.