Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Mar 2012
Offline Last Active Mar 20 2015 05:04 AM

Posts I've Made

In Topic: D3DCOMPILER_47.dll ?

16 February 2015 - 04:50 AM

I've definitely ran into some cases where the old _43 compiler would take minutes to compile a complex compute shader, and would take only a few seconds with _46 or _47.


Thanks, I've just tested it. No difference for non-compute shaders (at least in my case), unfortunately.

In Topic: D3DCOMPILER_47.dll ?

11 February 2015 - 07:16 AM

On a related topic, does bring D3DCOMPILER_47.dll any performance or memory benefits over the _43 version?

In Topic: Convert view space to world space issues

19 November 2014 - 04:23 AM

Hey guys, just wanted to let those who tried to help me know that the issue has been solved - my code was right, it was the engine (host application) delivering wrong matrices under certain conditions.


So everything's fine now, thanks again for your help :)

In Topic: Efficient array shuffing in pure HLSL

31 October 2014 - 09:24 AM

Hash! I need a hash, simple as it is! I should have come to that conclusion myself already in the first place happy.png


And if some very reasonable other suggestions here, are not possible for you to perform , you should politely state so.


I think I have explained myself well enough to make clear why I reacted the way I did. It wasn't just some "other suggestion" that made me mad but the fact that some people insist on such a "other suggestion" even after I have stated clearly that it is not an option in my case.


Nonetheless, your hint on goniometric functions, even though not exactly what I was looking for, has lead me to the solution - I simple and stupid hash.


Thanks again.

In Topic: Efficient array shuffing in pure HLSL

31 October 2014 - 04:16 AM

You need a deterministic function for at least 1 milion values that returns enough noise over them (since you have a determined index for every pixel).


Thanks. I don't have to do it for every pixel. That was, as I said, a simplification I had to make to avoid needing to tell a whole-day story here. Actually I pixelate ("downsample" in some sense) the screen to some extend, say 48 x 48 blocks. Would you then still suggest going the way of goniometric functions, or is there a simpler approach?




The best I can do right now is to give you a few links that I think are tangential to your problem but might help you come up with a workable idea.

Nathan Reed talks about PRNG on the GPU, and how a hashing function can be helpful there.

Alan Wolfe talks about creating a random shuffle operator.


I've already found those pages myself, but thanks anyway.




Sometimes, when we're deep inside a problem, we miss the forest for the trees. Its not that we doubt your skills OP, is just that a fresh look at the problem might yield not an implementation of XYZ idea, but a different ZYX idea altogether.

Now, if you don't like ZYX idea and still want to do it the XYZ way, that's fine too. Just try to consider other ideas first, they might save you lots of time.


I'm sorry but you're still off-topic, as *repeatedly* questioning me not being able to do it CPU-wise is off-topic. Don't get me wrong here, it's completely ok to ask if I couldn't do it on the CPU side  -   ONCE. But sticking on that and asking the same thing over and over is just annoying and not helpful nor constructive at all.