On Mon, 04 June 2001, Shane Nay wrote:
>
> On Sunday 03 June 2001 17:57, Micah Dowty wrote:
> > hmm. Good question :)
> >
> > I thought about it a little, and I see a few ways it might be done:
> >
> > - The arguments could be passed in the same way other primitives get their
> > parameters, via gropnode parameters. This would be unworkable though,
> > because currently there is a limit of 3 parameters. This could be
> > increased, but it would increase memory usage for every gropnode! Maybe
> > there's a better way to pass parameters in general?
> >
> > - Create an object with a handle, like the bitmaps, and use separate
> > functions to add points to a list referenced by this handle. It would work,
> > but could be cumbersome/slow if the polygons are changed frequently.
> >
> > - Have three 'primitives', BeginPolygon, EndPolygon, and PolyVertex. I
> > think this is a bit like how OpenGL defines polygons, so it might be good
> > to research that some. (I'm not an OpenGL programmer, but I have a friend
> > that is) BeginPolygon clears the internal list of vertices, PolyVertex adds
> > a vertex to this temporary list, and EndPolygon actually draws it.
>
> Okay, I'm having a micro problem with my implementation of these mechanics.
> Since I'm passing them in directly, the coordinate spaces are not being
> translated. I think that's the only major issue, otherwise polygons are
> pretty much done. (Well, there is this one other thing that's bugging me, a
> vertex edge condition..., but it's hardly noticable, and in order to fix it
> adds a ton of code/computation for really one pixel, hrmm, I guess I'll fix
> it anyhow) So what functions are used to translate the coordinate space
> before calling the draw routines?
>
> 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
