Previous Thread
Next Thread
Print Thread
Page 1 of 9 1 2 3 4 5 6 7 8 9
HLSL Shadow Mask Discussion Station #73673 10/14/11 08:26 PM
Joined: May 2009
Posts: 1,876
J
Just Desserts Offline OP
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,876
1) As I have said multiple times before, shadow_mask_x_count and shadow_mask_y_count should have no relation to the game's resolution unless you're trying to fudge the settings to reduce moiré. If you plug an arcade PCB into a different arcade monitor, the arcade monitor's physical shadow mask doesn't suddenly grow or shrink to the game's resolution - it's fixed relative to the game resolution. It depends on the dot pitch and dot configuration of the original monitor, but in the majority of monitor manuals that I read from Wells-Gardner and the like, the general rule of thumb is that they had 640 shadow dots on the X axis and 480 on the Y axis.

2) The shadow mask is currently applied during the wrong stage. With the current code, the shadow mask is applied to the image after it has been "bent" to simulate the optical pincushion effect from the rounded tube face, whereas the shadow mask, being behind the tube glass, would be visibly "bent" in the same geometry as the image. I just need to take the shadow mask-related code from post.fx and move it to occur at the end of focus.fx. This is probably contributing to the moiré effect.

3) The statement found on the MW forum, "The current bugs and problems with hlsl is that the current apreture.png is not 3 RGB lines like a pixel should be," is false and he or she needs to look at many different kinds of monitors under a magnifying glass in order to make a statement like that. In reality, different monitors have different aperture masks. What he is describing is instead an aperture grille pattern, where you have unbroken vertical bands. The current aperture.png, with the "brick" pattern of horizontal black bars, is based instead on the tube used in the Commodore 1702 monitor, and a similar pattern was present on many arcade monitors of the time. However, I will be perfectly honest and say that the aperture.png provided by ilya-v on MW is much better than the one that's currently in MESS. I'll experiment with it a bit and see what shakes loose.

Re: HLSL Shadow Mask Discussion Station [Re: Just Desserts] #73679 10/15/11 02:17 AM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
Hi Just Desserts,

Thankyou for posting this.

Reading what you have put under 1) I now understand what is going on and why people get confused or argumentive.

Yes I admit I (as well as some others) were setting "shadow_mask_x_count and shadow_mask_y_count" to the original game resolution to "reduce moiré" effect. Sometimes you have to work 'outside the square' to get things looking right for your personal preference (which is subjective anyway).

In regards to 2) I greatly appreciate what you have given us so far and would keenly be interested in any further updates you provide in the future. smile

PS; Would you like to have a quick skim of my setting descriptions here and give me a comment or feedback on what you think. (noting that shadow_mask_counts are skewed to reduce moiré)
If anything needs changing or is not quite right let me know. Thanks.
http://gamingnos.blogspot.com/2011/10/quick-start-mame-hlsl-filter-guide-up.html


Read about my latest custom HLSL setup here;
http://gamingnos.blogspot.com/
Re: HLSL Shadow Mask Discussion Station [Re: ] #73682 10/15/11 07:08 AM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
Originally Posted By ilya-v
Hi everybody.
By "The current apreture.png is not 3 RGB lines like a pixel should be,"
What I meant that its 6 line (doubled) so you need to set Half the shadow mask count.
This happens because mask_u(v)size value of 0.09375 takes TWO of these pixels from the current Aperture.png file.


Ilya-v, Are you sure you aren't using prescaling?

Just Desserts can you confirm if this is true or not, thanks.

Re: HLSL Shadow Mask Discussion Station [Re: ] #73684 10/15/11 07:46 AM
Joined: May 2009
Posts: 1,876
J
Just Desserts Offline OP
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,876
Originally Posted By ilya-v
No, prescaling just ups the resolution of the aperture not what part of it is taken (mask size).

Why don't you just TEST it yourself?


Since you know so much about the issue, I'd be interested in hearing about a fix for it. It's possible to edit the .fx files yourself without even having to recompile MAME or MESS, so if the issue is a problem with the shader, it can be fixed by anyone without a compiler.

I don't mean to be rude when I say this, the only reason why I say it is because I have been trying to find the right combination of shader settings + code settings for the past 2 hours and nothing really looks "right" yet. smile

Re: HLSL Shadow Mask Discussion Station [Re: Just Desserts] #73692 10/15/11 09:21 PM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
After sleeping on this I am thinking this is something where 'one setting fits all' may not be possible.

You'll have to forgive me, I thought 'shadow mask' and 'aperture grille' were the same thing. Although they each create a different look, the basic principle that they manipulate the displayed image that we see is similar. In the 'real world' they are both physical items behind the front of the glass, not part of the picture/image on the software side. Once the guns have fired the electron beams through either the 'shadow mask' or 'aperture grille' then the image that is displayed to us has taken on their different characteristics.

In saying that, what we are trying to achieve here is not actually emulating an physical 'shadow mask' or 'aperture grille' but the characteristics of what the image would look like after passing through one of these.

*** So in the real world 'shadow mask' and 'aperture grille' are not connected to game resolution or image output display resolution.***
*** What we are trying to achieve when emulating a 'shadow mask' or 'aperture grille' with this HLSL filter does rely on game resolution and output image resolution. Because we are trying to emulate how the image appears after it has already passed through said 'shadow mask' or 'aperture grille'. This means we are working with the images characteristics, ie: resolution and aspect ratio.

BASED ON THIS OFFER TWO DIFFERENT IDEAS GOING FORWARD:
A) [Trying to setup one setting fits all]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't know anything about what the 'real world' dimensions/engineering of 'shadow mask' or 'aperture grille' for arcade screens were, but if what is typed in this box is correct (which might not be due to my lack of knowledge) then:
1. All 'shadow masks' or 'aperture grilles' were exactly the same pattern/style regardless of monitor size.
2. If this is the case then certainly our 'aperture.png' could be 'tiled' to fill the dimensions of an 'correct aspect ratio' 'final output display/window'.
3. In a way of speaking, can be calculated using percentages or fractions.
4. If the dimensions of the 'aperture.png' are set correctly so mathematically we can input the 'multiplication number' for 'x' and 'y' [counts] so will correctly fill a 4:3 aspect ratio output for example.
5. Problem is that not all games may share the same aspect ratio so will our 'aperture.png' still be useable? Maybe if the 'aperture.png' was of a small enough size, this is where time would have to be spent mathematically to find out if it is possible for a 'one aperture.png fits all aspect ratios if correct numbers keyed into 'x' & 'y' [counts]' for all scenarios.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

B) [Using different 'aperture.png' per resolution]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't know anything about what the 'real world' dimensions/engineering of 'shadow mask' or 'aperture grille' for arcade screens were, but if what is typed in this box is correct (which might not be due to my lack of knowledge) then:
1. 'shadow masks' or 'aperture grilles' have different pattern/styles based on the physical size of the monitor/tv they were used with. For example if a 17" display had a completely different 'shadow mask' or 'aperture grille' pattern to a 21" which cannot be duplicated by means of 'tiling' the 'aperture.png'.
2. If this is the case then we would have to have an 'aperture.png' that is the same size resolution as either the original games resolution or our final outputted display/window resolution.
3. Maybe it is simple to create 'aperture.png' size to the same size as the original games resolution but if/when multiplied to final output resolution may cause slight blurriness. If 'aperture.png' is made to same size as the final outputted resolution then no blurriness but due to everyone's own personal final output resolutions 'aperture.png' would ideally be created by end users.
4. This is based on everyone using 'aspect ratio' correct final output resolutions the same as the original games resolution 'aspect ratio'.
5. If correct 'aspect ratio' is not maintained then end users will be creating their own form of distortion by stretching/etc.
6. Would no longer require 'x' & 'y' [counts] or 'usize' & 'vsize' if I am not mistaken. Only require's [shadow_mask_alpha] & [shadow_mask_texture]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

IN REGARDS TO SCANLINES:

Theoritically speaking, the way that 'shadow mask' (same would apply if we were using 'aperture grille' as well) is implemented in this HLSL filter; because with the 'overlay aperture.png' we are emulating the image after it has already passed through. We should not really be using the current 'scanline HLSL settings' feature because they appear on the wrong side. [ie: like Superman wearing his undies on the outside of his costume] wink

Due to how an 'aperture grille' is just made up of fine vertical wires I assume they would not interfere with horizontal 'scanline HLSL settings' so we could use them, but the implementation of 'scanline HLSL settings' needs to be before the 'aperture.png' not after.

Due to how an 'shadow mask' is a metal plate with tiny holes punched in it and because of how this changes the characteristics of the displayed image so much that we should not actually use the 'scanline HLSL settings' at all. The 'shadow mask' manipulated 'aperture.png overlay file' should already have these characteristics 'built-in'.

Please any comments or feedback appreciated.


Read about my latest custom HLSL setup here;
http://gamingnos.blogspot.com/
Re: HLSL Shadow Mask Discussion Station [Re: ] #73702 10/16/11 07:58 AM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
Sorry ilya-v,
I am not trying to offend you but due to the language barrier we don't seem to be understanding each other.

Originally Posted By ilya-v

I want to add that each monitor model has its SET number of pixels or shadow mask or RGB lines.


The 'shadow mask' is not actually part of the image that comes from the electron beams. It is actually a metal plate with very tiny holes in it. See here;
http://en.wikipedia.org/wiki/File:Lochmaske.JPG

Originally Posted By ilya-v

So option A (fits all) will be used to emulate a specific monitor,
and its the only accurate one.


Actually option B was to create individual 'aperture.png' files for specific 'monitors'.
Option A was to create one 'aperture.png' tile that can be multiplied to fit all 'monitors'. <not proven yet>

Originally Posted By ilya-v

When you buy a 1920x1080 resolution (matrix) monitor it doesn't change the resolution magically.
It stays 1920x1080 regardless of the software resolution the the game outputs.
That's what we are trying to emulate.


Sounds like you are getting 'size of shadow mask metal plate' mixed up with 'resolution' of image
displayed on screen. Forget about resolution of image when talking about 'shadow mask'. The size of the 'shadow mask' will not change because it is a metal plate behind the glass.

What 'we are trying to emulate' is the characteristics that the image looks like to our eyes after it has already passed through the 'shadow mask'. Since we aren't creating a real metal plate, all we are doing is modifying the 'original game image'. This is already given to us in a 'correct aspect ratio' and the games 'specific original resolution'. Not all games use the same resolution, so we can't make one 'aperture.png' and say 'one size fits all'.

Originally Posted By ilya-v

Scanlines should be a side effect of the monitor flashing the horizontal line (pixels) intermittently, first the odd then the even in certain hertz.
(1,3,5,7,9 etc.. then 2,4,6,8 etc..) this creates the visual effect of scanlines.


Have you ever seen a scanline effect like this in 'software'?

Re: HLSL Shadow Mask Discussion Station [Re: ] #73720 10/17/11 05:15 AM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
Originally Posted By ilya-v

This is what I call number of pixels or matrix and its fixed and set = non changeable (metal).
It also can be 1920x1080 or 512x384 for that matter.
Each pixel (dot) is 3 RGB lines for a CRT tv or an arcade monitor.

From now on I will just call it Shadow Mask.


Why measure by pixels and not milimeters or centimeters when we are talking about metal object?

Originally Posted By ilya-v

Ok now I understand.
Option A is what hlsl does now, it squeezes the number of pictures as you set it with the count option.


Yes, but...

Originally Posted By ilya-v

To makes the RGB lines (pixels) the right proportion and size as on the tv we need to draw the Aperture.png in perfect square (50x50 or 100x100) and let hlsl do the rest.
So option B is obsolete.


... this is where I was saying the mathematics would have to be looked at to see if it is possible to use one 'Aperture.png' that can be used for all situations. I don't think 50x50 or 100x100 I assume would have to be 4:3 ratio friendly since most games will be of that ratio.

Originally Posted By ilya-v

We just need to figure WHAT model the original arcade monitor was and what's his shadow mask count was.


In perfect world that would be great but how or who will gather that information?

Originally Posted By ilya-v

Yes we can.
Aperture.png has nothing to do with game resolution.
It has to do with monitor model and size (shadow mask).
Its what HLSL does, is squeezes (count) the given number of pixels (aperture.png) in the screen thus recreating a shadow mask..
I think there is some contradiction in your quoted post here.


Well actually shadow mask is physical object so measured in mm or cm. Aperture.png is an image so measured in pixels resolution. Because it is being 'overlayed' over the game image there is a relation between game image resolution and Aperture.png resolution. It is the basics of science/mathematics to find a common denominator to work from.

Originally Posted By jclampy
Have you ever seen a scanline effect like this in 'software'?


Originally Posted By ilya-v

No,
To emulate this behavior we need to make it dependent of game resolution and the shadow mask.
So that each horizontal row of pixels will flash in an interlaced order.
That is what happens in an interlaced TV (arcade) signal.

So for now the scanlines effects is only a steady translucent picture.


Yes but the programming involved would be substantial no doubt.

I am busy working on half a dozen projects at the moment so can't put time into looking at this at the moment. Although it is difficult communicating with the language barrier, it appears we are both moving in similar direction, with slightly different approach maybe. It sounds like if creating a workable 'aperture.png' is the way to go, then what results did you get from your tests? Were you able to come up with a 'proof of concept / design' yet?

Edit1:
Ok, so looking on wikipedia there are 'shadow masks' with circle holes and another with slots(which seems preferred as makes displayed image appear brighter). Aperture.png has the slot design so I guess we stick with that.



Do you agree with this picture, that one pixel is signified in the box as 1x red + 1x blue + 1x green?

Would stipulate that there is a connection between game resolution (made up of pixels) and what we see after shadow mask (aperture.png) is applied. Which is how the HLSL filter works.

Hmm, this is all very small if we are working at pixel level. This is why I was asking you early on whether this makes a big difference when you compare the 'zoomed out' image. I presume the only 'visible' difference between a display with shadow_mask and without shadow_mask is that the one with is slightly darkened.

Edit2:
Here is a quick mockup I made to show what I am thinking. This image is a quick representation of one pixel of game resolution image to three slots of shadow mask plate:

Note;
1. white will be made alpha channel
2. R G B = Red Green Blue so you compare to the wikipedia image.
3. the horizontal black is not straight because that is how the 'slots' look like on the wikipedia image, but I think they should probably all be the same size. So will do that in my next image I make.

Due to 'aperture.png' black bits representing slots on metal plate where RGB electron beams pass through needs to fit in with pixels of game resolution image. I am thinking 'aperture.png' would have to be made at a scale of enlargement. This is to contain enough information in the 'aperture.png' for the detail required. After I workout the resolution required for 'aperture.png' then we'll have to figure out how to tile it and shrink back down to proper size with HLSL settings.

Does this sound right so far?

Edit3:
Honestly due to the scale factors involved here I don't think this is going to workout. My 'aperture.png' is currently 28 pixels wide for 1 pixel of original game resolution. Oh well, I'll see what happens. I would assume we shrink and tile the 'aperture.png' and multiply the original game resolution to our final output resolution and hope things balance out.

Edit4:
Check this picture I found in the meantime to give idea of pixel to slots:
http://en.wikipedia.org/wiki/File:Closeup_of_pixels.JPG
and this one for styles of shadow masks:
http://en.wikipedia.org/wiki/File:Pixel_geometry_01_Pengo.jpg

Just in case it might be easy to do a aperture grille:
http://en.wikipedia.org/wiki/File:CRT_Phosphors.jpg

Edit5:
May have to go with the aperture grille design shown above as I think is easier to implement with horizontal and vertical tiling plus don't have to worry about correct 'aperture.png' scale ratio for vertical in regards to horizontal. For comparison if you look at the shadow mask it is actually a 2 pixel wide pattern that is tiled not a 1 pixel tile. Also aperture grille design would work/look better with how the HLSL filter currently implements 'scanlines feature' even though it is not correct at moment.

I will try and put something together for both a shadow mask design and aperture grille design to see anyway.

Last edited by jclampy; 10/17/11 10:51 AM.
Re: HLSL Shadow Mask Discussion Station [Re: Just Desserts] #73722 10/17/11 10:28 AM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
Hey Just Desserts,

How does the HLSL implementation input the 'aperture.png' does it input it at pixel 0,0 and then tile it from there downwards and to the right?

Edit:
Hey ilya-v,
Here is shadow mask aperture.png I have put together so far. It looks kind of right but I am not sure it will workout when implemented with HLSL filter. I have a feeling aperture grille aperture.png will work better with how HLSL filter has been designed.

This is for one pixel but is 400% zoom; (screengrab not my source picture)


This is for two horizontal pixels side by side 400% zoom; (screengrab not my source picture)


This is for 4x4 pixels tiled 400% zoom; (screengrab not my source picture)


Dimensions of my source image for one pixel is 25x20 so can round the corners of each slot if you want.

LOL, I still have this feeling that I am wasting my time doing this. crazy

Last edited by jclampy; 10/17/11 12:14 PM.
Re: HLSL Shadow Mask Discussion Station [Re: ] #73728 10/17/11 03:36 PM
Joined: May 2009
Posts: 1,876
J
Just Desserts Offline OP
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,876
How about you both stop arguing with each other and start actually talking to me instead?

I don't mean to be insulting, here, but it sounds like you're both debating from an academic standpoint but neither of you have ever bothered to actually look at the code in MESS or try to fix the code in MESS. Why not actually try to improve MESS rather than sitting on your academic high-horse and pointing at how much better other peoples' work is than mine? I'm looking at all of this back-and-forth, and it looks more like you're both concerned with being right than actually helping MAME or MESS, and that does nothing for me.

Ilya, the rainbow effect is not caused by bilinear filtering as far as I know, it is caused by downsampling in general. The same issue would occur regardless of whether aperture.png was bilinear-filtered or nearest-neighbor-filtered.

Fact: GPUs are not good at downsampling. When you scale down a texture by any significant factor, regardless of bilinear filtering or nearest-neighbor filtering, you end up with dropped-out texels. Bilinear filtering is designed with magnification in mind, not minification. Nearest-neighbor will omit neighboring pixels, but what occurs algorithmically with bilinear filtering is a linear interpolation across U/V between the current pixel and the "next" pixel. With minification, the "next" pixel ends up being more than one pixel away, which results in blending against the wrong colour.

I feel that even using nearest-neighbor filtering, however, will not help the rainbow effect. The rainbow effect is caused by non-contiguous pixels, not because of the way the non-contiguous pixels are blended.

The only way to get a really good shadow mask effect, in my opinion, is to perform a weighted average of all source pixels in aperture.png covered by a single destination pixel, which would be excessively slow.

I've been trying to come up with a good way of getting around this, but so far I haven't come up with one, which is why I haven't been messing with HLSL that much over the past few days.

Ilya, since you seem to know so much about how things should work, why don't you take a shot at trying to fix the HLSL implementation of shadow masking? After all, all the source code is there.

Re: HLSL Shadow Mask Discussion Station [Re: Just Desserts] #73739 10/17/11 06:16 PM
Joined: Oct 2011
Posts: 74
J
jclampy Offline
Member
Offline
Member
J
Joined: Oct 2011
Posts: 74
I haven't looked at the code because I am not a programmer either.

You stated that we should try and find a way to get things working how we want using the hlsl.ini settings which is what I am going to do. First I am trying to get an aperture.png together that works with my idea.

I am going to try an aperture grille style aperture.png (because that way I only have to worry about issues with 'tiling' horizontally and not vertically and it is a pixel repetitive pattern not 2 pixels wide).

I am thinking of using an aperture.png that has a resolution divisible of a 4x4 pixel ratio which should be tileable and scaleable with 'most' display resolutions. I still feel at the moment that because we are 'emulating' a real shadow mask or aperture grille that we need to align the 'overlay' with the game/output displayed pixels.

1. 'Just Desserts' I have asked you questions throughout my posts on this thread, which you have not answered.

2. I am trying to learn how these 'effects' come together in the 'real world' and understand how your HLSL filter emulates them. But is difficult if you are not actually responding to questions constructively.

3. I can't just look at your code to find out if I am not a programmer. So I am doing it the old fashioned way by asking. I will try and figure as much as I can on my own through intuition/logic. smile

Edit:
Heres an idea. Could the problem be that how the HLSL filter implements aperture.png be too complicated? I was thinking about how the Mame 'bezel artwork' feature adds the .png files. It can take border artwork .png of say 4000 pixels wide by 3000 pixels high and then output that to any user defined game playing resolution. It is all done internally with no user definable/input settings.

Maybe aperture.png should be one big resolution and implemented using similar methods rather than 'tiling' and 'sizing' settings that need to be entered by users? Is this something to consider?

Last edited by jclampy; 10/17/11 06:36 PM.
Page 1 of 9 1 2 3 4 5 6 7 8 9

Who's Online Now
1 registered members (1 invisible), 44 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,818
Posts116,113
Members4,921
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3