Rick Brewster

CodeLab v5.4 (for advanced users) Released May 21, 2020

Recommended Posts

 

I discovered this can be done by the following call:

configUI.SetPropertyControlValue(PropertyNames.Amount1, ControlInfoPropertyNames.DecimalPlaces, 3);

That works! Many thanks, very useful. B)

Share this post


Link to post
Share on other sites

There are two pieces of code that CodeLab generates which I have questions about.
 
1) Why is 'unsafe' needed here? or is just there so we can put unsafe code in Render?

protected override unsafe void OnRender(Rectangle[] rois, int startIndex, int length)
{
	if (length == 0) return;
	for (int i = startIndex; i < startIndex + length; ++i)
	{
		Render(DstArgs.Surface, SrcArgs.Surface, rois[i]);
	}
}

void Render(Surface dst, Surface src, Rectangle rect)
{
}

 
2) What does this line in OnSetRenderInfo do? This question is probably due to some ignorance of C# I have.

base.OnSetRenderInfo(newToken, dstArgs, srcArgs);

Thanks.

Share this post


Link to post
Share on other sites

1) Why is 'unsafe' needed here? or is just there so we can put unsafe code in Render?

Codelab has templates that use pointers.

 

2) What does this line in OnSetRenderInfo do? This question is probably due to some ignorance of C# I have.

It is used to perform any setup that the filter may require before Render is called.

The FurBlur source code in this post uses it to render the effect to a second surface which avoids the ROI problems with Render being called multiple times.

Share this post


Link to post
Share on other sites

Expanding on the Unsafe keyword;

Pointers can read past your virtual screen bounds (or whatever) into memory used for other stuff. If you start writing into these locations things are going to break quickly.

The Unsafe keyword let's you know you're close-to-the-edge and should be very careful. It is also an acknowledgement that you understand the risks ;)

Share this post


Link to post
Share on other sites

It is used to perform any setup that the filter may require before Render is called.

The FurBlur source code in this post uses it to render the effect to a second surface which avoids the ROI problems with Render being called multiple times.

I appreciate you taking the time to respond, but I already know what OnSetRenderInfo is used for as a whole. I specifically would like to know what the following line does.

base.OnSetRenderInfo(newToken, dstArgs, srcArgs);

Here it is in context.

protected override void OnSetRenderInfo(PropertyBasedEffectConfigToken newToken, RenderArgs dstArgs, RenderArgs srcArgs)
{
    Amount1 = newToken.GetProperty<DoubleProperty>(PropertyNames.Amount1).Value;

    base.OnSetRenderInfo(newToken, dstArgs, srcArgs);
}

Share this post


Link to post
Share on other sites

Whenever you override a base class function, it is a good idea to call the origional function you are overriding. That way, whatever your code is doing will be in addition to what was designed in the base class.

I'm not exactly sure what the base class is doing here, it could be nothing.

Share this post


Link to post
Share on other sites

Whenever you override a base class function, it is a good idea to call the original function you are overriding. That way, whatever your code is doing will be in addition to what was designed in the base class.

 

Ah, that makes sense. Thank you.

 

I'm not exactly sure what the base class is doing here, it could be nothing.

 

That is my suspension as well, because I removed that line of code and everything in my effect still worked. I'll leave it in though, just in case.

Share this post


Link to post
Share on other sites

A while ago I said:

 

I have a suggestion. I think the double-vector position control should be changed to three decimal places instead of the current two. As it is, there are only 200 or so possible values, which means for most reasonable window sizes, the position cannot be placed within a pixel. Even with three decimal places, positioning for large windows wouldn't be within a  single pixel, but at least it would usually be fine enough to be useful. I didn't use the position control in my Texture Shader plugin for that very reason.

 

I discovered this can be done by the following call:

configUI.SetPropertyControlValue(PropertyNames.Amount1, ControlInfoPropertyNames.DecimalPlaces, 3);

Great idea. I think the next rev of CodeLab will automatically put this in for all Double Vector controls.

Now, the question is, should I put this in for all floating point controls, like the decimal slider and roll control.

Share this post


Link to post
Share on other sites

That's a hard question. Because the Double Vector pretty much always represents the image range as -1 to 1, three places (or even four) makes sense. The Double Slider can represent lots of things, with lots of different ranges. If the range is 0 to 1000, it seldom makes sense to have three places of precision, and using the up-down control becomes more difficult for small adjustments, because the steps are too small. But many times when the range is 0 to 1, I wish I had more precision. I suppose the precision could depend on the range, with enough precision to ensure at least a thousand steps. What I'd really like -- though it might be difficult to implement -- is the ability to specify the precision, perhaps be adding control names like DoubleSliderControl1, DoubleSliderControl2, DoubleSliderControl3, where the digit would specify the number of places, with DoubleSliderControl having the default precision. That might present problems for the UI Designer, adding some ugliness of a bunch of extra controls, or requiring a new field for the decimal place specification. Because the smallest range of the roll controls is 0-90, allowing 9001 steps for two decimal places, I don't think it probably needs three places.
 
EDIT: I think the up-down increments for the roll control are too large. Currently, each click increments or decrements by 1. For Double Sliders, it's 0.01. I determined that the increments can be set by:

 configUI.SetPropertyControlValue(PropertyNames.Roll, ControlInfoPropertyNames.UpDownIncrementX, 0.01);
 configUI.SetPropertyControlValue(PropertyNames.Roll, ControlInfoPropertyNames.UpDownIncrementY, 0.05);
 configUI.SetPropertyControlValue(PropertyNames.Roll, ControlInfoPropertyNames.UpDownIncrementZ, 0.10);

That was just a test to try the three different increments. An increment of 0.01 for all three seems best to me.

Edited by MJW

Share this post


Link to post
Share on other sites

I don't see the need for a slider to have that level of precision...

 

I added a third decimal place onto the Scale control of my Jigsaw Puzzle plugin, and it made a significant difference.

Edited by toe_head2001

Share this post


Link to post
Share on other sites

I agree with toe_head2001. Many times for scale and shift type controls, two places isn't enough to make a singe-step change nearly imperceptible, which it needs to be for the user to achieve a particular result.

Share this post


Link to post
Share on other sites

Here is my proposal:

DoubleVector control, always add 3 decimal places

AngleControl, always add 3 decimal places

DoubleSlider control, if the upper bounds is < 1000 add 3 decimal places

RollControl, always add 3 decimal places and adjust the steps (posted above)

OK?

Share this post


Link to post
Share on other sites

Here is my proposal:

DoubleVector control, always add 3 decimal places

AngleControl, always add 3 decimal places

DoubleSlider control, if the upper bounds is < 1000 add 3 decimal places

RollControl, always add 3 decimal places and adjust the steps (posted above)

OK?

The angle control wouldn't take the 3 decimal places. Could this be a bug in paint.net? Only Rick knows for sure. ;)

Share this post


Link to post
Share on other sites

The UpDown increment also doesn't seem to work. I actually think 2 places is enough for both the Angle Chooser and the Roll control. One hundredth of a degree is pretty small. I wish the UpDown increment could be made smaller. The only way to enter more exact angles is either hit or miss with the slider or typing it in.

 

One thing that bugs me about all the controls is how they use (or don't use), the small and large slider increment value. I would think moving the slider should only change the control value in multiples of those values, so if one is 0.05 and the other is 0.25, all the slider movements would change the value by multiples of 0.05. Instead, the sliders seem to change the values in a rather haphazard way, which makes positioning to even values more difficult.

Share this post


Link to post
Share on other sites

CodeLab 2.10 Released

This is only for Paint.NET 4.0.6+!

Changes:

▪ Double Vector control, Double Slider control, and Roll control now have 3 decimal places of precision

▪ New options added to File > New template screen

▪ Scripts can now specify the version number:

// Version: 3.14

or

// Version: 3,14

 

 

Grab the CodeLab DLL here:

http://www.boltbait.com/pdn/CodeLab/

  • Upvote 3

Share this post


Link to post
Share on other sites

I was playing with ScintillaNET this morning, and decided to try using it in CodeLab for fun. BoltBait, you should look into this. It's highly configurable. It's like having Notepad++ (which uses Scintilla) inside CodeLab.

 

Although the IntelliSense stuff might be difficult, but I didn't look at how it's currently being done in CodeLab, so maybe not difficult to integrate the current implementation into the Scintilla control...

Edit: I took a look at the code for the custom IntelliSense, and I don't see why it wouldn't work.

 

Advantages over using a RichTextBox:

-Code folding

-Show white space

-Line numbers (adjusted for the hidden prepended lines of code?)

-Undo!

-Word wrap

-Autocomplete (things not covered by the IntelliSense)

-Current Line indicator

-all the other features that Scintilla has

-Discard all the code hacks to get RichTextBox working as a code editor
 
scintilla.png

Edited by toe_head2001
  • Upvote 3

Share this post


Link to post
Share on other sites

Bug: If you make a change to the script, then click OK before CodeLab rebuilds the effect, the change will not be applied.

(Yeah, yeah, "just wait the 3 seconds, pyro")

Share this post


Link to post
Share on other sites

CodeLab 2.11 Released

This is only for Paint.NET 4.0.9+!

Changes:

▪ Bug fixes

▪ "Hack" font added to supported fonts list. Download Hack Font.

▪ toe_head2001 replaced the RTF editor control with the ScintillaNET editor component.

This is awesome because it is basically the same editor you'd find in Notepad++. All of the silly patches I had to put in to make an RTF control work for syntax highlighting have been removed.

We now have proper unlimited UNDO and REDO commands in the editor. The editor now includes lots of other features of Notepad++ including brace matching, block folding, show white space, word wrap, and current line highlighting.

 

 

Grab the CodeLab DLL here:

http://www.boltbait.com/pdn/CodeLab/

  • Upvote 7

Share this post


Link to post
Share on other sites

Trying to build to DLL always gives me the error message:

---------------------------

Build Error

---------------------------

Before you can save as a DLL you must first save your source file using the File > Save as... menu.

---------------------------

OK

---------------------------

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.