View Single Post
Old 9th June 2015, 18:21   #30893  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by GCRaistlin View Post
There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.
Doesn't sound like madVR would be at fault.

Quote:
Originally Posted by Anime Viewer View Post
I'm having a hard time seeing a difference. As I'm toggling things off and on I thought I may have been seeing a small change in the roof edges, but then when I toggle again I don't think I see any change, so I'm not sure if I'm seeing any effect from the repair feature. With that being said if its believed a 1.0 value improves things then I say go ahead and set it to that. I don't see anything getting worse or negatively effected by having it set to 1.0, so I see no reason not to have it default to that value.
Ok. Anybody else objecting to setting "repair" to 1.0?

Quote:
Originally Posted by Anime Viewer View Post
When I have more time I'll try to spend more time adjusting the thinning settings and see if there are certain values that appeal to me in each type of FineSharp situation.
Would appreciate that, thanks.

Quote:
Originally Posted by Anime Viewer View Post
When using Doubling with the FineSharp in upscaling refinement it smooths out jaggedness of alaising lines.
That's what "repair" also is supposed to help with, I think.

Quote:
Originally Posted by GCRaistlin View Post
madshi, should I create a ticket on the bug tracker for my request about the ability to change the refresh rate from the icon menu?
The bug tracker is only for bugs, not for feature wishes. About your feature wish see my reply here:

http://forum.doom9.org/showthread.ph...43#post1721943

Quote:
Originally Posted by SecurityBunny View Post
That does seem to fix the issue. Queues fill fine with D3D11 10-bit output. The only issue I'm able to tell is with D3D11, present queue is 15-15/15 while on D3D9 it bounces between 15-16/16 | 16-16/16. So you seem to lose one prepresented frame with D3D11.

Unfortunately I don't believe my monitor supports 23/24p display modes since it switches back to 59.95 hz after going fullscreen for a few seconds. But for those few seconds testing 24hz (display reporting 24.00 in madvr), queues fill all the way with prepresented at 14-15/15. Testing 23hz (presuming you don't mean 23.976hz) queues did not fill but the display was outputting 22.99hz.

Testing 0.88.8 at 24hz, queues fill perfectly fine. But similar to above, D3D11 seems to lose a prepresented frame in present queue when compared to D3D9.
If your monitor doesn't support 23/24p, then you shouldn't see any image at all. You do seem to see an image. Not sure why it's switching back to 59p, though.

What is important to me is if v0.88.8 is in any way better than the test build or not. If v0.88.8 is not better (not at any refresh rate), then we can consider the problem in v0.88.9+ fixed, and we can stop investigating. You're saying v0.88.8 filled the queue at 24hz, and the test build, too. But the test build doesn't seem to fill the queues at 23hz. So does v0.88.8 do that?
madshi is offline   Reply With Quote