Render method, rect argument

[Pantaleao]

When looking at the following, at Render method (loop excerpt from codelab):

void Render(Surface dst, Surface src, Rectangle rect)
{
   for(int y = rect.Top; y < rect.Bottom; y++)
   {
       ...

       for (int x = rect.Left; x < rect.Right; x++)
       {
           ...
       }
   }
}

I see that both right and bottom sides of the area (rect) are excluded from processing; is there a reason for that? Aren't those sides representing valid points for processing? Any tips will be very appreciated!

[Toli]

No. They aren't.

Arithmetic (2nd grade): between a and b, there are b - a - 1 numbers (positions), excluding them, or b - a + 1 numbers (positions) including them. But the rectangle has b - a positions, so we have to exclude one side.

[Pantaleao]

No. They aren't.

Arithmetic (2nd grade): between a and b, there are b - a - 1 numbers (positions), excluding them, or b - a + 1 numbers (positions) including them. But the rectangle has b - a positions, so we have to exclude one side.

LOL Teacher, you missed the point completely! Rest assured I'm far beyond 2nd grade... FYI I'm a Senior R&D Systems/Software Engineer and Systems Architect, besides creating Process Control & Industrial Automation systems-related HMI's for a living!* LOL

Ok, let me tell (not teach ) you this:

It all depends on the underlying platform (many conditions apply...) and also on the underlying framework, among many, many other things, ok?

My simple question remains... so any other useful tips will still be very appreciated!

* Toli, next time less attitude, will you? I tend to react badly to such things... :twisted:

[BoltBait]

It seems to me that you could run a little test and learn the answer yourself.

Use the default CodeLab code and set all the pixels to black (primary color) by uncommenting a few lines.

Are all pixels black at the end of the test? Yes? Then, the code is correct.

[Andrew D]

No. They aren't.

Arithmetic (2nd grade): between a and b, there are b - a - 1 numbers (positions), excluding them, or b - a + 1 numbers (positions) including them. But the rectangle has b - a positions, so we have to exclude one side.

LOL Teacher, you missed the point completely! Rest assured I'm far beyond 2nd grade... FYI I'm a Senior R&D Systems/Software Engineer and Systems Architect, besides creating Process Control & Industrial Automation systems-related HMI's for a living!* LOL

Ok, let me tell (not teach ) you this:

It all depends on the underlying platform (many conditions apply...) and also on the underlying framework, among many, many other things, ok?

My simple question remains... so any other useful tips will still be very appreciated!

* Toli, next time less attitude, will you? I tend to react badly to such things... :twisted:

Great. Professor vs. Senior R&D Systems/Software Engineer and Systems Architect

[Toli]

Sorry about the tone.

Anyway it is correct. x = rect.Right or y = rect.Bottom do not yield to anything. I tried for myself.

[Pantaleao]

It seems to me that you could run a little test and learn the answer yourself.

Use the default CodeLab code and set all the pixels to black (primary color) by uncommenting a few lines.

Are all pixels black at the end of the test? Yes? Then, the code is correct.

Thanks, BoltBait! I'm not questioning the correctness of the code - I know it's correct! -, but just trying to figure out some details of the "intimacy" of PdN, so to speak! Not if, but why... (in this case: any special PdN reason or just the Win-post-98 API...)

I'm already playing with CodeLab and stuff, trying to learn by example (your material is great for this!) and the tutorials are great too, but I'm facing the 'lack of documentation syndrome' in relation to the effects API. Could you give me some pointers? I'm sort of eager to learn from the sources (not just the math involved in image manipulation - there are lots of sources for this - but mainly the public APIs from PdN), so that I can see the 'big picture'. Believe me, I'm a developer that actually reads the documentation and suffers from the lack of it! :shock:

Can you guide me through these first steps, pretty please?

Great. Professor vs. Senior R&D Systems/Software Engineer and Systems Architect

Indeed!! (and I didn't mention that I'm also a Project Manager and Architecture Team Leader...)

Lets see if we've reached a gentleman's agreement from now on...

@all: guys, I'm here to learn, ok? Let's forget all this gibberish about titles and all... here, I'm just a plain n00b! Any help is totally appreciated!!

Panta.

[BoltBait]

The only documentation that exists is the code for Paint.NET that you can download yourself and look at.

http://www.getpaint.net/download.html#src

Other than that, your best resource is the various tutorials that have been written:

viewtopic.php?t=5281
viewtopic.php?t=5308
viewtopic.php?t=6405

I learn best from code examples. For those, just read every thread in the Plugin forum. Many of the plugin authors publish their source code (myself included).

http://boltbait.com/pdn

[Pantaleao]

The only documentation that exists is the code for Paint.NET that you can download yourself and look at.

http://www.getpaint.net/download.html#src

*sigh* I was afraid you'd say that... OK! Let's dig then...

Other than that, your best resource is the various tutorials that have been written:

viewtopic.php?t=5281
viewtopic.php?t=5308
viewtopic.php?t=6405

I'm already carefully looking at them... great resources!!

I learn best from code examples. For those, just read every thread in the Plugin forum. Many of the plugin authors publish their source code (myself included).

http://boltbait.com/pdn

Sure, will work somehow; I'm devouring each entry there! It's just that I'm used to the documentation guidance... I'm even thinking about reverse-engineering PdN's architecture model! (Together, Rose, anyone?) :wink:

@BoltBait: dude, thanks for your time and invaluable help allover! 8)

@Rick: is there any PdN exportable class diagram model (e.g.: html, etc) that could be referenced?

[Rick Brewster]

Yes, there's a reason for this. It makes it much simpler to implement rendering code, especially if you go and start doing anti-aliasing. Think of these not as integer pixel columns and rows that you are specifying you want filled, but as a lattice points where the Left property of a rectangle states, "the rendering starts at this lattice line" and the Right property of the rectangle states, "rendering goes up to the very edge of this lattice line".

  0   1   2   3
0 +---+---+---+
 |   |   |   |
1 +---+---+---+
 |   |   |   |
2 +---+---+---+
 |   |   |   |
3 +---+---+---+

For this, the width and height are both 3. However, there is no physical pixel row or column 3. A rectangle that fills the whole area is defined as {Left = 0, Top = 0, Width = 3, Height = 3} with the implicitly defined properties {Right = 3, Bottom = 3}.

It especially makes more sense if you consider how things work for floating point pixel coordinates. It's much easier to write renderers and do logic and mathematics based on saying "render up to but not including pixel column 10.000000" than to say "render up to and including pixel column 9.999999". Because then, mathematically speaking, you still have a gap there.

[Pantaleao]

Yes, there's a reason for this...

That's it! It's perfectly clear for me now. Thanks Rick for this concise and yet precise answer. By the way, I'm just thrilled to be able to dig into PdN! What an amazing software project... I'd like to learn much more about it and with a great emphasis in it's architecture, design patterns being used, etc. So, I'm starting!

Once more, thanks and congratulations for this project!!

ps: regarding those diagrams I've mentioned, do you have anything to 'feed' me? (or documentation, for that matter...) :oops: