-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
GeDoSaTo - Downsampling from Infinity and Beyond!
- Thread starter Alo81
- Start date
The AO looks great. Nice work!
Has anyone got ACII working in the latest builds? I've tried varying settings but only get a blank beige screen with the HUD overlay.
With one of the earlier builds it worked perfectly. I've tried completely uninstalling and re-configuring GeDoSaTo to no avail.
Boulotaur2024
Member
You're right I get the same. I'll try to see if I can do something about it (I'm using a build that dates back from 2014/09/18)
EDIT : discussion thread on Github
Try setting interceptWindowProc to true. That might work but I am not sure..can't hurt to try?
Nope not working.
flashbandit16
Member
I think setting modifyGetCursorPos, modifySetCursorPos to true will work.
Yes that works now my second problem i use 2 screens and when i down sample it and when i am in game and turn around my mouse goes to the other screen and doesn't stay in the first one.
Jarth Mader
Member
I use two monitors as well. I believe this would be a game issue. Some games trap the mouse and some don't. I use a program called Actual Multiple Monitors which has a bunch of features that Windows lacks. It has tons of customizable hotkeys, one of which is a mouse lock toggle, which lets you lock the mouse to any window or to a specific monitor. It also has an option called Ignore Deactivation, which prevents fullscreen windows/games from minimizing when the mouse clicks outside that window, i.e. in a browser/multimedia player window on the second monitor. AMM costs money, $25 I believe, but it was the only program I could find that offered the Ignore Deactivation feature at a reasonable price. There may be free programs that offer the mouse lock feature.
I have a question Durante: You mentioned you were experimenting on some sort of anti-aliasing that took the good parts of FXAA but basically removed the bad (such as causing textures to appear blurrier). Any chance you will be releasing such AA as its own separate injector? Also, do you plan on updating GeSaTo to basically replace DSfix for Dark Souls 1?
Durante has said no plans to replace DSFix i believe.
is the AA youre talking about the one that mostly ignores text and hud elements?
I believe so, and I also recall Durante talking about how if doesn't affect textures like regular FXAA does, as in it really only aims at smoothing out edges...Something about being like Temporal FXAA or somesuch.
Edit: I also wanted to know if you can deactivate downsampling. I sometimes just wanted to try it for the (AA) injectors alone. Borderlands (1) is one such case where I can see it being massively useful (since the game has no AA to speak of).
@Boulotaur2024
How do I fix the "grainy" look in VSSAO2? Also, those SAO shots look fantastic, can't wait to try it out. (I wanted to but it doesn't work with Fahrenheit, assuming I did everything correctly)
http://screenshotcomparison.com/comparison/96387
How do I fix the "grainy" look in VSSAO2? Also, those SAO shots look fantastic, can't wait to try it out. (I wanted to but it doesn't work with Fahrenheit, assuming I did everything correctly)
http://screenshotcomparison.com/comparison/96387
jim2point0
Banned
This is the only answer I've seen so far that might solve the problem:
I've had this issue in Borderlands 2 a ton. Pain in the butt.
Oh. I thought I just wasn't setting the right toggle. Thanks Jim, I guess could just disable the second monitor for now, might help reduce some rage. =)
Durante implemented it into his PtBi tool, I believe it's called PXAA and TPXAA.
I imagine it isn't implemented into GeDoSaTo because ideally, you would just find a PSHash for your game so it's not being rendered on UI elements at all.
Boulotaur2024
Member
Interesting. VSSAO2 works for you but not SAO, at the same resolution ? You did configure ssaoType to SAO did you ?
Assuming you're using the very latest version from yesterday then there could be something wrong with the shader itself on NVIDIA cards (yes I like to imagine the worst case scenarii from the get-go) I can't say for sure. I wish I had both hardware to test.
There is a #SHOW_DEPTH define in SAO.fx that you can enable to see if the depth texture (the main ingredient for SSAO) is at least properly retrieved. It should ouput a grayscale image with closer items being darker than distant ones.
If you do see that then SAO should work. Granted It might need adjustments with the nearZ/farZ parameters but I know you're used to these so I suspect you already toyed around with them.
If you don't see any grayscale image then there is definitely something wrong but I'm suprised because Fahrenheit should be straightforward to run with the GenericDepthPlugin as it doesn't need any special zbufCompatibilityFlag at all (same for Resident Evil 5 btw. Both games run fine for me)
EDIT : looks like the GeDoSaTo.dll hasn't been compiled in a week, so once you're up to date overall. Grab and replace your dll with this one. It should be better
I've done every combination of SSAO settings that I could, and repeated them with your updated DLL installed, and on every account having SAO enabled has caused a crash in RE5. I do have an Nvidia card.
Code:
# Override the plugin selection process to always select the given plugin
# example: pluginOverride GenericDepthPlugin
pluginOverride GenericDepthPlugin
## SSAO
# Determine the type of AO used
# "VSSAO2" = Volumetric SSAO (default)
# "SAO" = Scalable Ambient Obscurance (heavy)
# "MSSAO" = Martinsh SSAO inspired by ArKano22 (light)
ssaoType SAO
# Enable and set the strength of the SSAO effect
# (all 3 settings have the same performance impact!)
# 0 = off
# 1 = low
# 2 = medium
# 3 = high
ssaoStrength 2
# Set SSAO scale
# 1 = high quality (default)
# 2 = lower quality, lower impact on performance
ssaoScale 1
# Set SSAO Blur type
# gaussian = soft, cheap
# sharp = depth-dependent, more expensive
ssaoBlurType sharpI've tried changing ssaoBlurType, ssaoScale, and ssaoType to every variety.
With VSSAO2 I get functioning, though not great looking AO, with MSAAO I get that grayscale depth image you describe, with no discernable way to disable it as there is no showdepth option in the MSSAO's fx file, and SAO causes a crash.
Here's the example of MSSAO running on the image, though only showing the grayscale output.
I can't seem to get SAO to not crash, nor MSSAO to not show that grayscale version.
Oh well i will buy that then when i have money just to make it all work. I do hate it when it goes to my second screen.
First time the game wasn't even launching when I had SAO selected. I went to github and downloaded the latest SAO build, and surprisingly the game starts now.
Problem is, it only shows a white screen, even when the intros play out. I uncommented show ssao/depth but it's the same thing. If I replace the existing gedosato.dll (latest version, I'm using the update tool) with the one you uploaded (which is smaller), gedosato won't work at all. In-game/driver AA is disabled.
Martinsh SSAO on the other hand, works but obviously needs to be properly configured.
You need to edit martinsh_ssao.fx and comment SHOW_SSAO. Also, don't forget to edit your keybindings so you can toggle AO.
You're right, this works. I was looking for a show_depth like in SAO.fx, glad to see it functioning!
Dalibor_San
Member
Actually now that you mention it, yes at Bonfires and world transitions...I didn't really think anything of it.
Thanks man.
That's one reason. The other is that PXAA and TPXAA are really inordinately expensive. That's perfectly fine if all our GPU is doing is taking a final rendered 720p image from a console and displaying it. Not so much when you try to put it on a 16x or more larger image from downsampling while also, you know, actually having to render the game on that GPU
Definitely. You can do anything, in principle
As for how feasible it is, it could literally be a 3 liner (in addition to the dozen or so lines to set up a plugin), or it could require hundreds of distinct interception cases for shader parameters etc. No way to know without trying.
I had the impression that your AA implementation was far superior to FXAA within the same expense in rendering. It would be great if you had somehow invented a new kind of "downsampling AA" that would crispify edges without the need to render everything at a higher resolution and then downsample.That's one reason. The other is that PXAA and TPXAA are really inordinately expensive. That's perfectly fine if all our GPU is doing is taking a final rendered 720p image from a console and displaying it. Not so much when you try to put it on a 16x or more larger image from downsampling while also, you know, actually having to render the game on that GPU
Definitely. You can do anything, in principle
As for how feasible it is, it could literally be a 3 liner (in addition to the dozen or so lines to set up a plugin), or it could require hundreds of distinct interception cases for shader parameters etc. No way to know without trying.
BONKERS
Member
That's one reason. The other is that PXAA and TPXAA are really inordinately expensive. That's perfectly fine if all our GPU is doing is taking a final rendered 720p image from a console and displaying it. Not so much when you try to put it on a 16x or more larger image from downsampling while also, you know, actually having to render the game on that GPU
Definitely. You can do anything, in principle
As for how feasible it is, it could literally be a 3 liner (in addition to the dozen or so lines to set up a plugin), or it could require hundreds of distinct interception cases for shader parameters etc. No way to know without trying.
Definitely makes me wish I knew more so I could give it a shot.
That would indeed be great, because I would patent it and get rich as fuck.
Free for games on open platforms, license fees up the wazoo on closed ones.
Sadly, it's nothing so grand. It's just a method specifically designed for the case where you have a lot of GPU time per pixel, but no further information than an image, and want to improve aliased edges without any degradation anywhere else.
BONKERS
Member
I'm eagerly awaiting Far Cry 4 TBH, I really want to see if HRAA is worth a damn for how complicated set it up seemed in the slides.
The emphasis is always on speed vs quality and quality they can get with speed.
And quality always suffers because of that.
I had high hopes for Sony's TMAA when Knack originally seemed really stable and HQ in videos. But seeing it in person with Knack and Killzone, I was disappointed.
The emphasis is always on speed vs quality and quality they can get with speed.
And quality always suffers because of that.
I had high hopes for Sony's TMAA when Knack originally seemed really stable and HQ in videos. But seeing it in person with Knack and Killzone, I was disappointed.
Wish you could make a separate injector for people who simply want to see how it looks. I noticed that sometimes your AA injection method works better than the vanilla version of those (most notably SMAA), so I always wonder how you're abe to bypass things like HUD elements.
BONKERS
Member
Another thing I am curious about, is since recently I discovered we can use SGSSAA/HBAO+ with GeDoSaTo by setting the game resolution to one you can actually use (IE 3200x1800) and then set that to your desktop resolution|(EDIT: Using "presentWidth/Height/Hz also does the same trick) to that and start up the game and still get slightly better scaling since scaling filters apply at native resolution.
I was wondering, if there was anyway GeDoSaTo could tell/trick the GPU driver into thinking whatever resolution you are using to play with was the display or whatever resolution?
Not sure if that makes sense. Essentially it seems since render resolution does not match the primary flip or a resolution listed within the driver, the GPU/Driver doesn't know what to make of it. And thus cannot force aftermentioned effect.
In Metro Redux for example, you can use HBAO+ with a certain flag. But if SSAA is enabled in any fashion it doesn't work. (4A's built in SSAA is essentially the same quality wise as driver downsampling). But if you manually play at say 3200x1800, which would be equivalent of 4xSSAA at 1600x900. HBAO+ works just fine. (Even though desktop resolution is still 1600x900.)
This seems to be the primary thing from keeping us from being able to use stuff like SGSSAA or HBAO+ with GeDoSaTo.
I was wondering, if there was anyway GeDoSaTo could tell/trick the GPU driver into thinking whatever resolution you are using to play with was the display or whatever resolution?
Not sure if that makes sense. Essentially it seems since render resolution does not match the primary flip or a resolution listed within the driver, the GPU/Driver doesn't know what to make of it. And thus cannot force aftermentioned effect.
In Metro Redux for example, you can use HBAO+ with a certain flag. But if SSAA is enabled in any fashion it doesn't work. (4A's built in SSAA is essentially the same quality wise as driver downsampling). But if you manually play at say 3200x1800, which would be equivalent of 4xSSAA at 1600x900. HBAO+ works just fine. (Even though desktop resolution is still 1600x900.)
This seems to be the primary thing from keeping us from being able to use stuff like SGSSAA or HBAO+ with GeDoSaTo.
Guys i was tinkering with the "generic_depth.h" source and noticed that it doesn't have the DOF.h included. Wouldn't it be useful to enable it and recompile the "GeDoSaTo.dll" with it enabled, to allow maybe with some experimentation to enable it in games other than dark souls ii, for example RE5. I don' t know if it is possible as i am not familiar at all with HLSL, ( only just started learning it) only saying it would be great .
Bulbosaur commented on this earlier
So feel free to give it a shot if you'd like. If it works, you could submit it to Durante on GitHub and it could be officially added in.
Thanks so much for checking this out. Both for the time spent and for stopping me endlessly futzing around with settings on and off!
I've been using GeDoSaTo so much now I've upgraded to a 970. Thanks Durante and everyone who's contributed (code/bug reports etc).
A couple months or so back I recommended GDST to someone for taking HUDless screenshots (EDIT: sorry, specifically in Divinity: Original Sin) and they're now reporting back that it doesn't work.
Before I try and troubleshoot it myself, are there any known issues that might have popped up in the last few months to cause compatibility problems between GDST and D:OS?
Before I try and troubleshoot it myself, are there any known issues that might have popped up in the last few months to cause compatibility problems between GDST and D:OS?
Need an opinion on this. Any good?
http://screenshotcomparison.com/comparison/96841
That's MSSAO btw, SAO doesn't work with this one either, game crashes on startup. (tried lotsa settings)
//seems that if I enable postprocessing, (MSS)AO won't work at all.
http://screenshotcomparison.com/comparison/96841
That's MSSAO btw, SAO doesn't work with this one either, game crashes on startup. (tried lotsa settings)
//seems that if I enable postprocessing, (MSS)AO won't work at all.
It's really weird (probably a bug) but if post-processing is enabled, then AA must also be enabled for AO to show.
As in, if you have AO, Post processing, and AA enabled, disabling AA also disables AO.
Also, the AO looks really good for parsing out the characters legs.
Boulotaur2024
Member
Thanks Halo81 and 7Sons, I just fixed the 'AO not working when postprocessing is on' issue . My fault. Could you test with that dll and tell me if SAO finally works at all. I also got the same white screen output when I grabbed the Github dll. So I decided to download the zip source-code and rebuild everything and... SAO works when I compile it myself. Same source-code. Seems very fishy. Sorry this is just another worst-case scenario but it might be related to the Directx SDK version : I'm using the DXSDK_Jun10 while Durante uses the DXSDK_Aug09. I could be completely wrong but I fail to understand why the same source-code doesn't produce the same results.
Something weird is happening here. I downloaded your gedo.dll, set gedo to SAO (default config)/strenght3/scale1/gaussian and the game game crashed, same as before.
Fiddled with the game/gedosato settings, game still crashed.
Reverted the game settings to the ones I was using before with MSSAO, all high except AA and gedosato (sao/strenght 3/scale1/gaussian) but this time I edited the SAO config. I've set nearZ/farZ to the same values I was using in the MSSAO config. (nz 0.16/fz 29) Started the game and surprisingly it worked so I came to the conclusion that these two settings are the ones causing the game to crash. So I reverted the near/far Z setting to the default ones to see if the game will crash again and it didn't this time. :-?
Both SAO and MSSAO work while postprocessing is on now, thanks!
Fiddled with the game/gedosato settings, game still crashed.
Reverted the game settings to the ones I was using before with MSSAO, all high except AA and gedosato (sao/strenght 3/scale1/gaussian) but this time I edited the SAO config. I've set nearZ/farZ to the same values I was using in the MSSAO config. (nz 0.16/fz 29) Started the game and surprisingly it worked so I came to the conclusion that these two settings are the ones causing the game to crash. So I reverted the near/far Z setting to the default ones to see if the game will crash again and it didn't this time. :-?
Both SAO and MSSAO work while postprocessing is on now, thanks!
I'm not aware of anything, I'll check this once I get home.
Certainly nothing general is broken, I am currently taking lots of hudless screenshots while playing Wasteland 2.
Edit: just tested in the current build in D:OS, works perfectly:
Boulotaur2024
Member
Glad you got it working ! I was so scared it was a NVIDIA/ATI issue with the shader itself. Wrong nearZ/farZ values should never crash your games. I mean unless you forgot a semi-colon in the shader or somethingBoth SAO and MSSAO work while postprocessing is on now, thanks!
I'll commit some more changes soon, mainly compatibility fixes for some more games support with the GenericDepthPlugin. I'm still having some issues with some games like Assassin's Creed (someone was kind enough to report it on Github thank you) that internally scale the injected depth texture to their internal format making it look squished (is that the right word ? squizzed ?). It's annoying as hell I tried many many combinations within SetViewport(). Changing the height obviously, modifying the Y value... but to no avail. Durante's own aspectquad() does work now though. It's extremely useful for us 16/10 user. Sorry for being technical but I suspect some readers -and I do hope so- are likely to take a look at the source-code someday
Here are some shots of SAO at a ridiculous 56 samples. (Now guess what game this is)
Other than that I added DOF to the GenericDepthPlugin. Technically it works. I mean everything is in place. Now all that's needed is a brain (Durante you got some free time I heard these day ?) to figure out how to adapt the shader to properly read/linearize the injected depth texture values. Right now all I get is a massive blur blindly applied all over the frame, not taking into account the distance of objects I mean.
![[Asmodean]](/data/avatars/m/123/123312.jpg?1526393694){kind=avatar}
[Asmodean]
Member
I've been having some small issues with recent versions. Sometimes when I go to launch the GeDoSaToTool binary, the dialog doesn't open, but the process will run. I then cannot terminate the process by any means, and have to reboot the system to stop it.
When I then go to launch GeDoSaTo next, after this has happened, I'll get some prompt about cleaning a reg entry and closing GeDoSaTo properly.
Has anyone else had this happen?.
When I then go to launch GeDoSaTo next, after this has happened, I'll get some prompt about cleaning a reg entry and closing GeDoSaTo properly.
Has anyone else had this happen?.
Yeah, sorry, I really should have reported back. Did my own troubleshooting for the guy early this morning, tested whatever I could, different versions whatever, it worked fine. Been a while since I've booted up D:OS. What a goddamn great year for games. Thanks for taking the time to look though; sorry for wasting that time.
[Asmodean]
Member
I've tried those, but thanks anyway. I've tried closing the process via the task manager as admin, I've also tried force terminating it via Kaspersky app management, neither will do it lol.
Yeah, it's fairly weird alright. It only seems to happen when launching it a second time after a reboot. Eg: first launch - it works as intended. If I unhook, and close the application, and the next time I try to run it, there's no dialog window, but the process is running in the task manager (which then cannot be stopped manually).
It could possibly have something to do with Kaspersky AV (I got it with my board). It was producing false positives with the recent versions and deleting the binary. But, I've put the GeDoSaTo binary, and folder path as trusted, and ignore, so the AV shouldn't be interfering with it anymore.
Hey Durante, if I wanted to use DSR for downsampling but also gedosato features like hudless and such, what would be the best way to do it? Or would the two interfere with each other if I have same resolutions with DSR and GeDoSaTo? Is it possible to globally disable downsampling in _user.ini (and then of course re-enable it for games like FF13)?
jim2point0
Banned
I can't imagine it's any different than custom resolutions. Most games see both my custom resolutions and GDST resolutions.