Vintage raster fonts on modern systems/websites

[deathshadow]

I'm working on a redesign of my website and been playing with the idea of recreating the CGA font. There are existing ones like "Ultimate Oldschool PC Font Pack":
http://int10h.org/oldschool-pc-fonts/fontlist/

But, well.. in the case of CGA fonts I think that the mentality of it may be all wrong. It concentrates VERY hard on hammering the fonts into pixel boundaries, which would make sense you want the glyphs perfectly formed -- EXCEPT that if you have ever sat in front of a real RGBI display, you know damned well that's NOT what happens! No matter how much you play with the adjustments the majority of RGBI displays -- even the highly vaunted 5153 or my personal favorite, the Tandy CM-5 -- the pixels never line up with the colour mask no matter how much you play with it.

To that end, something like cleartype's subpixel hinting or even just greyscale rendering could aid in making it feel more authentic BECAUSE it is less accurate and causes horizontal blurring. Same goes for sizing the font to the screen pixels -- why bother, it's not like CGA ever came CLOSE to lining up with the colour mask. Remember how mind-blowingly sharp EGA seemed when it came out? Yeah, that. You want to make it look like the older systems, you don't want it that sharp with the perfect alignment!

But even with that, what could be done to make it feel more realistic? First thing that came to mind was actually implementing the colour mask using generated content over the page elements. It's not precise and requires a bit of 'trickery' to make it so we don't break anchors, but a simple transparent .png could work wonders on that front.

Another thing to consider is the barely perceptible flicker of the scan/retrace missing on modern displays. If we're going to have a colour mask, maybe requestAnimationFrame could be used to swap a class then have CSS do the heavy lifting?

So to this end, I've made my own CGA font -- It's by no means codepage complete but since 99.99% of my content is restricted to the bottom 7 bits of ASCII, I really could give a flying purple fish about extended characters.... which has the nice side effect that my font ends up not even breaking the 12k mark as EOT. I went with a mostly CGA-like font more akin to the tandy one, but with a taller line-height.

Whilst I want the retro feel, I don't want to sacrifice usability or accessibility, and that means larger padding instead of hammering everything into pixel boundaries. It means font sizes that obey the system metric, not dipshitting pixel font sizes into the CSS.

Been playing with this on and off for a couple months -- got put on the back burner with a full time job that turned out to be a full time scam -- but this is what I have so far:

http://www.cutcodedown.com/prototype/prototype.periodAccurate.html

Thoughts, Ideas?

 

[deathshadow]

Oh, side note, I have NO idea what that's going to do on a quackintosh or linsux, much less mobile as I've NOT tested that deep yet. Given how OSuxxors blurs everything to be illegible, and freetype kerns like a sweetly retarded crack addict... I'm not hopeful about the result.

 

[Malc]

My honest opinion, I don't like it, I'm struggling to read the text, My eyesight is not as good as it used to be and that font on a black background is not working for me, If i turn off the flicker / mask / font it's better but still hard to read, Sorry i much prefer the old design, It's clean and i can read the text without straining my eyes.

 

[glitch]

Looks fine on Firefox ESR 52.1.0 on Slackware 14.2. Looks like old CRT fonts.

 

[krebizfan]

Readable enough with IE 11 on Windows 7. Very challenging to read using Chrome and the CPU usage spikes; that webpage is managing to send 4 cores each to about 50%. Which is bizaare.

 

[vwestlife]

Others have noticed that CRTs have a pixel blending effect that makes low-res graphics and text look less blocky:

To my eyes, a dot pitch of around 0.40 mm is just about right for CGA-res graphics. Anything much higher (like the Tandy CM-5's 0.63 mm) and the image looks fuzzy and out-of-focus, and anything much lower (like displaying CGA on an EGA or Multisync monitor) and you begin to see gaps between the scanlines.

 

[commodorejohn]

My honest opinion, I don't like it, I'm struggling to read the text, My eyesight is not as good as it used to be and that font on a black background is not working for me, If i turn off the flicker / mask / font it's better but still hard to read, Sorry i much prefer the old design, It's clean and i can read the text without straining my eyes.

Yeah, this isn't great. It's hard to read and doesn't really resemble CRT blurring anyway.

 

[reenigne]

It'd be nice to see the correct aspect ratio and a scanline/mask filter that doesn't make the image darker, but I appreciate that those are much more difficult to do within the constraints of a usable, accessible website.

I don't quite understand the flicker effect, though. A real CGA monitor flickers at a whisker under 60Hz, but is rock solid as far as lower frequencies are concerned (at least the ones I have are, despite running on 50Hz mains power instead of the 60Hz power they were designed for). To reproduce the 60Hz flicker in software would require a modern monitor with a refresh rate of 120Hz or faster because of the Nyquist limit. If I understand your code correctly, it looks like its supposed to flicker at 30Hz. In practice (on my machine at least) it seems to be much slower than that, maybe 2-3Hz (in fact it sort of looks like it's trying to reproduce the aliasing effect of a recording of a CGA monitor made with a TV camera that isn't synchronized to the monitor).

 

[KC9UDX]

Much of apparent flicker is due to non-incandescent electric lighting operating at mains frequency, not the monitor itself. It sounds like that's what you're experiencing, if I understand you correctly.

 

[deathshadow]

My honest opinion, I don't like it, I'm struggling to read the text, My eyesight is not as good as it used to be and that font on a black background is not working for me, If i turn off the flicker / mask / font it's better but still hard to read, Sorry i much prefer the old design, It's clean and i can read the text without straining my eyes.

Might I ask what OS/Browser/Platform? I'm interested more in where it fails than I am in deploying it real world... I do know that anything less than IE11 is NOT going to handle it well because they have no RequestAnimationFrame, relying on setTimeout as a fallback which is... less than reliable. (that's being polite, it's complete shit)

Readable enough with IE 11 on Windows 7. Very challenging to read using Chrome and the CPU usage spikes; that webpage is managing to send 4 cores each to about 50%. Which is bizaare.

That is odd behavior for Chrome, but then I've found ZERO consistency in Chrome across platforms... one of the reasons I use Vivaldi instead is that it seems to be more consistent/reliable.

Anything much higher (like the Tandy CM-5's 0.63 mm) and the image looks fuzzy and out-of-focus

Which pretty much describes every "period correct" CGA display I've ever used/seen. It's like the cheaper VGA displays that were only 0.52mm dot pitch, meaning you were often better off forcing it back to 640x400 mode for text instead of the 720x400 VGA defaults to.

That fuzzy/out of focus is kind of what I was aiming for since that's what CGA was, and why anyone who worked more than ten minutes with text on a PC went monochrome until EGA came along.

I don't quite understand the flicker effect, though. A real CGA monitor flickers at a whisker under 60Hz, but is rock solid as far as lower frequencies are concerned (at least the ones I have are, despite running on 50Hz mains power instead of the 60Hz power they were designed for).

I always found it highly noticeable, but not painful which is what I was aiming for and what you get IF the combination of browser+OS+Hardware is up to snuff. Problem is tablets aren't, phones aren't... and it would seem bargain basement LCD's aren't... and of course that there is no requestAnimationFrame in IE10/earlier meaning you're stuck at closer to 15hz -- completely unacceptable.

If I understand your code correctly, it looks like its supposed to flicker at 30Hz.

RequestAnimationFrame when supported by the browser delivers the refresh rate as your timer, whatever it is. Since you can only call at that rate, that's the rate I'm flipping between masks. Again though, not all browsers support it which is why my elementals.js library offers a polyfill for it that does the best browsers can manage... which usually sucks out loud and why it's WAY past due for the shotgun blast to the back of Microshaft Interdebt Exploder's head.

In practice (on my machine at least) it seems to be much slower than that, maybe 2-3Hz (in fact it sort of looks like it's trying to reproduce the aliasing effect of a recording of a CGA monitor made with a TV camera that isn't synchronized to the monitor).

That sounds quite far off, like you're getting the polyfill instead of modern browser support.

Again, standard question what browser/os/hardware?

Still just an experimental idea, probably going to take some ideas from it, but deep six a lot of it too. I actually like the simplicity with hard-lines of the layout -- would work better if I stopped limiting myself to the 05AF luma ranges. As it is I used #005 on the background which CGA couldn't ever deliver, just because using the dot-pattern had that horrible scroll effect.

... and you guys should be glad I disabled the audio code, it was set to produce a 19hz drone just to screw with people's heads because, well... I'll be honest, I rage coded that entire layout. That entire page concept is a giant middle finger to a certain group of web developers.

 

[commodorejohn]

well... I'll be honest, I rage coded that entire layout. That entire page concept is a giant middle finger to a certain group of web developers.

Okay, now I'm intrigued :D

 

[reenigne]

I always found it highly noticeable,

But was it a 60Hz flicker or a 30Hz flicker that you noticed?

RequestAnimationFrame when supported by the browser delivers the refresh rate as your timer, whatever it is.

https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame says "The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers". Since the vast majority of displays are 60Hz, it's safe to assume 60 callbacks per second is the common case. Since a period of flicker would be one bright frame and one dark frame, that would give a 30Hz flicker.

That sounds quite far off, like you're getting the polyfill instead of modern browser support.

Again, standard question what browser/os/hardware?

Chrome 58, Windows 7, Core 2 duo laptop from 2006. I'm guessing my machine is just to slow to update 60 times per second. I'll try it on a faster machine later and see how it looks there.

... and you guys should be glad I disabled the audio code, it was set to produce a 19hz drone just to screw with people's heads because, well... I'll be honest, I rage coded that entire layout. That entire page concept is a giant middle finger to a certain group of web developers.

Heh - well, thank you for disabling that! Was there a "period correct" reason for it? Closest thing I can think of is the 18.2Hz timer interrupt, which I guess could make a sound if there was interference between the interrupt handling logic and the PC speaker lines on the motherboard.

 

[Malc]

Might I ask what OS/Browser/Platform? I'm interested more in where it fails than I am in deploying it real world... I do know that anything less than IE11 is NOT going to handle it well because they have no RequestAnimationFrame, relying on setTimeout as a fallback which is... less than reliable. (that's being polite, it's complete shit)

Win XP, Firefox ESR 52.1.2, P4 3GHz Desktop

 

[Caluser2000]

Oh, side note, I have NO idea what that's going to do on a quackintosh or linsux, much less mobile as I've NOT tested that deep yet. Given how OSuxxors blurs everything to be illegible, and freetype kerns like a sweetly retarded crack addict... I'm not hopeful about the result.

On an old AcerPower F1 using linux 2.6.28 kernal, running XFCE with Seamonkey 2.40 looks ok. Took a bit for eyes to adjust. Best viewed in a darkened room.

 

[vwestlife]

I see no difference with the flicker turned on or off. (IE11, Windows 7 64-bit, Core 2 Duo E7500, Intel onboard graphics, LCD monitor @ 60 Hz).

 

[reenigne]

I'll try it on a faster machine later and see how it looks there.

The effect isn't visible at all on my Core i7 920 machine (again Windows 7, Chrome 58). I'm guessing that's just because the monitors connected to it don't have a fast enough response time to display it.

 

[deathshadow]

Those of you barely seeing it or not seeing it at all are likely the ones seeing it CORRECTLY. I've tried a bunch of hardware all the way down to P3, and it would appear that if your browser is not using hardware video acceleration, or it is relying on integrated graphics, you are NOT getting the 'proper' experience.

Min spec for video appears to be Ge7xxx era, again assuming the browser is using it properly which means Win7+. Like nVidia ION even on a Atom processor will deliver it properly, intel HD on a P4 will not.

I mean it's SUPPOSED to be 30hz with less than 2% luma diffference, you shouldn't really be able to consciously see it unless you're intentionally looking for it.

https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame says "The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers". Since the vast majority of displays are 60Hz, it's safe to assume 60 callbacks per second is the common case. Since a period of flicker would be one bright frame and one dark frame, that would give a 30Hz flicker.

Which is why the contrast level between them is so low -- so low that it shouldn't be as visible as it is on lesser configurations. I'm actually wondering on some of these systems if the second image is failing to load or something stupid like that it's so far off from what it is SUPPOSED to do.

... and realistically in modern displays 120hz and 144hz are becoming more and more commonplace, particularly as we move to 4k+ displays. My workstation for example has a 27" 2560x1440 IPS that does 120hz... along with a el-cheapo 24" 1920x1200, an expensive samsung 24" 1920x1200, and a pair of 17" 1024x1280 (yes, pivoted). I run the differing display types on purpose so that when working on professional sites and design, I have some clue how different it will appear across them instead of blindly trusting that the bleeding edge screen is what everyone else is going to get.

Heh - well, thank you for disabling that! Was there a "period correct" reason for it? Closest thing I can think of is the 18.2Hz timer interrupt, which I guess could make a sound if there was interference between the interrupt handling logic and the PC speaker lines on the motherboard.

Nothing related to period hardware at all. Was literally psychological warfare. Was going right for the perfect 'infrasound' frequency that requires less volume to be effective ... because I could.

https://en.wikipedia.org/wiki/Infrasound

It's often used in horror movies to help invoke the feeling of illness, unease, and paranoia. I didn't want to subject you guys to that -- unlike "designers", I like you guys.

 

[commodorejohn]

Okay, but seriously, dish on this revenge thing :lol:

 

[VileR]

As the guy who made the font pack you linked to in the OP... yep - there are a ton of headaches and compromises involved in getting these things to look "right" on a modern system. Aspect ratio is the first thing that pains me, but in retrospect, perhaps I should've enforced the correct aspect for every one of these fonts, e.g. CGA fonts should be ~83% as wide as they are, VGA 9-column fonts 75%, etc. Should be fine as long as you only modify the *width* (most current font renderers seem deal with that gracefully... departing from the grid along the y axis is a whole other story).

And then there's everything else - trying to simulate dot masks, scanlines, flicker, etc. is too context-dependent. You can sort of pry the functionality out of a browser if the stars (and w3c standards) happen to be aligned just right this particular week, but your favorite text editor or file manager are probably not going to support this.

That's why I decided to keep things simple with those fonts, even if it doesn't exactly give the perfect oldskool experience out of the box. Perhaps it should be possible to have just the scanline effect 'baked into' the fonts, since the number of scanlines per cell is intrinsic to the character set... but then that rules out simulating things like VGA scan-doubling.

Another approach is to have the vector outlines follow the perceptual shape of the glyphs, instead of the pixel grid. I did try that for the 9x16 VGA font - this time there's an aspect-corrected version, too:



...but as you can see, it sort of falls apart at large sizes with that rounded effect giving it a Comic Sans look. The advantage is that you can get away with arbitrary sizes that aren't multiples of the original height, but apparently there are some pitfalls here too... this screenshot is from a browser, and on Windows most browsers use DirectWrite these days which plays nice with unaligned horizontal strokes. Most other software still seems to be stuck with GDI however, and I'll save you the nauseating experience of seeing what that looks like.

Anyway, as for your site, I cannot notice any flicker - tried with an up-to-date Firefox (win7 on an i7-4790, GTX 550 Ti).

And in the nitpicking corner... are you sure it's the CGA font? Lowercase characters look too wide, more like one of the Tandy 1000 variants.

 

[deathshadow]

And in the nitpicking corner... are you sure it's the CGA font? Lowercase characters look too wide, more like one of the Tandy 1000 variants.

... and I quote:

I went with a mostly CGA-like font more akin to the tandy one, but with a taller line-height.

I wasn't aiming for perfect 1:1 CGA if for no other reason that the BS short line-heights that compromise legibility disastrously.

You also have the aspect ratio squishing, which I did NOT compensate for at all.