Smooth scrolling playfield - I think I've done it :)

[Wickeycolumbus]

Here are a couple different shots from the same frame. These are probed from the composite input to the RF modulator inside the 2600 itself.

 

A line that is black:

 

 

A line with containing some of the white text:

 

 

Not sure if this is what you were after, though it seems to be about as detailed as I can get them to be.

 

Edit: it appears that the color burst is added to the whole signal, you can see it in the HSync and image data.

Edited May 8, 2014 by Wickeycolumbus

[iesposta]

Scroll test two and scroll test three don't work.

Scroll test 2 altx pauses a fame (while the horizontal display area shifts)

Scroll test 3 moves up & down vertically.

 

Scroll test 2 alt was steady and four single pixel moves from right to left.

At least here Heavy Sixer, RF, NTSC CRT TV.

[eshu]

Here are a couple different shots from the same frame. These are probed from the composite input to the RF modulator inside the 2600 itself.

 

A line that is black:

 

P1020097.JPG

 

A line with containing some of the white text:

 

P1020096.JPG

 

Not sure if this is what you were after, though it seems to be about as detailed as I can get them to be.

 

Edit: it appears that the color burst is added to the whole signal, you can see it in the HSync and image data.

 

Hmm - that's a bit confusing, I don't think the colour burst should be added to the whole signal - it look slike something is at that point though.....I'll have a think over this for now....

 

Scroll test two and scroll test three don't work.

Scroll test 2 altx pauses a fame (while the horizontal display area shifts)

Scroll test 3 moves up & down vertically.

 

Scroll test 2 alt was steady and four single pixel moves from right to left.

At least here Heavy Sixer, RF, NTSC CRT TV.

 

Could you try the attached binary - This is an elongated version of the stabaliser, it should display all the different possible positions of the playfield. Using idfferent kernels that work on my system I can get this image stable and there doesn't appear to be any subpixel differences between the different positions, the idea was to send a version of this at the start and end of each frame....

stabaliser_alt.bin

Edited May 8, 2014 by eshu

[eshu]

garrr...there was a bug, some frames running at 263 scanlines - fixed....

 

 

scrolltest3_alt.bin

[iesposta]

Here is a beautiful video of the last binary.
Stable. #2 is a bit pincushion at the top, but overall effect works.
https://www.dropbox.com/s/gnqnc7xjuaci9bc/SmoothScroll.mov?dl=0

[eshu]

Here is a beautiful video of the last binary.

Stable. #2 is a bit pincushion at the top, but overall effect works.

https://www.dropbox.com/s/wfqssyismikhvx6/Video%20May%2008%2C%2010%2044%2020%20PM.mov

 

Thanks for testing - interesting - it looks like the top of the scroller is following the old pattern, so that #2 would be shifting a bit further, but the display is quickly bending into the correct position, I did some work last night to test the stabaliser on my setup but it didn't seem to be doing much, can I just confirm this is different/better than scroller2_alt.bin on your setup (I'm guessing/hoping that was exhibiting the subpixel drift?) - The pincuchioning/bend should hopefully be able to be fixed by moving the stabaliser further away from the scroll if this is effective on other setups.

[eshu]

Has anyone else had a chance to test the latest binary? Am really keen to know if stabalisation is working elsewhere, Ed - when you're back I'm really interested to find out if this works on your setup.....

 

I've been working on a blog entry to try and get all the explanation in one place - hopefully should get something up tomorrow....

[iesposta]

I'd say that 3 is better than 2. Really not that much different. 2.bin has a slight slant right to left in kernel "2" and 3.bin has that slight curve left to right just at the top.

Also, as I feared, both fail on Sony WEGA. No scroll between kernel 1 and kernel 2, although the visible area left to right shifts a pixel, so overall it only scrolls three spots.

This is a different Atari. A Sears Heavy Sixer RF NTSC ch 3.

I should take the same Heavy Six connected to the Zenith up to the Sony...

 

In my game we were going over cycle and the Zenith would jitter up/down a bit (as going over cycle should). The same build on the Sony was solid. The Sony does a whole lot of processing to all aspects of the signal.

 

I mention also on the Sony kernels 1 & 2, when scrolling doesn't happen, there is blue ghosting to the right of Playfield block into the black, and yellow from the left of the block to the right over the PF block. I didn't see this ghostingn the Zenith.

[Ed Fries]

Hi Eshu,

 

Here's test3_alt:

test3alt.MOV

[+SpiceWare]

Most of my stuff isn't back in my office yet, but my Atari is set up so I finally got around to checking this out. Impressive!

 

I took some photos to show what it looks like, but for some reason the site wouldn't let me upload them at a higher resolution even though they were under 2MB (smaller than Ed's movie). If you'd like more detail I could probably crop them instead of scale them.

 

The text moves to the left for each frame. The checkboard pattern moves to the left for frames 0-2, but frame 3 moves to the right, back to the same position as frame 1.

[iesposta]

Question: Why 4 kernels? Can't you use 0, 1, 2 to move left fine, then coarse (normal) shift the playfield one block with kernel 0?

[eshu]

I'd say that 3 is better than 2. Really not that much different. 2.bin has a slight slant right to left in kernel "2" and 3.bin has that slight curve left to right just at the top.

Also, as I feared, both fail on Sony WEGA. No scroll between kernel 1 and kernel 2, although the visible area left to right shifts a pixel, so overall it only scrolls three spots.

This is a different Atari. A Sears Heavy Sixer RF NTSC ch 3.

I should take the same Heavy Six connected to the Zenith up to the Sony...

 

In my game we were going over cycle and the Zenith would jitter up/down a bit (as going over cycle should). The same build on the Sony was solid. The Sony does a whole lot of processing to all aspects of the signal.

 

I mention also on the Sony kernels 1 & 2, when scrolling doesn't happen, there is blue ghosting to the right of Playfield block into the black, and yellow from the left of the block to the right over the PF block. I didn't see this ghostingn the Zenith.

 

Thanks again for testing. If you get a chance to swap 2600's between TV's it would be nice to know if theirs any difference - I'm erring on the side of it being differences in the TVs but would be nice to confirm. That blue/yellow ghosting is probably it scrolling less than a TV pixel, so that only the blue from the RGB phosphers is being lit on one side and the red and green from the other.

 

Hi Eshu,

 

Here's test3_alt:

 

Thanks Ed - doesn't look like much of an improvement, back to the drawing board I think....

 

Most of my stuff isn't back in my office yet, but my Atari is set up so I finally got around to checking this out. Impressive!

 

I took some photos to show what it looks like, but for some reason the site wouldn't let me upload them at a higher resolution even though they were under 2MB (smaller than Ed's movie). If you'd like more detail I could probably crop them instead of scale them.

 

The text moves to the left for each frame. The checkboard pattern moves to the left for frames 0-2, but frame 3 moves to the right, back to the same position as frame 1.

 

Thanks for this - did you use a tripod or something? The pictures seem to be taken from an identical position which is handy! - nice idea with the postit to I hadn't noticed 3 & 1 where the same offset so that's handy to know. Im did some quick measuring and it looks like the drift is about half a 2600 pixel. I.E the difference from frame 0-2.

 

Question: Why 4 kernels? Can't you use 0, 1, 2 to move left fine, then coarse (normal) shift the playfield one block with kernel 0?

 

A normal PF scroll, goes 4 2600 pixels at a time, so if we're scrolling 1 pixel at a time we need 3 intermediate steps - Kernel 0 is just a standard 2600 kernel with no use of RSYNC. I did at one point think the drift might be a whole 2600 pixel and tried removing one of the kernels, but no joy. As I mentioned above from measurements it looks like half a pixel.

 

I have a few more ideas to try out to see if it's possible to fix the subpixel drift, or at least reduce it, but I'm going to be quite busy with work for the next week at least, so they're probably won't be any new updates for a while. In the meantime if anyone gets a chance I'd like to confirm that the "stabaliser_alt.bin" binary is stable and shows proper one pixel differences between each kernel.

[SeaGtGruff]

In the MOVs and JPGs it looks like the "1" kernel scrolls more than 1 pixel (as others have noted), such that there's very little difference between the "1" and "2" frames. Just a thought, but I'm wondering how it would look if you try a 3-frame scroll-- 0, 2, 3, 0, 2, 3-- since there's so little change between 1 and 2 anyway? It might not be as smooth, but it also might not look like there's a slight "pause" from when the 1-2 frames are displayed (since they're so similar in position which might make it look like a single frame being displayed twice as long as the others)?

 

Edit: Or better yet, 0-1-3-0-1-3.

 

Or a 2-frame scroll, 0-2-0-2-0-2.

Edited May 11, 2014 by SeaGtGruff

[eshu]

In the MOVs and JPGs it looks like the "1" kernel scrolls more than 1 pixel (as others have noted), such that there's very little difference between the "1" and "2" frames. Just a thought, but I'm wondering how it would look if you try a 3-frame scroll-- 0, 2, 3, 0, 2, 3-- since there's so little change between 1 and 2 anyway? It might not be as smooth, but it also might not look like there's a slight "pause" from when the 1-2 frames are displayed (since they're so similar in position which might make it look like a single frame being displayed twice as long as the others)?

 

Edit: Or better yet, 0-1-3-0-1-3.

 

Or a 2-frame scroll, 0-2-0-2-0-2.

I think 1-3-1-3-1-3 is a perfect 2 pixel scroll. I can't remember if I did one with the _alt versions of the kernel, which so far seem to work on every setup except mine - I'll check and do a version using the correct kernels if I haven't....

[eshu]

Here is a 2px version with just kernels 1 & 3, I think this is right..

 

 

scrolltest3_alt_2px.bin

[+SpiceWare]

Thanks for this - did you use a tripod or something? The pictures seem to be taken from an identical position which is handy! - nice idea with the postit to I hadn't noticed 3 & 1 where the same offset so that's handy to know. Im did some quick measuring and it looks like the drift is about half a 2600 pixel. I.E the difference from frame 0-2.

 

Yep, I impulse bought one of these for $5 at Walgreens sometime last year. The phone holder comes off that little tripod. It uses the standard tripod thread size, so I have it on another tripod that I've had for years.

 

[SeaGtGruff]

I think 1-3-1-3-1-3 is a perfect 2 pixel scroll.

 

That's interesting. What about 0-2-0-2?

 

I wonder if drawing a sprite on top of the playfield-- say, a checkerboard pattern or something-- would help identify the exact amount of scrolling that's taking place on each frame? It would probably be best to have the playfield and sprite be the same hue, but with different luminance values so you can still tell them apart.

 

It would still be great to have a 1-pixel scroll, but if it can't be done exactly, or not consistently on different models, then a 2-pixel scroll (if consistent on different models) should probably be enough to give a smoother scroll.

[eshu]

 

That's interesting. What about 0-2-0-2?

 

I wonder if drawing a sprite on top of the playfield-- say, a checkerboard pattern or something-- would help identify the exact amount of scrolling that's taking place on each frame? It would probably be best to have the playfield and sprite be the same hue, but with different luminance values so you can still tell them apart.

 

It would still be great to have a 1-pixel scroll, but if it can't be done exactly, or not consistently on different models, then a 2-pixel scroll (if consistent on different models) should probably be enough to give a smoother scroll.

 

0-2 have a subpixel shift between them, so it's an imperfect 2 pixel scroll.

 

The technique shifts the whole screen so placing a sprite on top of the playfield won't help identify the scrolling amount anymore than the checkerboard pattern which is already below the scroller in the current binary.

 

Yes, the 2 pixel scroll should be twice as smooth as was previously possible, but a single pixel scroll would be twice as smooth again

[iesposta]

2 pixel scroll works on the Sony. The checkerboard pattern moves a subpixel left on 1 (or is it moving right on 3?)

 

I cant wait for the parallax test where the lower lines move 4 pixels middle lines move 2 pixels and top ones move 1 pixel.

And also see how different sets hold a color.

But I'm racing ahead.

I'm so impatient!

[SeaGtGruff]

 

The technique shifts the whole screen so placing a sprite on top of the playfield won't help identify the scrolling amount anymore than the checkerboard pattern which is already below the scroller in the current binary.

 

Yes, except the current checkerboard pattern has blocks that are 4 color clocks wide, and I was thinking of a checkerboard where each block is just 1 color clock wide. If a stationary sprite can't be drawn on top of the scrolling text, it would be more convenient to draw the checkerboard immediately below the scrolling text.

[+Andrew Davie]

I was just coming back to this to do some review/documentation on the technique.

I downloaded the last binary from post #115.  It runs fine on my NTSC under PlusCart.

But it does not work at all in my copy of Stella (6.6 PRE) - I just get a black screen and 0 scanlines/infinite fps.

I thought I'd post here so @Thomas Jentzsch and the Stella team could review in context.

 

 

[Thomas Jentzsch]

I went back several versions (until 4.7.2) and this demo never worked in Stella. It uses some TIA tricks which are not emulated in Stella.

 

@DirtyHairy Do you want to have a look? Should we create an issue?

[DirtyHairy]

To my understanding but this trick works by shaping the TV signal using timed VSYNC and RSYNC writes. If we really wanted to emulate this we would have to simulate a good deal of the TV signal generation and decoding. I don't think we should go down that rabbit hole just for this purpose.

[Ecernosoft]

Source file please?