ChronoScroller

[+Andrew Davie]

Here's a bit of a what-if experiment.

 

The CDFJ chess demo draws the chessboard using ChronoColour(TM) graphics to achieve full-screen 8-colour images at the cost of time-based multiplexing of colours and pixels on scanlines. Effectively, any single 8-colour pixel is completely formed over 3 consecutive frames. It gives a rolling shimmer effect. I've just done a quick'n'dirty demo to see what it might look like as a 1-playfield-pixel-resolution scroller. It's really really hard to judge on the emulator, and even more so to take screen capture of... my computer is just too slow, and the emulator doesn't give quite the same effect as running this on a TV. So the video here gives a basic idea but is pretty much quite different to what the eye would see on a TV, I'm pretty sure.

 

I'm hopeful it WILL run on the real thing but that's not guaranteed because I've added quite a bit to the processing time needed to draw the screen. Maybe someone with a Harmony cartridge can check this out and maybe even do a video if it actually works.

 

 

Anyway, here it is for posterity - a ChronoScroller... with any luck it will auto-detect the NTSC/PAL/SECAM system, but if not... sorry. There are two methods; one can "lock" the scroll so that it only scrolls every 3 frames (that is, a single ChronoColour(TM) frame). Alternatively, one can allow freeform scrolling on a per-frame basis in which case you would expect to see little jagglies when it's scrolling fast as individual ChronoPixels aren't fully formed. I think the chessboard isn't the ideal graphics for a scroller, anyway, but at least the basic principle is demonstrated.

 

Vivid screenshot shows the SECAM version, 'coz that's kinda interesting

 

 

ChronoScroller.bin

[+splendidnut]

Works on my regular Harmony cart on a CRT TV (NTSC).  Movement appears a bit rough though, kinda like it's scrolling over a rocky surface.

[+Andrew Davie]

3 hours ago, splendidnut said:

Works on my regular Harmony cart on a CRT TV (NTSC).  Movement appears a bit rough though, kinda like it's scrolling over a rocky surface.

Thanks for testing. I'm randomly picking a new scroll speed every few seconds and accelerating up/down to it. That might be the reason. I should probably put a joystick control on it to see how it "feels".

 

 

[+Andrew Davie]

This version uses the 'unlocked' scroll, smooth transitions between scroll speeds, and longer durations at each speed.

Perhaps it looks a little less "rocky road"...

 

 

 

ChronoScroller 20200219d unlocked.bin

Edited February 18, 2021 by Andrew Davie

[+splendidnut]

The 'unlocked' version does clean up the rockiness a bit... quite a bit actually.  There's still a little bit, at the faster speeds, due to the rolling effect of the ChronoColor(TM).

[+Andrew Davie]

Here is a much improved version.  At some speeds there seems to be a bit of a "jag" in the speed, and I'm not sure if I'm seeing a Stella thing, or some bug in the code. Probably the latter. It's now under joystick control - press/hold left/right to change the speed. It will accelerate up to the new speed rather than just jump, so everything should look continuous and smooth.

 

It's been interesting understanding how all of the visual "artefacts" operate. I do understand now. Given three lines A,B,C - although each line is an independent interleaved Chronocolour (ICC) pixel, they are out of "phase" with respect to each other. In particular, for any frame then pixel A will be displaying one ICC component colour, pixel B the next, and C the third. So if A is red, then B might be green, and C blue. And the very next frame, A will be green, B blue and C red. The colours roll through those three scanlines, RGB...RGB...RGB...

 

Now consider if we do a horizontal scroll. In the last visible frame, then assume we had a red pixel. So an ON pixel was only shown ever 3 frames (every time red rolled around to the scanline).  So, for that last visible frame, if we had a red pixel on line 1, and another red pixel on line 2, and another on line 3... we wouldn't see three lines of red. We'd see one line of red, and two lines of black, because lines 2 and 3 were in a different RGB phase than the R of the first line.  Likewise the next frame we'd see black, RED, black.  The red effectively rolls around those three lines to form 3 red pixels, but as noted phase-shifted.  That's all fine, until we scroll. Let's go back to the last visible frame, where the first line is shown red, and the next two black. Now we scroll one pixel to the left.  We will see black, RED, black, as the phase has also changed. And on the next frame we'll see black, black, RED.  So our eye can catch this black "edge" of things as it scrolls, even though the pixels are all red -- but the timing is such that we don't always see RED in any given pixel, because the pixel moves before it gets a chance to see red.

 

 

 

One solution is to wait 3 frames minimum before scrolling again. This allows the full cycle of RGB and guarantees any ICC pixel of any colour is always fully defined.  This is the "locked" interpretation from a few posts back. Another is to just not worry about it and put up with the colour artefacts. And that's what this version does. I'm undecided as to which I might use, but at least now I understand the whys and wheretofores.

 

Definitely needs to be run on a CRT.  In Stella set phosphor to 30% or more.

 

 

ChronoScroller 20200219 manual.bin

Edited February 19, 2021 by Andrew Davie