I was even thinking of developing a mini-SKIF or Special K injection module that could toggle global injection or trigger a per-process injection for the game bar a few months ago, but I ran into confusion with the WPF and sample codes they have (they have C++ examples but no C# for some reason…).
… Maybe I only mentioned it on the PCGW Discord…
Anyway, that plan didn’t pan out — I haven’t gotten back to the initial example I threw together since I hit that wall block of frustration (god, I’ve been too far away from real development for too long).
Anyway, yes, a SK module for the game bar with some basic functionality (e.g. run SKIF, toggle global injection, perform process-based injection) would be AMAAAAZING!
Hmm my computer can heat up my room even when idle. I rarely game when the weather is hot, lol. My temps are fine at full load as well, i get like mid 60s on the GPU when playing Crysis remastered, and my overclocked CPU rarely hits 70c if ever. Motherboard and drive temps all seem normal as well according to HWinfo, but ig even 30-40c is enough to heat up a room.
Huh, yeah, I don’t think my computer is capable of that. It’s a large 4x6 meters room with some 2.3 meters to the ceiling from the 1930s or something like that, so at most the computer might increase the ambient temperature by a degree or two.
My server and NAS is in a separate sorta walk-in closet (1x2 meters) where the ambient temperature is like at 30 degrees or so with both of them constantly spinning. I initially had the door to that room more open (it’s always slightly opened due to cables), but eventually closed it as much as it was capable of due to the minimum temperature those two devices generate — even during Sweden’s summer (where we can get like 30 degrees or so).
There was some injection incompatibility with the game bar for a while (it uses a COM-based service that SK sometimes gets stuck in), but that’s all been resolved recently and there’s a very good chance I could build exactly what you are discussing.
This feels like it’s meant to be. I love that it’s not tying me to some kind of Valve / Steam service too SK’s not as store agnostic as I’d like it to be. I was fine with that when Valve was on friendly terms with me, but now I’d really like to stop supporting doing anything special for Steam games.
On that note of weird COM-based stuff that SK has to deal with …
Microsoft probably doesn’t want this to be readily known, but all of UWP is available to regular old Win32 software because it is built using COM. They do not document the COM GUIDs and other things necessary to activate UWP’s interfaces, but any part of Windows that does something interesting that is only available in UWP (e.g. the new controller API and certain aspects of HDR) can be used in a normal application if you’re willing to spend a bit of time reverse engineering things
Because games and game-related software is not supposed to built using C# !!
I don’t like that language because it’s easy to develop software for, but too far away from the metal for performance critical applications.
Laughably, my sentiment is shared by the generation of developers before me, who insist that high-performance software has to be written in assembly language There is a pattern here, sometimes I wonder if we’re all wrong. I mean clearly the people before me are wrong and assembly is irrelevant, but … am I also wrong? At some point the penalties of C# will be negligible, I just don’t think we’re there yet.
The memory I ordered around 8th of this month is finally gonna arrive at my house tomorrow. Been stuck in status at NJ since like 9th. Finally got an update on it. rofl. The reason memory took so long is its the horrible USPS service. Why do sellers even use that?
Yeah, having an easily accessible toggle for Special K from all games that isn’t tied to Steam sounds like a dream come true.
When I attempted to build the plugin, I think I ran into some compiler issue with the app manifest – despite following and using Microsoft’s specific instructions, Visual Studio didn’t want to compile the damn thing due to manifest related issues or whatever.
The fact that I couldn’t figure out how to solve something so ‘simple’ was why I eventually determined that I’ve been away from proper development for too long – I can barely figure out how to work Visual Studio before I even get into the proper coding part of the thing…
The whole stuff is documented in the below link though, with samples on GitHub. From my short look into it, it should (manifest issues aside) honestly be really simple with just a XAML based window that registers itself with the game bar. Technically the “app windows” that gets registered with the game bar can supposedly just run as usual windows as well during development, so I imagine for someone with basic modern GUI coding using Microsoft’s latest languages or whatever they call them it would be extremely simple.
Just another reason why I am thoroughly annoyed at myself for not succeeding with it…
It’s the use of XAML that threw me off, to be honest. I remember XAML being promoted heavily with WPF, and through there C#. Seeing XAML be used with C++ confused me.
The game bar is designed to run separate processes for itself, its renderer, its capture service and widgets. Every widget is its own process running externally, I like certain things about that (it’s secure and stable) and dislike others (UWP suspends processes to save battery)
That application suspension behavior in UWP drives me up the walls. Special K’s DLLs need to be unloaded when UWP decides to suspend a process otherwise the DLL gets locked and stuck.
I wouldn’t feel too bad that you couldn’t stuff working. This whole UWP thing is weird, the more I learn about how it technically works under the hood the more I think Microsoft hasn’t done an adequate job documenting interop and explaining to seasoned developers familiar with traditional Win32 how to get stuff up and running.
I can write Win32 apps from scratch, but if you introduce stupid things that have to be configured in the Visual C++ IDE that aren’t code, I’m much less useful That’s more or less the same problem you’re frustrated with.
On that note, most Swedish retailers have pushed their ‘in stock’ date for the 3080 to November, so… I guess I have to wait until after AMD’s announcements before I get a RTX 3080, so that’s something.
At least it allows me to spread out the payments a bit as my iPad Pro + accessories ended up costing me almost as much as the 3090 costs
Going by the accidental reveal earlier and some initial listings yeah even the 3090 despite being kinda the Ampere Titan GPU is getting multiple SKU’s despite it’s small volume compared to the 3080’s and 3070’s and later on the 3060’s
Same as before it’s the various cooler designs mounted on top and altering the clock speeds.
From the earlier Video Card Z article on Gigabyte making a oops and posting their entire GPU catalog for Watch_Dogs legion code redemption including the rumored but unconfirmed “S” variant and higher VRAM models.
EDIT: Then there’s everyone else like Asus, Palit, MSI, EVGA and all the rest.
EDIT: September 24th so ~4 days until the 3090’s then.
I wonder if this works… This is a quote from the Path of Exile thread:
I wonder if this is why Watch Dogs 2’s built-in camera captures the game in overly bright or dark when using flip model (at least I assume it’s flip model that’s causing it, as I can’t be bothered without flip model, lol).
Or perhaps it’s merely displaying the captured photos overly bright or dark…
Anyway, it’s a shame as I took a couple of good photos using the in-game camera before I noticed how bright/dark they ended up being…
I can potentially do something about this to post-process the gamma, but … that undoes the entire benefit of flip model in the first place.
If you add an extra step in getting an image out of the swapchain’s buffer to apply color correction before the GPU can scanout a signal, we’re back to doing something that’s not technically buffer flipping.
I hate all engines that use swapchain color processing. They need to do gamma themselves the lazy bastards
Seriously, leaving the images in the swapchain in a state where gamma correction hasn’t yet been applied has no conceivable benefit. It just adds extra latency, which is fantastic when you’re building a game (!!)