Jump to content

Photo

Video Life without flicker, how?


8 replies to this topic

#1 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • 171 posts
  • Location:Hannover, Germany

Posted Fri Jun 15, 2012 11:12 AM

Lately I've been playing a bit CommaVid's "Video Life" cartridge a bit. It's quite impressive. First of all it's only one of two carts that use the "CV" "bankswitching" type: just 2k of ROM, but 1K of additional RAM. So it's not really "bankswitching".

And I'm really impressed how they implemented the "framebuffer". They use triple sprite with far spacing and display one stripe down, so you get 8 pixel data, 8 pixel nothing, 8 pixel data, ... until the 48 "odd" of the 96 pixel are displayed. The next picture will then display 8 pixel nothing, 8 pixel data, 8 pixel nothing, ... until the "even" 48 pixels are displayed as well.

I tried to hack something similar myself, but instead of an image that's only a bit darker, but all in all very viewable, I get flicker like hell. So as I'm digging deeper into the original "Video Life" code, I want to ask if anyone has already been there, and is willing to share the secret to save me some time on this weekend. ;-)

Thanks in advance,
SvOlli

#2 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,118 posts
  • Location:Canada

Posted Fri Jun 15, 2012 11:27 AM

If you are looking at it in Stella then the alt-P is probably enabled by default for video life. So your rom is not recognized as having alt-p by default.

#3 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • Topic Starter
  • 171 posts
  • Location:Hannover, Germany

Posted Fri Jun 15, 2012 11:35 AM

Found it!

I was trying it in Stella first, and Stella activates "Display.Phosphor" when detecting "Video Life" by md5sum.

On a real 2600 it looks quite like expected.

D'oh!

#4 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • Topic Starter
  • 171 posts
  • Location:Hannover, Germany

Posted Fri Jun 15, 2012 3:47 PM

To round this up: here's what I had in mind. Pretty lame to what eshu's come up with, but it'll serve my purpose. :)

Attached Files



#5 Joe Musashi OFFLINE  

Joe Musashi

    Moonsweeper

  • 305 posts

Posted Fri Jun 15, 2012 4:04 PM

To round this up: here's what I had in mind. Pretty lame to what eshu's come up with, but it'll serve my purpose. :)


Very nice!

If you want to reduce the flickering a bit, a popular technique to do so are "flicker blinds". This is an "interlaced" version of the "Venetian Blind Technique" used in Video Chess.

The idea is to move the sprites back and forth by 8 pixels in each line and switching the pattern every frame. For example, the batari basic titlescreen kernel does this.

SA_1.png SA_2.png

#6 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • Topic Starter
  • 171 posts
  • Location:Hannover, Germany

Posted Fri Jun 15, 2012 4:20 PM

Thanks!

I was thinking about this as well, but in the end I didn't do it for two reasons:
- I had trouble once with moving a sprite more than the range of -8 to +7, and didn't want to dive into this again, although I've seen that it's possible.
- I'm using a modded PAL Atari with AV (FBAS) out, connected to a VGA converter or a beamer. Both don't "overlay" the half pictures and this way the image looks a bit better, because of the regularity.

And I've got 10 cycles on the left of the image to spare, which I could use for some color cycling routine. I'm still thinking demo here, trying to get the most effects in one scanline. ;-)

#7 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Fri Jun 15, 2012 5:51 PM

You can check out my own bitmap code in this old thread to see how to move the sprites 8 pixels left and 8 pixels right to get flicker-blinds. The pictures in that thread also show how you can use dithering to get a more textured picture. There were some utilities posted or linked to in that thread for converting a dithered monochrome picture into the data values needed for the sprites. You start with a picture, scale it down to the right size (in this case, 96x192), convert it to a grayscale image, then convert the grayscale image to a dithered monochrome image using some dithering algorithm-- for the pictures I did, I just used PaintShop Pro to do it all. Then you use some other utility to convert the dithered monochrome image to 1s and 0s, and split them up into 8-bit "columns" to get the data for the sprites.

Of the pictures I did, the two best are shown below. Note, I cranked up Stella's phosphor blending to 100% on the Spock image to get a brighter picture; it's actually a lot darker otherwise.

Nolan.png

Spock.PNG

Edit: By the way, the method you used-- simple flickering, or shifting the sprites on alternating frames rather than on alternating lines-- actually looks better on some modern HD TVs that automatically convert the non-interlaced picture to an interlaced picture.

Edited by SeaGtGruff, Fri Jun 15, 2012 5:55 PM.


#8 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • Topic Starter
  • 171 posts
  • Location:Hannover, Germany

Posted Sat Jun 16, 2012 2:01 AM

You can check out my own bitmap code in this old thread to see how to move the sprites 8 pixels left and 8 pixels right to get flicker-blinds.

Ah, thanks for pointing me out.

Edit: By the way, the method you used-- simple flickering, or shifting the sprites on alternating frames rather than on alternating lines-- actually looks better on some modern HD TVs that automatically convert the non-interlaced picture to an interlaced picture.

Same goes for (at least my) beamer and my Video-to-VGA converter. That's what I mean with the second reason for sticking with the "Video Life" approach.

#9 SvOlli OFFLINE  

SvOlli

    Chopper Commander

  • Topic Starter
  • 171 posts
  • Location:Hannover, Germany

Posted Mon Jun 18, 2012 12:19 PM

I did some updates to the code. The trick of moving the sprites back 8 pixels to the original position is very picky about timing. That's one of those things I'd never figured out all by myself. Thank you, Joe and SeaGtGruff.

While the old version was a dual-line kernel display, the new version some kind of "simulates" a dual-line kernel by switching the "sprite-lines" every half frame. The new version is also trimmed down to 96x85 instead of 96x96 for two reasons: now the graphics fit in 1K, as intended, and I can access the graphics data without "penalty cycles" for page crossing.

I did also some comparison of the output as well. First, my Video->VGA converter, for this I've created an ASCII sketch.

The number indicates the line number, a small letter indicates that the sprite is shown on first half frame, a capital letter is the same for the second half frame.

Here's what it looked like using the old code:
0a..0c..0e..0g..0i..0k..
..0B..0D..0F..0H..0J..0L
1a..1c..1e..1g..1i..1k..
..1B..1D..1F..1H..1J..1L
2a..2c..2e..2g..2i..2k..
..2B..2D..2F..2H..2J..2L
Using the new code:
0a..0c..0e..0g..0i..0k..
..0B..0D..0F..0H..0J..0L
..1b..1d..1f..1h..1j..1l
1A..1C..1E..1G..1I..1K..
2a..2c..2e..2g..2i..2k..
..2B..2D..2F..2H..2J..2L

So, the old code looked slightly better, but that's the only time that this is the case.

In Stella it looks the same (with phosphor) or better (without phosphor).

I also attached two small (2 seconds each) films taken from my beamer to show the different flickering there.

So I come to conclusion, that interlacing gives the viewing better experience, except for the VGA converter, but the disadvantage there the rather minor.

Next: some code cleanup...

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users