I actually thought i’d have to wait as long as a year for support for the HD rumble, whether through native support in some games, or a third party tool. I love the Joycon’s haptic feedback, and i’ve only heard PS5 is an improvement over it. I still wish Microsoft did this for their Series X, they have the best controllers imo.
My original prediction has always been to expect an announcement of a pro console in the first quarter of 2021, aka after the new gen has been released. Now i’m wondering if it’s a good idea for them just to wait another two years to release an all new Switch altogether, but starting off with a crossgen phase. If they do wait, DLSS could probably help them bridge the gap between portable and the new consoles, but we don’t know how expensive it would be to implement in all the games it would benefit. Also worth noting “on the go” consoles seem like a hard sell when everyone’s at home.
Yeah portability could be a challenge in the more affected countries where there’s mandatory curfews and other restrictions.
If they continue their partnership with NVIDIA I would imagine DLSS would work really well for the two modes and overall less GPU demand plus acceptable visual quality and over time familiarity and further improvements making the most of upscaling with less visual issues or glitches and missing elements.
Fine weather here today so everybody is outside and the military had their drills as usual so restaurants and shops are completely packed.
Bunch of BV206’s or what they are again parked outside the pizzeria however well one can actually park our glorious “armor” well at least it’s something.
EDIT: Well the state of Sweden’s less-than-armored forces aside…
Looking forward to seeing what early 2021 looks, availability for some of the new hardware would be a start.
December 16th to 18th early estimated date for some of the 5800’s and 5900’s CPU wise, 3080’s are just missing entirely and the upcoming third party 6800’s and 6800XT’s for the 25th well they’re going to be gone really fast I expect.
Another interesting surprise… SwapChain format overrides work in most D3D12 games.
That means as soon as I work out the details of HDR screenshots, I’ll also be able to add HDR to the RTX version of Control That’ll make a lot of people happy.
I technically have Control running in HDR in D3D12 already, I just can’t do any luminance processing yet
Strange decision from the developers, route in a lot of RTX stuff even update DLSS 2x (1.9 to 2.0 and then 2.1) but omit HDR support.
If they’re already in there doing NVAPI stuff routing in HDR should have been achievable as well or even HDR through NVAPI since they would already be doing stuff there for the DLSS and RTX code.
EDIT: But it’s the same on console this one time so yeah, suppose on X Series you do have that auto mode to try and cover for it though.
Yeah a few weeks more for the OSD possibly after 0.11.1.0 came out with all these HDR updates and resulting compatibility additions is what I was expecting and now it’s what a few widgets that are troublesome but a lot of functionality just already works in this test build.
(Bit more to it but really quite a step from earlier to what this build now has.)
HDR and other overrides might still be a significant amount of work to rig up though, will be interesting to see how it all goes.
lol, there’s still lots of work to do. D3D10/11/12 share a lot in common, so that makes it both simple and difficult. I can support most of the same features as I do in D3D11 with enough time and effort, but that should ideally come with a lot of code refactoring to clean up the core.
If I clean up the common components enough, I can probably reach backwards an API to D3D10 too without too much effort. It seems like a good idea at this point. I don’t really know about Vulkan, but I can definitely polish off D3D12 and get some benefits in the process.
Code conformity and compatibility across most everything of DXGI (10 - 12) sounds like it’d be excellent.
Unsure about D3D9 and the earlier plugins and work for getting that up and back to full functionality but I like what I’m hearing.
EDIT: Or how it’s called.
EDIT: VLK support is interesting too especially when throwing DXVK into something D3D9 (And more but for this D3D9) just makes it work better.
EDIT: Well relatively speaking…10 - 20 FPS with dips and then with that it’s up to 120+ in some cases due to Navi / RDNA GPU issues is a bit more than “better” although even when technically functional it just tends to be faster anyway.
(Unsupported on Windows for all sorts of reasons but usable and beneficial. )
EDIT: Only main drawback is the hack solutions AMD did to resolve some D3D11 performance and compatibility issues so for these titles (I believe Assassin’s Creed Unity is one.) performance just fails.
(They don’t really work under DXVK/Vulkan.)
Otherwise it’s a neat 30 - 60% gain which can also apply to NVIDIA but often a bit less due to less problematic D3D11 driver code and more stable D3D9 driver code and GPU functionality.
Render support in Vulkan, I imagine, would be easier seeing how it relies on external overlay hooks. So getting SK to render in a Vulkan games just requires SK to interface with Vulkan properly and then register itself as an overlay in the registry of Windows.
Kinda… I mean, if Special K were merely an overlay the way that RTSS / Steam are, Vulkan layers would be totally awesome. But I generally do more inside of a game than just draw stuff over top the game
I really dread SPIR-V. It makes -modifying- shaders in Vulkan ridiculous. Here in D3D land, the same tools I built to modify shaders in D3D11 work backwards and forward down to D3D10 and D3D12 with just a little bit of API-specific sugar sprinkled on top. But SPIR-V is different, and each engine could have its own language and conventions… I don’t really want anything to do with modifying Vulkan shaders.
Got it working on MHW DX12, needed to disable some 3rd part applications because i was getting a dxgi.dll error on the main menu.
Saying that… i dont have the swapchain management options on it ? And it does not give me the status of the windows display, what kind of frame buffer or color format ?
FUNCTION NAME: NvAPI_D3D_IsGSyncCapable
DESCRIPTION: This API gets G-Sync capability for the given device context. This is only reliable after the first present call has completed.
Parameters
[in] pDeviceOrContext The D3D9, D3D10, D3D11 device, or D3D11 device context
[in] NVDX_ObjectHandle The handle of primary surface
[out] pIsGsyncCapable if G-Sync can be enabled, *pIsGsyncCapable is true.
SUPPORTED OS: Windows 7 and higher
RETURN STATUS: This API can return any of the error codes enumerated in NvAPI_Status. If there are return error codes with specific meaning for this API, they are listed below.
It literally only discusses D3D9/10/11 and if you try to call it with the equivalent constructs from D3D12 it fails. I think I’m the only person in the world who ever used that feature anyway
Just looked at that, seems a few things references D3D12 and support for GSync itself should work so the internals in the driver must have something.
There’s VRR but then you might not get the full GSync functionality (Same with FreeSync2 Premium on AMD.) hmm curious.
Well probably it’s just the documentation not being up to date here NVIDIA has plenty of extensions and DirectX 12 features plus Vulkan through a number of extensions same as AMD.
Don’t their own G-Sync Indicator rely on that NVAPI call? Or perhaps it doesn’t… I don’t remember seeing that go away when technically VRR isn’t active any longer (e.g. situations where SK would indicate that VRR is inactive).
