Best way to understand the differences?

[Jeff-20]

This discussion alone is a victory for the vic.

[adric22]

I agree with Boray that VIC competes with VIC-II in terms of on-screen color and resolution; and VIC is faster with its low resolution modes of its own. But throw in C64 hardware sprites, well, that's a horse of a different color.

I guess we have different definitions of "compete." When I think of compete I think of two competitors that are in the same league. That means either player has a chance to win. Sort of like the Amiga could compete with IBM VGA graphics. In some cases the Amiga would win out where in others the VGA might win depending on who's strengths you are playing to.

I'm sorry but the VIC-20 is not in the same league with C64 graphics.

[Boray]

Picture's look better when they are smaller, don't they. Not only smaller. Those pictures you posted are not representative of how they would look like on a C64. The FLI format used would probably flicker and the c64 display is a bit grainy and blurry. Those pictures is just an optimal dream representation of the graphics data itself.

Vic-20:


Normal Multicolor C64 picture:



Anyway, I actually went here to mention that the diskdrive is about 20% faster on the Vic-20. The default mode for the 1541 is however the slower c64 speed so to get the faster speed on the vic-20, you have to do this command: OPEN15,8,15,"UI-":CLOSE15

[TMR]

Picture's look better when they are smaller, don't they. Not only smaller. Those pictures you posted are not representative of how they would look like on a C64. The FLI format used would probably flicker

Landing in the Village is a NUFLI format image so it's 320x200x16 without interlace. Apart from size, that's not far off what my C64 puts out.

[Boray]

Ok, that's cool. I wasn't aware that something like that existed. But my c64 display is certainly not as clear as my modern PC. If you make a pixel by pixel grid (10101010) on my c64, every other character looks greenish and every other purplish. I guess this is the reason why they thickened the character set on the c64.

[Boray]

Does this NUFLI method work on the Plus/4 as well? That would be cool with all those colors.

[Boray]

deleted

[TMR]

Ok, that's cool. I wasn't aware that something like that existed. But my c64 display is certainly not as clear as my modern PC. If you make a pixel by pixel grid (10101010) on my c64, every other character looks greenish and every other purplish. I guess this is the reason why they thickened the character set on the c64.

That's artifacting and most 8-bits of the same era suffer from it when handling pixels that are less than one colour clock wide, especially when running NTSC; due to some deliberate designing around it the problem is far less of an issue on the C64 than it is the Apple 2 or Atari 8-bit where some games actually rely on the colours generated by artifacting for in-game graphics.

The problem is reduced by using a PAL machine and knocked back further by running with a monitor or television that accepts chroma and luma separately.

Does this NUFLI method work on the Plus/4 as well? That would be cool with all those colors.

It's a combination of AFLI and hardware sprites with colour splits so isn't possible on the Plus/4; the closest thing at the moment is DFLI.

[Boray]

Thanks for the explanation. I suspected there were sprites involved.

[RJBowman]

That's artifacting and most 8-bits of the same era suffer from it when handling pixels that are less than one colour clock wide, especially when running NTSC; due to some deliberate designing around it the problem is far less of an issue on the C64 than it is the Apple 2 or Atari 8-bit where some games actually rely on the colours generated by artifacting for in-game graphics.

Apple II's Hi-Res graphics hardware was designed specifically to take advantage of artifacting to produce color.

[TMR]

That's artifacting and most 8-bits of the same era suffer from it when handling pixels that are less than one colour clock wide, especially when running NTSC; due to some deliberate designing around it the problem is far less of an issue on the C64 than it is the Apple 2 or Atari 8-bit where some games actually rely on the colours generated by artifacting for in-game graphics.

Apple II's Hi-Res graphics hardware was designed specifically to take advantage of artifacting to produce color.

The same is true for some NTSC games for the Atari 8-bit, the issue isn't as obvious with the PAL machines though and the colours produced change depending on the video hardware.

[ral-clan]

I don't know if anyone has mentioned a big difference between the C64 and VIC:

C64 has 40 columns of text - VIC has 22
C64 has the legendary SID audio synth chip - VIC has only square wave audio
C64 has sprites - VIC doesn't

Still, I like the VIC-20 better.

[Mike]

These are limitations only when you stick to the letter of the book:

C64 has 40 columns of text - VIC has 22

Here's MG Browse, displaying ASCII texts in 40 columns on the VIC-20. The routines were also used in the VIC Bible series.

C64 has the legendary SID audio synth chip - VIC has only square wave audio

Both can output digitized sounds over the volume register. The VIC-20 can emulate the SID to a great degree, see here.

C64 has sprites - VIC doesn't

Even though I'd have to admit defeat on this one (the VIC-I chip simply doesn't have that extra DMA to overlay sprite data seamlessly), there's Robert's Software Sprite Stack, which does a tremendous job putting lots of moving objects on the screen.

I'm sorry but the VIC-20 is not in the same league with C64 graphics.

It's quite interesting what the VIC-I chip is capable of, when one removes some limitations on the mainboard ... see here.