View Single Post
Old 15th October 2018, 14:44   #2
Fumbling_Foo
Senior Member
 
Fumbling_Foo's Avatar
 
Join Date: May 2016
Location: Mississippi, USA
Posts: 285
I have limited experience with non-warp shader stuff, but have a general idea of what to do from here. You'll want to start off with settings the borders and wave code to red, setting the other color channels to 0. Then you can slowly adjust from there and work with the decay amount to get the effect you want.


bAdditiveWaves=1

This may whiten the screen, set it to 0 for now.


So, for example here, raising the wave_r value will of course make the red from the wave brighter, especially if wave alpha is 1 (or above, but I think anything above 1 or below 0 has no additional effect). Here, wave_g and wave_b should be set to 0 for now, otherwise the wave will appear grayish to white with additive setting on.

wave_r=0.650000

wave_g=0.650000

wave_b=0.650000


I'm assuming you're not intending for the outer border to do anything but provide a buffer for the inner border to do its work or for it to mix in black colors with the red colors. If the per pixel section has significant warping, the outer border will transfer its color to the screen.

ob_r=0.000000

ob_g=0.000000

ob_b=0.000000


Here, also, .25, .25, .25 will give dark gray, you'll want to start with a high ib_r value and 0 values for g and b to get red, then work from there.

ib_r=0.250000

ib_g=0.250000

ib_b=0.250000


Having ib_a = 0 makes it invisible, so it will not translate any color information to the screen. Your borders as they are may not be working as inteded.

ib_a=0.000000


Again, if you want motion vectors to be preset on the screen, you'll need to increase the mv_a value to above 0 (1 is 100% visibility wherever alpha is concerned). With that fixed, mv_r = .1 is going to look green with mv_g = 1, so raise the red value, set the green value to 0, and start from there to get the colors you want.

mv_r=0.100000

mv_g=1.000000

mv_b=0.000000

mv_a=0.000000


Again, I'm not really familiar with what decay is doing, but that seems like a huge value. Is it working as intended? From the milkdrop preset authoring guide (can be found in "docs" folder under milkdrop2 folder, " decay (0..1) - controls the eventual fade to black; 1=no fade, 0.9=strong fade, 0.98=recommended".

per_frame_5=decay = 3000000+57.75; // Magic 'flame' decay


I've never heard of the sqr() function. Are you trying to do sqare root? sqrt() is the proper function.

per_frame_8=ob_a = sqr(sqr(sin(time*1)*.25+.25)); // 'ad-lib decay' to black - no ugly artefacts


Usually, if there is a syntax error milkdrop throws a compiler error and points to where that occurs. I don't think per-vertex code does this though, so there can be syntax errors here and the preset will still fully compile without error. Again, unfamiliar with sqr(), did you mean sqrt()?

per_pixel_5=dx = dx*sqr(y); //dampens top

per_pixel_8=dx = dx -(x-.5)*.04*(.8-sqr(y)); //drift towards centre

per_pixel_9=dx = dx + cos(sqr(y-.5)*10-time*1.1)*sqr(1-(y))*.01; //add flutter at top


Hope this helps . I've been working with milkdrop for a while now but still a lot I don't know.

Creativity turned into madness. And then back again.
Fumbling_Foo is offline   Reply With Quote