Re: 16-bit versions of gnuplot doomed?

[Hans-Bernhard B. <br...@ph...>]

On Wed, 25 Feb 2004, Daniel J Sebald wrote:

[PM3D stuff doesn't go through the 2D parts of gnuplot]

> In some sense it does.  I mean, it may not be set up that way, and that 
> is why I say the two are diverging.  When it boils down to it, 3D is 
> still just drawing lines, filled polygons, colorbox key, etc. 

It's exactly the filled polygons that don't really use any 2D stuff.

The rest of the plot (largely) doesn't care whether a given dataset is
output as pm3d, lines or points, but the actual surface plotting, where
the real work is, does.  Note that the core data structure you pass
to term->filled_polygon takes an at least optionally 3D data point for
input: struct gpiPoint.

> give the illusion of 3D.  Do you agree with that?  

As long as we don't add an actual 3D terminal driver (OpenGL, VRML
or whatever), yes.  But that's not something we have to worry about now.

> >>It should be just the core routines for graphics and then maybe a
> >>"graph2D.c" and "graph3D.c".  If a major change is made to graphics.c
> >>right now it will undoubtedly mess up some of the patches currently on
> >>SF.  

Well, the "core routines" are actually in term.c and the drivers, not in
graphics.c.  The current graphics.c is esentially just that graph2D.c
you're talking of.  It contains exactly those things that are specific to
2D plotting: the implementations of 'with <style>' for 2D, and the 2D
graph area positioning stuff, particularly the rather monstrous function
boundary().

A more natural split of graphics.c could therefore be along those lines.
I.e. it might make sense to split out boundary() and its helpers into a
new module layout2d.c.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.