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.

DarkBASIC Professional Discussion / Creating a New Simple Tweakable Variable in a Bloom Shader

Author
Message
Sixty Squares
20
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 6th May 2010 01:01 Edited at: 6th May 2010 02:51
Hey guys,

I've been looking at EVOLVED's post-bloom shader (original .FX file is attached, you can download the demo from his site [DEMO]), and I can't wrap my head around this. All I'm trying to do is create a global tweakable variable that I can change from DBPro and use on a certain aspect of the shader. The variable is fine everywhere EXCEPT when I try to use it in the POW(number, power) command. When I plug it into the "power" part, it doesn't work. Here is what I'm trying to do, in more detail:

So I was looking at the shader, trying to make the bloom effect brighter and more widespread. I realized that changing this:


To this:


Made the bloom shader significantly brighter. By decreasing that power in the pow command from 10 to 2, the color was less dark, and everything just looked brighter. So I figured I would try to make a variable to control it with. I called it ColorPower and put it at the top, changing this:


to this:


And then I tried doing this:


The problem is, the screen turns out black, which means the shader isn't working. I thought maybe the ColorPower variable wasn't working, so I tried doing this which would make the screen have a red overtone to it:


It worked, so I knew that the ColorPower variable was indeed global. So then I thought maybe the POW command didn't like variables, so I tried this:


Which also worked. So, I tried this:


Which did not work. Any idea why this is happening? I just want to be able to allow this global tweakable variable "ColorPower" to change the value used in the "pow" command, but it's not working! It doesn't work for any other global variables either, even those that are already there.

Anyway, if anyone has any idea why this is happening (I hope it's just some stupid mistake I don't know about), I would appreciate it.

Here is the full code:


Thanks,
-Sixty Squares
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 6th May 2010 01:36
The following bit of your code looks wrong to me. Are you sure you've given us the right version of your shader? Also, could you post EVOLVED's code as well so we can see what you've changed?

Sixty Squares
20
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 6th May 2010 02:18 Edited at: 6th May 2010 02:24
Oops, that is the wrong code! My apologies, thanks for pointing that out . That code should be this. The only thing I've changed from Evolved's original code is that "pow" statement and the addition of a ColorPower variable.



EVOLVED's original .fx file is attached to the first post; here is the code:


EDIT: Fixed my mistake in the first post.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 6th May 2010 13:45
That's an interesting one - the shader won't compile. The reason is one of those subtle limitations of PS1.4.

In PS1.4 the pow() function compiles to a series of multiplications. So, when you had "10" instead of "ColorPower", the compiler knew what to do - it produced the following asm code:



Your "color" variable is the initial value of the register "r0". The first mul operation calculates the square of "color" and stores it in r0, the second calculates the square of that and stores it in r1, i.e. the fourth power, the third calculates the eighth power the same way and stores it in r1. At this point r0 contains the square of color and r1 contains the eighth power. The final mul multiplies these to get the 10th power. Phew! Essentially, the PS1.4 compiler doesn't know how to handle the case of an unknown power.

The ps2.0 compiler produces something very similar when you use the literal 10. However, when you use "ColorPower" the asm code becomes:



Notice two things: the increase in number of instructions and the use of the log and exp functions. The log and exp functions are not available in PS1.4.

The simplest solution to your problem is to try using ps2.0 as the compile target, i.e. change



to



I can't guarantee this will work as I haven't time now to check. It's possible a few other changes are needed to get things working correctly in ps2 - however that change does allow the shader to compile.
Sixty Squares
20
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 7th May 2010 03:07
Wow, I understand, thanks for the explanation . I changed it over to ps2.0 and it's working perfectly now, thanks again for your help! On a side note, how did you know it wouldn't compile? Is there a .fx file editor/compiler I can download? I have DarkShader, which can compile, but it didn't seem to give very specific errors (from what I just tried). What do you use?
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 7th May 2010 05:39 Edited at: 7th May 2010 05:40
I used Dark Shader. Your shader should have failed to compile in Dark Shader and given a rather unhelpful error message (that's not Dark Shader's fault, it's what the DX9 shader compiler says - you get the same in FX Composer ... up to a point ). I then decided to look at the asm listing of the version with "10" instead of "ColorPower" since that version did compile (look on the Build menu). As soon as I saw that listing I realised what was probably going on and proceeded from there - and double checked with the MS DX9 SDK docs. I don't use PS1 shaders much and need to be reminded that they have important limitations in addition to the familiar lower instruction count limits.

Thanks for the feedback.
Sixty Squares
20
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 8th May 2010 17:02
Ah I see. I didn't know about that Save Assembly thing, but then again I wouldn't have known what to look for . Thanks again-- learn something new everyday

Login to post a reply

Server time is: 2026-07-26 04:28:02
Your offset time is: 2026-07-26 04:28:02