MXAO port to GeDoSaTo

i wanted to ask, what license is MXAO 1.5.7r under?

no commercial use in mind whatsoever, i'm just working on porting it to gedosato (since it has much better compatibility regarding the depth buffer with older, dx9 games) and i was wondering if you're ok with me throwing it out in the wild. started with 1.5.7r because while i'm a programmer, i'm kinda new to shaders, and that version isn't as glued to reshade as the latest one (i may be wrong on that though, just took a quick look to compare).

you wouldn't happen to have a dx9 version of MXAO somewhere around, would you? i'm doing this with the witcher 1 in mind, but many more games can benefit from it, from mass effect trilogy to the original skyrim, which some prefer to this day.

In theory im against any ports to third party content but GeDoSaTo is fine. The newest MXAO is just larger and not more glued to ReShade, only the controls need to be mapped. And also in every way superior to 1.5.7r so it'd be a bad choice to use that one.

Since GeDoSaTo's AO appears to be mediocre, wouldn't it be a good idea to port MXAO to it officially? If you could get me in touch with its developer (he has been around here in the early ReShade days but not anymore) I'd be happy to help.

Most of MXAO's performance comes from stuff that I'm not sure GeDoSaTo supports out of the box.

porting it officially would definitely be the best choice, i'm just not sure who would handle it. GeDoSaTo's dev stopped working on it quite some time ago it seems, he's still active on github though - and GeDoSaTo's source code is there. he started working on dx11 support at some point, but never managed to finish it.

and that's i guess the main thing - as it is, i'm trying to port MXAO to dx9 so it'll compile at all under GeDoSaTo (nasty hack, dumping it as a replacement for HBAO.fx). by doing this, i'm learning about shaders. i've got some C/C++ knowledge, my directx experience equals zero though. all i'm hoping for is that it'll perform better than HBAO, which i guess it should, even in dx9 - altough i'm not sure what you mean by stuff that GeDoSaTo may not support out of the box. as it is, i'm just rewriting parts of MXAO - not even trying to touch GeDoSaTo's code, at least not yet.

ok, i see i was a bit naive. took a look at GeDoSaTo code, gotta mess with it it seems. can't figure for the love of god how to set up render targets inside the shader file in dx9 (if that's possible at all), and i guess that's what you meant with stuff not supported - multiple render targets in a single pass.

i can set those up in GeDoSaTo though, i have to mess with it anyway since it has all the passes hardcoded depending on the AO shader chosen in the config, so it was my mistake to not check it in the first place. i'll switch to the newest MXAO at this point, i'll keep poking you if i'll encounter any problems. gonna turn GeDoSaTo into a wrapper first though.

looks like i'll be doing the "official porting" stuff, unless you're willing to take over.

[strike]there's one potential problem though, GeDoSaTo uses GPLv3, so pushing a fork with MXAO to github would release MXAO under GPLv3, while you've released MXAO under CC BY-NC-ND 3.0. i could release GeDoSaTo fork with MXAO support under GPLv3, but without MXAO itself, while the MXAO port would be released separately under CC BY-NC-ND 3.0. one can argue that such MXAO port is just a generic dx9 port that can be used with whatever software, including but not limited to, GeDoSaTo. in such case, it's the GeDoSaTo requiring non-GPLed MXAO for full functionality, not the other way around, so it should be fine.[/strike]

i should start reading readme files first. GeDoSaTo repository has some shaders covered by separate license, so it isn't a problem to throw MXAO in there and add it to the list of exceptions.

let me know what you think, i'll keep you updated and won't release anything without your approval. throw a discord invite maybe, so i can stop derailing this thread any further.

It's funny I was thinking of porting it to GeDo last friday while drinking my coffee before work.
But GeDoSaTo is pretty much a dead project now that DSR/VSR are out.
Last PR (Pull Request) is from April 25th and is still pending...
I'm not even sure Durante cares about it at all, you know.

I want to help but I don't even know if the VS solution compiles with VS2017...
You want to modify ssao.cpp and either you create another branching for MXAO or you can reuse the HBAO branching paths.

You probably don't need to add separate noise texture like HBAO though (Marty removed it recently I think).
So you can safely remove this line :

I don't know if MXAO needs complicated parameters entry... only depth texture and color texture ?
Then you should be fine (?)

EDIT : oh sorry for derailing the thread

as far as MXAO goes, it needs to be ported to dx9, because GeDoSaTo is dx9 only. i'll have to set up render targets in GeDoSaTo as well.

but changing GeDoSaTo into a wrapper goes first. i'll wrap d3d9 and user32 only, so stuff like texture handling and possibly built-in frame limiter will go out of the window (not sure about the last one, didn't check it's requirements). gonna throw in some shared memory as well, so that user32 knows what resolution the game thinks is running at, for mouse pointer translation.

for me, GeDoSaTo is still good on three fronts:
- you can use arbitrary high resolutions, regardless of your monitor, unlike DSR/VSR
- you can use the same scaling the other way around, in case you're running games on lower-end hardware, gaining resolution scaling in games that don't support it (and dx9 games rarely do, if ever)
- if you're after limited postprocessing, focused on AO, AA and some tone mapping, it's better than reshade for dx9 games due to higher compatibility with dx9 games regarding depth buffer

the last part is what got me into trying it in the first place. i wanna play the witcher 1 again, and with HBAO it looks great, but my A8-7600 can handle it with HBAO in 720p, and there are issues with mouse scaling during conversations, making it impossible to select icons responsible for actions like shopping. MXAO is faster, so i've decided to port it, end of story.

as for injector vs wrapper, GeDoSaTo hooks into everything that loads user32, loading a small dll, and that small dll checks if the process in on a whitelist, loading GeDoSaTo if it is. it had to be done that way, being an injector, but it's a dangerous approach, because it may load into some online game a user didn't put on a whitelist, and cause a ban. also, people apparently had tons of compatibility issues with more recent builds, most likely caused by this approach. wrapper should work better, and it'll be safer to use.

since Marty isn't here - and with him, invite to his discord server - here's an invite to mine: discordapp.com/invite/uSSe2Rh
so anyone willing to discuss GeDoSaTo and/or porting MXAO to it, lets go there to avoid derailing this thread. Marty, i'll keep an eye on here, but feel free to join there as well.

Did you get permission to start porting MXAO? Unless it's strictly for personal use, and you're not planning to distibute your port, that's kind of forbidden by Marty's license.

it was discussed on the previous page...

MXAO perf comes from mipmapped depth and normal buffer (latter only required for SSIL). This also means you need to output a 4 component buffer (AO channel + RGB channel) and blur it, I suppose GeDoSaTo went the way to use 1 channel texture only for performance.

Boulotaur2024 I wasn't aware that you are not the main dev of GeDoSaTo sad to see this promising project go to waste.

i have to mess with texture setup in GeDoSaTo because of render targets anyway, so it's not a problem.

as for GeDoSaTo itself, i won't say i have plans for it, but i want to get it working as a wrapper with dx9 games and MXAO - and with it's main feature, scaling, obviously. so it should at least work better than the last official releases people were complaining about. definitely won't be adding dx11 support or anything like it, i just don't want it to go to waste because it was abandoned in a kinda messy state. after all, for games like the witcher 1, mass effect trilogy, and plenty of others, it's the best bet to get good AO working.

bottom line, as long as i'm tinkering with it, it's not dead yet.

i know that improving depth buffer detection in Reshade for dx9 games is also an option, but for me GeDoSaTo has the bonus of built-in scaling, lanczos included. for lower-end hardware it's really a game changer when you can boost the visuals while sacrificing a few pixels. ideally, it all should be ported to Reshade, but the last (few) times i've tried it, it always had issues with depth buffer, even in games in which it was supposed to be working perfectly. going the easy route then, since dx9 games are my main focus for now.

unic0rn wrote: for me, GeDoSaTo is still good on three fronts:
- you can use arbitrary high resolutions, regardless of your monitor, unlike DSR/VSR

Keep in mind that using this will kill the depth buffer in GeDoSaTo as it downsamples the framebuffer, but not the depth buffer. (at least I never could get it to work!). If this is still the case, it would ruin your effort a bit I think, so please test this out first if you want to use it with downsampled higher resolutions

the build i was testing with the witcher 1 didn't have a problem with it, but i was upscaling from 720p to 1080p to gain some performance with HBAO. it isn't the newest build, i've grabbed it from a comment section under some youtube video since the guy claimed newer one doesn't work - but there are tons of complains about newer builds not working at all. when i'll finish turning recent codebase into a wrapper, i'll check it out, but i see no reason for it not to work.



(don't mind the framerate, recording butchered it for some reason)

actually, after thinking about it for a few seconds (i need sleep, a lot of sleep), i think you may be wrong. [strike]i didn't analyze the scaler code, but i've got a feeling the whole processing takes place in the original resolution and scaling is the last step.[/strike] as far as my half-asleep brain can tell, scaling is the last step. doesn't have to be, GeDoSaTo supports plugins doing their job both before and after the scaling, but AO (and AA - depth plugin in general) seems to work before scaling. makes sense, since HBAO gives me much bigger performance hit when running in 1080p than when running 720p upscaled to 1080p. so basically, it doesn't have to scale the depth buffer.

that's assuming i understood you correctly in the first place, that is "not working at all", not "working, but very very slowly" - but performance isn't a problem in this case. decent GPUs have enough power to run dx9 games with all the effects in 4k, while lower-end hardware benefits from stuff being rendered at lower resolution than native.

since noone seems to want to move to discord with this, can one of the mods please cut the whole GeDoSaTo stuff into a separate thread in "Discussion" maybe? sorry for the trouble, it wasn't my intent to derail this thread.

Ok, then I did something wrong then I could never get the depth buffer to work for DOF when using scaling (up/down didn't matter), using the native res of the monitor made it work. It indeed should work as expected, but just in case it doesn't work, it would be a shame doing all this work and then finding out the depth buffer isn't available for the effect, hence my remark .