Secret colours of the Commodore 64 • Hacker News Board

Re: Secret colours of the Commodore 64

#71

Post by ldite » Thu, Mar 23, 2017, 11:15 AM UTC

rusk wrote: post #49

flashman wrote: post #37

> Sidebar: A note on frames per second. The European PAL C64 updated at 50fps, whereas the US NTSC systems updated at 60fps This is because alternating current is 50Hz in PAL countries (eg Europe), and 60Hz in NTSC countries (eg America). Analogue TVs vertical refresh rate was synced to the AC frequency for a bunch of practical reasons, which meant gaming consoles had to send signals to the television at either 50Hz…

> for a bunch of practical reasons Basically makes it cheaper to build. You have a natural frequency there to use, and you don't have to come up with all this additional hardware to smooth out the existing frequency and come up with a new one. I think there was a flip-side to this ... though NTSC had faster refresh, PAL had a higher resolution (more lines). I'm not sure, but I think this may have been a tradeoff.

It also reduced the effects of mains interference. If you had a 60Hz vertical scan, but there was interference from 50Hz mains (as there often was) then this would cause rapid rolling vertical distortion.

At 50Hz, even if the vertical sync wasn't actually locked to the mains frequency, any mains distortion would roll much, much more slowly, and be less offputting.

Re: Secret colours of the Commodore 64

#72

Post by vanderZwan » Thu, Mar 23, 2017, 11:18 AM UTC

I'm wondering why they went with a dragon boss that flipped from one solid color to the other - wouldn't switching between a checkerboard pattern of the two colours have worked better?

Re: Secret colours of the Commodore 64

#73

Post by Flow » Thu, Mar 23, 2017, 12:19 PM UTC

kazinator wrote: post #22

I remember writing a piece of machine language on a C-64 which flipped the color palette as fast as possible. It was so fast that all you saw was individual horizontal line segments of different colors within every individual raster line. (I.e. it was faster than the horizontal refresh rate of the CRT which is usually what, well over 10 kHz.) Sheesh, when was that? Probably 1985.

Mid-rasterline color splits, often combined with snakes of sprites, often with border removal effects.

Watch this demo for state-of-the-art in that kind of programming on the C64.

https://www.youtube.com/watch?v=lseBxJYpz54

Re: Secret colours of the Commodore 64

#74

Post by renaudg » Thu, Mar 23, 2017, 12:21 PM UTC

I guess it's all about which 8-bit we have fond memories of but ... the C64 is not known for having a great palette. It looks rather dull and washed out.

The Amstrad CPC probably had the most vibrant palette of all of the 8-bits.

A C64 artist even tried to prove otherwise, but IMHO scored an own goal : http://www.indieretronews.com/2016/02/is-c64-palette-far-sup...

Re: Secret colours of the Commodore 64

#75

Post by jacobush » Thu, Mar 23, 2017, 12:22 PM UTC

phire wrote: post #55

Lerc wrote: post #6

Earlier quoted context omitted.

I was under the impression that there must have been some additional signaling to make interlacing happen. If for no other reason than the display would need to know which frame was the upper scanline and which was the lower. Apart from the fact that they would have advertised the increased resolution (albeit flickery). On the Amiga, which did do interlaced modes. you could tell on a screen showing a single colour wh…

It's not an additional signaling. TVs were designed in the 30's, where electronics were extremely primitive and expensive. You wanted the consumer device to be as simple as possible so it could be within the consumer price range. So TVs were little more than a Radio receiver hooked up to a cathode ray tube (CRT). To drive a CRT you need 3 signals: X position, Y position and brightness. The dumbest possible design is…

Amiga had the A2024 monitor and I always thought is was kind of quad interlace weird interlace for an exotic monitor with long afterglow.

However, the thruth is different but also strange. http://bboah.amiga-resistance.info/cgi-bin/showhardware_en.c...

Apparently, the monitor samples four frames, puts them in 4 frame buffers, then outputs a complete image to the CRT, each frame representing a quadrant on the screen. Must have been very expensive...

Re: Secret colours of the Commodore 64

#76

Post by c64d81744074dfa » Thu, Mar 23, 2017, 12:22 PM UTC

vanderZwan wrote: post #72

I'm wondering why they went with a dragon boss that flipped from one solid color to the other - wouldn't switching between a checkerboard pattern of the two colours have worked better?

Yes but it looks like this wasn't possible. C64 multicolor sprites have 4 colors and it looks like one frame of the dragon is already using 4 colors.

Also, having two separate ditherings of each sprite would use twice the memory per sprite, and that dragon looks to be composed of multiple sprites and possibly multiple frames of animation per sprite. Most games were memory limited, which means the devs had to make several compromises just to get the game to fit at all.

Re: Secret colours of the Commodore 64

#77

Post by mb_72 » Thu, Mar 23, 2017, 12:23 PM UTC

As an Australian user of the TRS-80 Color Computer I was always disappointed the artificating technique: https://en.wikipedia.org/wiki/Composite_artifact_colors ... didn't work on PAL so I never got to see all the 'cool' colours promised on game adverts in USA-based magazines!

Re: Secret colours of the Commodore 64

#78

Post by dzdt » Thu, Mar 23, 2017, 12:25 PM UTC

Question: the demos on the website are not smooth in my mobile chrome browser. Is it even POSSIBLE to get glitch free per display frame update in a browser? I grew up with the c64; the kind of tearing and frame-rate glitches we see on nearly every other platform since make me sad!

Re: Secret colours of the Commodore 64

#79

Post by Filligree » Thu, Mar 23, 2017, 12:42 PM UTC

dzdt wrote: post #78

Question: the demos on the website are not smooth in my mobile chrome browser. Is it even POSSIBLE to get glitch free per display frame update in a browser? I grew up with the c64; the kind of tearing and frame-rate glitches we see on nearly every other platform since make me sad!

If all the stars align. So, basically, no.

There are too many layers, half of which don't synchronize correctly, and if even one is out of alignment you'll get tearing/stuttering.

Re: Secret colours of the Commodore 64

#80

Post by simias » Thu, Mar 23, 2017, 12:58 PM UTC

rusk wrote: post #49

flashman wrote: post #37

> Sidebar: A note on frames per second. The European PAL C64 updated at 50fps, whereas the US NTSC systems updated at 60fps This is because alternating current is 50Hz in PAL countries (eg Europe), and 60Hz in NTSC countries (eg America). Analogue TVs vertical refresh rate was synced to the AC frequency for a bunch of practical reasons, which meant gaming consoles had to send signals to the television at either 50Hz…

> for a bunch of practical reasons Basically makes it cheaper to build. You have a natural frequency there to use, and you don't have to come up with all this additional hardware to smooth out the existing frequency and come up with a new one. I think there was a flip-side to this ... though NTSC had faster refresh, PAL had a higher resolution (more lines). I'm not sure, but I think this may have been a tradeoff.

You have more lines with PAL but in practice since most of the game devs were either in Japan or in the US (with a few notable exceptions) most games were designed for NTSC and many didn't bother to increase the resolution when porting to PAL. Furthermore many games refreshed the display at half the video framerate so you end up with 25fps on PAL.

So in many cases you end up with games that run at 5/6th the nominal speed and have black bars at the top and bottom of the screen. PAL gaming was pretty crap, but of course at the time I didn't know any better and I didn't understand english anyway, so it's not like I had a choice...