eFX Shader Injector Support Thread

BF4 launch

Make sure BF4 (Launch) "Game properties" (right click on game in Origin) options are set to x64, Game might be launching x86 (32 bit) sometimes otherwise!

 

EFX provides the tools, that shader can easily be implemented (by anybody who knows HLSL). Just take the shader source from Boulotaurs injector and modify it a bit to use the eFX shader layout (I'm not sure if his implementation was publically available, I can ask Boulotaur if I'm allowed to post it if not).

 

the dll is called dxgi.dll. i run the same exe each time... its very strange because one week ago it worked flawless :S

the funny thing... radeonpro didnt work with bf4 for me only with efx... and now radeonpro works and efx not *LOL*

 

you would be so kind as to do so, of course thank you very much and very grateful for all their contributions, we get a different color to life

 

That would be so cool .

 

Crosire could you ask permission Boulotaur

 

will be that we will not have our Christmas

 

Please precise the connection between these two tools

 

Crosire: This is an excellent post processing framework you've developed with eFX, especially for an injector/interceptor. I only discovered this the other day. Thanks for sharing it, and keep up the great work.

Do you happen to have any eFX documentation, for the definitions, syntax etc?, because, as of now, I've to look for them via dumping strings from the binary with a hex editor, and it's far from ideal. eg: BUFFER_WIDTH, BUFFER_HEIGHT, projection matrix I/O, etc.


Also, if anyone happens to be looking for an example of what you can do with eFX. Below is a link to a post with a small hq effect suite written by me, for eFX. I wrote it for a game I decided to have a replay of at the moment (Dark Souls) So it's currently only for d3d9, but it can easily be ported to SM 4/5, OGL.

(Apparently I can't post direct links, insufficient post count. So you'll have to add the wwwdot etc lol..)

Link to post: neogaf.com/forum/showpost.php?p=95210767&postcount=7671

 

I decided to give your shaders a try with the original Bioshock (since I'm currently playing through it), but for some reason it is not loading at all. The game will load, but the settings/shaders will not load. I have tried to toggle it on/off and reload them while in game, but it does nothing. I'm playing this on Steam and have disabled the community (steam overlay) while in game. Any ideas?

 

I'm pretty sure Bioshock defaults to d3d10 on supported hardware(?). Those shaders will currently only work for d3d9 (DX9). Don't get me wrong I'm not particularly a fan of DX9 myself (lingerer), but seeing as I wrote these for DS, which is d3d9. I didn't bother adding any cross-api conditions etc.

I'll probably port them, if there's interest in me doing so, I suppose. Doesn't take too long to do, typically.

Edit: for the time being, if you wanted to try the shaders out, You can set the game to run on DX9 if you right-click the desktop shortcut ->properties, and add -dx9 to the target: eg - BioShock\Builds\Release\Bioshock.exe" -dx9

Or you can add it to the launcher options in steam.

 

Why would your FXAA implementation be better than anything out there ? Seems to me like it's the regular FXAA 3.11 version. I just tried it and well it's just your typical blurry FXAA (which I happen to like I don't mean it in a negative way). It's not superior to SMAA since the latter is much less blurry, just as usual.

And welcome to the forum Asmodean : )

 

Uh, I didn't remotely say anywhere, that it was "better than anything out there" lol

I did say it was typically higher quality than the general SMAA 1x that comes shipped with injectors. Maybe it's just my own opinion, of course. I don't think the injector SMAA has good enough coverage on texture/sub aliasing, and lod etc.

Some screens below, of the shader off, and on. I'm not able to take new screens right now, but these are on my skydrive.

I dunno, maybe you consider these 'blurry', but I can't see any blurring. I'm running the game at 1440p natively.

(again, can't post direct links)

Just copy/paste these into the address bar. Don't add wwwdot.
To view original quality, you've to right-click the image, & view original.

Off: sdrv.ms/1cjrpCP
On: sdrv.ms/1ckAdVI

Off: sdrv.ms/KhF1Wi
On: sdrv.ms/19FSiAX

Thanks for the welcome btw ^.^

 

Have a welcome from me too, Asmodean. Nice to see another one being able to actually use the featureset of eFX and not relying on other people's work.
There is no real documentation there yet, I think that would be too early, as stuff still changes quickly. One of the current SweetFX/eFX bundles has a file with all the interesting macros and annotations though, that's a good starting point.

By the way, I'm sorry for the lack of updates currently, I'm a bit busy right now.
There is some great progress regarding the OpenGL capabilities of eFX, experienced no more crashes with my current builds, the OpenGL hook works great and post processing already as well in some games (a number of graphical artifacts yet though). Also replaced the fullscreen quad for rendering with a single fullscreen triangle, just another micro optimisation to improve performance even more.

 

Thanks for the info, and the welcome. I had actually found that bundle with the readme inside, since I last posted. I look forward to your future updates.

 

Hi Crosire,

I've been working with eFX and SMAA v2.8 (using CeeJay.dk's SweetFX bundle). I managed to get quite a bit done, but I've stumbled into some issues while trying to set up SMAA T2X (temporal supersampling).

First, is it possible to get the previous post-processed frame directly through eFX? If not, that could be a big plus for shader effects that can utilize it (motion blur, adaptive lighting, velocity calculation, etc.).

Alternatively, is there anyway to buffer information (a texture of how the frame looks at the time for example) and then call that back later (in the next frame, or maybe even a number of frames later; I know how to ouput to a texture and call that back in another pass, but that all gets wiped after the frame). This could be used in the effects I mentioned above, or it could possibly even be repurposed for optimizations (using depth stencils most likely) or a number of other things.

Secondly, is it possible to buffer a variable so that it persists between frames but is alterable. Boolean flags come to mind, but ints or floats could also be useful. I currently need a flag to alternate how SMAA renders the scene every other frame (once offset slightly one way, and once offset slightly the opposite direction). To expand on this, might it even be possible to have eFX handle the branching involved in using such a boolean flag and have it directly alter variables in the script each frame? That could potentially speed up shaders that use such mechanisms.

As an example for the last case:

[float] myFloat < string type = "alternating"; string values = "1.0", "0.0"; >;

This would automatically set myFloat to the two different values every frame, outside of the shader. So no boolean flag needed, much less messy if statements that check said flag and assign values based on it.

Or to expand upon that Idea:

[float] myFloat <string type = "rotating"; string values = "0.0", "1.0", "2.0", "3.0"; >;

Which would cycle through all four separate values. I believe this could be used in SMAA 4x, to give you an example of where a "rotating" type could be applied.

I'd also like to say great work with the injector. I haven't had any problems with eFX itself so no bugs to report. Just looking for information/ideas on how to solve the two issues I'm having with setting up T2X and suggesting features.

Edit: Oh yeah, reloading external resource textures every frame feels bad. Is that slowing down SMAA by chance? And! is there a way to specify the dimensions of the texture being loaded because I think they may be getting stretched to the Render Target's dimensions at the moment (if you output them to the screen they stretch at least instead of leaving blank space, or repeating). AND! Is there a way to possibly take Anisotropic samples of the textures and load them into the Texture object as well? That could possibly increase the accuracy of SMAA (just a 1/2-length x sample and a 1/2-length y sample would be enough probably). If not on the last one, I suppose the samples could just be baked into the texture using any old texture editor. AAAAAND! "NO AND THEN".

 

First of all, thanks a lot. Yes, all of your request are possible to implement. Storing a copy of the previous image isn't hard, that one could be directly combined with the idea of texture buffers you can write to once or more often, but not being limited to render to it every frame. I'm not sure how one could set this up using shader annotations yet though... Having a variable store a value should already possible by declaring it as uniform, but without adding a shader annotation, aka "uniform float fValue;". The value you set it to should survive a new frame (I'm not entirely sure if it was possible to write to uniform variables from a shader, so correct me if I'm wrong).
eFX only loads textures and binds them to the shader once at startup (and on shader recompile), they are then stored on the graphics card and kept there, so no reloading per frame at all. It's already possible to change a texture dimensions by specifying a "width" and "height" annotation, so it looks like this: "uniform texture2D tex < string type = "texture"; int width = 800; int height = 600; >;".
Setting a shader variable from eFX is expensive (it needs to be copied from CPU to GPU first, so I avoid that where possible. The solution of manually changing them in your shader would be faster.

 

All globals are automatically uniform and trying to change them in a function results in a compilation error. Back in ps_1_x there was no error, but changing them locally (within a function) did not change them globally (so the next pass couldn't see that xVar had been changed). You can change globals to static and all functions see them and can write to them (I think), but then they reset every frame.

Also, there's the matter of flipping the variable inside of the shader. If you put the branch inside of a pass, it may be getting ran screen width * height number of times, resulting in complete craziness. Setting up a runonce should fix this, at the cost of another branch.

I thought of setting up multiple local boolean values, but local values cannot be classified uniform. Multiple local values would also require branching in every pass that uses them to flip the value.

Basically, for instances where you want to alternate something in your shader, frame to frame, having the controller variable handled externally is the way to go. It's also how the SMAA devs did it in their demos (they actually set the variables that need to alternate externally as well, but I can understand how setting up a flexible framework for that would be difficult and possibly more of a performance hit.)

Perhaps implementing an integer counter in eFX that counts up to a user-configuerd value and passing that to the script would be the best solution. The overhead on that shouldn't be very high and that would allow alternating or rotating functionality. You could even restrict it from running unless it was defined in the shader somewhere.

int = ((int + 1) % max); in eFX (or you could use an if statement instead of modulo).

int myInt < string type = "counter"; int max = 3; >; in a shader.

 

Oh yeah, I forgot to ask about the other thing.

Is there a way to set up an upscaled render target? I'm thinking either 2x in both dimensions or 3x in both dimensions; anything past 3x and the precision gained in interpolation probably isn't worth the performance cost. I have an idea I'm calling interpolated downsampling.

Basically, add a shader pass at the very end that interpolates an upscaled version of the image. I already have a particular interpolation method in mind and everything. The D3Dxx application should *cough* *cough* automatically downsample the interpolated image meaning I shouldn't have to hand-blend back down to the output resolution or anything.

This is pretty experimental as far as I know, and may or may not end up producing a higher quality image or be worth the performance impact of interpolating and blending an upscaled image, assuming that it works in the first place.

 

Yes that is totally possible. Just write:
"texture2D target < string type = "output"; float width = 2 * BUFFER_WIDTH; float height = 2 * BUFFER_HEIGHT; >;"

About the counter: That one is easy to add, 5 lines of additional code maybe. I'll implement it as soon as I got time.