Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Oct 2013 20:34 Edited at: 4th Oct 2013 20:38
I'm at wits end here.
I recently revisited an "almost working" directional lighting / shadow mapping shader with the intent that maybe this time I could finally get it figured out.
I eventualy noticed that trying to override the camera view matrices did not seem to have the desired effect and when pondering that I discovered I didn't even have the latest DBP version installed (I recently reformatted my computer, so I guess I merely forgot to update it).
Now after I did upgrade to version 1.761 my shader has stopped working completely.
I cannot figure out why on earth this would happen; it takes several seconds to load and once it's loaded up my DBP project that utilizes it renders nothing at all for the objects which have it applied. When testing it with the DarkSHADER editor it takes even longer to compile the shader and eventually gives up, telling me the DBPro window isn't responding. A few seconds later it outright crashes.

I haven't changed the shader one bit since it was working with my old DBP version (from 2010 something I think, might have been version 1.6x). Now I have went over every line, trying to remove things to only have the essentials left but still to no avail. As far as I can tell it crashes because of some overload in the DirLightPS pixel shader, but compiling it with fxc says it should only use ~380 instruction slots (vertex / pixel shader 3.0 should allow for at least 512).


If anybody feels like taking a look at my shader, be my guest.
I've removed some half-unfinished point light functionality from it to make it more concrete if the ordering of instructions looks odd as a result of that.



Finally, any ideas on what might be causing this would be greatly appreciated. Googling hasn't yielded a single similar thing so far.


Edit: Tried to make the tabs in the code block look more coherent.


"Why do programmers get Halloween and Christmas mixed up?"
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 4th Oct 2013 22:44
I am in a similar situation; but have not worked on shaders for months, so I am a bit rusty at the moment.

I am looking into communicating with the DirectX API commands using DBP DLL functions; but I fear that is no different to using FXC.exe based on my research.

So far my only work around besides FXC compiling is to dumb down the shaders and apply more than one alpha-blended shader to a multi-limb object; which is not a specular solution to say the least.

Another thing to try is to seperate the shader into multiple passes; enabling and disabling each one to pin point causes of crashes more quickly.

That is all I can add to this thread with my current knowledge.

Brendy boy
20
Years of Service
User Offline
Joined: 17th Jul 2005
Location: Croatia
Posted: 4th Oct 2013 23:34
try upgrading to U77, the version you are using isn't the newest

Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 5th Oct 2013 01:09
Well, now it doesn't take particularly longer to load than it did before when used from my own DBP test project (timed to ~0.1 seconds).
However it still crashes Dark Shader with an "has stopped responding" message, which I find weird - it's the exact same shader...
And of course my objects are still not rendered at all in my own project, so there's no real progress to talk about there.

@Chris: About removing part by part to find the point of error in the shader, I've tried that, but it seems like it optimizes away all code that doesn't contribute to the final output colour of the pixel shader (where the problems seem to lie, the vertex and depth mapping shaders are fine). I'll try a new approach and still save parts of the computations for the output, but that will take some planning since the yielded output will be weird with parts just cut out. Or now that I think about it maybe I could just output a fully white colour subtracted with the previously calculated value * 0.0000001 or something. Will try that tomorrow.


@Brendy boy: unfortunately RC77 breaks compatibility with some third party libraries that I use. Therefore I've never really used it before and I haven't seen any issues either. I just recompiled the Basic3D and Camera dll's from the open source repository to replace the ones from U76, but that didn't make any difference either (I assume those are up to date).


"Why do programmers get Halloween and Christmas mixed up?"

Login to post a reply

Server time is: 2026-07-06 10:36:02
Your offset time is: 2026-07-06 10:36:02