Previous Thread
Next Thread
Print Thread
Page 8 of 19 1 2 6 7 8 9 10 18 19
Re: A couple GLSL issues [Re: cgwg] #76641 01/31/12 10:48 AM
Joined: Sep 2006
Posts: 89
M
M. Twitty Offline
Member
Offline
Member
M
Joined: Sep 2006
Posts: 89
cgwg, what a wonderful thing. And thanks for consolidating all of the settings in the main file.

Re: A couple GLSL issues [Re: cgwg] #76645 01/31/12 02:01 PM
Joined: Jan 2012
Posts: 22
Q
quartz Offline
Member
Offline
Member
Q
Joined: Jan 2012
Posts: 22
yep, fixed. which is weird, because you'd think an nvidia compiler would produce something that works on another nvidia card...

I like the new adjustable rounded corners and proper 144 border blackout. I'd faked it previously by abusing the 'effect' image options. the tilt feature is cool too, but is there an easy way to have it read an ini value rather than being hard coded in the vsh? for games with sideways screen hacks (like daioh) you have to swap the x and y values. you can get around this currently by having a separate copy for normal and sideways games, but that seems silly. don't bother if it's too much of a pain to implement though.

one thing I would really like to see is the scanline bloom effect like you put in the 'crt-old/scanline' version at the top of the page. I think that really gives the proper look. (if it's already in crt-geom I can't see it, maybe make it adjustable?)

good work though. this really ought to come bundled in the mame distros or with the source or something.

Re: A couple GLSL issues [Re: cgwg] #76646 01/31/12 02:08 PM
Joined: Jan 2012
Posts: 22
Q
quartz Offline
Member
Offline
Member
Q
Joined: Jan 2012
Posts: 22
...or, the top of the previous page at this point...

while I'm thinking of scanlines, how hard would it be to implement an 'aperture1x3rb' style effect as an alternative to the simple-light-and-dark scanlines? using an effect image doesn't play nice with the screen curvature options (and tends to make the picture darker in a way that can't be compensated for easily).

if you could somehow give the choice of different tv/arcade patterns all in one package, that would be awesome.

Re: A couple GLSL issues [Re: cgwg] #76647 01/31/12 02:13 PM
Joined: Mar 2001
Posts: 16,446
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,446
OS X doesn't use vendor OpenGL stacks or drivers. Apple uses a unified GL stack (including an LLVM-based shader compiler) and their own drivers. So you get very consistent results across cards on OS X (hardware capabilities permitting), including what the shader compiler accepts or doesn't. And Apple's compiler is less permissive than what Nvidia ships in their Windows and binary-blob Linux drivers (as is ATI's on PCs; hence a lot of demoscene stuff only runs on Nvidia).

Last edited by R. Belmont; 01/31/12 02:15 PM.
Re: A couple GLSL issues [Re: R. Belmont] #76649 01/31/12 02:17 PM
Joined: Jan 2012
Posts: 22
Q
quartz Offline
Member
Offline
Member
Q
Joined: Jan 2012
Posts: 22
Originally Posted By R. Belmont
Apple uses their own drivers.


right right right.... I forgot about that for some reason. valve had problems with that too when they ported portal.

Last edited by quartz; 01/31/12 02:18 PM.
Re: A couple GLSL issues [Re: quartz] #76666 02/01/12 04:31 AM
Joined: Jul 2007
Posts: 78
C
cgwg Offline OP
Member
OP Offline
Member
C
Joined: Jul 2007
Posts: 78
Originally Posted By quartz
the tilt feature is cool too, but is there an easy way to have it read an ini value rather than being hard coded in the vsh? for games with sideways screen hacks (like daioh) you have to swap the x and y values. you can get around this currently by having a separate copy for normal and sideways games, but that seems silly. don't bother if it's too much of a pain to implement though.


I'm aware of this issue. I haven't tried it, but I think that it is possible to detect which direction is down by using the derivative functions in GLSL, although that's not ideal. The proper way of doing this (and other things) would involve integrating the shader into MAME like is done with HLSL on Windows.

Quote:
one thing I would really like to see is the scanline bloom effect like you put in the 'crt-old/scanline' version at the top of the page. I think that really gives the proper look. (if it's already in crt-geom I can't see it, maybe make it adjustable?)


Ok, I've added the old-style purely gaussian scanline bloom as an option controlled by #defines. It's uploaded here, with the old-style scanlines currently enabled.

Quote:
while I'm thinking of scanlines, how hard would it be to implement an 'aperture1x3rb' style effect as an alternative to the simple-light-and-dark scanlines? using an effect image doesn't play nice with the screen curvature options (and tends to make the picture darker in a way that can't be compensated for easily).


Aperture/shadow mask patterns are a difficult thing to do. I've written about this before, both in one of the HLSL threads on these forums and on the byuu.org forums, but the upshot is that most currently available monitors don't have a high enough resolution. And any pattern will always have the effect of darkening the picture. That being said, given that there might be some interest, maybe I'll try to dig up my past experiment in simulating a curved aperture grille (although I suppose that would mean that I should also implement a shader that simulates a cylindrically curved screen to go with it).

Re: A couple GLSL issues [Re: cgwg] #76668 02/01/12 05:51 AM
Joined: Jan 2012
Posts: 22
Q
quartz Offline
Member
Offline
Member
Q
Joined: Jan 2012
Posts: 22
Quote:
The proper way of doing this (and other things) would involve integrating the shader into MAME like is done with HLSL on Windows.

it's not a big deal, like I said you can just have two copies with different names. I don't think this is important enough to waste a heck of a lot of time on.

Quote:
Ok, I've added the old-style purely gaussian scanline bloom as an option

hrm, I see that the code is in there, but I'm not seeing a difference between this and the 'fixed' geom you posted last.

upon closer inspection, I'm not sure about what exactly it is I'm seeing in the old 'scanlines' version. I thought it was taking areas of high luminosity and making the dark lines less dark (closer to native unfiltered brightness), but now that I look harder it seems it's only doing that near the center of the screen, and the outlying areas are pretty much unchanged? maybe I'm unclear what the bloom effect was supposed to look like and what I'm really seeing is a weird bug. I can post pics if you have no idea what I'm talking about.


Quote:
but the upshot is that most currently available monitors don't have a high enough resolution.

I'm not sure I see the problem here. current monitors are already good enough to handle what is effectively a 2px wide light/dark scanline effect, how is a 2px wide green/magenta effect that much different?

Quote:
And any pattern will always have the effect of darkening the picture.

that's not entirely true, as you can compensate for it within the shader by lightening the bright lines- not something I can get with a simple effect png because it's always applied last in the chain and always multiplies down.

Re: A couple GLSL issues [Re: cgwg] #76689 02/02/12 12:47 AM
Joined: Mar 2007
Posts: 237
T
The Flying Ape Offline
Senior Member
Offline
Senior Member
T
Joined: Mar 2007
Posts: 237
Really cool effect, excellent work. Using MAME 0.144 (and 0.144u6), Fedora 16, Radeon HD 5670, runs great!

Tinkered with the parameters in main(), first, can you pass parameters already, or alter main() to allow passing of parameters?

Assuming I get this, the tilt away/towards is determined by vec2(), so I altered it to vec2(-0.15,0.0) and looks great for pacman for tilt away, but the same settings for mrdo renders as a tilt towards, so I have to change to +0.15 Is that supposed to do that?

Re: A couple GLSL issues [Re: quartz] #76698 02/02/12 03:47 AM
Joined: Jul 2007
Posts: 78
C
cgwg Offline OP
Member
OP Offline
Member
C
Joined: Jul 2007
Posts: 78
Originally Posted By quartz
maybe I'm unclear what the bloom effect was supposed to look like and what I'm really seeing is a weird bug.


I decided to make a few pictures. Here are some scanlines with the bloom effect turned off. The little bit of clipping in the bright parts is unintentional; I would have to adjust the normalization to eliminate it. The profile of the scanlines is gaussian, with constant width.

Now with the bloom effect turned on. It's not a big effect, but the scanlines get wider when the image is brighter.

Finally, the newer, nongaussian bloom effect. At the bright parts, the scanlines get a bit wider, but they also change shape and become flatter.


Quote:
current monitors are already good enough to handle what is effectively a 2px wide light/dark scanline effect, how is a 2px wide green/magenta effect that much different?


Unlike scanlines, the phosphor triplets on a CRT have no direct relation to the pixels generated by video hardware. Usually, the dot pitch will be somewhat higher than the distance between scanlines.

Originally Posted By The Flying Ape
Tinkered with the parameters in main(), first, can you pass parameters already, or alter main() to allow passing of parameters?


Currently MAME passes a few parameters to external GLSL shaders. These give necessary values like the pixel dimensions of the image. Passing through more parameters would require modifying the code that interfaces with the shaders. At some point, it makes more sense to integrate a CRT shader like is done with HLSL on Windows.

Quote:
Assuming I get this, the tilt away/towards is determined by vec2(), so I altered it to vec2(-0.15,0.0) and looks great for pacman for tilt away, but the same settings for mrdo renders as a tilt towards, so I have to change to +0.15 Is that supposed to do that?


Yes, my shader doesn't automatically detect which direction is down. In this case, mrdo and pacman are rotated 90 degrees in opposite directions by MAME, so you would need opposite tilt parameters for them.

Re: A couple GLSL issues [Re: cgwg] #76721 02/02/12 03:28 PM
Joined: Jan 2012
Posts: 22
Q
quartz Offline
Member
Offline
Member
Q
Joined: Jan 2012
Posts: 22
Quote:
I decided to make a few pictures.

ok, that makes sense. however what I was seeing was that towards the center of the screen, the bright lines bleed together into a solid lump with no dark in-between.
this appears to be a bug though: it comes and goes depending on window size. mind you I have all the scaling and filtering options turned off, and if I screencap the image and open it in photoshop they're all exactly the same size to the pixel. it just happened that the default size was one where it showed up, and the game I was playing at the time had a lot of bright parts in the center, so I thought it was intentional.

Quote:
Unlike scanlines, the phosphor triplets on a CRT have no direct relation to the pixels generated by video hardware.

that's only mostly true. remember that your original 15khz monitors were limited to 250-300 vertical lines because of frequency issues, and most games used pretty much all of those. the range of possible pixel-to-phosphor ratios is a lot smaller than what you'd see for a pc monitor crt running at who knows what res. I think you could fudge it. even if all you did was overlay the aperture1x3rb when playing the game at 2x or larger, that would still look halfway decent IMO. I mean, it's not possible to get a modern lcd to look exactly like an arcade monitor, I think most people would be happy as long as it's a good faith attempt along the same lines. you could always let people turn it off with a #define if they don't like it.


Quote:
At some point, it makes more sense to integrate a CRT shader like is done with HLSL on Windows.

how easy would it be to get that started anyway? I don't really know the mame dev community, would they be receptive to this? crt-geom as it stands is already pretty damn good, it would be nice to make it more official.

Page 8 of 19 1 2 6 7 8 9 10 18 19

Moderated by  R. Belmont 

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