Muppet of a Man
Member
Hey, but the Xbox brand and the Windows 10 platform unifying is great guys, right!? Right?!? (Please clap / Pls respond)
Vulcan please save us.
Screen tearing isn't noticeable at high refresh rates. I unlock and rock always. The input lag is horribad with vsync....I guess my question would be, why on earth do you want to play without V-Sync?
I mean, I actually do know whyyou get slightly less input lag, potentially higher framerates, etc. But damn, I don't understand how people are able to tolerate the screen tearing; it's really bad. And I suspect that's what Microsoft thinks to.
Which isn't to say they're right, given that PC gaming is about options, but...
Why the title? The article specified it's the windows store, it isn't dx12 (except the vsync working different). I suppose it serves to know who reads the article and who reads just the title.
Even though Ashes of the Singularity is not a Windows Store application, the behavior we are seeing is part of the push that Microsoft is making to sell games through that store with a unified platform.
Right? 2 pages of outrage and they're just the Windows Store limitations everyone already knew about. DX12 inherently doesn't and shouldn't have these limitations.Why the title? The article specified it's the windows store, it isn't dx12 (except the vsync working different). I suppose it serves to know who reads the article and who reads just the title.
Console and PC meet in the middle to create a Microsoft hell for us all to burn.
From a developer's perspective this article seems a bit muddled. Really they should have someone who understands the APIs that they're discussing a bit more.
Skip to the TLDR if you don't care for details.
The first thing is implications of the change from WDDM 1.3 to WDDM 2.0 that affect presenting to the screen. Under WDDM 1.3 the typical win32 app (non windows-store app) either presents directly to the screen in exclusive fullscreen mode, or presents to an intermediate surface that is then handed to the desktop compositor in windowed mode (bitblt mode). This is what pretty much all DirectX 11 games use. I said typically, because win32 apps could also use the flip presentation mode with WDDM 1.3 instead if you wanted to. Windows store apps could only use the flip presentation mode. Using flip presentation meant the app presents to the desktop compositor at all times, which then handles presenting to the screen.
With WDDM 2.0 and when using DirectX 12, win32 apps now have to use the flip presentation mode, the same restriction windows store apps had under WDDM 1.3. What was previously an option for win32 apps is now the only option.
The important distinction to make however, is that just because win32 apps and windows store apps now share the same presentation model does not mean win32 apps now have all the restrictions of windows store apps (i.e. sandboxing etc). You can still intercept and hook DirectX 12 games, get pointers to their swapchain buffers, and things like geodesato could still be made (swapchain interception might have to work slightly differently though). Just for example's sake, I was curious how the 3DMark DX12 API test works, so I hooked it's execution with nsight. And bear in mind that's an application that is designed intentionally to prevent interceptions.
That still leaves the concern that DirectX 12 games have less flexibility in how they present though, they have to go through the compositor always now? V-Sync only? No triple-buffering? How will that affect VR headsets?
The short of it is that microsoft took on those concerns during the insider preview and extended the flip model in WDDM 2.0 so that you can reproduce the presentation behaviour of the older WDDM/DXGI versions. The DirectX team actually have a youtube channel where they've posted some videos on the various presentation modes:
DirectX 12: Presentation Modes In Windows 10
DirectX 12: Unthrottled Framerate
The first video is quite long and more technical, while the second is shorter and just gives a high level explanation of how to reproduce full-screen exclusive presentation behaviour. The article in this thread is concerned that the AMD driver doesn't support unthrottled framerates, but that is on AMD's driver team and not an intentional feature of WDDM 2.0 (specifically DXGI 1.4).
TLDR:
As a consumer, the concern isn't that developers will suddenly embrace window's store apps because they now have to use the same presentation model with win32 apps too (which they could already do in WDDM 1.3 anyway). That's one tiny facet of development. They've both used XInput for a while and nobody cared about that, for example. There's no real loss of functionality either, unless the dev's choose to omit things. The only real concern is that publishers begin asking dev's to use the window's store API instead of making win32 applications. As a consumer the best way to prevent that is tell the publishers no in the only way they understand - don't buy the windows store version of anything, I know I won't be.
The only real concern is that publishers begin asking dev's to use the window's store API instead of making win32 applications. As a consumer the best way to prevent that is tell the publishers no in the only way they understand - don't buy the windows store version of anything, I know I won't be.
From a developer's perspective this article seems a bit muddled. Really they should have someone who understands the APIs that they're discussing a bit more.
Skip to the TLDR if you don't care for details.
The first thing is implications of the change from WDDM 1.3 to WDDM 2.0 that affect presenting to the screen. Under WDDM 1.3 the typical win32 app (non windows-store app) either presents directly to the screen in exclusive fullscreen mode, or presents to an intermediate surface that is then handed to the desktop compositor in windowed mode (bitblt mode). This is what pretty much all DirectX 11 games use. I said typically, because win32 apps could also use the flip presentation mode with WDDM 1.3 instead if you wanted to. Windows store apps could only use the flip presentation mode. Using flip presentation meant the app presents to the desktop compositor at all times, which then handles presenting to the screen.
With WDDM 2.0 and when using DirectX 12, win32 apps now have to use the flip presentation mode, the same restriction windows store apps had under WDDM 1.3. What was previously an option for win32 apps is now the only option.
The important distinction to make however, is that just because win32 apps and windows store apps now share the same presentation model does not mean win32 apps now have all the restrictions of windows store apps (i.e. sandboxing etc). You can still intercept and hook DirectX 12 games, get pointers to their swapchain buffers, and things like geodesato could still be made (swapchain interception might have to work slightly differently though). Just for example's sake, I was curious how the 3DMark DX12 API test works, so I hooked it's execution with nsight. And bear in mind that's an application that is designed intentionally to prevent interceptions.
That still leaves the concern that DirectX 12 games have less flexibility in how they present though, they have to go through the compositor always now? V-Sync only? No triple-buffering? How will that affect VR headsets?
The short of it is that microsoft took on those concerns during the insider preview and extended the flip model in WDDM 2.0 so that you can reproduce the presentation behaviour of the older WDDM/DXGI versions. The DirectX team actually have a youtube channel where they've posted some videos on the various presentation modes:
DirectX 12: Presentation Modes In Windows 10
DirectX 12: Unthrottled Framerate
The first video is quite long and more technical, while the second is shorter and just gives a high level explanation of how to reproduce full-screen exclusive presentation behaviour. The article in this thread is concerned that the AMD driver doesn't support unthrottled framerates, but that is on AMD's driver team and not an intentional feature of WDDM 2.0 (specifically DXGI 1.4).
TLDR:
As a consumer, the concern isn't that developers will suddenly embrace window's store apps because they now have to use the same presentation model with win32 apps too (which they could already do in WDDM 1.3 anyway). That's one tiny facet of development. They've both used XInput for a while and nobody cared about that, for example. There's no real loss of functionality either, unless the dev's choose to omit things. The only real concern is that publishers begin asking dev's to use the window's store API instead of making win32 applications. As a consumer the best way to prevent that is tell the publishers no in the only way they understand - don't buy the windows store version of anything, I know I won't be.
Ryan of PcPer just posted his article on the "controversy" surrounding how frametimes and frame pacing are being measured under DX12 at the moment. It appears as if MS is trying to enforce limitations on user control via DX12, similar to how this works currently on the windows 10 store. For example, the ability to turn off Vsync, implement your own overlay, use Gsync or GFE, or inject any .dll is currently complex... and probably not possible in its currently planned state.
From a developer's perspective this article seems a bit muddled. Really they should have someone who understands the APIs that they're discussing a bit more.
Skip to the TLDR if you don't care for details.
The first thing is implications of the change from WDDM 1.3 to WDDM 2.0 that affect presenting to the screen. Under WDDM 1.3 the typical win32 app (non windows-store app) either presents directly to the screen in exclusive fullscreen mode, or presents to an intermediate surface that is then handed to the desktop compositor in windowed mode (bitblt mode). This is what pretty much all DirectX 11 games use. I said typically, because win32 apps could also use the flip presentation mode with WDDM 1.3 instead if you wanted to. Windows store apps could only use the flip presentation mode. Using flip presentation meant the app presents to the desktop compositor at all times, which then handles presenting to the screen.
With WDDM 2.0 and when using DirectX 12, win32 apps now have to use the flip presentation mode, the same restriction windows store apps had under WDDM 1.3. What was previously an option for win32 apps is now the only option.
The important distinction to make however, is that just because win32 apps and windows store apps now share the same presentation model does not mean win32 apps now have all the restrictions of windows store apps (i.e. sandboxing etc). You can still intercept and hook DirectX 12 games, get pointers to their swapchain buffers, and things like geodesato could still be made (swapchain interception might have to work slightly differently though). Just for example's sake, I was curious how the 3DMark DX12 API test works, so I hooked it's execution with nsight. And bear in mind that's an application that is designed intentionally to prevent interceptions.
That still leaves the concern that DirectX 12 games have less flexibility in how they present though, they have to go through the compositor always now? V-Sync only? No triple-buffering? How will that affect VR headsets?
The short of it is that microsoft took on those concerns during the insider preview and extended the flip model in WDDM 2.0 so that you can reproduce the presentation behaviour of the older WDDM/DXGI versions. The DirectX team actually have a youtube channel where they've posted some videos on the various presentation modes:
DirectX 12: Presentation Modes In Windows 10
DirectX 12: Unthrottled Framerate
The first video is quite long and more technical, while the second is shorter and just gives a high level explanation of how to reproduce full-screen exclusive presentation behaviour. The article in this thread is concerned that the AMD driver doesn't support unthrottled framerates, but that is on AMD's driver team and not an intentional feature of WDDM 2.0 (specifically DXGI 1.4).
TLDR:
As a consumer, the concern isn't that developers will suddenly embrace window's store apps because they now have to use the same presentation model with win32 apps too (which they could already do in WDDM 1.3 anyway). That's one tiny facet of development. They've both used XInput for a while and nobody cared about that, for example. There's no real loss of functionality either, unless the dev's choose to omit things. The only real concern is that publishers begin asking dev's to use the window's store API instead of making win32 applications. As a consumer the best way to prevent that is tell the publishers no in the only way they understand - don't buy the windows store version of anything, I know I won't be.
From Windows 8, to Xbox One, to Windows 10 absurd privacy settings, to the closed platform, Microsoft is paving the road for its own demise by turning one incredibly stupid tyrant.
Right now Microsoft thinks of being too big and embedded in the PC world to "fail", but the overall situation and context is very similar to the demise of IBM in the 80s.
We are just waiting for some enlightened tech genius who's able to make some "compatible" at same or better performance. At that point Microsoft will disintegrate.
Thanks for that explanation but when you say that there is no loss of functionality - this isn't actually true as so far FreeSync and DSR/VSR can't work with borderless window presentation in DWM. Or am I mistaken?
This is what I expected to happen since Microsoft said they will take PC gaming seriously. Every time they took it seriously, they tried to lock it down. Here we're seeing it happen again. Hopefully the industry will be wiser to these tactics this time and not play by their standards, but they have the money to back it up, so who knows.
Goddammit.
Don't know about FreeSync but DSR/VSR work if you change your desktop resolution. It is a pain in the ass but that is the way with borderless.
Yeah so it's kinda obvious we can't trust MS with handling the PC platform going forward. Gaben was right. We need an open platform for PC.
The PS/2 line was created by IBM in an attempt to recapture control of the PC market by introducing an advanced yet proprietary architecture. IBM's considerable market presence plus the reliability of the PS/2 ensured that the systems would sell in relatively large numbers, especially to large businesses. However the other major manufacturers balked at IBM's licensing terms to develop and sell compatible hardware, particularly as the demanded royalties were on a per machine basis.
The two companies had significant differences in culture and vision. Microsoft favored the open hardware system approach that contributed to its success on the PC; IBM sought to use OS/2 to drive sales of its own hardware, including systems that could not support the features Microsoft wanted. Microsoft programmers also became frustrated with IBM's bureaucracy and its use of lines of code to measure programmer productivity.IBM developers complained about the terseness and lack of comments in Microsoft's code, while Microsoft developers complained that IBM's code was bloated.
Maybe it's time to stop being so hostile to people who are don't take personal computers for granted. There's too many gamers who hand wave this stuff off because it's convenient for their hobby.
Devs, please use Vulkan and keep selling your games on Steam/GoG/Origin/uPlay. Thanks.
Wow Microsoft, it's not enough you fuck up your last console you wanna mess with pc gaming too. Seriously if that's what DX12 entails, keep that shit off my pc. Who the fuck over there thought it was a good idea to not give people the standard options they've been accustomed to for so long?
Fuck, and to think so far I liked Windows 10 as an OS.
In this case it should be allowed. If Microsoft can't form a cohesive argument to their own shenanigans on Win10 store and DirectX, why should anyone else?I never understood why some people can't formulate a cohesive argument without tons of profanity.
LOL
Patience people. They should/have to listen like they did with the X1.
Hopefully they'll have a suggestions/changes page setup for this too.
Not everything works right out of the gate.
I never understood why some people can't formulate a cohesive argument without tons of profanity.