MXAO port to GeDoSaTo
- unic0rn
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- Marty McFly
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.
Please Log in or Create an account to join the conversation.
- unic0rn
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- unic0rn
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- Boulotaur2024
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 :
if(type == SSAO::HBAO) effect->SetTexture(noiseTexHandle, noiseTex);
Then you should be fine (?)
EDIT : oh sorry for derailing the thread
Please Log in or Create an account to join the conversation.
- unic0rn
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- TreyM
Please Log in or Create an account to join the conversation.
- unic0rn
- Topic Author
Please Log in or Create an account to join the conversation.
- Marty McFly
Boulotaur2024 I wasn't aware that you are not the main dev of GeDoSaTo sad to see this promising project go to waste.
Please Log in or Create an account to join the conversation.
- unic0rn
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- OtisInf
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 resolutionsunic0rn wrote: for me, GeDoSaTo is still good on three fronts:
- you can use arbitrary high resolutions, regardless of your monitor, unlike DSR/VSR
Please Log in or Create an account to join the conversation.
- unic0rn
- Topic Author
(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.
Please Log in or Create an account to join the conversation.
- OtisInf
Please Log in or Create an account to join the conversation.