Simple and working line drawing effect (using CodeLab)

[zarathoustra]

"Your code is ugly, slow, and generally sucky."

"No, your code is ugly, slow, and makes puppies sad."

Shut up. Both of you.

lol

Besides, if externally changing Paint.NET's window title via a method that was designed to do exactly this sort of thing affects the program's operation in any way whatsoever, then your code just sucks.

Telling me that my code sucks is immature and unprofessional, pyrochild. Lose the attitude.

[oma]

Almost everything in this forum contains no plugin: you're in the wrong forum for that. If you don't know what is CodeLab or what is the PaintDotNet API, look elsewhere. There's absolutely nothing complicate here to understand what it is about.

actually I do know what codelab is. I may not be a rocket scientist computor programing geek, and for not having much formal schooling I'm still fairly intelligent. So please try not to talk down to me. I'm just trying to understand what you are getting at.

As for trusting you come in here all puffy "I know better attitude" in your first post not a nice way to make a point. Your arguments and examples are something I would study, but I'm not sure the method of your passing on your knowledge is remotely polite. lets just say you need to work on your "bedside manner"

We are not morons, some of us know more than others in some fields, you may just happen to know more than me in codelab. That doesn't make you superior to me. I'm just trying to learn more everyday. Life is too short to go thru it not seeking new knowledge. It just happens to be more pleasant to learn from somepeople over others.

ciao OMA .

PS I started following this post when you were not in the plugin development umberalla and it was in Creations tutorial and I flagged it then to look at further. ......?

[zarathoustra]

Status of closing this thread ?

[pyrochild]

Status of closing this thread ?

It doesn't need to be closed, as long as the arguing stays to a minimum

[oma]

I don't think it needs to be closed. I just am a little bit slower at grasping some of these things. Its easier when you are younger and have peers and mentors to help you thru these types of learning long posts. Its far outside my comfort zone but I'm trying to expand my computor abilities. Learning a bit about code lab programing just adds to my enjoyment of paint.net/

myself I'm more of a hands on type person. I learn quicker by say something like :

this dll doesn't use these principals and working with it then working with a dll that does have some of the changes verdy listed.

as in any art quality versus speed almost all the time. I'd like the opportunity to judge if one dll using these methods is better in comparison to one without. That's all.

ciao OMA

[verdy_p]

Status of closing this thread ?

If you close this thread, I will not post an antialiasing version of this fast renderer (I have one, but it is tuned differently, for filling polycurves, including various splines, including Bezier of second and third degree and NURBS, and including non convex areas or areas with holes using the even/odd filling rule, as in SVG; it also supports 3D with orthoptic or perspective projections, and it can fill with bitmap brushes; however it still does not support MIPMAPs, and it is NOT a full 3D engine as it does not use z-buffers, and does not compute hidden surfaces, and performs no animation, which is done elsewhere on top of the renderer, with much more complex code or that can use hardware vertex shaders for computing the geometry).

[initially my code was written in Java (posting this code to C# or J# for DotNet is trivial), because both Java2D/Java3D and GDI/GDI+/DirectDraw/Direct3D lack some graphic primitives (for common shapes) and both don't have a good enough precision (or have too limited numeric ranges), and they do cause problems when rendering, for example, very complex vector graphics (such as high precision SVG geographic maps, or CAD models), or mathematical functions (too many approximations produce completely wrong images).]

Antialising is another unrelated problem: any non-antialiasing rendering engine can be used to create antialiased images: this is a basic transform, which can be optimized only to avoid unneeded works when the fill colors (or brushes) are plain, but when using complex brushes such as scaled bitmaps or computed shades, you have no other choice than fully rendering the image at higher resolution, possibly working in small bands to reduce the memory used for the intermediate high-resolution image, and then rescaling it to the final resolution (including the alpha plane). So you'll still need to use a very fast non-antiliasing renderer (as fast as possible) to render the intermediate image which is MUCH bigger than your final display resolution (a good and precise antialiaser for imagery applications will use intermediate images that are 256 times bigger, i.e. 16 times in each dimension, for all color/alpha planes; popular antialiasers only support 4x4 or 8x8 subsampling, because they are too slow or too CPU intensive to compute the intermediate image, exactly because their non-antiliasing engine is not fast enough, or is underoptimized, or uses too many external memory ressources).

[oma]

he's not a mod, only ones that can close a thread are mods.

I'd be interested, like I say I'm always trying to learn. I know I'll never be a pro at programing or using codelab, but I'm always interested in how anothers minds works in their strong areas.

ciao OMA

[Ego Eram Reputo]

Needless to say we Mods are watching this thread closely and it will be closed if necessary. So behave :!:

Note: Anyone caught making puppies sad will be dealt with in severe terms

On with the discussion...,

[pyrochild]

Despite the near-constant minor bickering in this thread, I do find the information contained herein to be useful and interesting, so let's keep the puppies happy.

[verdy_p]

For those that were ennoyed to always see the too long source code, I've hidden it by default. You need to unroll it now. This can help browsing between messages.

Anyway, I've fixed also minor details in the source, notably after publishing the fully inlined version of the fast line() routine, when I saw that the early version, despite correct, did not use the usual rounding mode: when two candidate pixels at equal distance from the theoretical line, the one which was chosen was not always chosen as the one with the highest coordinate, i.e. always the one at the bottom or left here (this rounding rule generally used in most 3D renderers, as it is also coherent with the binary rounding mode when using floatting points coordinates): the early code was still correct (lines were also drawn with the same pixels, independantly of the direction of drawing) but it used another rounding rule in one symetric pair of octants.

Some 2D/3D engines however may use the another floating-point rounding mode, such as the IEEE's recommended mode (rounding half-integers to their nearest even integer); this is not used here as it would complicate the test to perform when e==0; but this rounding mode is typically used when rendering mathematical objects or statistics (as it better distributes and balances the quantization errors).

But if you use this fast renderer to build a antialiasing renderer, you won't notice any visible difference, as it will just have a extremely small impact on the overal quantization error, and only within small differences of the alpha channel, and only on very few positions in the final image where the theoretical diagonal lines will pass through the exact middle between quantized pixel centers.

This IEEE rounding mode is generally not chosen in 2D images as it will show some "granularity" (in 4x4 pixels square cells) of frequently used lines such as those with exact slope 1/2 or 2 (but this granularity will be invisible when using it to produce antialiased images). It may be used when the image is in fact the quantization of an analog signal: this rounding mode may enhance a little (i.e. increase) the signal/noise ratio (the effect is a bit less than 1dB in the worst case) by allowing more precise reconstruction of the analog signal's amplitude (it may be used for example to feed a JPEG/MPEG image compressor with less data losses and with a slightly better compression rates and with a slightly higher dynamic and precision of contrasts).