Is changing OGL_DX_PRESENT_DEBUG setting really necessary? My testing shows that Prefer layered on DXGI Swapchain alone is sufficient.
User talk:Aemony
Yes, as it mentions on the following line:
"This value will enable the DXGI swapchain layer in most scenarios, including DXVK."
Without that flag set, the interop layer won't engage in various scenarios (typically emulators, DXVK, and a few other cases).
I am BRR.
Hi, I would like my account to be deleted and my edit history anonymized. Thanks in advance.
Merge from xxxxx (YYYYY) to Anonymous (466) is complete. xxxxx (YYYYY) has been deleted.
Can you please change my username to LaserMoai?
Thanks in advance.
Hi,
Your account has been renamed.
Cheers, Aemony
This is a test where I add a random URL that I think will trigger captcha?
This is the link: https://lipsum.com/
Please look into it.
- )
First off, thank you for your work on the various. I do have one suggested change for the lists that I hope will be considered. Given that is not unheard of for some games in development and even in late stage testing not to survive to release, or to undergo significant redevelopment before they do, my suggestion is to wait to add games to the lists until the games are formally released. Alternatively, the games could be commented out in the lists until they are released. Best regards.
^First sentence should have linked to the various lists on https://pcgamingwiki.com/wiki/Category:Graphics_API.
The lists are dynamically generated by polling PCGW's internal database of pages, making them directly influenced by the community-driven input on PCGW as editors or guests go around and update articles on their own leisure. This means that there is no manual supervision of each entry when one gets added.
All that said, the release date column technically allows to separate the released games from games currently in development, as TBA/Early Access titles or similar will not have a release date set, or have one set in the future.
About this edit (at the bottom):
https://pcgamingwiki.com/w/index.php?title=Microsoft_Windows&diff=782979&oldid=782873 From: https://pcgamingwiki.com/wiki/Microsoft_Windows#Changing_default_timer_resolution
" Other applications might already be requesting a higher resolution, such as the Steam client and Discord,[Note 1] making this tool unnecessary."
Could you confirm that, despite of having TimerResolution tool enabled and set to maximum, it still reverts it to default value?
It's easy to check.
Download:
filecroco.com/download-timer-resolution/
Set to maximum. Wait ~1 minute or less. Don't close the app. Download and open:
vvvv.org/contribution/windows-system-timer-tool
Check the timer.
It should show still the same value.
Please confirm it to make an edit.
I've amended the note with references and more detailed info on the Power Efficiency Diagnostics Report.
You didn't provide any new references, but you only confirmed credibility of your own edit as a reference.
Could you confirm that, despite of having TimerResolution tool enabled and set to maximum, it still reverts it to default value while checking it in other program?
> it still reverts it to default value while checking it in other program?
I'm not sure I understand... The note is meant to show that _other applications_ on the computer might already be requesting a higher resolution (e.g. lower value) for the timer. It have nothing to do with reverts to the default value.
The only reason the timer would revert to its default value would be if no other process requests a higher resolution, e.g. the opposite of what that note is talking about.
For clarification, yes, certain application can request timer resolution change, it is among others the reason to use Timer Resolution.
Bad timer resolution settings may influence CPU performance, and this is the tool to get rid of this problem - among others, to keep that value the same all the time, despite any program's request. That was the thing I asked you on the beginning, to verify it, if you just deny that this tool is unnecessary due to random program's request. The tool should prevent it.
The thing I try to say is that, if this tool kept in background (with resolution set to 0.5), really keeps the same value of the timer, then it is not true that:
"Other applications [...], such as the Steam client[41] and Discord,[41] [make] this tool unnecessary"
And this edit is the purpose of the discussion.
Changing timer resolution by normal applications which you mentioned, is said by MS as a bad practice.
W10 can revert value to default. If random program can change that value, it can cause performance issues especially on W8 and below.
That "more information" note is only there to mention the fact that other applications might already be setting a higher timer resolution already, which will remain in effect until either those processes are terminated, or they request another timer resolution by making a follow-up call.
TimerTool itself only sets the requested resolution when clicking on "Set Timer" and then assumes the timer is set as requested until its process is terminated, since Windows uses the lowest value (that is, highest resolution) requested by any process until said process is terminated (or the process requests the resolution unset or lowered).
Basically, that note is meant to highlight the fact that other applications can also requests various timer resolutions, and it is up for each user interested in knowing more to generate a power efficiency diagnostics report and determining whether another process is already setting a higher resolution or not.
For me, personally, I have no use of that tool since both Discord and Steam (as well as my sound card) requests a 1ms resolution constantly, which keeps the timer resolution on my system set at 1ms forever. I imagine in the case of Discord and Steam it might be their use of CEF (Chromium Embedded Frameworks) since Chromium used to love to set the timer resolution to 1 ms and forget it.
Thank you for your reply.
Yes, we already mentioned that some application set their own timer resolution, but as you said - e.g. 1 ms. The tool sets 0.500 ms timer, and it is widely used value by CPU testers to have reliable results while using various configurations which may cause diffrent timer changes.
In my PC I also have 1ms all the time, I also use Steam and Chrome, but it is kept on 0.5 ms while using this tool and keeping it in backround. I also have some sound card from Creative.
Considering this, I still cannot really agree with your edit, though I understand what you mean, still, in my opinion, it is misleading. 1ms is not 0.500 ms. But it is generally very small performance change, and considering that fact, we may say that the program is unnecessary in such case. Though, in the entry I already stated certain dependance while 30% performance increase existed when default resolution clock was changed from ~10ms to 0.500ms. Logically change from 1ms to 0.500ms won't give noticeable performance increase - and this the thing I'd write next to your note, to clarify what you mean if you don't have anything constructive against.
I'd say just leave the whole section as it is right now as there's nothing directly wrong with anything per se. "more information" bullet are just that, more information. They're meant to provide additional information that for those users wanting to know more, but can otherwise be ignored.
The point of that bullet isn't to showcase that Discord or Steam requests a 1 ms timer resolution. The point of that bullet is to make those wanting to know more aware that they might already be running another application that's requesting a higher resolution (than the default 10/15 ms), and instruct them on how to find out which applications they are and what timer resolution they're requesting.
Can we please talk?
The edit notes on the history page should explain the situation already, but here's a more elaborate explanation:
1. The source of the fix is already present in the fixbox as a reference. This is the standard way of referencing fixes on PCGW, and we do not need a duplicate link 5 lines below the existing one.
2. The image of the launcher does not contribute with anything since a screenshot of the external launcher is already present higher up the page. The only differences between the two screenshots were a) the GPU selected, and b) the resolution selected. This isn't enough to warrant a new screenshot solely for that fixbox. The instructions of the fix are clear enough without the additional duplicate screenshot.
"The source of the fix is already present in the fixbox as a reference"
1.Could you please point out where? The Fixbox I see only includes the fix that I found and added here to the PC Gaming Wiki. --The link is really meant as a citation and it keeps getting removed.
2.The Image makes it clear that the Fix is for nVidia cards ---and not RV cards which dont have the problem.
As for #1 where is the *good* edit that links back to the source?
As for #2 go for it.... I think that its confusing.
The link is used as the actual reference of the fix: https://images.aemony.se/sharex/firefox_2019-06-09_00-38-45.png per the standardized instructions for how to reference fixes on PCGW.
The image is unnecessary to make it clear that it concerns Nvidia cards since on a modern Nvidia GPU is already a part of the informative bullet of the issue: https://images.aemony.se/sharex/firefox_2019-06-09_00-41-36.png
Using an image that is identical to an already existing image by arguably 95%+ to convey that it concerns Nvidia cards is not an effective way of conveying information. Actually mentioning it in the bullet point as the page currently does is a far more effective way.
Why are they removed/replaced? With them one can navigate through the games with one click.
It was mentioned that the infobox was starting to become too long and so the seriesboxes were deemed to be removed when they are replaced by the new taxonomy rows that also includes the seriesname.
The team is aware of the downside of this though and we're currently discussing adding an automated check that will automatically add the seriesbox below the infobox again with either an expanded state (basically the same as before) or a collapsed state (like how the seriesbox worked on mobile devices). It would basically calculate how many rows a seriesbox included and if it was found to be too many (something like 10 or more), it would collapse the section.
We currently have no estimation though when this might be implemented.
Sounds good to me.
Will we ever come to a point that we will merge with Fandom? That would make Fandom the ultimate superpower for not just documenting virtually everything, but also PC games. I think it would be cool plus we would have an even bigger community of gamers to make this place more aware.
Perhaps we can even partner with Fandom, kinda like what Fanatical did.
Hi,
This is like the wrong channel for this sort of discussion -- any such discussion needs to be had in a larger space such as the community site, https://community.pcgamingwiki.com/, or over in the Discord server where more users can comment upon it.
That said, personally I do not see any immediate reasons why it would be necessary -- PCGW is already doing its own thing and slowly but steadily growing in awareness and popularity.
Cheers!