Didn't at first....and then I thought, 'oh, does it need DX9 for that?'. And sure enough that was it. Turned the raster bloom to 0, but otherwise it's stock. Looks pretty good on my '11-vintage Acer LCD. Vector games and golden-age raster look good, too, no crappy LCD blur, though the backlight glare is still a little unsavory. I could deal, though.
Oh, yeah, this was on .159, but it illustrates the point.
Man, I can't stand that HLSL uneven row sizes throughout the screen. This makes some rows to be darker than the others and it feels pretty fake. Is there any way to set HLSL to make rows of the very same size (pixel size)?
> Man, I can't stand that HLSL uneven row sizes throughout the screen. This makes some > rows to be darker than the others and it feels pretty fake. Is there any way to set > HLSL to make rows of the very same size (pixel size)?
Beside that i dont see a single scanline, that is uneven, did you look at the picture at 100% ? I guess not, as you wouldnt talk such rubbish then. They are the VERY same size. Are you that Hyperspin-fanboy, that is flaming HLSL all the time? You sound exactly like him.
> Beside that i dont see a single scanline, that is uneven, did you look at the picture at 100% ? I guess not, as you wouldnt talk such rubbish then. They are the VERY same size. Are you that Hyperspin-fanboy, that is flaming HLSL all the time? You sound exactly like him.
Dude, whoa. Rog didn't maximize the image, yeah, okay.
Now let's take snapshots in fullscreen and see if those lines are still evenly distributed lol. Really I don't see the point of taking pictures of the windowed output.
> Oh, yeah, this was on .159, but it illustrates the point.
It doesn't really illustrate any point whatsoever, since HD4000-class integrated graphics have nothing to do with Intel's shitty integrated graphics from circa 2006.
> Didn't at first....and then I thought, 'oh, does it need DX9 for that?'. And sure > enough that was it. Turned the raster bloom to 0, but otherwise it's stock. Looks > pretty good on my '11-vintage Acer LCD. Vector games and golden-age raster look good, > too, no crappy LCD blur, though the backlight glare is still a little unsavory. I > could deal, though. > > > Oh, yeah, this was on .159, but it illustrates the point.
I can see the uneven lines in the middle of that screen. Thick bars is showing. Light and dark. I guest they can't see it because of their screen isn't bright enough to show it.
Anyway it not showing here on the GLSL OpenGL shader. Which is blending in a lot better than the HLSL. Only thing this shader doesn't have is that cool blur effect. If someone coding in that effect in a shader then I be willing to add it onto the website. Other wise the BGFX probably gonna take over the GLSL OpenGL.
Now that's better. It's cool that some GLSL shaders have no issues scaling without screwing the scanlines indeed, there are a few doing that on RA as well. For the shaders that don't the only solution is to force an integer scale, which is okay with some games, not really with others depending on your screen, as it can mean either huge black borders or lots of lines left out of screen limits.
> Now that's better. It's cool that some GLSL shaders have no issues scaling without > screwing the scanlines indeed, there are a few doing that on RA as well. > For the shaders that don't the only solution is to force an integer scale, which is > okay with some games, not really with others depending on your screen, as it can mean > either huge black borders or lots of lines left out of screen limits.
Yep GLSL scales better than HLSL. SDL have that better coding than D3D. My point is GLSL shaders doesn't need to be change every time when a game screen doesn't have that even scales.
Waiting to see BGFX be better than HLSL and GLSL. If it not even better than GLSL then it just wasted their time adding it. I will see though.
> > Beside that i dont see a single scanline, that is uneven, did you look at the > picture at 100% ? I guess not, as you wouldnt talk such rubbish then. They are the > VERY same size. Are you that Hyperspin-fanboy, that is flaming HLSL all the time? You > sound exactly like him. > > > Dude, whoa. Rog didn't maximize the image, yeah, okay.
No, I'm not. I don't even know what are you talking about. But to me, analyzing the OP first picture, with very good eyes and no glasses, I can tell that the thickness is not the same on every single line. Some lines are blurred, which makes the difference between lines very noticeable.
I don't have anything against HLSL or its author(s), I just think that the final result displayed in that picture is not good enough. Maybe it's a configuration not well adjusted by the author of that picture, it's just my humble opinion. Compared to GLSL, I still stick to GLSL hands down.
> It doesn't really illustrate any point whatsoever, since HD4000-class integrated graphics have nothing to do with Intel's shitty integrated graphics from circa 2006.
It illustrates that an embedded chipset can do HLSL. Which could be more or less obvious if one Wiki'd the hardware...but how many people besides me do that??
There are vertical lines that crosshatch the scanlines. At least over here, I have to click on the image (which renders it in a dedicated page), and then I have to click on that to magnify it to full size. Then it looks good, except in the light blue area, where the vertical lines are still showing slightly. Oh, and there's moire effect all through the light blue area.
> I don't have anything against HLSL or its author(s), I just think that the final > result displayed in that picture is not good enough. Maybe it's a configuration not > well adjusted by the author of that picture, it's just my humble opinion. Compared to > GLSL, I still stick to GLSL hands down.
While there are many redeeming qualities about the current state of HLSL, I have never known it to produce even scanlines when in fullscreen mode.
The auto pre-scale of HLSL has a bug, that result in a much too small render target and you will see these blurry uneven scanlines; not to mention how a shadow mask looks. Therefore you should define a pre-scale which fits your vertical screen resolution and the vertical resolution of the game best.
e.g. Screen resolution: 1600x900 Game resolution: 320x224 Pre-scale: 900 / 224 ~ 4
You also can use higher pre-scales, but this will decrease your performance.
Anyway, I'm working to get rid of the manual pre-scale definition by using a correctly sized render target that suits the used resolution.
> The auto pre-scale of HLSL has a bug, that result in a much too small render target > and you will see these blurry uneven scanlines; not to mention how a shadow mask > looks. Therefore you should define a pre-scale which fits your vertical screen > resolution and the vertical resolution of the game best. > > e.g. > Screen resolution: 1600x900 > Game resolution: 320x224 > Pre-scale: 900 / 224 ~ 4 > > You also can use higher pre-scales, but this will decrease your performance. > > Anyway, I'm working to get rid of the manual pre-scale definition by using a > correctly sized render target that suits the used resolution. > > Scanlines > > > Shadow Mask
That how it look on the GLSL (CRT-geom-halation shader) No messy blur lines. Matches the HLSL Wip Auto Pre-scale the 3rd screen.
If you want. Make it where the lines flicker by lighten and darken up. The flick per second or so. Only see it flickering with the screen darken up.
For example. I know it not a CRT. But the CRT does the same.
You're actually about two to four years late on this. I posted some interesting benchmarks with a now-older laptop using HLSL a long time back.
I'll admit I was a bit surprised at how effective the HD3000/4000 line were, but at this point they should be able to handle up to 1080p just fine. The only place you'll start to hit issues is when you get into 4k resolutions, where the calculations will tax even more modern video cards.
It's pointless to even judge before it's completely implemented, and raving about how bad it is would only serve to demoralize people from actually finishing the work. Why don't you actually just kindly keep quiet on judgments until there's feature parity?
BGFX is going to be a whole lot more than just CRT simulation.
> It's pointless to even judge before it's completely implemented, and raving about how > bad it is would only serve to demoralize people from actually finishing the work. Why > don't you actually just kindly keep quiet on judgments until there's feature parity? > > BGFX is going to be a whole lot more than just CRT simulation.
OK you press the button.
I think you missing the point on GLSL vs HLSL. On the HLSL you have to re-config the settings. GLSL doesn't need to be re-config on the settings once it is done. Look how many times that the HLSL been work on. HLSL been mess with more than the GLSL. Even it get broken again and again. MooglyGuy got sick of messing with it and pass it to someone else. HLSL been work on for 10 years or so. I just don't understand why they just don't move onto GLSL. It like keep beating the dead horse for fixes over and over.
I know they must've have that hobby and bored.
I would've just move on for sake. That just me.
Very hard to fix something that keep on breaking.
In a few years Jezze probably pass it to someone else. He will get sick of it. I don't know how long he will put up with it.
Anyway I got that out of my system. It the truth. I have nothing against those guys. I'm not them.
> You're actually about two to four years late on this. I posted some interesting benchmarks with a now-older laptop using HLSL a long time back.
I'll admit I was a bit surprised at how effective the HD3000/4000 line were, but at this point they should be able to handle up to 1080p just fine. The only place you'll start to hit issues is when you get into 4k resolutions, where the calculations will tax even more modern video cards.
Oh. Well I might well be. But WAIT....I recall now, I did a MW search before posting and didn't find anything. Mm-mmm-mmm.
> On the HLSL you have to re-config the settings. GLSL doesn't need to be re-config on the settings once it is done. Same goes with HLSL, once you're done you can save your settings in a custom ini.
> Even it get broken again and again. Tell me what got broken again and again in the past year, since I'm working on HLSL?
> HLSL been work on for 10 years or so. It's been about 4 years.
> I just don't understand why they just don't move onto GLSL. Show me what cannot be achieved with current HLSL implementation and I show you what cannot be achieved with the current GLSL implementation.
> In a few years Jezze probably pass it to someone else. I'm sure in a few years (actually months) we will only have BGFX on top of GLSL and HLSL, and maybe I got my hands on it too.
> > On the HLSL you have to re-config the settings. GLSL doesn't need to be re-config > on the settings once it is done. > Same goes with HLSL, once you're done you can save your settings in a custom ini.
I'm talking about the changes on the settings. Every time someone change the HLSL ini settings then we had to re-config it.
> > Even it get broken again and again. > Tell me what got broken again and again in the past year, since I'm working on HLSL?
Remember the HLSL files or something got broken? Those already been fix a few times.
> > HLSL been work on for 10 years or so. > It's been about 4 years.
Seem longer... I guest your right. I can't keep up.
> > I just don't understand why they just don't move onto GLSL. > Show me what cannot be achieved with current HLSL implementation and I show you what > cannot be achieved with the current GLSL implementation.
Know what. GLSL can't do the things that HLSL can do. HLSL can't do the things that GLSL can do. Fair enough.
> > In a few years Jezze probably pass it to someone else. > I'm sure in a few years (actually months) we will only have BGFX on top of GLSL and > HLSL, and maybe I got my hands on it too.
I'm sure BGFX shaders be better than both of those. I can't stand of waiting.
> > > On the HLSL you have to re-config the settings. GLSL doesn't need to be re-config > > on the settings once it is done. > > Same goes with HLSL, once you're done you can save your settings in a custom ini. > > I'm talking about the changes on the settings. Every time someone change the HLSL ini > settings then we had to re-config it.
And if someone changes the GLSL shader the settings might also change. Other than HLSL the shader code and setting are in the same file.
> Remember the HLSL files or something got broken?
I remember that every time someone had problems with the HLSL files they were outdate, because only the mame.exe was replaced.
I played about 6 hours of MAME tonight with my new Nvidia GTX 970 and Acer Predator XB271HU. Nothing beats HLSL with Jezze's raster.ini settings and I can say this as someone who's ran a lot of GLSL as well.
Really looking forward to what the future brings and am very thankful for everyone's work.
Your work on fixing the issues with the scanlines is hugely appreciated, thank you
If I download your screenshot and zoom into the .wip section then the scanlines are still not even despite being calculated from a pure white background of the same colour.
It looks like the brightness of each scanline is being calculated by a sinusoidal equation of some sort but the offset of the peak brightness is being shifted.
The following is taken from your .wip picture:
The left hand side shows the scalines at the top of the image, the right hand side shows the scanlines slightly below the scanlines shown on the left.
In this case the thickness of each scanline is even. The brightness is not.
I see what you mean, but I think it is not possible to fix that issue with a full-screen scale unless the resolution of the screen is a exact multiple of the game resolution.
I can see your predicament but the approach that GLSL takes towards scanlines does not suffer from the same issue. I believe this is also what Roger is referring to.
I understand that the link above can be argued to be less accurate than the simulation that HLSL provides. However, the scanline and aperture aspects of the GLSL seem to scale correctly.
Would it not be feasible to adopt a similar approach for HLSL whilst keeping the remaining, more accurate aspects of CRT simulation intact?
> It's pointless to even judge before it's completely implemented, and raving about how > bad it is would only serve to demoralize people from actually finishing the work. Why > don't you actually just kindly keep quiet on judgments until there's feature parity? > > BGFX is going to be a whole lot more than just CRT simulation.
Word and absolutely agree. It seems a lot of people have no understanding and sense, how much work in the past 2 years went into HLSL and even worse they claim things here, that are simply not true. If you people have no nerves to play with the settings of HLSL, then dont judge about HLSL and stuff you dont even test for yourselves.
Does GLSL have a LCD shader for Gameboy? NO Does GLSL have any Vector shader? NO Does GLSL have NTSC, Bloom and the usual CRT stuff all together? NO Does GLSL have Phosphor Life simulation? NO Does GLSL have a slider menu to adjust parameters in realtime? NO
The GLSL geom shader has exact the same issue. I didn't tested lottes implementation, but I bet it has it too.
A screen resolution of 1600x900 may not the best example, because is quite low nowadays. But the higher the vertical resolution the less you will notice the interpolation of the scanlines.
Edit: - added lottes implementation to the screenshot
> The GLSL geom shader has exact the same issue. I didn't tested lottes implementation, > but I bet it has it too. >
Right and Lotte CRT is the worst of the worst, it has a nice shadowmask, yes, but the rest is not nearly as good, as CRT-geom or HLSL. Talking about moire? just look at this crap.
And Jezze is right, the lower the screen-resolution, the more artefacts will show up. Pretty bad on every bar-top, i have seen in the last years.
> I haven't noticed any interpolation using the attached GLSL shader based on Lottes' work. It is obvious from that screenshot you posted though.
I added an example of lottes implementation in my last post.
> Would rounding to the nearest integer for each scanline have a desirable effect or would that introduce other issues?
If I would force all scanlines to be integer sized, 220 scanlines would be exactly 4 pixel height and 4 scanline would be exactly 5 pixel height; based on the screen and game resolution used in my examples.
As I said before it would be the best to have a screen resolution which has a multiple of the game resolution. But then you would have a black border around the screen, depending on the real resolution of your monitor.
Just a remark about black borders; depending on the display and emulated hardware, when using integer scaling the resulting borders can be rather small and very much acceptable, I don't know why people freak out with the idea of borders. For instance in cases you're playing on a big display it's often much more enjoyable to have a clean scaled picture with reasonable borders rather than the obligatory maximum stretching.
Also I've said it in other threads but when using a smaller display this time, having the possibility to integer-stretch outside of screen limits, resulting in the opposite (a few lines left out) is also quite enjoyable.
Of course it's very nice if alternatively using a shader(s) can still maintain visual integrity while using the entire V or H real estate, but it also means those who care about a clean picture have no choice but to use the shader(s) since an integer option is not included in base MAME to begin.
Really curious to see how all that'll evolve with BGFX.
> > > It's pointless to even judge before it's completely implemented, and raving about > > > Does GLSL have a LCD shader for Gameboy? NO > > There is a LCD shader? Nice!!! I missed it. Perhaps it would work nice with Game > Gear.
So far as I know, it's only been tested on classic Gameboy (monochrome against pea soup). Perhaps I am wrong, but I never saw test images for anything else.
> Right and Lotte CRT is the worst of the worst, it has a nice shadowmask, yes, but the > rest is not nearly as good, as CRT-geom or HLSL. Talking about moire? just look at > this crap. > > And Jezze is right, the lower the screen-resolution, the more artefacts will show up. > Pretty bad on every bar-top, i have seen in the last years.
This is exactly why I've had to stop using the artwork all together. As much as I enjoy looking at it, I can't have it changing the game area depending on game I run.
It should be the opposite where the artwork is manipulated around the screen area not used so the game area is the exact same whether artwork is enabled or disabled.
That or if some kind of slider could be added where you shrink the game area to make artwork more prevalent or vice-versa that would be kinda cool.
I just added the artwork, to show you all what happen, if the (game) screen-resolution is small. In bartop environments you usually deal with 1024x768 and that tend to look like my picture, if vertical oriented games are launched, even without artwork.
Also you can use cropped artwork presentation, which give exactly the results you desire. TBH the handling of artworks, is for the ass. Not intuitive at all, even the devs cant explain it well enough, how it works. Artworks are nice, but handling is rubbish, must have been good weed at that time to understand that logic behind it.
I don't know if I'm understanding your comment about artwork - but since I've played around in creating some of it, I'd say there's a dilemma for artwork creators.
That is - for original artwork, there is a desire to perfectly (as possible) replicate the original artwork. However, Mame isn't able to truly recreate the original experience in this regard, because in the virtual world the artwork shares screen space with the gameplay. So often, perfectly replicating the original artworks dimensions, means the gameplay area is heavily compromised. This is especially true in a 16:9 world.
However, the gameplay area is perfectly customizable within the LAY file - so there is no reason at all that the option to switch off the artwork should affect the original aspect ratio of the gameplay.
When beginning my artwork journey I thought about this quite a bit, and decided on a policy of producing artwork that was always compromised to maximize the gameplay area. So purists will hate my decision, those who want to play games might enjoy it. As I say, it's a dilemma. The fact remains, in the original cabinets the screen wasn't compromised by the artwork, unless it was a conscious design decision by the developers (overlays etc). In Mame, there's only so many pixels to go around.
Personal preference, but cropped artwork never satisfied me. Basically it corrects the gameplay size, but often butchers the artwork. Each to their own, of course. I think Mr. Do and Comboman would very much disagree with me.
> However, the gameplay area is perfectly customizable within the LAY file - so there > is no reason at all that the option to switch off the artwork should affect the > original aspect ratio of the gameplay.
I never said that you cant perfectly cutomize the gameplay area. I said it is not intuitive and i am not the only one that have problems to fully understand the lay-file. To determine the gameplay-area, you need to do calculations. It would be a lot easier, if there would just exist X,Y values in pixelsize, like 800x600... but no, you need to subtract, to add and what not.
Lay-files need also caution and accuracy while creating, especially for systems that dont have any artwork. Just look how ugly Vectrex turned out and it is not only ugly, it is completely wrong in aspect ratio, if you compare it with the real hardware. So somebody didnt know this and tried to fit the game screen into the lay-file and the result is a console-presentation in wrong aspect ratio. It is especially bad, because even if you turn off artworks, the screen with the wrong aspect ratio remains. Whose fault is that? the lay-files of course. As those overlays are ugly crap anyway, wouldnt it be logical, to stretch them to the correct aspect ratio, so that at least the game play area is correct?
Mr. Do wouldnt deliver quality like this and i would rather not have any overlay file for the Vectrex, but correct aspect ratio of the gameplay area instead.
I did offer to write an "idiots guide" to creating artwork - because I agree with you, learning them can be hellish. It's often a matter of deciding what you want - something completely authentic, which may or may not actually look good if you're playing on a modern LCD screen - or something that is somehow compromised. I agree with you, if a compromise must be made, then it makes sense not to compromise the gameplay area...... but I know I've made mistakes in the past - as everyone does.
> I don't know why people freak out with the idea of borders.
The clue is in the word used. I've alwasys thought of blank/black as space. Expand into the space, not be occluded by it. It's the nature of people, though....borders, boundaries.....rather than boundary conditions.
Index 
Threaded 
HLSL with Intel HD4600 works.....
Reply
[Re: 
to understand that logic behind it.
