|
"correct" scanlines
#350659 - 02/25/16 12:40 AM
|
|
|
I know you can set the scanlines to whatever you want in MAME, but is there a "correct" setting for each game? Shouldn't it be based on what type of monitor the game originally used?
|
|
|
|
Re: "correct" scanlines
[Re: mike20599]
#350666 - 02/25/16 04:06 AM
|
|
|
> Shouldn't it be based on what type of monitor the
> game originally used?
No?
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: "correct" scanlines
[Re: mike20599]
#350683 - 02/25/16 05:26 PM
|
|
|
> I know you can set the scanlines to whatever you want in MAME, but is there a
> "correct" setting for each game? Shouldn't it be based on what type of monitor the
> game originally used?
For games sold as conversion kits (which is the large majority), there is no "type of monitor the game originally used". Even games in dedicated cabinets often came with different monitors over their production lifetime depending on what was in stock.
|
|
|
|
Re: "correct" scanlines
[Re: mike20599]
#351618 - 03/16/16 03:57 AM
|
|
|
I think I know what mike20599 is asking because I am wrestling with a similar question. If a game was horizontal the original monitor was installed landscape. If the game was vertical the monitor was installed portrait. Do the scan lines stay with the orientation of the monitor or (based on they driver) do they always stay vertical or horizontal wrt the cabinet?
I am installing a 16:9 LCD oriented vertically and just bought a mini slg and want to be sure it will work for all of my games (vert mon w/ vert and hor games). Or would i need to be able to switch for each? Or does it matter which direction the scanlines go?
Bottom line: Should scanlines always be horizontal, vertical, depend on the orientation of the original game,or doesn't matter?
|
|
|
|
Re: "correct" scanlines
[Re: COXXON]
#351619 - 03/16/16 04:31 AM
|
|
|
This I can answer for you.
Scanlines are always across the long length of the monitor. This means that on a horizontally mounted monitor, they'll be horizontal. On a vertical monitor, they'll be vertical.
As such, the scanlines will obviously not be the same between the two types of games and should follow the game's orientation in general.
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
|
yeah, oooold topic.....
[Re: Firehawke]
#351639 - 03/17/16 03:09 AM
|
|
|
Technically, Firehawke is correct. However, there have been ways to have the lines of every game going the same way. I've done this with old MAME by using the scanlines 25% vertical. When the png system was added, I and some others liked this and someone created rotated versions for this purpose. I still use this on games like Pac-Man (288 line games - lots you don't know nothing about here....), where the settings are direct draw, switch resolutions, 800x600, scanlines rotated png.
However, I've recently found the right HLSL settings are pre-tty nice! In this case, working for 224x240 and 224x288 vertical orientation games. Some curvature was added as well. Beauty. At least over here....
((Funny that I was preparing these images for a fresh topic to show off.....))
|
Scifi frauds. SF illuminates.
_________________
Culture General Contact Unit (Eccentric)
|
|
|
|
Best I could manage with my phone. The image is richer, and the colors brighter, than either D3D and png, or HLSL, because they're actual hardware scanlines produced by the synthesis of the resolution with the right png file. And the image isn't being 'masked'.
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
Scifi frauds. SF illuminates.
_________________
Culture General Contact Unit (Eccentric)
|
|
|
|
> Best I could manage with my phone. The image is richer, and the colors brighter, than
> either D3D and png, or HLSL, because they're actual hardware scanlines produced by
> the synthesis of the resolution with the right png file. And the image isn't being
> 'masked'.
Vertical games shouldn't have horizontal scanlines. It's not a matter of opinion because the beam actually scans across the long dimension of the monitor. So horizontal scanlines for a horizontally oriented monitor and vertical for a vertically oriented monitor.
If you think that's wrong though, here's why. In many/most of the CRT arcade monitors you'll see, the the shadow mask is course and the beam is too wide to see scanlines. So instead of the scanlines you might see the shadow mask/aperture grille instead.
So on CRTs with a vertical RGB stripe mask like trinitron: https://en.wikipedia.org/wiki/Trinitron
you could see vertical stripes on a horizontal monitor (and the other way around too). But those stripes definitely aren't the scanlines from the electron beam scanning across the screen. Which again, is not a matter of opinion or debate. It's just the way it is.
EDIT: If you like horizontal lines on your vertical games that's fine. Just call them a "low res approximation of an aperture grille pattern" and not "scanlines" so nobody's head explodes when they read it 
EDIT2: I'm a picture of a horizontal monitor showing vertical stripes from the aperture grille. And you can see that the actual scan lines aren't visible at all.
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
Edited by SoltanGris42 (03/17/16 07:34 AM)
|
|
|
| Dullaron |
|
Diablo III - Dunard #1884
|
|
|
|
|
Reged: 07/22/05
|
|
Posts: 6125
|
|
Loc: Fort Worth, Tx
|
|
|
|
Send PM
|
|
|
Re: Here's an example of the rotate png scanlines...
[Re: SoltanGris42]
#351647 - 03/17/16 11:52 AM
|
|
|
> > Best I could manage with my phone. The image is richer, and the colors brighter,
> than
> > either D3D and png, or HLSL, because they're actual hardware scanlines produced by
> > the synthesis of the resolution with the right png file. And the image isn't being
> > 'masked'.
>
> Vertical games shouldn't have horizontal scanlines. It's not a matter of opinion
> because the beam actually scans across the long dimension of the monitor. So
> horizontal scanlines for a horizontally oriented monitor and vertical for a
> vertically oriented monitor.
>
> If you think that's wrong though, here's why. In many/most of the CRT arcade monitors
> you'll see, the the shadow mask is course and the beam is too wide to see scanlines.
> So instead of the scanlines you might see the shadow mask/aperture grille instead.
>
> So on CRTs with a vertical RGB stripe mask like trinitron:
> https://en.wikipedia.org/wiki/Trinitron
> you could see vertical stripes on a horizontal monitor (and the other way around
> too). But those stripes definitely aren't the scanlines from the electron beam
> scanning across the screen. Which again, is not a matter of opinion or debate. It's
> just the way it is.
>
> EDIT: If you like horizontal lines on your vertical games that's fine. Just call them
> a "low res approximation of an aperture grille pattern" and not "scanlines" so
> nobody's head explodes when they read it
>
> EDIT2: I'm a picture of a horizontal monitor showing vertical stripes from the
> aperture grille. And you can see that the actual scan lines aren't visible at all.
Good old Punch out. That the way the lines go. The way I remember.
|
W11 Home 64-bit + Nobara OS / AMD Radeon RX 5700 XT / AMD Ryzen 7 3700X 8-Core 3.59 GHz / RAM 64 GB
|
|
|
|
> > Best I could manage with my phone. The image is richer, and the colors brighter,
> than
> > either D3D and png, or HLSL, because they're actual hardware scanlines produced by
> > the synthesis of the resolution with the right png file. And the image isn't being
> > 'masked'.
I love the combination of integer scaling + a .PNG overlay
The resulting picture is so much brighter and clearer than most existing crt shaders it's fascinating.
Looks much better in real life because the RGB 'strips' that I've added to every pixel 'shine' and as a result, simulate a kind of 'life' to the pixels and a simili-dithering instead of full plain color areas.
It's not using any kind of smoothing nor shades of grey, everything is pure RGB colors on a single .PNG file, so It's very sharp and colorful but not 'pixel-ey'. Considering a normal 60Hz LCD is producing more or less smearing and can have a relatively insufficient brightness output when too much stuff is overlayed, this method actually works best.
Of course many people won't accept the black borders area, but it's possible to integer-scale the other way and make the picture bigger than the screen in some cases (of course that means creating a new .PNG to match the different scaling factor too! quite the hassle)
Too bad screenshots kind of fail at showing how good it looks in practice:
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
> MAME isn't about playing the games anyway.
|
|
|
Re: Here's an example of the rotate png scanlines...
[Re: LensLarque]
#351665 - 03/17/16 07:50 PM
|
|
|
> > > Best I could manage with my phone. The image is richer, and the colors brighter,
> > than
> > > either D3D and png, or HLSL, because they're actual hardware scanlines produced
> by
> > > the synthesis of the resolution with the right png file. And the image isn't
> being
> > > 'masked'.
>
> I love the combination of integer scaling + a .PNG overlay
> The resulting picture is so much brighter and clearer than most existing crt shaders
> it's fascinating.
>
> Looks much better in real life because the RGB 'strips' that I've added to every
> pixel 'shine' and as a result, simulate a kind of 'life' to the pixels and a
> simili-dithering instead of full plain color areas.
> It's not using any kind of smoothing nor shades of grey, everything is pure RGB
> colors on a single .PNG file, so It's very sharp and colorful but not 'pixel-ey'.
> Considering a normal 60Hz LCD is producing more or less smearing and can have a
> relatively insufficient brightness output when too much stuff is overlayed, this
> method actually works best.
>
> Of course many people won't accept the black borders area, but it's possible to
> integer-scale the other way and make the picture bigger than the screen in some cases
> (of course that means creating a new .PNG to match the different scaling factor too!
> quite the hassle)
>
> Too bad screenshots kind of fail at showing how good it looks in practice:
Your overlay is pretty good. Like you say, the image stays pretty bright. That's because you have a lot of pixels that don't have the RGB pattern on top of them lowering the brightness. CRT shaders can keep a bright high contrast look too. It's really just a matter of keeping the scanlines bright and sharp, having an aperture mask that doesn't lower the brightness too much, and not letting the shader blur the pixels too much.
Timothy Lottes had a blog post a few months ago where he talked about a non-realtime CRT shader. One of his ideas is how to properly apply tone-mapping in a CRT shader to get back the brightness without losing quality in the aperture mask effect. I added a quick and dirty tone-mapping step to my local copy of his GLSL CRT shader and it looked pretty nice. I never fixed it to do exactly what he described though, but I may do that soon and post it here if it looks good. The images are missing from the blog post now, but you can read the post here: http://timothylottes.blogspot.com/2015/09/tonemapping-slot-mask-simulation.html
He had several ideas that wouldn't work with the GLSL system. I don't know which of them are feasible in the new BGFX shader system that MooglyGuy has been working on. I suppose I can try to make a version of Lottes' shader for the new system once it's in the main MAME branch. I guess that would be a good way for me to learn how the new system works.
|
|
|
|
|
> Your overlay is pretty good. Like you say, the image stays pretty bright. That's
> because you have a lot of pixels that don't have the RGB pattern on top of them
> lowering the brightness. CRT shaders can keep a bright high contrast look too. It's
> really just a matter of keeping the scanlines bright and sharp, having an aperture
> mask that doesn't lower the brightness too much, and not letting the shader blur the
> pixels too much.
>
> Timothy Lottes had a blog post a few months ago where he talked about a non-realtime
> CRT shader. One of his ideas is how to properly apply tone-mapping in a CRT shader to
> get back the brightness without losing quality in the aperture mask effect. I added a
> quick and dirty tone-mapping step to my local copy of his GLSL CRT shader and it
> looked pretty nice. I never fixed it to do exactly what he described though, but I
> may do that soon and post it here if it looks good. The images are missing from the
> blog post now, but you can read the post here:
> http://timothylottes.blogspot.com/2015/09/tonemapping-slot-mask-simulation.html
>
> He had several ideas that wouldn't work with the GLSL system. I don't know which of
> them are feasible in the new BGFX shader system that MooglyGuy has been working on. I
> suppose I can try to make a version of Lottes' shader for the new system once it's in
> the main MAME branch. I guess that would be a good way for me to learn how the new
> system works.
Interesting, hope he'll reload the pics.
In my case it's a really simple job, here on a 3x4 pixels file I just start with set of strong % of RGB px on the bottom line and the rest is filled with vey light %.
Then I adjust everything step-by-step using pure white with a level of alpha transparency to tune every px layer-by-layer until I'm satisfied with the balance.
The problem though here is that it could use an additional very thin line of black(s) in-between the two strong % RGB lines that currently constitute the pseudo-mask line we're seeing.
As it is of course it tends to create dark spots on plain full colors instead of a continuous line.
I'd try something on x5 but MAME is giving me trouble with the integer scale, maybe I'm using the wrong H & V bitmap stretching values, I don't know.
Anyway this is not a convenient method, lots of work to cover enough source resolutions over a single monitor resolution, and it has to be redone with entirely new values and many new sets of overlays for using a monitor with a different res.
I'm not even talking about vertical games over landscape, finding the right spots and colors is very difficult on just a Full-HD panel.
Fingers crossed for great things with BGFX, naturally. 
Here another one before I switch to something different;
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
> MAME isn't about playing the games anyway.
|
|
|
|
Sorry for double-posting, just wanted to add this works great for tiny screens as well, here on 1600x900 laptop screen with a barbaric 3x4 png using 80% & 10% RGB, still manages to look awesome;
(no big borders here with Capcom games of course since 4x 224 is 896)
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
> MAME isn't about playing the games anyway.
|
|
Index 
Threaded 
"correct" scanlines
Reply
[Re: 
