Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Mar 2012
Offline Last Active Jun 07 2016 02:11 AM

#5178251 Intrinsics to improve performance of interpolation / mix functions

Posted by on 05 September 2014 - 01:59 AM

Thanks to you both.


I'm doings loads of such averages, not just one single. That was just an example. Typically I'm processing e.g 128 to 1024 iterations in a for-loop (depending on the effect I implement). That's why performance considerations come into play. Compute shaders are out of scope in my case, I have to do everything in plain old HLSL pixel shaders.


As for what the compiler already optimizes, this is primarily what interests me. My question might have been not clear enough. I'm less interested in what theoretically could improve performance but what command / functions or best practices lead to the best optimized compiled code.


I am well aware that different GPU hardware (or firmware) might JIT compile intermediate code differently, but I'm interesting to know what *most* common GPU / systems will do.


E.g. it wouldn't help to use a mad() in my shaders when most systems would still compile that command into two instructions (mul,add) instead of a single madd. Similar goes for lerp() and the like.The noise() function for example is not supported by most GPUs although present in the HLSL standard.


Of course I can read what Microsoft writes on their HLSL intrinsic functions pages. But since reality differs from standards definitions such as HLSL, I'm interesting to learn how to write my HLSL shaders to benefit from hardware supported features as much as possible.

#5173328 Convert view space to world space issues

Posted by on 13 August 2014 - 07:09 AM

Ok, thanks.


I'll check the m_v2w matrix from hmodel, you might be right with that. And yes, I meant that the engine seems to pass that matrix in the geometry and/or lighting phase/stage of the graphics pipeline to the HLSL shaders, but not in the post-processing stage where I do my stuff.




You need to check documentation (if any?)


Hehe, that's one of the best STALKER jokes I've ever heard laugh.png

(there is absolutely NO documentation about the shaders, neither officially nor in-officially - otherwise I wouldn't be here so often)



I'll post my progress when I got a chance to check these things.

#5164244 Execute shader depending on what's visible on screen

Posted by on 02 July 2014 - 01:18 AM

Do you have access for any gbuffer data?


No, as I said no directX API or other raw 3D / GPU instructions. Only (repeated for the 3rd time now):


  • Camera world position
  • Camera direction
  • Camera FOV
  • 2 Box corner world coordinates (left-bottom-front, right-top-back)

plus the mentioned functions to calculate the distance and view angle to a given world space point.


Is it really that hard?

#5124338 Direct X 11 really worth it?

Posted by on 17 January 2014 - 03:50 AM



Thanks, but I can google that myself cool.png


I meant, from a practical point of view, which of the newly supported features are mostly used or useful in DX11 when it comes to game development? What are the key features you would say that makes it worth porting your legacy DX9 code up to DX11?


Or, say it yet another way, what high-level features (those advertised by the game industry) "need" DX11 if you want to bring them in your own game when?

#5124325 Direct X 11 really worth it?

Posted by on 17 January 2014 - 02:33 AM

Purely in terms of being a graphics API, I would say D3D11 is unquestionably better than D3D9. It's cleaner, leaner, and let's make use of newer hardware capabilities. Will that actually matter for your game? It depends on what kinds of game you're making, but in general the graphics API isn't going to become a limiting factor until you start having a really sophisticated level of graphics tech. If you want bleeding-edge graphics, then yes you want D3D11. If you want sprites or rudimentary 3D, the API isn't going to be that important.


Hi, may I ask which hardware capabilities supported by D3D11 (besides Tesselation) are the most important for modern 3D games in your opinion? Or, put it another way, what supported hardware features does a modern 3D game benefit most from when using D3D11 compared to D3D9?

#5107842 New demo (indoor scene)

Posted by on 08 November 2013 - 04:07 AM

Well, I like it smile.png


Cool lighting / reflections. The scene maybe still looks a little too "polished", e.g. textures / texture mapping are too uniform and clean, but that's normal in that state of development. Plus (as I'm a shader effect guy), there is a huge untouched potential of shader techniques and effects that could be applied in order to make the entire scene look more realistic, such as advanced normal mapping, parallax mapping, light effects (shafts/rays, lens flares etc.), SSAO / HBAO, dynamic depth of field and the like, but I guess that's not yet on your current todo list since you're saying you need to do things like collision detection first.


So keep up the good work !

#4947458 Math for computing relative sun direction

Posted by on 08 June 2012 - 01:38 PM

Sure, I'm so free to quote some other guy who has made some screenshots:

Notice how the telephone pole is blocking the sun where I am standing, which logically means I should be standing in its shadow. But notice where the pole's shadow is. Way in front of me! Nowhere near where I am:


Here's the sun behind a tree, blocking the sunlight from my view, so I should be in its shadow, but again, the shadow is way in front of me:


And a graphic to show what's happening:


I know from other source that the reason for this lies in the way the engine calculates the sun's coordinates which are passed to the shader. The geometrical horizonal taken for sun light direction calculation is about 40 degrees below the game world's horizon - meaning I'll need a way to correct this shader-wise. A simple vector shift or rotation with these 40 degrees should be accurate enough to make shadows look acceptable.