Interlace smooth scrolling demo

[Joe Musashi]

roland p suggested in another thread to use an interlaced display to achieve slow and smooth vertical scrolling. I remember that this had been proposed also for the Amiga back in the 80s, though I don't think I ever saw it in practice (it may be possible some PS2 titles do it implicitly when scrolling end credits, but I would have to check).

 

So, I decided to give it a try on the 2600. I started with the sync routines from Billy Eno and Glenn Saunders' example. Unfortunately, I only have a PAL VCS/TV, and it turned out that while it in pricinple works, there are some problems with the colors. So I went doing it from scratch for PAL50 kernels after I found a description of how field synchronization works.

 

For PAL this is similar to NTSC in that the sync for the second field starts half a line later, only that for PAL the sync is 2.5 lines long while for NTSC it's 3 lines (this is the interval m in the Field Synchronization diagrams).

 

I used this timing to create a PAL50 demo showing smooth vertically scrolling text. Basically, the text graphics moves at 25Hz, but is smoothed by switching fields inbetween.

 

I've tested this on several CRT TVs and it works even on a 40-something year old BW TV-set. It is, however, a very subtle effect. If you press the left trigger, interlace is turned off and you should be able to see the difference if you go close enough to the screen (if the VCS would have an RGB output and a less blurry image it would probably be more noticable).

 

 

You can also try it in z26, but you may have to load the ROM a couple of times until the text moves slowly.

 

 

There's also an NTSC version of this demo. I could not test it on an NTSC system. If someone with a Harmony can try it, please let me know if it still works there too.

InterlaceScrollDemo_PAL50.bin

InterlaceScrollDemo_NTSC.bin

InterlaceScrollDemo.asm

[SeaGtGruff]

I haven't tried the NTSC program on real equipment yet, but in both z26 and Stella it appears to have some kind of glitch. If you watch the PAL50 version in Stella in debug mode, the text appears to scroll up a line on every other frame, and remains stationary on every other frame. But the NTSC version appears to scroll up 2 lines every other frame, then scroll down 1 line every other frame, with the overall effect that it appears to scroll up at roughly the same speed as the PAL50 version except the image has an annoying vertical double-image effect.

[Joe Musashi]

Yes, it may well be that the NTSC version is not correct. If you run the PAL50 version in z26 and have "Show FPS" on, it reports that the line count alters between 311 and 313, while the NTSC version alters between 262 and 263. I checked Glenn Saunders' example again and this alters between 267 and 269 lines.

 

I made another NTSC version that now switches between 261 and 263 lines. Maybe that may work better on a real machine.

 

In z26 both NTSC versions show smooth scrolling on my MacBook with a 60Hz TFT, but it I have to try a couple of times (can also happen with Glenn Saunders' code). I'm guessing that z26 sometimes can get confused when mapping a specific sync signal to an even or odd field.

InterlaceScrollDemo_NTSC_20120722.bin

Edited July 22, 2012 by Joe Musashi

[SeaGtGruff]

I made another NTSC version that now switches between 261 and 263 lines. Maybe that may work better on a real machine.

Although I still haven't tried it on a real machine, the scrolling now looks correct in Stella and z26.

 

I'm confused about the line counts, though. Properly-interlaced fields should be 312.5 and 312.5 for PAL, or 262.5 and 262.5 for NTSC. Assuming the emulators add the two half-lines together and count them as an extra full line for one of the fields, the counts should be 312 and 313 for PAL, or 262 and 263 for NTSC. So the problem might not have been the line count on one of the fields but rather the number of lines scrolled on one of the fields.

[+Gemintronic]

I thought smooth horizontal scrolling was the naughty no-no uh uh cannot do thing on the 2600?

Edited July 22, 2012 by theloon

[Thomas Jentzsch]

I thought smooth horizontal scrolling was the naughty no-no uh uh cannot do thing on the 2600?

And it still is.

[Zach]

I just tried both NTSC binaries. The first one appears to jiggle a little like SeaGTGruff describes. The one from post #3 looks good, but it doesn't seem to change when I press the button, so maybe it is only showing regular scrolling?

Edited July 22, 2012 by Zach

[+Gemintronic]

I thought smooth horizontal scrolling was the naughty no-no uh uh cannot do thing on the 2600?

And it still is.

 

Maybe I came off a little snarkey. I guess what I'm looking for is an explanation why this is unique? Hasn't vertical scrolling been figured out for quite some time?

[SeaGtGruff]

Maybe I came off a little snarkey. I guess what I'm looking for is an explanation why this is unique? Hasn't vertical scrolling been figured out for quite some time?

Normal vertical scrolling is 2 scan lines per frame, because a normal 2600 screen is non-interlaced, hence each frame has only 262 or 312 lines that are double-spaced in comparison to an interlaced screen. This demo draws an interlaced frame, so each field has 262.5 or 312.5 double-spaced lines which combine to form a frame with 525 or 625 single-spaced lines. So the vertical scrolling is 1 scan line per field.

[Joe Musashi]

I just tried both NTSC binaries. The first one appears to jiggle a little like SeaGTGruff describes. The one from post #3 looks good, but it doesn't seem to change when I press the button, so maybe it is only showing regular scrolling?

 

Thanks for trying them! Here's another one that has scrolling disabled by default, it can be enabled by pressing the right button. The left button turns off interlace as before. When interlace is on, a slight jittering should be visible. Without scrolling it may be a bit better to see if the syncing is working at all.

InterlaceScrollDemo_NTSC_20120724.bin

InterlaceScrollDemo_20120724.asm

[roland p]

I tried the demo in Z26. Indeed the effect is very subtle (after having the fields synced in the right order by restarting the emulation). Z26 is weaving the two fields all the time instead of displaying the two fields after each other (and insert black lines inbetween the vcs' lines).

 

I also had an other idea for making the scrolling even smoother (disclaimer: maybe I'm just really fantasizing here ). Only on real crt's.

 

If you look at the trick that shifts the second field one scanline:

 

The second field (even) is shifted by ending the first field in the middle of a scanline.

So if you end the first field not in the middle of the last scanline but at different times, the scrolling could be even smoother?

 

The sequence is now, end last scanline at 50%, end last scanline at 100%

 

An other sequence could be: end last scanline at 75%, 50%, 25%, 100%? So four fields for every 'frame'.

 

If this works out good, you could scroll in 76ths of a scanline, and scrolling would get a real 'analog' feel.

Edited August 19, 2012 by roland p

[SeaGtGruff]

So if you end the first field not in the middle of the last scanline but at different times, the scrolling could be even smoother?

 

The sequence is now, end last scanline at 50%, end last scanline at 100%

 

An other sequence could be: end last scanline at 75%, 50%, 25%, 100%? So four fields for every 'frame'.

 

If this works out good, you could scroll in 76ths of a scanline, and scrolling would get a real 'analog' feel.

I had the exact same idea several years ago when I first started learning about TV displays. When I posted my idea, posters who are more knowledgeable about TV said it might not work, because the TV might sync to the nearest half line anyway, or something like that. I didn't try it at the time, because I didn't have a programmable cart. And I can't try it now, because I don't have a CRT TV. But I'm curious to see someone else try it to see if it works or not!

[Joe Musashi]

That's what I would expect too, that when the TV detects a sync signal, it just moves the beam to a defined start position. Another possibility would be that when the timing is changed, point C (in the diagram) moves along the scanline, but we would need it to move only vertically.

 

I think I had played with changing the timing by a few cycles, but all I got were wrong PAL colors and a wrong synchronization.

 

I currently don't have time to do more experiments and my CRTs are stashed away again. If someone else wants to try, it should be easy to change the timings of the different sync routines at the top of the code.

[iesposta]

I thought smooth horizontal scrolling was the naughty no-no uh uh cannot do thing on the 2600?

 

 

And it still is.

 

Until May, 2014 when Eshu succeeded in a horizontal 1-pixel playfield scroll:

http://atariage.com/forums/topic/224946-smooth-scrolling-playfield-i-think-ive-done-it/?p=2986451

 

https://www.dropbox.com/s/gnqnc7xjuaci9bc/SmoothScroll.mov?dl=0

 

Edited August 29, 2018 by iesposta

[+Gemintronic]

I've seen some Sonic the Hedgehog scrolling demos that at least simulate a smooth scrolling playfield since then as well. I'm glad people are still figuring out viable techniques - with or without hardware assist!

[Thomas Jentzsch]

I've seen some Sonic the Hedgehog scrolling demos that at least simulate a smooth scrolling playfield since then as well. I'm glad people are still figuring out viable techniques - with or without hardware assist!

It only looks smooth because it scrolls fast and moves 4 pixel per scroll. Real smooth scrolling allows 1 pixel per scroll.

[Mr SQL]

Obviously the Sonic demo has real smooth scrolling, or it wouldn't appear that way.

It's not about how many pixels, but how many increments per second; 30 will give very smooth scrolling regardless of the increment.

 

WARPDRIVE's title screen moves 8 pixels at a time, but does so 30x per second making the scrolling super smooth despite the 8 pixel increments:

http://javatari.org/?ROM=http://relationalframework.com/WARPDRIVE_AFP.bin&SCREEN_FULLSCREEN_MODE=1

Flipping the BW switch will make the scrolling even smoother via motion blur reduction technology, more info on that is available here and it's equally applicable to smoothing 60 FPS modern console output on 120 Hz displays; MBR science discussions are here and here modern,6502

[+Gemintronic]

It only looks smooth because it scrolls fast and moves 4 pixel per scroll. Real smooth scrolling allows 1 pixel per scroll.

 

Drat! I was hoping that it used some combination of ball/missile0/missile1 to fake 1 pixel per scroll.

[AkashicRecord]

Drat! I was hoping that it used some combination of ball/missile0/missile1 to fake 1 pixel per scroll.

Like Grand Prix. (A technical marvel)