Jump to content

Photo

Bus Stuffing Demos


224 replies to this topic

#1 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Oct 19, 2016 6:19 PM

CURRENT VERSIONS OF THE DEMOS:

Some demos were original posted in other topics.
 
NOTE: At this time these demos only work on real hardware via a Harmony Cartridge.
 
1 demos prior to June 6, 2017 run under Stella 5.0.0-pre6 or pre7.
 
2 demos from June 6 on need Stella 5.0.0-pre8 or newer.

 


Instead of having demos all over, I thought I'd consolidate them into a single topic.  As I update the demos I'll update this post so it's easy to find the current versions.

RPG demo - this creates a 12x16 multicolor tile display. As with the other demos, this only works on real hardware via a Harmony cartridge. Stella support will be released once we finalize the driver.
Attached File  rpg_20161019.bin   32KB   224 downloads
 
At this time this is a non-interactive demo.  However, you can specify your TV Type via the difficulty switches.

Left Difficulty=A, Right=B for PAL60:
rpg - PAL.png

Left=A, Right=A for SECAM60:
rpg - SECAM.png

Left=B for NTSC:
rpg - NTSC.png IMG_7689.jpg



#2 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 760 posts
  • Location:Orlando, FL US

Posted Wed Oct 19, 2016 6:42 PM

Is flicker used?

#3 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Oct 19, 2016 7:25 PM

Is flicker used?


Yes, only way to create a 96 pixel display on the 2600. If you have trouble with 30 Hz flicker try wearing a pair of polarized sunglasses, that'll help.

#4 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 760 posts
  • Location:Orlando, FL US

Posted Wed Oct 19, 2016 9:11 PM

No trouble here. Just trying to work out the algorithm you used.

Looks really good btw. I assume the character would move in tile sized steps and take the place of the background. That would work nicely for an RPG.

#5 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Wed Oct 19, 2016 9:48 PM

No trouble here. Just trying to work out the algorithm you used.


Usual 96 pixel display created by alternating between 2 layouts, even odd:
rpg_dbg_e01bd232.png rpg_dbg_e0224b43.png

and odd even:
rpg_dbg_e01be0c9.png rpg_dbg_e01ca225.png

even and odd refer to the positions of the players on each scanline:
; The players are positioned:
; EVEN: 0-1-0-1-0-1-
; ODD:  -0-1-0-1-0-1
 

This is the update for the even Scanlines:
  sty GRP0    ; before 34
  sty COLUP0  ; before 34
  sty GRP1    ; before 39
  sty COLUP1  ; before 39
  sleep a few ;   35
  sty GRP0    ; 3 38 @37-43
  sty COLUP0  ; 3 41 @37-43
  sty GRP1    ; 3 44 @41-49
  sty COLUP1  ; 3 47 @41-49
  sty GRP0    ; 3 50 @47-54
  sty COLUP0  ; 3 53 @47-54
  sty GRP1    ; 3 56 @52-59
  sty COLUP1  ; 3 59 @52-59
 
The @x-y are the cycle ranges those instructions must finish on, they're the cycles between instances of each player.  Bus stuffing makes it possible to change both the image and the color in those cycles.  Odd scanlines use same update pattern, just with slightly different cycle ranges.

cd-w worked out the timing. The kernel also supports PF1 and PF2 updated on every scanline (symmetrical mirrored) with background and playfield color changes on every line, but based on another test we decided we're going to remove that and put the ball behind the "hero" instead. The ball will be colored based on the tile the hero's standing over, so the black behind the hero standing in the road would be grey instead. It won't be a perfect replacement though, when standing over the grass the green behind the hero would be solid instead of the alternating dot pattern.
 

Looks really good btw. I assume the character would move in tile sized steps and take the place of the background. That would work nicely for an RPG.

Yeah, much better than I was expecting. Yep, the hero moves a tile at a time. The engine's flexible, while I'm demoing it as a 12x16 display with 8x12 tiles it could just as easily be 12x12 with 8x16 tiles, 12x24 with 8x8 tiles, 12x25 with 8x8 tiles etc. The height of the tiles just needs to be a multiple of 2.

I'll be releasing the source for all the demos once we finalize Bus, we're still making changes to it that will break the current demos.

#6 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Thu Oct 20, 2016 7:49 PM

Volcano & lava, ball now used to backfill behind the hero:
rpg.png

Attached File  rpg_20161020.bin   32KB   147 downloads

#7 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Oct 22, 2016 2:25 PM

Yes, it displays correctly with right diff in 'A' position on my sixer! :thumbsup:

 
I added an auto-detect to the 128 Chronocolour demo. If it works right you won't have any gaps or overlaps.
Attached File  128chronocolour_20121022.bin   32KB   159 downloads

Left Difficulty=A for PAL. This is only checked one time, when you power up the console.


 The demo starts with a 240 line display.  
Screen Shot 2016-10-22 at 3.16.16 PM.png
 
Which you can decrease with the joystick in order to get a higher refresh rate, and thus less flicker.
Screen Shot 2016-10-22 at 3.17.34 PM.png
 
For those trying this out, 240's quite a bit less than the usual 262 scanlines so your TV may not like the picture.  If this demo scrolls when first loaded, then Artillery Duel and Buck Rogers probably don't work on your TV either.
Screen Shot 2016-10-22 at 3.20.18 PM.png Screen Shot 2016-10-22 at 3.19.22 PM.png

#8 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,881 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Oct 22, 2016 4:20 PM

Did the previous ChronocolourTM start at 240? Those worked no problem. 

Because the best I can get with this last one on a Framemeister to LCD is split-screen. 

 

Same no go on Sony 32" TV. Starts out all over the place. Joystick down ends in last spot split screen. 


Edited by iesposta, Sat Oct 22, 2016 4:30 PM.


#9 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Oct 22, 2016 4:42 PM

Did the previous ChronocolourTM start at 240? Those worked no problem.

 
The previous Chronocolour is part of the 128 pixel demo and outputs a steady 262 scanlines.  
 
This build was created specifically to test this idea, I'm not surprised at all that it doesn't work with a modern display.

I don't think 128 Chronocolour will be useful unless the framerate could be increased. My C= 1084 can handle a variety of framerates :ponder: if it could handle down to 131p then the flicker would be exactly the same as Andrew Davie's Chronocolour examples...

 
Turns out my C= 1084S can handle down to around 190 scanlines, about 80 frames per second. That does result in a better picture, but is still pretty bad as far as flicker goes.

#10 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,881 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Oct 22, 2016 4:50 PM

I'm still testing. 

No go on 3rd try. 27" WEGA. This display won't jitter, where others do. 

Going to try RF on a pre-2000 CRT. 

This is fun. 

 
The previous Chronocolour is part of the 128 pixel demo and outputs a steady 262 scanlines.  
 
This build was created specifically to test this idea, I'm not surprised at all that it doesn't work with a modern display.
 
Turns out my C= 1084S can handle down to around 190 scanlines, about 80 frames per second. That does result in a better picture, but is still pretty bad as far as flicker goes.

Attached Thumbnails

  • image.jpg
  • image.jpg


#11 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,881 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Oct 22, 2016 6:57 PM

Success! The Zenith 27" works. 

Figures.  That's the display that the 1-pixel playfield scroller worked, where the others would only show 3 steps or 2 steps.

I thought there was always a slight space visible between every player strip, but some places it doesn't. 

It changes also. The text has pairs on the right without gaps. 

The 100 and 200 blu car picture is different. 

And the ChronocolourTM has a big 4 player solid block then a three player solid block on the right. 

 

Maximum squish:

Atari Jr. w/scrap built S-Video:

image.jpg

 

Heavy 6er RF, no squish:

image.jpg



#12 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Oct 22, 2016 8:58 PM

The 100 and 200 blu car picture is different.


100 = 128x100 pixels
200 = 128x200 pixels

#13 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sat Oct 22, 2016 9:06 PM

Turns out the on-the-fly color conversion was taking too much time for PAL and SECAM. So I removed it and configured the project for NTSC and PAL60 builds.

Attached File  rpg_20161022_NTSC.bin   32KB   139 downloads
Attached File  rpg_20161022_PAL.bin   32KB   112 downloads

You can now run around. What you're on controls your speed: roads=fast, swamp=sluggish. The world's been expanded to 6 screens.
IMG_7700.jpg IMG_7701.jpg

Left Difficulty A changes the status line to show time remaining, with Vertical Blank on the left and Overscan on the right. Something scrambled, like this time for Vertical Blank, just means the even and odd frames are taking different amounts of time.
IMG_7702.jpg

#14 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,881 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Sat Oct 22, 2016 9:22 PM

100 = 128x100 pixels
200 = 128x200 pixels


I was still referring to the slight gap between the Players, and that each demo has different groups of Players that DON'T have the slight dark gap.

#15 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,195 posts
  • Location:Italy

Posted Sun Oct 23, 2016 2:53 AM

 

Yes, it displays correctly with right diff in 'A' position on my sixer! :thumbsup:


I added an auto-detect to the 128 Chronocolour demo. If it works right you won't have any gaps or overlaps.

 

It works! Alignment is now correct on both my 6 and 4 switches consoles.

Anyway I cannot get the tv to sync correctly. At start the screen just rolls and by increasing the scanline count with the joystick the best I can get is a stable "split-screen" arrangement like in the pictures posted by iesposta above.
Also, I only get the chronocolour car image (with NTSC colours), the firebutton doesn't cycle through different screens like previous demos. Is this the expected behaviour?



The latest RPG demos work fine! Very nice!
Previous version showed a screen-roll in SECAM mode.

 



#16 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Oct 23, 2016 8:59 AM

It works! Alignment is now correct on both my 6 and 4 switches consoles.

Awesome! I'll migrate the autodetect routine to the original 128 pixel demo.  Most likely this will happen mid-to-late November as I need to get the BUS demos I'll be showing at the Houston Arcade Expo wrapped up.

 

Also, I only get the chronocolour car image (with NTSC colours), the firebutton doesn't cycle through different screens like previous demos. Is this the expected behaviour?

Yep, I cloned the 128 demo and ripped everything else out except chronocolour in order to minimize overhead (ie: remove OverScan). That way I could shrink the scanline count (down to 240) before the car image had to be made smaller. Likewise the NTSC/PAL was changed to minimize overhead, it used to run every frame in the now missing OverScan, so I moved it to Initialize(), which only runs when you first power up. Set Left Difficulty=A for PAL then load the demo. I updated reply #7 to include this info.

 

The latest RPG demos work fine! Very nice!
Previous version showed a screen-roll in SECAM mode.


Great! There were way too many color changes to calculate for PAL and SECAM - 6 colors per scanline, so 1152 per frame. For games like Draconian that's not a problem as only a single color is calculated per display object (so maybe 20 times per frame). If there's RAM space it'd be possible for me to preconvert all the colors when you specify the TV Type via (the not yet in place) menu. However, the shape & color info is intermingled like this so it would use up a lot of RAM. 

Forest_ID = (*-Tiles)/(TILE_HEIGHT*2)
    .byte %00000000, GREEN+4  ; 0
    .byte %00010000, GREEN+4  ; 1
    .byte %00111000, GREEN+6  ; 2
    .byte %00111000, GREEN+4  ; 3
    .byte %01111100, GREEN+4  ; 4
    .byte %01111100, GREEN+6  ; 5
    .byte %11111110, GREEN+4  ; 6
    .byte %11111110, GREEN+4  ; 7
    .byte %00111000, GREEN+6  ; 8
    .byte %00010000, OCHRE+4  ; 9
    .byte %00010000, OCHRE+4  ;10
    .byte %00010000, OCHRE+4  ;11  

 

The data's like that as the C code can use unsigned short int (works with 2 bytes at a time) for faster performance when copying the player-color data into the frame buffer. You can see the impact in the current RPG demo via the TV Type switch.

COLOR = original unsigned char (works with 1 byte at a time), alternates between $10 and $11 left over in VB:
IMG_7704.jpg

 

B&W = unsigned short int, alternates between $12 and $14 left over in VB:
IMG_7703.jpg

So unsigned short int is 2-3 scanlines faster. Not enough to compensate for the color conversion routines though.

Original routine using unsigned char:

    unsigned char* player_data;
    unsigned char* tiles[12];
...
    player_data = ((unsigned char *)(DD_BASE + PLAYER_DATA));
...
           for(i=0;i<TILE_HEIGHT;i += 2)
            {
                // EVEN
                *player_data++ = *tiles[ 0]++;  // shape
                *player_data++ = *tiles[ 0]++;  // color
                *player_data++ = *tiles[ 2]++;  // shape
                *player_data++ = *tiles[ 2]++;  // color
                *player_data++ = *tiles[ 4]++;  // shape
                *player_data++ = *tiles[ 4]++;  // color
                *player_data++ = *tiles[ 6]++;  // shape
                *player_data++ = *tiles[ 6]++;  // color
                *player_data++ = *tiles[ 8]++;  // shape
                *player_data++ = *tiles[ 8]++;  // color
                *player_data++ = *tiles[10]++;  // shape
                *player_data++ = *tiles[10]++;  // color
                // ODD
                *player_data++ = *tiles[ 1]++;  // shape
                *player_data++ = *tiles[ 1]++;  // color
                *player_data++ = *tiles[ 3]++;  // shape
                *player_data++ = *tiles[ 3]++;  // color
                *player_data++ = *tiles[ 5]++;  // shape
                *player_data++ = *tiles[ 5]++;  // color
                *player_data++ = *tiles[ 7]++;  // shape
                *player_data++ = *tiles[ 7]++;  // color
                *player_data++ = *tiles[ 9]++;  // shape
                *player_data++ = *tiles[ 9]++;  // color
                *player_data++ = *tiles[11]++;  // shape
                *player_data++ = *tiles[11]++;  // color
                
                for(c=0;c<COL_COUNT;c++)
                    tiles[c] += 2;
            }

 
Revised routine using unsigned short int:

    unsigned short int* player_data;
    unsigned short int* tiles[12];
...
    player_data = ((unsigned short int *)(DD_BASE + PLAYER_DATA));
...
           for(i=0;i<TILE_HEIGHT;i += 2)
            {
                // EVEN
                *player_data++ = *tiles[ 0]++;  // shape & color
                *player_data++ = *tiles[ 2]++;  // shape & color
                *player_data++ = *tiles[ 4]++;  // shape & color
                *player_data++ = *tiles[ 6]++;  // shape & color
                *player_data++ = *tiles[ 8]++;  // shape & color
                *player_data++ = *tiles[10]++;  // shape & color
                // ODD
                *player_data++ = *tiles[ 1]++;  // shape & color
                *player_data++ = *tiles[ 3]++;  // shape & color
                *player_data++ = *tiles[ 5]++;  // shape & color
                *player_data++ = *tiles[ 7]++;  // shape & color
                *player_data++ = *tiles[ 9]++;  // shape & color
                *player_data++ = *tiles[11]++;  // shape & color
                
                for(c=0;c<COL_COUNT;c++)
                    tiles[c]++;
            }


#17 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Oct 23, 2016 9:16 AM

I was still referring to the slight gap between the Players, and that each demo has different groups of Players that DON'T have the slight dark gap.

 

 

Gotcha!

 

The gaps should appear based on when adjacent players are on alternate scanlines.  If I disable bus stuffing then the text, line, and both car demos have this arrangement:

text.png

 

where you can see the players appear next to each other a few times on the right, but not at all on the left, so you should see fewer of those slight gaps on the right side.  They should all be the same though, don't know why you're seeing different results.

 

The chronocolour demo does use a different arrangement:

chronocolour.png

 

Turning off bus stuffing causes some of the left side to get messed up for some reason, but you can still see the difference on the right side, which would cause the gaps to be different.



#18 maiki OFFLINE  

maiki

    Dragonstomper

  • 692 posts

Posted Sun Oct 23, 2016 3:23 PM

It is really bad news that you have to use interlacing because it simply sucks. On the other hand, so many people do not care about proper image of vintage video games nowadays, using crappy LCDs or plasmas... that it probably does not matter... which is bad news as well...



#19 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 760 posts
  • Location:Orlando, FL US

Posted Sun Oct 23, 2016 4:16 PM

It is really bad news that you have to use interlacing because it simply sucks. On the other hand, so many people do not care about proper image of vintage video games nowadays, using crappy LCDs or plasmas... that it probably does not matter... which is bad news as well...

 

Just because these demos happen to use interlacing doesn't mean all applications of the new BUS driver will need to. I'm sure he could have just as easily demonstrated a full width asymmetric playfield with multi colored sprites plastered all over the place.



#20 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Oct 23, 2016 5:47 PM

It is really bad news that you have to use interlacing because it simply sucks. On the other hand, so many people do not care about proper image of vintage video games nowadays, using crappy LCDs or plasmas... that it probably does not matter... which is bad news as well...


There are 5 Bus Stuffing demos so far, 3 use interlace, 2 do not. I'm running all of these demos on my C= 1084S that I've had since purchasing my Amiga 2000HD back in 91. All the demos look fine on it with the exception of the 128 Chronocolour demo.  I've stated before that the 128 Chronocolour is just an interesting tech demo, but not something useful due to the flicker.

If you're talking specifically about the RPG demo then yes, we must use interlacing to generate a 96 pixel display. There's no getting around that with the 2600. Up until now we've been able to get at most 2 colors per scanline(not counting the background color) with a 96 pixel display:
draconian.png

We wanted to see how far we could push that with Bus Stuffing and Chris came up with this 12 color version.  We thought it'd lend itself to a tile base game, so decided on a simple RPG demo to see if that was the case.  I think the results speak for themselves.

 

Same goes for the 128 pixel demos, interlace is required.

 

Anyway, these are all just demos that we're creating to test out the Bus Stuffing Driver.  We need to make sure it works correctly on real hardware, and in Stella, before we can release it for other people to start creating new games.  I didn't have to share them, but thought people might find them interesting as we've been talking about Bus Stuffing for years with nothing to show until now.   If you don't find them interesting, then don't download them.



#21 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,616 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Sun Oct 23, 2016 11:15 PM

It is really bad news that you have to use interlacing because it simply sucks. .


Why does interlace suck? On a CRT screen the flicker is hardly noticeable. Many Atari games use flicker, and a constant 30hz interlace looks far better than 15hz flicker.

I agree that it looks poor on an LCD TV, but that is because the image is not handled properly by the TV.

Chris

#22 alex_79 OFFLINE  

alex_79

    Stargunner

  • 1,195 posts
  • Location:Italy

Posted Mon Oct 24, 2016 10:29 AM

constant 30hz interlace looks far better than 15hz flicker.

 

It's also better than non-interlaced 30Hz flicker, altough a little worse than a standard 625/525 lines interlaced TV signal, where scanlines are closer together.

 

The RPG demo looks really good on real hardware.

Especially for large solid tiles (like the rocks and the trees), the perceived flicker is minimal and it gets even better if you back away a bit from the screen. In the "grass" tiles with small green dots on black background flicker is a bit more evident.

Anyway, by tweaking the colors and the graphics to minimize the effect, I think that the kernel could be very well used in a game.


Edited by alex_79, Mon Oct 24, 2016 10:29 AM.


#23 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Mon Oct 24, 2016 11:15 AM

I guess the snow-peaked mountains need something better than programmer graphics :lol:
 
Mountain_ID = (*-Tiles)/(TILE_HEIGHT*2)
    .byte %00000000, WHITE      ; 0
    .byte %00001000, WHITE      ; 1
    .byte %00011000, WHITE      ; 2
    .byte %00111100, WHITE      ; 3
    .byte %00111100, WHITE      ; 4
    .byte %00111100, OCHRE+12   ; 5
    .byte %01111110, OCHRE+10   ; 6
    .byte %01111110, OCHRE+8    ; 7
    .byte %01111110, OCHRE+6    ; 8
    .byte %11111111, OCHRE+4    ; 9
    .byte %11111111, OCHRE+2    ;10
    .byte %11111111, OCHRE      ;11
 
I've made a color change which may help:
Mountain_ID = (*-Tiles)/(TILE_HEIGHT*2)
    .byte %00000000, WHITE      ; 0
    .byte %00001000, WHITE      ; 1
    .byte %00011000, WHITE      ; 2
    .byte %00111100, WHITE      ; 3
    .byte %00111100, OCHRE+6    ; 4
    .byte %00111100, OCHRE+6    ; 5
    .byte %01111110, OCHRE+4    ; 6
    .byte %01111110, OCHRE+4    ; 7
    .byte %01111110, OCHRE+2    ; 8
    .byte %11111111, OCHRE+2    ; 9
    .byte %11111111, OCHRE      ;10
    .byte %11111111, OCHRE      ;11
 
rpg.png IMG_7707.jpg

I have asked for contributions if anybody's willing :)

#24 iesposta OFFLINE  

iesposta

    River Patroller

  • 3,881 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Mon Oct 24, 2016 12:16 PM

I keep asking, but get no definitive answer. 

From what I have learned, it seems to me "VCS flicker" and "interlaced display kernel" are different. 

Tell me if this is wrong, please. 

 

If the VCS sends the CRT a properly formed NTSC interlaced scan lines, which are like flicker Frame A and Frame B, using the spec of almost what kernels are using with the 3 Vblanks etc, but in the proper line format of the first and last scan line being "half a scan line" we would have 480i. 

Doesn't the CRT display 480i better than the "VCS flicker"????

 

The true interlaced demos look like a new display mode to me, and not like flicker. 

 

And wouldn't the extra work to get this output be lessened by splitting work up in both A & B frames?

 

Would this true Atari interlaced mode be 480i at 30Hz or 30 FPS, but real broadcast TV is 480i 60Hz 60 FPS, or am I mixing apples and oranges?



#25 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • Topic Starter
  • 12,620 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Mon Oct 24, 2016 1:02 PM

They are different. If you look closely at the display of the 2600 you might notice that the scanlines are thicker than the gaps between the scanlines. What you think of being like this:
 
xxxxxx

xxxxxx

xxxxxx
 
(xxxxxx = scanlines, blanks = gap between scanlines) is more like this:
xxxxxx
xxxxxx
xxxxxx

xxxxxx
xxxxxx
xxxxxx

xxxxxx
xxxxxx
xxxxxx
 

The alternate frame for a 480i signal would be like this:
xxxxxx

xxxxxx
xxxxxx
xxxxxx

xxxxxx
xxxxxx
xxxxxx

xxxxxx
 
So the upper & lower edges of the scanlines of the even and odd frames overlap(capital XXXXXX), which helps to hide the flicker.
XXXXXX
xxxxxx
XXXXXX
xxxxxx
XXXXXX
xxxxxx
XXXXXX
xxxxxx
XXXXXX
xxxxxx
XXXXXX
 
An interlaced display gives you more vertical detail.

The reason we typically use flicker on the VCS is to show more horizontal detail per scanline than the VCS is capable of - more than 2 independently moving sprites, more than 48 pixels, more colors (such as the timer in Lady Bug), etc.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users