|
CRT-aperture GLSL shader
#368803 - 08/17/17 03:37 AM
|
|
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
Re: CRT-aperture GLSL shader
[Re: Dadriell]
#368806 - 08/17/17 04:41 AM
|
|
|
Looks pretty nice. Thanks for posting your work.
If you make any more, feel free to add them here as well ![](//www.mameworld.info/ubbthreads/images/graemlins/smile.gif)
I'd really like to look at all the CRT Royal stuff, but RetroArch handles MAME too badly for it to be worth it for me.
Thanks again for your post
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: Dadriell]
#368810 - 08/17/17 10:38 AM
|
|
|
Awesome job. I appreciate any new CRT shader. It is a little sad, that MAME cant stack shaders like they do in Retroarch. That way everybody could create their own shader-setups, but progress like this is definitely great.
|
|
|
Dullaron |
Mitchell or Dunard Garaus
|
|
|
Reged: 07/22/05
|
Posts: 6134
|
Loc: Fort Worth, Tx
|
|
Send PM
|
|
|
Re: CRT-aperture GLSL shader
[Re: uman]
#368830 - 08/18/17 01:50 AM
|
|
|
> It is a little sad, that MAME cant stack shaders like they do in Retroarch.
MAME will someday. It will. Just needed more cool changes to it. Never give up that dream.
|
W11 Home 64-bit + Nobara OS / AMD Radeon RX 5700 XT / AMD Ryzen 7 3700X 8-Core 3.59 GHz / RAM 64 GB
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: Dadriell]
#368833 - 08/18/17 05:07 AM
|
|
|
I'm curious, since I'm hacking up HLSL right now, what do people want most from these shaders?
|
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
Re: CRT-aperture GLSL shader
[Re: anikom15]
#368834 - 08/18/17 07:05 AM
|
|
|
> I'm curious, since I'm hacking up HLSL right now, what do people want most from these > shaders?
I'm unsure about what you're doing or what your skill set is, but it would be nice if vector stuff worked with BGFX.
As of right now you have to run with -video d3d and the vector.ini is decent, but it would be nice to have something like vector.json or some equivalent option using BGFX.
|
|
|
|
|
> I'm curious, since I'm hacking up HLSL right now, what do people want most from these > shaders?
I am also unsure what exactly you mean with that. From what was said in the past, is that BGFX should replace HLSL to ensure a shadersystem that is equal across all OS platforms. It was also said, that the conversion process from HLSL to BGFX is easily done (this was two years ago). So first, it would be nice to see all functions from HLSL ported over to BGFX, that would be a good start. I agree to B2K24, that all vector stuff should be in BGFX too. It would be sad, if the vector improvements done by Jezze would be lost or only available for windows users. Jezze´s work could be further improved by introducing and supporting HDR, as HDR monitors are now available and affordable.
If this is something that is interesting for you, here are some helpful links, including Moogly Guy´s manifest to proper vector rendering: https://github.com/mamedev/mame/issues/399 http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=104711&page=3
One probably easy thing, would be to add the tilt function from the crt-geom shader to the HLSL port in BGFX. It is a underestimated function, especially in combination with multiple screen artworks.
And no, i am not harassing you or anyone else, who is willing to improve shaders, but if you already asking what people do want most, then that would be my wishlist. MAME has some unique shader functions, so why not adding even more.
One idea for a unique feature would be a shader generated bezel which mimics a outer glow, like in this picture:
[ATTACHED IMAGE]
Edited by uman (08/18/17 10:13 AM)
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: uman]
#368845 - 08/18/17 04:30 PM
|
|
|
Would you mind if the hum bar was removed?
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: anikom15]
#368847 - 08/18/17 04:58 PM
|
|
|
I did not write the code and IMHO the hum bar is just a kind of a nice gimmick. It is a phenomenon that happens, by filming a CRT screen and the camera is not in sync with the CRT screen. It is not something that really happens on a CRT screen, not even on a one with quirks.
On the other side, it feels bad seeing Jezze´s work/functions removed one by one, like it happens already and just for the purpose of BGFX. I am neither a Linux or a Apple user, but that is just my opinion.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: uman]
#368849 - 08/18/17 05:24 PM
|
|
|
The reason I ask is because the current implementation is an annoyance to me and doesn't fit well in the whole scheme.
'HDR monitor' probably means three things: 1. Good contrast 2. Wide gamut 3. Higher bit-depth
1. doesn't require any additional changes in MAME. 2 could be bad if 3 is not present in the monitor as well. Honestly, wide gamut is a pain in the ass and outside of photography really doesn't need to exist, but the next video standards use wide gamuts so I guess we have to live with them. To implement this in MAME is tricky. We'll probably need a third-party color management library and have to override everything the OS does, which can potentially be confusing and annoying, because every OS does color management differently, and there are quirks like how color management doesn't actually work for fullscreen apps on Windows. As far as the shader goes, right now I implemented 8 color space matrices. I might have to generate these matrices in real-time instead. It depends what sort of gamuts are used in these monitors. Hopefully they all just use the UHD standard, but I suspect it's not so simple. If you can, send me info on these monitors.
I want to make a shader for artwork, the glow effect would have to go there, but that's probably a separate project right now.
I can't make any improvements to the vector shader, but I can try to port it to BGFX. Porting is not as trivial as advertised unfortunately.
|
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
Re: CRT-aperture GLSL shader
[Re: uman]
#368854 - 08/18/17 07:20 PM
|
|
|
> I did not write the code and IMHO the hum bar is just a kind of a nice gimmick. It is > a phenomenon that happens, by filming a CRT screen and the camera is not in sync with > the CRT screen. It is not something that really happens on a CRT screen, not even on > a one with quirks. > > On the other side, it feels bad seeing Jezze´s work/functions removed one by one, > like it happens already and just for the purpose of BGFX. I am neither a Linux or a > Apple user, but that is just my opinion.
So you're saying the guy playing these cabs live does not see the hum bar effect?
https://youtu.be/0WK1Ec-KVVQ
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: B2K24]
#368858 - 08/19/17 02:27 AM
|
|
|
> So you're saying the guy playing these cabs live does not see the hum bar effect? > > https://youtu.be/0WK1Ec-KVVQ
Yes, the "hum bar" is an artefact of the difference between the refresh frequency of the CRT and the shutter frequency of the camera.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: anikom15]
#368860 - 08/19/17 02:30 AM
|
|
|
Wide gamut doesn't hurt you if you ignore it, provided the user has set up their monitor properly. If you don't provide a colour profile, Windows/OSX assumes you're targeting sRGB and maps it into the monitor's gamut automatically.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: uman]
#368861 - 08/19/17 03:14 AM
|
|
|
> On the other side, it feels bad seeing Jezze´s work/functions removed one by one, > like it happens already and just for the purpose of BGFX. I am neither a Linux or a > Apple user, but that is just my opinion.
I'll have the final say in whether anikom's changes get merged in, and I will reject it if it strays too far from the look and feel of Jezze's shaders. I don't want the great work that Jezze has done to be broken or forgotten.
What I would like to see is a more concentrated effort on bringing the BGFX features up to parity with the HLSL backend, so that Jezze's shaders can be accomplished identically. I unfortunately cannot volunteer that effort, because I'm working two jobs and am occupied 14 hours a day on weekdays, and only slightly less on weekends. Hopefully that will be lifting soon, but I'd really like to see someone else with a passion for graphics come in and do what I can't, in a modular and forward-looking way.
Ultimately Direct3D 9 is a technological dead-end and is more than likely going to have its support increasingly restricted as time goes on, not by MAME, but by operating systems. I like Jezze's shaders, and I hope I'll like anikom's shaders, and I want a modern system where both can be supported, and more.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: anikom15]
#368862 - 08/19/17 03:20 AM
|
|
|
> Would you mind if the hum bar was removed?
I would. It's a neat-looking effect regardless of accuracy, and currently it harms nothing by existing. And if you even have to ask that question, you're at least somewhat unsure if it can be supported while implementing the changes you have in mind, and if you're encountering this uncertainty then you're most likely heading in the direction of making the HLSL system less flexible, which is not at all the direction you should be heading. Reconsider, as woe and ruin lies along this path.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: B2K24]
#368863 - 08/19/17 03:44 AM
|
|
|
Vas is correct but let me elaborate one thing. The artifact from the camera is distinct from a rare but possible hum bar created by a ground loop problem. This hum bar is visible to the human eye and appears to move upward slowly.
Another problem, not to be confused with the other two, is loss of sync signals. This will cause shuttering and bending.
All of these things are undesirable and are not normal for CRTs.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: MooglyGuy]
#368864 - 08/19/17 03:45 AM
|
|
|
It actually doesn't hinder any of my changes, and I doubt it ever would. I just don't like it.*
*Of course I'm keeping it.
Edited by anikom15 (08/19/17 03:54 AM)
|
|
|
Qun Mang |
Legend of Link
|
|
|
Reged: 12/12/03
|
Posts: 746
|
Loc: Hidden Hyrulian city Lurkopolis
|
|
Send PM
|
|
|
Re: CRT-aperture GLSL shader
[Re: MooglyGuy]
#368865 - 08/19/17 04:59 AM
|
|
|
Quote:
you're most likely heading in the direction of making the HLSL system less flexible, which is not at all the direction you should be heading. Reconsider, as woe and ruin lies along this path.
Devquote if I ever read one.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: anikom15]
#368866 - 08/19/17 11:51 AM
|
|
|
> Vas is correct but let me elaborate one thing. The artifact from the camera is > distinct from a rare but possible hum bar created by a ground loop problem. This hum > bar is visible to the human eye and appears to move upward slowly. > > Another problem, not to be confused with the other two, is loss of sync signals. This > will cause shuttering and bending. > > All of these things are undesirable and are not normal for CRTs.
I have never seen a "real" hum bar in my life and i have seen a lot CRT´s in my life. The only effect that comes near to a hum bar, is a very thin line (like 2 pixels that darkens the effected area) that moves up slowly, this was due to very long cables used. But this line was in no way, so noticeable like i.e. the hum bars in the youtube video.
Undesirable is a question of taste, because there are people that prefer a "moody/blurry" look for the screen, especially on arcade games, as it is how they remember them from their memories. This is due to the fact, that many arcade machines did run with no or low service support, often changed pcbs, running the games afterwards with wrong focus settings and what not. Those "undesirable" effects are exactly what makes HLSL so special and these effects actually really happened on the CRT screen and are something that was seen by everyone who stand in front of it.
And this is the only thing i dont like, regarding the hum bar. People with not enough knowledge, are tend to think that this effect "really" happened on CRT´s, like B2K24 for example.
> I'll have the final say in whether anikom's changes get merged in, and I will reject > it if it strays too far from the look and feel of Jezze's shaders. I don't want the > great work that Jezze has done to be broken or forgotten. > > What I would like to see is a more concentrated effort on bringing the BGFX features > up to parity with the HLSL backend, so that Jezze's shaders can be accomplished > identically. I unfortunately cannot volunteer that effort, because I'm working two > jobs and am occupied 14 hours a day on weekdays, and only slightly less on weekends. > Hopefully that will be lifting soon, but I'd really like to see someone else with a > passion for graphics come in and do what I can't, in a modular and forward-looking > way. > > Ultimately Direct3D 9 is a technological dead-end and is more than likely going to > have its support increasingly restricted as time goes on, not by MAME, but by > operating systems. I like Jezze's shaders, and I hope I'll like anikom's shaders, and > I want a modern system where both can be supported, and more.
A job is a job and should have the highest priority... always. It is what makes any further effort and work for MAME developing even possible, not to mention any "real" life basis. No need to say, that i agree with all other mentioned arguments.
However i am sure, that you can contact Jezze for help, in a case where someone is getting stuck with a particular problem.
> The reason I ask is because the current implementation is an annoyance to me and > doesn't fit well in the whole scheme. > > 'HDR monitor' probably means three things: > 1. Good contrast > 2. Wide gamut > 3. Higher bit-depth >
> I want to make a shader for artwork, the glow effect would have to go there, but > that's probably a separate project right now. > > I can't make any improvements to the vector shader, but I can try to port it to BGFX. > Porting is not as trivial as advertised unfortunately.
If you make HDR support possible, you will also improve vector rendering/shading. I think vector games will benefit visually the most of HDR implementation. It is a step further to realistic mimics of phosphor life and the brightness/ B&W levels of a CRT screen.
But making HDR possible is another story. Maybe it is better to wait and see, how the gaming industry will solve all the problems mentioned here, regarding HDR. I only know, that some games already support it and the next gen consoles will for sure. I just dont own a HDR supporting monitor, so i can be of no help here. But i know, that even without a HDR monitor, some effects calculated in 16bit per (RGB) channel, create much better results in my Adobe After Effects program and i think this could apply to MAME and shaders too (might be wrong here).
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: uman]
#368869 - 08/19/17 07:17 PM
|
|
|
Part of my changes was switching to 16-bit floating-point for some textures and I think it does actually improve things, but might just be placebo. Anyway the reason was out of necessity for my additions, not trying to make anything look better.
Another thing is I know both BGFX and D3D renderers much better now so perhaps I can help fix bugs in the future, though I also have a real job, I suspect it's not as intense as MooglyGuy's.*
Anyway I'm sorry to have derailed the original thread. I'll get some screenshots and start a new thread talking in more detail about what I'm actually doing.
*Getting married is another story but that is still a whiles away.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: anikom15]
#368871 - 08/20/17 12:05 AM
|
|
|
> Part of my changes was switching to 16-bit floating-point for some textures and I > think it does actually improve things, but might just be placebo.
Placebo doesn't get you whitepapers. PIX is a thing for DX9, and there are plenty of other graphics profilers as well. Take a frame capture. Compare these captures as you apply your changes.
> Another thing is I know both BGFX and D3D renderers much better now so perhaps I can > help fix bugs in the future, though I also have a real job, I suspect it's not as > intense as MooglyGuy's.*
Fortunately, my second job is finally coming to an end in a week or two. It should have 1.5-2 months ago, but that's how it goes when it comes to game development schedules.
> *Getting married is another story but that is still a whiles away.
Oh, you haven't even heard the story of Migrationsverket (the Swedish immigration service) finally processing the partnership residence application between my partner and I, a year and a half after we applied for it, a few months ago. It involves an abrupt vacation in Norway for a few weeks, comedic levels of bureaucracy, and some interview answers that wouldn't be out of place in Curb Your Enthusiasm.
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: MooglyGuy]
#368883 - 08/20/17 11:18 AM
|
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: mhoes]
#368884 - 08/20/17 11:23 AM
|
|
|
> > PIX is a thing for DX9 > > Not that I know a single thing about the matter, but at least the product > requirements page for PIX states that it's for DirectX 12 only, and not DirectX 9 ? > > https://blogs.msdn.microsoft.com/pix/requirements/
The version of PIX which ships with the DirectX 12 SDK is for DirectX 12 only, this is true. But there is also the DirectX 9 SDK, which ships its own version of PIX which is for DirectX 9. PIX originally stood for "Performance Investigator for Xbox" and dates to the early 2000s when it was used for GPU-level debugging on Xbox development kits (and, for that matter, all Xbox platforms since).
|
|
|
|
Re: CRT-aperture GLSL shader
[Re: MooglyGuy]
#368886 - 08/20/17 11:35 AM
|
|
|
> > > PIX is a thing for DX9 > > > > Not that I know a single thing about the matter, but at least the product > > requirements page for PIX states that it's for DirectX 12 only, and not DirectX 9 ? > > > > https://blogs.msdn.microsoft.com/pix/requirements/ > > The version of PIX which ships with the DirectX 12 SDK is for DirectX 12 only, this > is true. But there is also the DirectX 9 SDK, which ships its own version of PIX > which is for DirectX 9. PIX originally stood for "Performance Investigator for Xbox" > and dates to the early 2000s when it was used for GPU-level debugging on Xbox > development kits (and, for that matter, all Xbox platforms since).
Ah. Thanks for pointing that out. I should have googled harder.
|
|
|