Back when Moogly first added BGFX shader support I was sort of keeping up with things.

I could write and compile shaders and everything was fine. Sometimes shader compilation would break for one or more backends when BGFX (the third party stuff, not MAME) was brought in, but it usually went away with the next BGFX update.

But I was working a full-time job and another 66%-time teaching job and stopped paying attention for a couple months.

Anyway, I can't compile shaders or bgfx-tools, with the official dev tools now.

Specifically, I get errors compiling shaderc at first. Then, after solving this (or attempting to) by manually running some commands involving flex/bison that I have no idea what they do, I can get a little further. I end up at a command prompt (cmd.exe not bash) that the bash shell opened with nothing going on.

That's also what I get if I just head into the mame/src/osd/modules/render/bgfx/shaders folder and try to compile the shaders from there. Which also used to work but doesn't now.

I don't know if it's just some makefile nonsense, some kind of path/package issue, or something else. But at the end of the day, I can't compile the shaders/bgfx-tools in Win7 or Win10 on a couple different PCs with either freshly downloaded or updated dev tools.

My guess is that something broke awhile back in the 3rd party bgfx section and that nobody noticed because (1)shaders aren't compiled very often (2)people don't use windows (3)you still have old working compiled bgfx tools in your environment so you don't see the breakage.

Any ideas on how to get this working again?

It can still be done on Win7. I needed to grab a D3D compiler DLL from the platform SDK or from an IE11 install, but once I had that it worked.

I didn't think of anything like that. I'll see if I can find what I need. Thanks for the tip!

Any chance that we see a automated compile process?
Its really hard and annoying for a beginner/novice/noob like me, to test the shader results. It was a lot easier in the past with OpenGL, but with way less options of course.

This is no criticize, i just want to know, if there are thoughts about it .

Well it is automated - there are make commands for doing it. But it's more manual steps than with OpenGL which is compiled on-the-fly.

You mean like the one we have now? You just need d3dcompiler_47.dll in c:\windows\system32. You'll have to track it down yourself, but after that "make shaders" works just fine to rebuild all shaders in MAME, immediately putting them in the right spot for use.

Except it's not, even the OpenGL version of BGFX uses post-processed shaders of some kind. It's not like the OpenGL version just magically reads the .sc files that aren't supplied with a stock MAME distribution.

Well, i know my engrish is bad and i apologize. With OpenGL i really meant the old one, not that one in BGFX. It takes more steps now, until i can test a shader. In the past, i could just open a shader with notepad, change it and i was done with it.

Anyway, thanks for all the infos. I hope i will have the time to use them, as soon as possible .

Then no, you won't be able to do that. The BGFX library needs to have its shaders pre-compiled. I would be really happy if Branimir made the BGFX library able to support runtime shader compilation, but I really don't see that happening anytime soon, and in any case, the BGFX library has nothing to do with MAME other than being what my shader code interfaces with, so it's none of our concern at the end of the day.

That's a shame, I think MAME users enjoyed the "plugin" aspect to the OpenGL code.

And yet there are commercial games using BGFX. Don't be impertinent, we're hardly the only/biggest user of the library. The same rule goes for the BGFX library that goes for MAME itself: Feature requests can fuck off if they don't come with a corresponding patch.

And in this case he'd want the compiler to work on at least Mac and Linux (ie, without D3DCompiler) so that would be quite some patch.

OpenGL and BGFX. I still using both.

That having been said, I'm pretty sure there's already a way to invoke shaderc for a specific platform. If shaderc could be made to compile on Linux and OS X (for all I know it already does), then I see no reason why Micko couldn't work his magic and change "make shaders" to only invoke the GLSL, GLES, and Vulkan targets for shaderc.

Shaderc does already compile on Linux. Lacking in clean makefile magic, I had to make the following changes in order for "make shaders" to work:

• In src/osd/modules/render/bgfx/shaders/makefile, comment out the lines that contain TARGET=n, except for the case n=4.
• In src/osd/modules/render/bgfx/shaders/shader.mk, add a backslash before the semicolon in the lines
  
  Code:

  VS_FLAGS+=-i $(THISDIR)../src/;$(THISDIR)../examples/common/
  FS_FLAGS+=-i $(THISDIR)../src/;$(THISDIR)../examples/common/

For a first try, I've ported my CRT shader to bgfx; get it here in uncompiled form. Note that this has only been tested on Linux/GLSL with an Nvidia card.

#
# BGFX POST-PROCESSING OPTIONS
#
bgfx_path bgfx
bgfx_backend auto
bgfx_debug 0
bgfx_screen_chains crt-geom,crt-geom,crt-geom
bgfx_shadow_mask slot-mask.png
bgfx_avi_name bgfx.avi

Not showing the effect here on MAME64 (Windows 10 with AMD graphics card). I just tried it out. I'm doing it wrong? The rest of the bgfx shaders works.

No shit it doesn't show the effect, he said he supplied the shader in uncompiled form. You need to build it first.

Oh ok.

thats awesome cgwg... will try as soon as i am home... sounds promising.

Neat!

But dx9 and dx11 shaders won't compile right now because bgfx has some annoying constraints (bgfx itself, not MAME).

Look here: https://bkaradzic.github.io/bgfx/tools.html

and you'll see:



So for crt-geom to work we need:

• all the "vec2(0.5)" type things updated to vec2(0.5, 0.5) or I guess vec2_splat(0.5)
• the matrix multiply for the transformtation to use mul(x,y)
• all access of varying parameters to be in main() ONLY

The last one is a bit of a pain for your shader because you expect sinangle, cosangle, stretch, etc to be available everywhere. The shader will need those passed into every function that uses them. Also, even though the varying parameters aren't accessible in functions that aren't main(), you still can't use those variable names in the helper functions. So you can't for example do this:

because the compiler will bitch about the name sinangle and cosangle.

And somewhere you have a variable called "point" that is some kind of reserved name or something. So that needs changing too.

I'm not trying to force you to make all these changes, I could probably do it if I have a few minutes later. But I wanted to list the required changes here in case you wanted to make the modifications yourself, but didn't have access to a Windows PC with MAME build tools.

Good work though. HLSL is too slow to run on integrated graphics and CRT-geom isn't. So it definitely is useful to have available.

Thanks Soltan, that sounds promising

Thank you SoltanGris42 for the info and indeed, it would be nice to have crt-geom, it became a very popular shader among MAME users.

Ok, I took a shot at it.

I didn't try to make smart decisions about the best way to do anything. Just mindlessly fixed whatever the compiler was complaining about.

And even though the opengl version looked fine, the dx versions produced incorrect output with the matrix/vector multiplication and so I switched it to separate multiplications.

I also added in a magenta/green striped aperture mask just because I thought it was a standard feature in most crt-geom versions floating around the internet. And I added a slider to turn off the effect. I hope cgwg doesn't mind...

The file I'm uploading has a bgfx folder to merge with the one in the MAME folder that includes the chain/effect/binary shaders and a separate folder with the modified source.

Here you go: http://filebin.ca/2kEIhx4PExYW/crt-geom_bgfx_modified.zip

Thank you SoltanGris42

Thank cgwg! I looked at crt-geom when Moogly first added the bgfx system and decided it would be a PITA to port to bgfx because of the way it used "#define"s for everything.

So it's pretty cool that cgwg just popped up with "Here's a bgfx shader"

Because we wouldn't have had it otherwise unless MooglyGuy went on another shader porting binge.

I'm gonna wait until it is added to the https://github.com/mamedev/mame I have no idea on what I'm doing. Not that smart. No rushing at all.

Nevermind. Keep my mouth shut about removed the HLSL and OpenGL later on.

Well it's actually super simple.

You just need to get the "effect", "chain", and "shader" folder contents in the right place. It's easier than switching GLSL shaders or modifying the json files to change the default shaders. And I know that you've done that stuff.

So you should be able to do it.

Because who knows when or if it will end up in MAME git. I'm not sure what license crt-geom is, or whether JD wants to add every random shader to MAME or not. I think crt-geom would be great to have, personally, because it's got to be the most commonly used of the GLSL shaders and people trying to run HLSL on a potato will have more luck with crt-geom.

Understood SoltanGris42

@Dullaron just extract the archive as SG stated (basically the root of your mame folder)

Then simply run with

Oh ok. I thought I have to compile it first. Working here. Thanks guys.

There should be no problem with the license:



and cgwg always gave us kindly the permission to use it.
i agree with the low-resource statements of crt-geom. it is really a good alternative for low-end setups.

I probably gonna host that. Since it free to use. Adding it later today on the website. With a note saying what it is for.

So will this be added to next distribution?

Anybody care to take a screenshot or two?

If someone can package it up into a nice pull request (or at least a diff) it can probably go in.

Added onto https://sites.google.com/site/o0kinghanco0o/crt-geom-alternative-downloads (Note: horizont only. Tested on Galaga and it leaving color lines. Turn it to the side will fix the problem.)

I may just leave it there for backup anyway.

Yeah.

I wasn't going to change a bunch of stuff in the shader. It's cgwg's, after all. But I probably should have handled vertical games correctly at least.

If cgwg wants to do more work on it, that wold be great. I guess that if he doesn't want to, I can fix it up a bit so it can be included in MAME.

I can try to copy the format/style of MooglyGuy's shaders and I suppose I can figure out how to do a diff or a pull request if nobody else will.

It would take a few days or a week since I'm pretty busy work though.

No problem at all. If you can't do it then don't worry about it. People will have to lay down to their side or turn their arcade screen to vertical for Galaga or some other vertical games. cgwg probably doesn't know how to make it to auto flip yet. No worry.

If you can get it completed before the end of the month, so it can go into the next release that would be really awesome

I have send you a PM regarding all of these "problems" .

Thanks! It's hard to debug this sort of thing on Linux.

The main reason I never included this in the MAME version is that the same functionality was available using the -effect overlays.

I've created a new version that does a similar thing using textures loaded from files, and I've created a bunch of suitable images. Note that these are all designed for displays with RGB subpixel order, so they won't behave that well under rotation. It's available here, again in uncompiled form.

This version compiles out of the box with no changes. I'll attach the compiled version here so people can try it.

http://filebin.ca/2kZGvOzagKb0/crt-geom_bgfx_v2_compiled.zip

As far as the aperture mask goes, I always add it in the shader rather than a MAME effect overlay, because in my own shader I do additional processing after this step. Since the shadow mask/aperure grille costs a lot of brightness and some saturation/contrast, I do an additional tone-mapping step after the shadow mask to bring it back.

And for rotation I'm not sure what the best thing is. You can always just use the u_swap_xy uniform to decide whether to rotate the mask. But that doesn't always look good for every mask texture, so I don't know if should be automatic or not. Maybe just add a manual selection for mask rotation? Then people can just copy/paste the chain file and use different defaults with their vertical games.

Uploaded the updated files. I removed the older files. Hard to see the color lines on this version. I removed the note about the color lines.

I will keep an eye out here on any new changes.

Feeling energetic, I created a "deluxe" multi-pass version of my shader; get it here, again in uncompiled form. This includes the halation effect that's been available in some versions of this shader for a long time, as well as a new phosphor persistence effect with power law fall-off, as I planned to implement over five years ago.

Very, very nice cgwg. I like your new phosphor persistence, especially on b/w games.

In case someone want to test a compiled version, you can grab it here: http://filebin.ca/2l0KeafVvpy7/crt-geom_deluxe_bgfx_v3_compiled.zip

Thanks. I uploaded the v3 files. v2 files been deleted. Working.

Love the Deluxe version.

Hi cgwg,

I looked into your source code of crt-geom/deluxe and still have some noob questions about it. In your source, i found some irritating stuff, like this in the fs_crt-geom.sc file for example:



AFAIK, in the "old" GLSL version of the shader, only one option should be enabled at once and the other needs to be commented out. In my documentation it is stated like this:



Same is true, for the LINEAR_PROCESSING, commenting it out, makes the shader faster, but AFAIK produce lower quality.

Right now, i would assume that BGFX is calculating both processes.

Would not we need only one "Tilt" parameter, with the correct use of the "u_swap_xy function"? .
If we use this function, the "Tilt" should be always correctly oriented and if the rotation info (90 or 270) from a game could be retrieved, only positive values would matter. In my thoughts, this would lead to a single "Tilt" parameter, that would always tilt in the desired direction and would work for every game.

Anyway, the new version from you, is looking awesome and a nice comparison "side-to-side" to HLSL.

No, there's never been a reason not to enable both. Over time I've come to prefer the Gaussian profile, and the oversampling will improve image quality with some reduction in speed.


The "LINEAR_PROCESSING" feature will indeed be a bit slower, but whether the quality is higher is debatable. (I believe this feature was actually added by one of the other authors, and I've never been in favour of it.) The image on a CRT is blurred horizontally in (at least) two different steps:

• In the video amplifier, which has limited bandwidth
• In the electron beam, which has nonzero width.

To first approximation, the gamma ramp occurs between these two steps. In the default setup, my shader does four-tap Lanczos interpolation before applying the gamma ramp. This provides some simulation of the first step but not the second. If "LINEAR_PROCESSING" is turned on, the gamma ramp is applied before the Lanczos interpolation; this means that there is no simulation of the nonlinear effects that occur in the first step.


Yes, that's a good idea. I actually tried using "u_rotation_type" for this (the code is still present in my shader but commented out) but that uniform only carries the user-specified rotation and not any automatic rotation of the game screen. I don't know if this was the intended behaviour.

Is there away get the circle lines on the screen through the crt settings? BGFX already set to it. B2K24 post these snapshots of the real thing. http://imgur.com/y1ITYIu and http://imgur.com/NY7rlck

mcx997 post these snapshots from the BGFX I think. http://www.imagebam.com/image/35620d491739191

http://www.mameworld.info/ubbthreads/sho...part=1&vc=1

All I saw is the curve lines on the crt.

Well we get these artifacts in shaders with curvature because the aperture mask and/or scanlines are almost but not quite lining up with the pixels of the display. More resolution helps to fix this problem.

When you take a digital photo of a real CRT, the real aperture mask and scanlines are almost but not quite lining up with the sensor in the camera. So the effect is virtually identical to what you see in shaders.

You DO get some of this on real CRTs seen by your eyes and not a camera. But not nearly to the extent that we get it in photos or in CRT shaders.

BTW since I'm posting anyway. I won't have time in the next few days to set up a current build environment and figure out how to do the pull request for crt-geom. Work is beyond crazy and I'm not losing sleep time to this (sorry...). So someone else will have to do it if it needs to be done soon to be in the next MAME release.

I belive u-man posted a compiled version that just drops in over the MAME source with the shader source, chains, effects, and shaders in the right place. I think that cgwg's last update had everything except the compiled shaders. So it should be easy to add if MAME devs want it, right? Just drop the files in and go.

Files added to the source now.