VOGONS


some more shaders for SVN r4319 and later

Topic actions

Reply 40 of 60, by Diduz

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2020-04-20, 05:22:
Diduz wrote on 2020-04-19, 21:29:

No luck with the garbling/smearing of CRT-Geom overscan, though. It's beyond my knowledge and ability. 😁

That's due to sampling the input texture with negative X/Y co-ords, they get clamped to 0. The same effect would be happening on the right/bottom sides if there wasn't extra padding.

Still, I remember that CRT-Geom overscan settings worked fine under DosBox Daum, but then again those were Direct3D fx shaders with a different code, I guess.

Reply 41 of 60, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
Serious Callers Only wrote on 2020-04-19, 23:12:
jmarsh wrote on 2020-04-19, 20:23:

BTW this really should be something upstream does, when a glshader is turned on, turn off the normal scaler. Combining a software scaler and a glshader seems like a recipe for unnecessary pain. In fact maybe it would be better to 'pretend' both use the same mechanism in the conf file just to prevent confusion with this and the need to turn off the one you're not actually using.

No because there are things scalers can do that shaders can't and vice-versa. Someone might want to use HQ2X/3X scaler with a CRT shader, for example.

The price of that kind of brittle flexibility (instead of say, making a two pass glshader for crt-hqx), is that you're going to get a bunch of 'spurious' bug reports that you can't do anything about because they're 'user errors' and the users are going to be pissed it's so easy to get it wrong.

In my particular computer (my experience only), besides the bugs, combing these two is asking for slowdown that might not happen if you only use either one apart - but that's likely because by computer is very very bad. Anyway, anecdotal datapoint: don't combine a software scaler with a glshader when your computer cpu/gpu are bad - two things that might be bearable individually might become horrible combined. In my case, even scale2x scaler combined with any shader is asking for sub 30 fps, while i can use pixel-perfect glshader with no scaler, go figure.

While I can't say anything about the CPU penalty of running normal shader on top of the GLshader, I agree that doing it this way is problematic/confusing for endusers. At the least it needs to be documented in the config but even then it is probably going to get missed in the wall of text. I did expect that the GLshader is going to be the only one that gets used when you set it and the scaler setting will only get used if the shader can't be loaded (for whatever reason).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 42 of 60, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

hi everyone

I've recently converted some more shaders from the libretro repository
https://github.com/libretro/glsl-shaders/tree … ter/crt/shaders

this is the current set, available in the archive attached to this post
crt-aperture.glsl
crt-caligari.glsl
crt-easymode.glsl
crt-geom.glsl
crt-hyllian.glsl
crt-lottes-fast.glsl
crt-nes-mini.glsl
crt-pi.glsl
fakelottes.glsl
yee64.glsl
yeetron.glsl
zfast_crt.glsl

I'd recommend:
- fakelottes for up to 640x480
- easymode for over 640x480
- geom as a jack of all trades

for each one of them I've created a tweaked variant, mainly for reducing the curvature effect and brighten the image a bit

@tyrells feel free to add them to your github

Attachments

Reply 43 of 60, by tyrells

User metadata
Rank Newbie
Rank
Newbie
Delfino Furioso wrote on 2020-05-08, 23:31:
hi everyone […]
Show full quote

hi everyone

I've recently converted some more shaders from the libretro repository
https://github.com/libretro/glsl-shaders/tree … ter/crt/shaders

this is the current set, available in the archive attached to this post
crt-aperture.glsl
crt-caligari.glsl
crt-easymode.glsl
crt-geom.glsl
crt-hyllian.glsl
crt-lottes-fast.glsl
crt-nes-mini.glsl
crt-pi.glsl
fakelottes.glsl
yee64.glsl
yeetron.glsl
zfast_crt.glsl

I'd recommend:
- fakelottes for up to 640x480
- easymode for over 640x480
- geom as a jack of all trades

for each one of them I've created a tweaked variant, mainly for reducing the curvature effect and brighten the image a bit

@tyrells feel free to add them to your github

Awesome work! Will add them this weekend.

Reply 44 of 60, by leileilol

User metadata
Rank l33t++
Rank
l33t++
Dominus wrote on 2020-04-20, 15:10:

While I can't say anything about the CPU penalty of running normal shader on top of the GLshader, I agree that doing it this way is problematic/confusing for endusers. At the least it needs to be documented in the config but even then it is probably going to get missed in the wall of text. I did expect that the GLshader is going to be the only one that gets used when you set it and the scaler setting will only get used if the shader can't be loaded (for whatever reason).

I think before the scalers/shaders are decoupled there should be an option to do normal2x regardless anyway since the appearance doublescanned VGA can be important for the relevant video cards. Not doing that otherwise would lead to a weird 15Khz VGA fantasy scanliney look with CRT shaders some might think is how the VGA dos experience was.

(also yeah software scalers can make a lot of pebkac issues, very many common Gzdoom complaints involve users turning on hq4x 'improvements' while loading hi-res addons and whatnot, loads of 512x512 textures becoming 32768x32768 or so, and that's not even thinking about those who use modern normal map pbr addon stuff with software scaled textures given the placebo effect of a quality increase, and texture compression is off by default so no DXT helping out there)

apsosig.png

Reply 46 of 60, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I added the shaders to the ppa. I renamed them slightly to clarify some names and always follow the convention crt_NAME for the user to easily know what's for a CRT shape or not. At least, i hope that's what being placed on those dirs means. Underscores is just because it's a informal convention in linux and because i don't like double 'extensions' (the .tweaked)

My conversions:

debian/glshaders/interpolation/pp.glsl => usr/share/dosbox/glshaders/pixel_perfect.glsl
debian/glshaders/interpolation/pixellate.glsl => usr/share/dosbox/glshaders/pixellate.glsl
debian/glshaders/crt/crt-aperture.glsl => usr/share/dosbox/glshaders/crt_aperture.glsl
debian/glshaders/crt/crt-caligari.glsl => usr/share/dosbox/glshaders/crt_caligari.glsl
debian/glshaders/crt/crt-easymode.glsl => usr/share/dosbox/glshaders/crt_easymode.glsl
debian/glshaders/crt/crt-easymode.tweaked.glsl => usr/share/dosbox/glshaders/crt_easymode_tweaked.glsl
debian/glshaders/crt/fakelottes.glsl => usr/share/dosbox/glshaders/crt_fakelottes.glsl
debian/glshaders/crt/fakelottes.tweaked.glsl => usr/share/dosbox/glshaders/crt_fakelottes_tweaked.glsl
debian/glshaders/crt/crt-geom.glsl => usr/share/dosbox/glshaders/crt_geom.glsl
debian/glshaders/crt/crt-geom.tweaked.glsl => usr/share/dosbox/glshaders/crt_geom_tweaked.glsl
debian/glshaders/crt/crt-hyllian.glsl => usr/share/dosbox/glshaders/crt_hyllian.glsl
debian/glshaders/crt/crt-lottes.glsl => usr/share/dosbox/glshaders/crt_lottes.glsl
debian/glshaders/crt/crt-lottes-fast.glsl => usr/share/dosbox/glshaders/crt_lottes_fast.glsl
debian/glshaders/crt/crt-lottes.tweaked.glsl => usr/share/dosbox/glshaders/crt_lottes_tweaked.glsl
debian/glshaders/crt/crt-nes-mini.glsl => usr/share/dosbox/glshaders/crt_nes_mini.glsl
debian/glshaders/crt/crt-pi.glsl => usr/share/dosbox/glshaders/crt_pi.glsl
debian/glshaders/crt/ScanLine.glsl => usr/share/dosbox/glshaders/crt_scanline.glsl
debian/glshaders/crt/yee64.glsl => usr/share/dosbox/glshaders/crt_yee64.glsl
debian/glshaders/crt/yeetron.glsl => usr/share/dosbox/glshaders/crt_yeetron.glsl
debian/glshaders/crt/zfast_crt.glsl => usr/share/dosbox/glshaders/crt_zfast.glsl
debian/glshaders/xbr/xbr-lv2-3d.glsl => usr/share/dosbox/glshaders/xbr_lv2_3d.glsl
debian/glshaders/xbr/xbr-lv2-noblend.glsl => usr/share/dosbox/glshaders/xbr_lv2_noblend.glsl
debian/glshaders/xbr/xbr-lv2.glsl => usr/share/dosbox/glshaders/xbr_lv2.glsl
debian/glshaders/xbr/xbr-lv3.glsl => usr/share/dosbox/glshaders/xbr_lv3.glsl

The filename of the right side, minus glsl appears as a conf file option for these without needing to select the path. Godspeed.

Reply 47 of 60, by tyrells

User metadata
Rank Newbie
Rank
Newbie
Serious Callers Only wrote on 2020-05-12, 16:05:
I added the shaders to the ppa. I renamed them slightly to clarify some names and always follow the convention crt_NAME for the […]
Show full quote

I added the shaders to the ppa. I renamed them slightly to clarify some names and always follow the convention crt_NAME for the user to easily know what's for a CRT shape or not. At least, i hope that's what being placed on those dirs means. Underscores is just because it's a informal convention in linux and because i don't like double 'extensions' (the .tweaked)

My conversions:

debian/glshaders/interpolation/pp.glsl => usr/share/dosbox/glshaders/pixel_perfect.glsl
debian/glshaders/interpolation/pixellate.glsl => usr/share/dosbox/glshaders/pixellate.glsl
debian/glshaders/crt/crt-aperture.glsl => usr/share/dosbox/glshaders/crt_aperture.glsl
debian/glshaders/crt/crt-caligari.glsl => usr/share/dosbox/glshaders/crt_caligari.glsl
debian/glshaders/crt/crt-easymode.glsl => usr/share/dosbox/glshaders/crt_easymode.glsl
debian/glshaders/crt/crt-easymode.tweaked.glsl => usr/share/dosbox/glshaders/crt_easymode_tweaked.glsl
debian/glshaders/crt/fakelottes.glsl => usr/share/dosbox/glshaders/crt_fakelottes.glsl
debian/glshaders/crt/fakelottes.tweaked.glsl => usr/share/dosbox/glshaders/crt_fakelottes_tweaked.glsl
debian/glshaders/crt/crt-geom.glsl => usr/share/dosbox/glshaders/crt_geom.glsl
debian/glshaders/crt/crt-geom.tweaked.glsl => usr/share/dosbox/glshaders/crt_geom_tweaked.glsl
debian/glshaders/crt/crt-hyllian.glsl => usr/share/dosbox/glshaders/crt_hyllian.glsl
debian/glshaders/crt/crt-lottes.glsl => usr/share/dosbox/glshaders/crt_lottes.glsl
debian/glshaders/crt/crt-lottes-fast.glsl => usr/share/dosbox/glshaders/crt_lottes_fast.glsl
debian/glshaders/crt/crt-lottes.tweaked.glsl => usr/share/dosbox/glshaders/crt_lottes_tweaked.glsl
debian/glshaders/crt/crt-nes-mini.glsl => usr/share/dosbox/glshaders/crt_nes_mini.glsl
debian/glshaders/crt/crt-pi.glsl => usr/share/dosbox/glshaders/crt_pi.glsl
debian/glshaders/crt/ScanLine.glsl => usr/share/dosbox/glshaders/crt_scanline.glsl
debian/glshaders/crt/yee64.glsl => usr/share/dosbox/glshaders/crt_yee64.glsl
debian/glshaders/crt/yeetron.glsl => usr/share/dosbox/glshaders/crt_yeetron.glsl
debian/glshaders/crt/zfast_crt.glsl => usr/share/dosbox/glshaders/crt_zfast.glsl
debian/glshaders/xbr/xbr-lv2-3d.glsl => usr/share/dosbox/glshaders/xbr_lv2_3d.glsl
debian/glshaders/xbr/xbr-lv2-noblend.glsl => usr/share/dosbox/glshaders/xbr_lv2_noblend.glsl
debian/glshaders/xbr/xbr-lv2.glsl => usr/share/dosbox/glshaders/xbr_lv2.glsl
debian/glshaders/xbr/xbr-lv3.glsl => usr/share/dosbox/glshaders/xbr_lv3.glsl

The filename of the right side, minus glsl appears as a conf file option for these without needing to select the path. Godspeed.

Thanks for the update @Serious Callers Only, you are correct with your assumumptions about the dirs. The only execption is scanline.glsl, which is actually classified slightly differently in libretro (it is in it's own directory named 'scanlines') , but it definitly fits with the rest of the crt shaders, which is why its grouped with them in this repo. I might actually rename the pp.glsl to pixel_perfect.glsl in my repo too, as it makes more sense.

Reply 48 of 60, by tyrells

User metadata
Rank Newbie
Rank
Newbie
tyrells wrote on 2020-05-12, 22:25:
Serious Callers Only wrote on 2020-05-12, 16:05:
I added the shaders to the ppa. I renamed them slightly to clarify some names and always follow the convention crt_NAME for the […]
Show full quote

I added the shaders to the ppa. I renamed them slightly to clarify some names and always follow the convention crt_NAME for the user to easily know what's for a CRT shape or not. At least, i hope that's what being placed on those dirs means. Underscores is just because it's a informal convention in linux and because i don't like double 'extensions' (the .tweaked)

My conversions:

debian/glshaders/interpolation/pp.glsl => usr/share/dosbox/glshaders/pixel_perfect.glsl
debian/glshaders/interpolation/pixellate.glsl => usr/share/dosbox/glshaders/pixellate.glsl
debian/glshaders/crt/crt-aperture.glsl => usr/share/dosbox/glshaders/crt_aperture.glsl
debian/glshaders/crt/crt-caligari.glsl => usr/share/dosbox/glshaders/crt_caligari.glsl
debian/glshaders/crt/crt-easymode.glsl => usr/share/dosbox/glshaders/crt_easymode.glsl
debian/glshaders/crt/crt-easymode.tweaked.glsl => usr/share/dosbox/glshaders/crt_easymode_tweaked.glsl
debian/glshaders/crt/fakelottes.glsl => usr/share/dosbox/glshaders/crt_fakelottes.glsl
debian/glshaders/crt/fakelottes.tweaked.glsl => usr/share/dosbox/glshaders/crt_fakelottes_tweaked.glsl
debian/glshaders/crt/crt-geom.glsl => usr/share/dosbox/glshaders/crt_geom.glsl
debian/glshaders/crt/crt-geom.tweaked.glsl => usr/share/dosbox/glshaders/crt_geom_tweaked.glsl
debian/glshaders/crt/crt-hyllian.glsl => usr/share/dosbox/glshaders/crt_hyllian.glsl
debian/glshaders/crt/crt-lottes.glsl => usr/share/dosbox/glshaders/crt_lottes.glsl
debian/glshaders/crt/crt-lottes-fast.glsl => usr/share/dosbox/glshaders/crt_lottes_fast.glsl
debian/glshaders/crt/crt-lottes.tweaked.glsl => usr/share/dosbox/glshaders/crt_lottes_tweaked.glsl
debian/glshaders/crt/crt-nes-mini.glsl => usr/share/dosbox/glshaders/crt_nes_mini.glsl
debian/glshaders/crt/crt-pi.glsl => usr/share/dosbox/glshaders/crt_pi.glsl
debian/glshaders/crt/ScanLine.glsl => usr/share/dosbox/glshaders/crt_scanline.glsl
debian/glshaders/crt/yee64.glsl => usr/share/dosbox/glshaders/crt_yee64.glsl
debian/glshaders/crt/yeetron.glsl => usr/share/dosbox/glshaders/crt_yeetron.glsl
debian/glshaders/crt/zfast_crt.glsl => usr/share/dosbox/glshaders/crt_zfast.glsl
debian/glshaders/xbr/xbr-lv2-3d.glsl => usr/share/dosbox/glshaders/xbr_lv2_3d.glsl
debian/glshaders/xbr/xbr-lv2-noblend.glsl => usr/share/dosbox/glshaders/xbr_lv2_noblend.glsl
debian/glshaders/xbr/xbr-lv2.glsl => usr/share/dosbox/glshaders/xbr_lv2.glsl
debian/glshaders/xbr/xbr-lv3.glsl => usr/share/dosbox/glshaders/xbr_lv3.glsl

The filename of the right side, minus glsl appears as a conf file option for these without needing to select the path. Godspeed.

Thanks for the update @Serious Callers Only, you are correct with your assumumptions about the dirs. The only execption is scanline.glsl, which is actually classified slightly differently in libretro (it is in it's own directory named 'scanlines') , but it definitly fits with the rest of the crt shaders, which is why its grouped with them in this repo. I might actually rename the pp.glsl to pixel_perfect.glsl in my repo too, as it makes more sense.

Quick update: pp.glsl now renamed to pixel_perfect.glsl

Reply 49 of 60, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Ok, time to update the build anyway, since the other part of this patch is broken since r4343

I'll probably wait until the github mirror i'm using updates and that breakage becomes 'official' if it ever does. Why can't sourceforge have github mirrors for the svn repositories it has automatically....

Last edited by Serious Callers Only on 2020-06-28, 05:58. Edited 1 time in total.

Reply 50 of 60, by dosmax

User metadata
Rank Newbie
Rank
Newbie

Just a brief question re the pixel perfect shader: is the aspect ratio supposed to be right windowed? I'm wondering whether I'm doing something wrong or maybe the shader just isn't supposed to work right in a window.

It seems to work fullscreen for me, but if I run DosBox windowed, the aspect ratio is wrong for most 320x200 VGA games, with different output aspect ratios for different window resolutions. E.g. 1280x960 typically results in a ~1:1 output aspect ratio. No software scaler used, software aspect correction on or off doesn't seem to make a difference.

Edit: tested with both a pure SVN build and DosBox ECE to make sure it's not a glitch in ECE, which I normally use. Both behave the same way.

Reply 51 of 60, by dosmax

User metadata
Rank Newbie
Rank
Newbie

OK, to partially answer my own question, the issue does not seem to be related to fullscreen/windowed, but to the resolution used. Without having dived into the algorithm I'd say the shaders's aspect ratio correction produces usable results with 320x200 input for output resolutions at and above 1000 (200x5) pixels height, below that however the computed 'correction' for the most part is too far off to be usable.

Probably not the shader's fault though, after all there has to be a large enough output res to scale e.g. 320x200 in a pixel perfect way to 4:3.

Last edited by dosmax on 2020-05-30, 13:10. Edited 1 time in total.

Reply 52 of 60, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

For pixel perfect the output resolution has to be large enough to allow integer scaling (in both directions) to match the aspect ratio. 1280x960 is too small, 1600x1200 would be the minimum to integer upscale 320x200 at 4:3.

Reply 53 of 60, by dosmax

User metadata
Rank Newbie
Rank
Newbie

That's what I figured myself in the meantime. Thanks for the confirmation. 1600x1200 are perfect, 1000 height already produces an almost correct result that comes close enough for my taste (1280x1000, so 1.28 instead of the ideal 1.33). Below 1000 height things fall apart completely. Should have thought about it for 10 minutes longer originally before I posted the question...

Reply 55 of 60, by dosmax

User metadata
Rank Newbie
Rank
Newbie

Not sure if this will be of any use for someone. I did a little modification of the lottes-fast CRT shader that suits my personal taste. It provides a rather subtle CRT sim effect, basically mimicking a 'modern' CRT with good image quality. Most importantly scanlines have been set to zero, the aperture mask alpha is reduced and the image is relatively sharp.

That alone wouldn't warrent to upload the modified shader, but I also added a custom luminance gain function that is used as a final step. To me that improves the result quite a bit. The gain is applied mainly to bright parts of the image and ensures that the overall color impression stays pretty close to the original image, i.e. the image looks less dull than it is typically the case with mask overlays and whites don't become grey as they normally do.

If you want to play with the extra parameters, check the 'ADDITIONAL FUNCTIONS AND DEFS' section. The output gain is heavily fine tuned to the rest of the shader parameters to ensure that at full white there still is a faint hint of the aperture mask visible and no/very little color clipping occurs. So be careful when you make any changes. The result with/without gain or a comparison to the original image can optionally be displayed side by side, useful for fine tuning.

Permission to add the shader to the archive is of course granted if it is found to be useful enough.

Attachments

  • Filename
    crt-lottes-fast.subtle+gain.zip
    File size
    6.94 KiB
    Downloads
    25 downloads
    File comment
    lottes-fast CRT tuned for subtlety + added luminance gain
    File license
    Public domain

Reply 57 of 60, by almeath

User metadata
Rank Newbie
Rank
Newbie
dosmax wrote on 2020-05-31, 13:43:
Not sure if this will be of any use for someone. I did a little modification of the lottes-fast CRT shader that suits my persona […]
Show full quote

Not sure if this will be of any use for someone. I did a little modification of the lottes-fast CRT shader that suits my personal taste. It provides a rather subtle CRT sim effect, basically mimicking a 'modern' CRT with good image quality. Most importantly scanlines have been set to zero, the aperture mask alpha is reduced and the image is relatively sharp.

That alone wouldn't warrent to upload the modified shader, but I also added a custom luminance gain function that is used as a final step. To me that improves the result quite a bit. The gain is applied mainly to bright parts of the image and ensures that the overall color impression stays pretty close to the original image, i.e. the image looks less dull than it is typically the case with mask overlays and whites don't become grey as they normally do.

If you want to play with the extra parameters, check the 'ADDITIONAL FUNCTIONS AND DEFS' section. The output gain is heavily fine tuned to the rest of the shader parameters to ensure that at full white there still is a faint hint of the aperture mask visible and no/very little color clipping occurs. So be careful when you make any changes. The result with/without gain or a comparison to the original image can optionally be displayed side by side, useful for fine tuning.

Permission to add the shader to the archive is of course granted if it is found to be useful enough.

This is an excellent shader! I am just wondering which settings I adjust, in order to:

1. Reduce or remove the darkening effect in the corners? (I do not know the technical term for it - the blackening effect on the pixels that simulates the back light fading in the corners of the CRT)
2. Reduce the roundness of the corners - not entirely squared off, but more along the lines of a Trinitron CRT.
3. Any other settings that can bump up the luminance/brightness just a tad more but keeping everything well balanced for color accuracy (I really like the massive brightness boost in the tweaked lottes shader but I dislike the prominent scanlines)

Reply 58 of 60, by dosmax

User metadata
Rank Newbie
Rank
Newbie

Thanks. Most CRT shader presets just aren't well suited for anything newer than CGA monitors since they are mostly made for replicating the look of an early game console on a (cheap) TV. They do great in that regard, but that's just not how VGA/SVGA looked on a PC monitor. For making DosBox look like something from the VGA/SVGA era shaders have to be modified. Most importantly no VGA capable monitor ever had blatantly visible scanlines for each pixel of a 200/240p resolution, even the oldest VGA monitors drew two scanlines per pixel at 200/240p (double scan). When I think back to monitors I had in the 90s/early 2000s, I don't really recall them to have any noticable scanlines at all.

Anyway, the look of the corners can be changed with the CURVATURE and CORNER parameters just above the section with the added parameters for the luminance gain. I didn't change any of that, so these controls work just as they do with the unmodified lottes-fast shader. BTW: The lottes-fast shader also allows you to simulate a Trinitron aperture grille instead of a RGB dot matrix mask, IIRC you would have to set MASK to 1 instead of 3 for that. Caveat: doing so will break the carefully adjusted parameters for my added luminance gain since with the Trinitron grille the shader looks brighter per se.

The strength of the luminance gain can be adjusted with the FINAL_GAIN_MULT parameter or by lowering FINAL_GAIN_POW. Lowering the latter would leave the maximum strength the same, but darker parts of the image would be affected more. That's probably what you want to do.

Be careful though, the general idea behind the gain besides providing an output image that looks more similar to the input was that at full white the aperture mask becomes almost (but not entirely) invisible, which looks as if very bright colors outshine the mask. Even small changes to the parameters can break that impression by either making the max values too bright or not bright enough.

Reply 59 of 60, by almeath

User metadata
Rank Newbie
Rank
Newbie

Yes, I see what you mean. All the adjustments are very finely balanced, so any additional brightness gained does not seem to be worthwhile. Otherwise, it ends up with the same problem as lottes tweaked, being the loss of the shadow mask effect on the bright colors. Seems you cannot really have it both ways, unless you have a professional quality LCD with 1000 nits of brightness. 😉

On my 5k screen it does look really nice, and very close to what I remember from 90s CRT monitors. I only used Trinitron TVs for video games and so aperture grille does not trigger any DOS era nostalgia for me personally.

I could not end up modifying the corners without getting strange pixel distortions along the top of the screen, so I just decided to zero those out and go with a flat picture. My experience of CRTs was in the late 90s, so by then the screens with extreme curvature where generally gone anyway.