I didn't think Stella's CRT emulating was all that accurate IMO. I mean, it wasn't like the NTSC filter in some recent SNES/NES emulators.

I've always wanted a 'virtual monitor' too. I remember some replies along the lines of 'thats impossible', but..... how the hell is this screensaver for X being more faithful than even Apple 2 emulators!?

Calling it an impossibility is just laziness. 😜

If I knew more about shader language I'd just make one myself and be done with it - it's very possible. I made my efforts, though, and didn't manage, as I said..

I've seen that screensaver - there's Stella (keep in mind it's emulating an aged late 70s/early 80s TV), NES/SNES emulators as you said, MAME (I think it has a CRT emulating filter, no?)... home computer emulators (Apple/Mac/PC/etc.) seem to be behind in that respect, at least console emulators have a few examples.

All MAME has is a lazy aperture pattern overlay - no CRT wackiness like oddities like flicker and color bleed.

A virtual monitor emulator could lead into a render-to-texture overlay on a 3d monitor in a virtual computing environment (running at a VERY HIGH refresh rate w/ vsync) where there's a fully modeled computer with glsl shaders spit all over it, like Far Cry 2 pcs but....... not fictional! Like those virtual pinball emulators. That way, you can throw in some displacement mapping on the screen to get the curvature for free thanks to GPU muscle, and the like. And then you throw in 3d support.......

in other words, virtual this-guy

I've had that thought too, but I think it would be better to stick to just rendering the emulator surface to a warped model - I think that's what you meant as well, but I don't want to confuse anybody who might help us! 😁 There's two ways to go about that, the other being warping the 2D output itself per-frame with shaders/scalers, as I said.

Your thought would be especially tantalizing when real "3D" monitors come out, and I don't mean 3DS-style 3D, I mean holographics, we do have these things now, you know - it's just $20000 for a black and white holographic monitor and $25000 for a (crappily) color-capable version (I actually requested quotes a few years back, heh). The interesting thing is they're touch capable.. seems a leap forward before making the base technology cheaper - 🤣.

I'm pretty sure you could do this fairly easily with a compositing window manager such as Compiz on Linux, which renders everything via OpenGL as a texture or surface. It has all kinds of effects, including transparency and window warping - now you just need to write a plugin to do it 😀

Unfortunately that won't help on Windows (which I primarily use - yes, a technical person who uses Windows by choice... O.O), and wouldn't be cross-platform. DWM on Windows (Vista+ anyway) is also a compositing WM, but it's very undocumented and obscure to hook into it in almost any way (thus the lack of fancy plugins for Windows like Compiz has). I feel that code internal to DOSBox would be the best solution, because it would be crossplatform - fully. I do see what you mean, though - the "works with any program" version of the concept. A shader would be the easiest, I think, but they're only supported for DirectX output (who knows why we don't have OpenGL shaders for OpenGL output mode, then it would be universal...) and only on patched builds, so that's not really universal either. Scalers are, but I'm not sure if you can write a scaler that wouldn't interfere with the common setting to scale everything to the desktop resolution that people like me typically use (typically with no scaler).

Yushatak wrote:

CRTs in good working order are becoming harder and harder to get, but few people realize how important they are to the gaming experience.

This is why I'm keeping all of my CRT's. The best time to get a couple was a period a couple years ago, when excellent CRT's were dumped en-masse for free (BUT pick-up only, 🤣).
They are becoming harder to find as most people tossed them already and the ones that are available are becoming less excellent and a bit more expensive.

I expect this trend to continue, CRT sales becoming less frequent, price slowly getting higher and the choice becoming less.

I've got a dozen or so functional CRTs, but the two that are of a quality that I could use with a modern machine for anything but DOSBox are damaged slightly. My 19" (one I used on my main desktop when it was new) is blurry, literally from the number of hours it was used. My 21", which I bought from a friend during that "get rid of CRTs" era for $100, is too dim. It looks alright on it's own, but when I place it next to my LCD it looks like crap, and it's "natural" resolution is 1280x1024, which isn't actually all that large (not to mention it's still very dim).

What I mean by natural resolution is the physical size of the objects on the screen (I use icons to measure) that (almost) matches the size of the objects on an LCD at it's native resolution. I find that most LCDs have the same size, and most CRTs do as well, but only at a certain resolution (on a CRT I imagine this is related to dot pitch). Everything looks fine on them at various resolutions, but as a CRT ages the higher resolutions start to lose cohesion and sharpness, brightness, etc.. Anything higher than 1280x1024 is hard on that monitor now, while it comfortably did 2048x1536 in it's heyday. As the CRT slowly dies, you have to turn the resolution down another click every few months of use to keep the image comfortable on your eyes, or it gets blurry and becomes uncomfortable to look at.

I have one nice CRT left that's almost new, but it topped out at 1280x1024 in the first place, and I don't think it ever displayed that resolution properly even when new. It runs 1024x768, and that's a bit small for a modern OS to be usable, even for a secondary monitor, due to the (REALLY DAMN STUPID) forced increases in DPI between XP and Vista. I've found ways of scaling it back down in DPI using registry hacks, but everything gets jagged and "blurry" then..

I had been banking on those fancy compact CRT displays that were being developed. Same depth as an LCD, but with the quality of a CRT, based on that old technology. Can't remember their acronym.. anyway they got canceled, which was IMMENSELY disappointing to me.

Anyway it doesn't look like they're coming back or showing up en masse any time soon, so I recommend we get some emulation going before there's no CRT to reference. 😮

I'm actually happy that I do not have to look at the shortcomings of old monitors...

The people on the MAME forums are upset CRT's are getting harder to find too. Arcade games on anything other than a CRT doesn't look right, not to mention downright impossible to see when trying to build a horizontal cocktail cabinet.

h-a-l-9000 wrote:

I'm actually happy that I do not have to look at the shortcomings of old monitors...

Convergence, geometry and weight/size are not the good points of CRT's, but lack of blurring, input lag; color accuracy, blacks and support of various native resolutions are some excellent benefits.

h-a-l-9000 wrote:

I'm actually happy that I do not have to look at the shortcomings of old monitors...

Ditto. Who needs the eye strain.

collector wrote:

h-a-l-9000 wrote:

I'm actually happy that I do not have to look at the shortcomings of old monitors...

Ditto. Who needs the eye strain.

Sometimes these shortcomings were taken advantage of with actual features relying on them. One particular worth mentioning would be the CGA afterglow being abused to mix colors so it could display more than 4 eye-cancery colors.

> CGA afterglow
Do you know an example?

> but lack of blurring, input lag; color accuracy, blacks and support of various native resolutions
How would you emulate these?

h-a-l-9000 wrote:

>
> but lack of blurring, input lag; color accuracy, blacks and support of various native resolutions
How would you emulate these?

On an LCD? You can't of course. I was just standing up for the poor ol' CRT's. 😀

h-a-l-9000 wrote:

> CGA afterglow
Do you know an example?

Yes. King's Quest. It's only used in composite mode, an RGB monitor did not present the same hardware features. On an RGB monitor you experience the miserable limited color palette of CGA, but on a composite monitor it's like playing with EGA. If I'm not mistaken, there's a patch that may have already been integrated into DOSBox to replicate this behavior for CGA.

As for emulating a CRT - I would emulate larger phyiscal pixels (configurable by dot pitch = size), scanline sweeps (configurable, I'd disable if using BFI [see below]), phosphor life (phosphor ghosting, more obvious on MONO and CGA, but still present in small amounts on any CRT), and screen curvature. Late CRTs didn't have curvature, so this would be toggleable for those who want to emulate that, but personally I miss the nice curved sheet of glass bending the image slightly. All of the stuff could be disabled/combined/etc. to the user's taste. After all, these are all aesthetic features - there are very important non-aesthetic ones, though..

The human eye's "refresh rate" interacts in strange ways with the refreshing of a CRT. On a CRT you see the image burned into your retina, the image fades away, clearing the eye's "memory", and your eye sees the new one. On an LCD, it's constantly showing the image, so there's blurring because the eye takes in no blanked image to reset itself, it's like watching a movie with DIVX where the screen sometimes fails to update - if it rewrote the whole thing every frame that wouldn't happen, right? To replicate this, you can insert black frames every few frames - some monitors were made that did this, and the technology was (obviously enough) called "BFI - Black Frame Insertion". It has other names, too, but that's the most honest one. I'd like to see this as an option in CRT emulation, too - as well as other approaches to emulating the interaction of the human eye with a CRT without actually requiring a CRT, that way you can choose the one that works best for you, or none at all. The other prominent method is a scanning backlight - basically scanline emulation in hardware.

See here, or google around yourself:
http://www.behardware.com/news/8273/a-glimpse … d-with-bfi.html

Also see here, though note 100hz+ section only applies to TV:
http://en.wikipedia.org/wiki/HDTV_blur

I bet most of you weren't aware of that, and it's probably the biggest difference between a CRT and LCD in image quality and comfort!

Ditto. Who needs the eye strain.

Personally I get eye strain from using an LCD - CRTs do not trouble my eyes one bit.

Obviously the more widely known practical benefits of resolution independence (this is already "emulated" by scaling the image, both by hardware and by DOSBox depending on your settings), better color reproduction, etc. can't be reproduced, but there are important differences that can be.

As for color reproduction, get an sRGB LCD or Laser "LCD" (way wider color gamut) with power-based blacking (don't know if there's a real term for that). There's a method of producing black on an LCD based on literally showing nothing in the relevant parts of the screen - this produces a proper "nothingness"-style black, rather than the not-really-black that we have on most LCDs. These two things are not emulatable, it's a matter of waiting for the relevant technologies to become common. In the meantime, I believe Acer LCDs do this for their blacks, at least some of them. sRGB LCDs and Laser "LCDs" do exist, but they're expensive - not reasonable yet.

You see, in my quest to figure out why the CRT left such an impact on me and others, I have read extensively about each and every feature and point (both good and bad) and how we've tried to replicate the good ones so far - I'm not just blindly saying "MAKE A CRT EMULATOR, 🤣!".

if anyone has a radeon 9800 lying around (or similar) you could try thr tv smartshader
http://www.beyond3d.com/content/articles/85/4

heres the shader code :

shader copyPixelShader =
"!!ARBfp1.0
TEMP pixel;
OUTPUT oColor = result.color;
TEX pixel, fragment.texcoord[0], texture[0], 2D;
MOV oColor, pixel;
END";

shader vOffsetPixelShader =
"!!ARBfp1.0
OUTPUT oColor = result.color;
PARAM temp = { 0,0,0,0 };
TEMP temp0;
MOV temp0, temp;
SIN temp0.y,program.local[0].y;
ADD temp0, temp0, fragment.texcoord[0];
FRC temp0.y, temp0.y;
TEX oColor, temp0, texture[0], 2D;
END";

shader vBreakupPixelShader =
"!!ARBfp1.0
OUTPUT oColor = result.color;
PARAM temp = { 0,0,0,0 };
PARAM temp1 = { 0.05,0,0,0 };
TEMP temp0;
MOV temp0, temp;
ADD temp0.x, fragment.texcoord[0].y, program.local[0].x;
FRC temp0.x, temp0.x;
TEX temp0, temp0, texture[1], 2D;
MUL temp0, temp1, temp0;
MUL temp0.x, temp0.x, program.local[0].y;
ADD temp0, temp0, fragment.texcoord[0];
FRC temp0.x, temp0.x;
TEX oColor, temp0, texture[0], 2D;
END";

shader vScreenPixelShader =
"!!ARBfp1.0
PARAM scale = {0.8, 0.8, 0.8, 0.0};
PARAM scale2 = {0.2, 0.2, 0.2, 0.0};
PARAM offset = {0.2, 0.0, 0.0, 0.0};
PARAM white = {1.0, 1.0, 1.0, 1.0};
TEMP pixel;
TEMP pixel2;
TEMP pixel3;
TEMP coord;
OUTPUT oColor = result.color;
TEX pixel, fragment.texcoord[0], texture[0], 2D;
ADD coord, fragment.texcoord[0], offset;
FRC coord, coord;
TEX pixel2, coord, texture[0], 2D;
MUL pixel2, pixel2, scale2;
MUL pixel, pixel, scale;
ADD pixel, pixel2, pixel;
TEX pixel2, fragment.texcoord[0], texture[1], 2D;

ADD coord, fragment.texcoord[0], program.local[0];
FRC coord, coord;
TEX pixel3, coord, texture[1], 2D;
MOV pixel3.r, pixel3.a;
MOV pixel3.g, pixel3.a;
MOV pixel3.b, pixel3.a;
MUL pixel3, pixel3, program.local[1];
ADD pixel3, pixel3, white;
MUL pixel, pixel3, pixel;

MUL pixel, pixel2, pixel;
MOV oColor, pixel;
END";

shader vScreenColor=
"!!ARBfp1.0
PARAM YIQ1 = {0.299, 0.587, 0.114, 0.0};
PARAM inverse_YIQ1 = {1.0, 0.956, 0.621, 0.0};
PARAM inverse_YIQ2 = {1.0, -0.272, -0.647, 0.0};
PARAM inverse_YIQ3 = {1.0, -1.105, 1.702, 0.0};
PARAM scale = {0.0, 0.2, 0.0, 0.0};
TEMP pixel;
TEMP coord;
TEMP green;
OUTPUT oColor = result.color;
TEX pixel, fragment.texcoord[0], texture[0], 2D;
DP3 pixel.rgb, pixel, YIQ1;
MOV pixel.gb, scale;
DP3 green.g, pixel, inverse_YIQ1;
DP3 green.r, pixel, inverse_YIQ2;
DP3 green.b, pixel, inverse_YIQ3;

MOV oColor, green;
END";

timeTillVerticalShift = 1000;
verticalShiftCycleLength = 200;
numOfTurns= 3;
curFrameNum = swapNumber % timeTillVerticalShift;
if (curFrameNum < verticalShiftCycleLength)
{
vOffset= 4*(numOfTurns * curFrameNum) /verticalShiftCycleLength;
}
else
{
vOffset= 0;
}
vOffsetPixelShader.constant[0] = {vOffset/3,vOffset,0,0};
surface temp = allocsurf(width, height);

texture[0].source = backbuffer;
destination temp;
apply vOffsetPixelShader;

timeTillBreakup = 450;
breakupShiftCycleLength = 50;
numOfTurns= 4;
breakupPower=1;
curFrameNum = swapNumber % timeTillBreakup;
if (curFrameNum < breakupShiftCycleLength)
{
breakup= (numOfTurns * curFrameNum) /breakupShiftCycleLength;
}
else
{
breakup= 0;
breakupPower=0;
}
vBreakupPixelShader.constant[0] = {breakup/7,breakupPower,0,0};
load_texture(1, 256, 16, 1, "ubyte", "noise.raw");
surface temp1 = allocsurf(width, height);

texture[0].source = temp;
destination temp1;
apply vBreakupPixelShader;

texture[0].source = temp1;
destination temp;
apply vScreenColor;

curFrameNum = ((swapNumber )% 7)/7;
curFrameNum2 = ((swapNumber )% 9)/9;

curFrameNum3 = ((swapNumber )% 600);
CycleLength=200;
if (curFrameNum3 < (CycleLength/2))
{
Noise= curFrameNum3/(CycleLength/2)*0.8;
}
else if (curFrameNum3 < CycleLength)
{
Noise= 1-((curFrameNum3-CycleLength/2)/(CycleLength/2))*0.8;
}
else
{
Noise=0;
}

curFrameNum3 = ((swapNumber )% 90)/90;
vScreenPixelShader.constant[0] = {curFrameNum,curFrameNum2,0,0};
vScreenPixelShader.constant[1] = {Noise,Noise,Noise,1};
load_texture(1, 256, 256, 1, "ubyte", "lines.raw");
texture[1].magfilter = "linear";
texture[0].source = temp;
destination temp1;
apply vScreenPixelShader;

texture[0].source = temp1;
destination backbuffer;
apply copyPixelShader;

This shader doesn't require a Radeon 9xxx, it's just an ordinary OpenGL shader as far as I can see - it may require that (or the nVidia equivalent, or other older competitors) as a minimum, though. After reading the page and realizing that these are OpenGL shaders, I have to point out that they're not supported in any build of DOSBox I'm aware of - only DirectX shaders are. As well, it's a generic shader so would need rewrites to work with DOSBox. Finally, emulating "reception issues" doesn't sound like a good idea, but after cutting those out and removing the "bezel" overlay (since it doesn't warp the picture to match, it's just cutting screen real estate away for nothing) it would be a nice shader to use for monochromatic games - as well as composite CGA, which was often done on monochromatic green monitors (color gear wasn't always available or affordable, and some had built-in mono screens like the Sr. Partner, which I happen to own). Scanlines aren't that prevalent in most monochrome/CGA monitors, but I do have one monitor that looks EXACTLY LIKE THIS (without the reception issues, of course) that's intended for composite CGA - my Zenith... I once hooked up a modern PC to it by way of adapters and played Fallout 3 in monochromatic green - a fun experience. 😁

Interesting thread. Personally I'm very happy that we now have LCDs and I don't need to look at a flickering pixel mush and I can see the games without the technical limitations of that time...

Mau1wurf1977 wrote:

Interesting thread. Personally I'm very happy that we now have LCDs and I don't need to look at a flickering pixel mush and I can see the games without the technical limitations of that time...

I agree, but if you have for example ZSNES it is very fun to simulate having an old TV , like one you may have had as a kid.