dMZX Forums: UI to swap shaders at runtime; ability to choose shader in game.cnf -> Archived Requests -> Tracker

Pretty sure i'm not the only person who thinks it's jarring to read that GLSL is the highest quality and best performing renderer, naively enable it, and get something that looks totally different from traditional MegaZeux. Why not use simple.frag or something?

I guess we'll wait to see if you are the only person or not. This is the first I've heard of it. I personally like the smoothing of the GLSL renderer. simple.frag sucks at high resolutions.

--ajs.

Updating status to: Awaiting Feedback

God, I hate that thing. It seriously is shameful. It looks bad and I wouldn't recommend it to anybody.

Can you be more specific about your archetectures and graphics cards? That'd help.

Also, what artifacts or problems are you seeing? (My mind is failing me, but I'm 99.9% sure these weird things would manifest themselves in a screenshot, so that would help too)

MZX screenshots use the software renderer. You'd have to do a capture with OS functions, not with MZX's built-in capabilities.

To preface, i haven't argued or otherwise reacted here because i don't really know anything about graphics, let alone making them consistent in appearance and fast on a variety of displays and video cards.

But basically my issue is the smoothing in hqscaler, which IIRC is the default. ajs prefers it and i admit it's a matter of personal taste, but my gut says that in a low resolution environment like MegaZeux, it's kinder to the art and more respectful to the intent of the artist to render pixels square and precisely differentiated.

Primarily I use GLSL with nearest.frag at 1920x1080, modern scaling enabled, on the Radeon HD 6630M in my Mac Mini. I personally can't suggest using nearest.frag as a default, though, because in the World's Most Popular Resolution, 1366x768, it looks like crap.

Well, that is, it looks like crap on this Radeon HD 6320 laptop, using, IIRC, the Canonical repository-provided AMD Catalyst driver. I don't grasp whether that's just the math of using nearest neighbor with a resolution that doesn't nicely divide against 640x350 or if it's a problem with the infamous linux Radeon drivers or what, but it doesn't scale properly. So on the laptop, I set the window and fullscreen resolution to 1280x700. Windowed looks good and fullscreen is tolerable but blurry...

Anyway, i'm sure it's clear i don't really know what i'm talking about on this stuff. But i'm happy to discuss it or provide more/better information.

To clarify to Terryn's point; yes, sorry. I meant OS-level screenshots, not in-MZX screenshots.

Since I wasn't very elaborate in my original response, and I still very much think the default is up for discussion, here's my viewpoint:

nearest -- not appropriate as a default because it doesn't work unless your resolution is an even multiple of MZX's native resolution. Its saving grace is that MZX never used a 4:3 native resolution and people have gotten used to the squashed widescreen aspect (aka 'modern'), so a small amount of distortion isn't noticeable at 16:9 (modern aspect ratio is 1.82:1, 16:9 = 1.78, which is very close). Still doesn't look great at 16:10, and is IMO a non-starter at 4:3 or 5:4. The video_ratio option can mitigate some of the aspect issues, but if width is a non-multiple, pixel quantization is still problematic. Additionally, most folk are using scalers because they don't want letterboxing.

simple -- no obvious advantage to using this as a default (except possibly speed). You might as well use the software renderer; your graphics card or monitor should already scale a full-screen software rendered window with identical linear interpolation. There are some computers with bad GPUs or drivers that can't support the 640x350 mode, however. Again, video_ratio largely mitigates this problem as it allows folk to run at 640x400 or even 640x480 which are widely supported modes.

hqscale -- as asgromo aptly put it, whether you like the effect or not is a matter of personal taste. It does however better demonstrate the utility of the glsl renderer, and exposes its customizability better than the other options. It is also (IMO) has good all round consistency, and works at a variety of common resolutions. I don't like linear/simple because it "blurs" stuff. hqscale results in a sharper image. I use nearest instead of hqscale where I can, but see above for why I might not.

<fourth option> -- nobody's discussed this, but there is latitude to add more shaders which are variations of hqscale. Unfortunately "good" scaling is a fairly intractable problem and MZX has a pretty unique set of requirements. There are other scaling algorithms beyond nearest neighbour that are designed to retain edges and detail better than (bi)linear interpolation. None of these have been implemented.

--ajs.

Another thing I was going to suggest but didn't:

Part of the problem with the glsl renderer is that changing the shaders requires manually renaming the files from the extra/ folder over the shipped version. For the vert shaders, this isn't really an issue. But the frag shaders are useful customization points.

From my days of playing SNES games in emulators and remembering all the video options available with the radically diverse set of possible scaling modes, I do think it would be better if we could change the scaler used by just specifying a different renderer a la "glsl-simple", "glsl-nearest". I had already started some work (that was never completed) to allow the renderer to also be changed at runtime (see graphics.c, search for "change_video_output"). People would probably be less worried about the default renderer if it was painless to preview all possible renderers and change to them from within MZX.

At the time, I didn't decide how to avoid the compatibility problems the OpenGL renderers have typically had. Even if you can support OpenGL, you can't necessarily support programmable renderers. When they fail, they don't always fail gracefully. Whatever dialog system was used, it would have to behave something like Windows does and change the setting back after a timeout if the user didn't confirm it was OK.

--ajs.

This post has been edited by ajs: 12 June 2012 - 08:32 PM

If it's possible to switch shaders on the fly, would it be worth it to allow robotic to "suggest" a shader for a given board? It might allow for some nice graphical touch-ups where curves vs edges are preferred.

(if this is met with tacit approval or better I'll file a feature request so we don't forget)

It is possible to change shaders at any time (though MZX's graphics layer isn't designed to do so, so it isn't necessarily an easy change) however IMO a game should not be able to control a user preference like this. If glsl was more universally available (i.e. it was the only renderer) it may make sense -- even possibly for games to provide their own shaders -- however as it is not I would not recommend adding this feature.

--ajs.

AMD Mobility Radeon HD 4650 using Catalyst 11.10 WHQL UnifL v2 with MZX at 1280x700 and the default shader looks like someone smeared a bunch of nasty blobs all over the screen -- I'll play with it some more eventually

edit: pix

What F12 sees


What I see


It's so painful to look at! I feel like nearest neighbor should probably always be the default for scaling up MZX. Maybe there should be a poll on it?

Well, one motivation for changing the default to nearest is that it'll force me to implement the runtime selection stuff I suggested, which is IMO a much better solution than trading one hard-coded default for another. OTOH I've softened my position against nearest in recent months because it's pretty clear most folk will be running MZX on a 16:9 display now. It's hard to not get 16:9 on any new laptop, computer monitor, phone or tablet device (which I hate, but it's a reality). 16:9 is the least affected by nearest's distortion issues. I have a 16:10 display, and a couple of old 5:4 LCDs lying around. The distortion of nearest on 5:4 is really noticable and (IMO of course!) much less pleasant/desirable than the screenshot you posted.

Unrelated to the above, I'll be interested to see what you come up with by playing with hqscale. I think it will be hard to do much better without introducing the same random-row-of-doubled-up-pixels artifact you get with nearest on most resolutions (but especially bad on 4:3, or 5:4). Really if you are using a resolution with an aspect close to 640x350 there is no better setting than nearest, so why try to do anything more complicated?

EDIT: I also agree that hqscale did a bad job here with the one-pixel grey text and some other detail in the art work. I do wonder if that's a driver issue, rather than a fragshader issue, because it had plenty of pixels to get that right..

--ajs.

This post has been edited by ajs: 23 December 2012 - 07:16 AM

Updating status to: Approved
Updating severity to: 1 - Low
Updating version to: 2.85

It might be a poor video card issue or a driver issue-- that screen capture was taken on a laptop with a Radeon Mobility HD 4650, of which the proprietary driver does not work in Windows 7 and I have to use a 3rd party version of Catalyst that specializes in switchable graphics but has relatively poor (but at least extant) support for my NBLB5. It's a pain.

I agree that having an interface to switch shaders (and possibly renderers if we want to go really wild!!! yeah right) is probably the very best solution to this. I'll rename this to reflect that + approve it so I don't forget about it. Does this depend on a major version change (ie 2.84d/e/f/whatever or 2.85)?

Bump. This would be a nice thing to have in 2.84d if possible.

Dumping some links on here that might also be worth considering.

HQ4x algorithm used in some emulators: http://www.hiend3d.com/hq4x.html

GPLv2 cg shader for this algorithm: https://github.com/l...ter/hqx/hq4x.cg

--ajs.

I replaced hqscale with the hq4x shader I found. Looks better IMO.

Linear, which I don't think anybody uses:



Old hqscale implementation:



Nearest:




(Due to my laptop's ideal aspect ratio, nearest works very well. It's the holy grail, really.)

New hqscale:




IMO, this algorithm seems to get closer to nearest but with a big of jaggy reduction and fewer artifacts.

I sent out a git pull request to change the default to nearest as requested by the majority on this thread, but I'm still working on improving hqscale, as I personally prefer it.

--ajs.

This post has been edited by ajs: 29 August 2013 - 04:01 AM

More examples, vertical stipple and fonts, both tricky to handle.

Nearest:


Old hqscale:


New hqscale:


--ajs.