Hmm..., okay, I think I need to finish what I'm working on, you can take a
look at it, and see what needs to be done for the clipping and expansion
stuff to work. I'm going to finish and fix the pixel errors that I found,
and post the present work as something to think through, and how it fits in
the present organization, etc.
As far as cutting it up into triangles/trapezoids..., well, I'd prefer not to
:). Because then you're creating a potential O(N-2) for all rendering
subprocesses. (Each subprocess probably being up to a 2N problem iterated
along all y coordinates) Besides it's a bitch and a half to implement :)
(Not to mention I just deleted all that code..., damn, I'm going to regret
that I think) It could be done, but it would have to be cleverly written to
be fast, and it would inherently be larger in terms of code size.
So, I'll post my present way of solving the polygon tomorrow or later
tonight, and we can work through fitting that into the present rendering
architecture. (I don't think it's going to be that hard)
Thanks,
Shane Nay.
> All the code to translate coordinates and perform clipping is in render.c
> At line 122 the gropnode_map() function is called, to convert whatever
> coordinates the gropnodes are measured into to pixels. This is important
> for things like PG_MAP_SCALE automatic scaling for the canvas. Immediately
> after that, the divnode position and optional scrolling are added. Then the
> mapping offset is added. (This is a value that themes or apps can use to
> offset the coordinates by an amount in pixels while measuring the
> coordinates in arbitrary units)
>
> In general, this code assumes that the primitive is represented by an (x,y)
> coordinate, width, and height. Maybe the polygon code bypasses this? Maybe
> the BeginPolygon/EndPolygon/PolyVertex method is used? Then, each vertex
> would get its own pass through this rendering loop, so it could be
> translated and mapped very easily. Clipping could still be a challenge
> though. The clipping at each vertex's render pass would probably be
> bypassed in favor of doing the clipping at EndPolygon. This is probably the
> way to do it with the least modification to the rendering engine. Maybe
> another possibility is to decompose the polygon into triangles before it
> enters the rendering engine, make one gropnode per triangle? This
> simplifies clipping, but reduces flexibility.
>
> Or maybe the whole thing needs another overhaul ;-)
>
> By line 137, node.r is in screen coordinates. gropnode_clip
>
> --
> To the systems programmer, users and applications serve only to provide a
> test load.
>
>
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/pgui-devel
-------------------------------------------------------
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
