Okay, well, present polygon code is out there now. Now we can get to..., how
do we fit this into our present architecture I guess :).
> 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)
Okay, with polygon, we've basically added a new "type" of object into the
lexicon, one with a non-finite number of vertices. Clipping for these is
going to be a massive hassle, as is transformation to sizing. My idea would
be something like this...
Since we already have good handling for things that are rectangles, why don't
we let picogui's renderer think the polygon is a rectangle by creating a
"bounding box" around the polygon. Then we can clip the polygon based on
that bounding box. When we get to the polygon rendering code, it can see if
the clipping box is the same as the bounding box for it's shape, and if not
it will jump forward in it's scanline calculations to the point for the
requested clip rectangle, and terminate at the end of it's clip rectangle.
Also we'll need to have a scan of the vertices to adjust their location based
on the w's of the clip rectangle.
This requires that we pass a clip rectangle to the polygon code, which is
pretty a-okay with me. We should probably do the transformations for things
like PG_MAP_SCALE on it's vertices prior to drawing it. So we have to have a
special section of logic that deals with non-finite number of vertice objects.
> 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
Yep, I looked at the clip code and the expansion code. Handling expansion
like PG_MAP_SCALE shouldn't be hard at all. Writing the modifications to
polygon to allow for clips is going to be a massive pain the behind, but it's
totally doable. I'll just adjust the vertices on first pass prior to
computing scanlines. (Which will take some mult/div I think)
I really don't see a major reason to re-write the whole 2D rendering model.
I have been spending some cycles thinking about doing a couple things though
that would require some changes possibly..., here's what would be really cool:
Being able to put normal widgets on top of canvases at distinct locations
would be nice. I don't think that doing this would be totally horrible...,
we just put them last in the rendering cycle with finite sizes. Events would
be a tiny bit tricky, but I don't think they'd be horrible.
Another thing I've been sort of pondering over lately is a basic 3D rendering
system. It doesn't fit in well at all with our present system, and would
basically have to live outside of the whole gropnode thing, I mean, the 3D
canvas would be a grop, and it would have registered components that live
inside of itself that is totally seperate from the 2D engine. The 2D engine
could tell it to redraw some rectangle within itself or something like that,
and it would do some ray-casting to re-draw those pixels. Anyway, I might
start mucking about with a 3D canvas. I'm going to take the same approach to
the 3D code as I have with all the 2D stuff I've done so far..., and try to
keep it real tiny and fast. (Though obviously this falls into the category
of an option when building the server :) Don't expect to see any code for
this anytime soon though..., I'm still trying to lay it out in my head.
Either that or I'll work on some 2D animation stuff, not sure.
Anyway, I'd like to finish up the polygon code first though, so Micah after
you take a peek at what I've done so far with the Polygon, and read the top
couple paragraphs talking about clipping and expanding vertices, let me know
which direction you want to take. We can split the work between us in some
way if you'd like. (I'm starting a new job on Friday though, so I will
likely have less spare cycles to work on this stuff I think, but hey, it's
just 40 and I'm usually at it 80)
What I would like is if you would do the vertice manipulation, and
rectangular clip and hand that in to the polygon drawing function. Then I
will implement clipping within the polygon drawing function. I've looked at
breaking up the polygon to triangles and it's a pretty slow process, so I
think our present tact would be faster. (After I look at the clipping a
rectangle against a polygon in a scanline method for polygon drawing, I might
change my tune..., but I really don't think it will be all that bad)
Thanks,
Shane Nay.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
