+Andrew Davie Posted January 29 Share Posted January 29 On the Zeropage Homebrew show yesterday I introduced a "new" display technology that I call "interleaved ChronoColour", or iCC for short. I thought I'd give a bit of an overview here at to what's actually going on with this display system. First, have a peek at the longplay video demonstrating pretty much how iCC looks to the human eye... I linked to mid-video as there's a bit of an issue at the start with the different frame rate of my screen capture and the iCC display. So, iCC is leaning heavily on the way the human eye perceives things, combined with phosphor refresh on a CRT (or as emulated here in Gopher2600 emulator). Essentially, there's a bit of blending going on here, and iCC takes advantage of persistence of vision (on a per-scanline resolution) and CRT persistence. By modifying the colour on any scanline, and the on/off pixels on any scanline - and thus changing the screen content every single frame, it's possible to display effectively 8 colour (at least as perceived by the eye) with minimal flicker; in fact flicker is a poor word here, and I like to use "shimmer" to describe it. So, normal ChronoColour displays on/off pixels on triplets of scanlines. Consider three "primary colours" such as red/green/blue. ChronoColour sets the playfield colour to these colours on successive scanlines, repeating down the screen. So, R/G/B/R/G/B/R/G/B... etc. And our eye perceives on-pixels on these lines as being a colour that's "blended" with the on pixels on both the scanline above, and the scanline below. Of course red, green, blue are only one possibility. in fact, ChronoColour uses arbitrary colours on the successive lines - whatever works to produce a nice blending of R+G or R+B or G+B or R+G+B and of course R, G, B alone. So if we're displaying red, we can only see red every 3 scanlines, and black on the G/B lines (i.e., no pixel). So this all works just fine, and was used in the original Boulder Dash and many of my ChronoColour demos such as the chess demo, the Rubik's cube, Sokoboo, and others. iCC works on the same principle, but instead of 3 scanlines being used for the R/G/B colours, just a single scanline is used - but over successive frames. So we have R on frame 0, G on frame 1 and B on frame 2 (for any single scanline). But also, on frame 0 the next line is G and the line after that is B. So frame 0 is exactly a ChronoColour frame as described at the start of this post. But the next frame, frame 1... is a ChronoColour frame shifted up by one scanline (effectively). More accurately, each triplet of frames (frames 0, 1, 2) are now three chronoColour frames shifted in "phase" by one colour. And frame 4 is the same as frame 0. So the display is rotating colours through a single scanline (R/G/B) over time, and over triplets of scanlines (R/G/B) over space. Now this sounds expensive, as you would initially think you'd need to triple the graphics data to define stuff. But actually it's not - I realised that in the draw systems I could use just one shape definition, but when drawing map triplets of lines to the appropriate scanline they need to be drawn on. So line 0 of a shape might end up being drawn on lines 0 of the RGB triplet on screen, but in the next frame, line 1 would be drawn on line 0 of the RGB triplet on screen. It's kinda hard to describe this all, and sounds very complex... but the code to do it is actually incredibly (and surprisingly) simple. Here's a close-up study/video showing the iCC in action, slowed down many many times and zoomed way in. What you're looking at is (for example) how the parallax pixels in the blank areas are "shifting" in a 3 pixel position vertically. This is their blue colour being shown on all 3 "RGB" lines spatially, and also temporally (over multiple frames in different vertical positions). This is happening so quickly (20Hz frequency for displaying on all 3 lines) at normal speed that, combined with the phosphor persistence and the eye's blending... it just appears as a 3-scanliine-deep blueish dot. Hopefully that makes sense. In summary, pixels are now effectively 3 scanlines deep, and the colour of that pixel is displayed on all 3 scanlines, but at different times, or at least not always on every frame. So in the video this looks very sparse and admittedly very very odd and unattractive. But, run it at normal speed, and it looks like the video above where everything looks kinda solid - a bit shimmery (depending on the colours, really) - but really not too bad at all. iCC. The lovely thing about this new system is that it's cheap. You can turn it off easily by simply not rolling the colours over successive frames, just keeping the original R/G/B on successive scanlines. When you do that you have the original ChronoColour system. I put it on an option switch in my new tech demo. Extra cost for including this technology is very very low - just a few lines of code, literally, so its essentially just as fast to draw; just one indirect to vector to the correct line in the bitmap draw system. 8 2 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.