gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] 9th (asko)


From: Tuomas Lukka
Subject: Re: [Gzz] 9th (asko)
Date: Mon, 14 Oct 2002 09:07:12 +0300
User-agent: Mutt/1.4i

On Fri, Oct 11, 2002 at 09:13:58PM +0300, Asko Soukka wrote:
> Benja Fallenstein wrote:
> > Changes from 0.6: A terrible lot ;-)
> 
> Indeed.
> 
> > Your mind* views would be cool (and also, in related news, the
> > ball-and-stick cell view). If you do re-implement them, please consider
> 
> Re-implementing mind* views means really complete rewriting. I want to
> combine them into single class using the same single recursive routine. Then
> I have to solve some problems occurred in the earlier versions (discussed
> below). In my 0.6 ball-and-stick cell view is not actually "stick" anymore,
> because of mine and Tuukka's line breaking hack :-) 

> For ball-and-stick we
> need also new circular vob (for the ball). Is RoundBgVob ok? 

Fine for now. For implementing this with OpenGL, the simplest way is to use a
texture for the circular shape (alpha=0 outside, alpha=1, color=black at edge,
alpha=1, color=1 at inside) and then color it with glColor.

> Actually, I was
> going to implement it already on Thursday, but then I got confused should I
> make a new Circle shape class to handle it's data (and from where to inherit
> it) or use Java's Rectangle or Ellipse2D.

Why is a class needed? This should probably just be a single Vob without
any data, where the circle is drawn inside the (0,1)x(0,1) rectangle.

> > following Ted's rule that interpretation of a corner list should stop
> > when another "left" connection is encountered:
> 
> When I did those views I "knew" the corner list structure, but didn't
> understand why it should have been interpeted like that. I hope I do now and
> try to follow that rule in the future.
> 
> There are also other problems in my old views, especially in the later
> MindSun one. In the main circle's substructures (curves or something) cells
> are not shown in their original order (from top to bottom), but the first
> cell is in the middle, the first half of cells are next to it and the latest
> half is shown before it. That only because transforming the curve into
> circle looks then nicer O:-)
> 
> Also support for d.3 in both views is so artificial that I'll probably drop
> it until better ideas. And what about long ranks? Mind views tried to show
> as much as possible (finally limits were hard coded to avoid crashing with
> history ranks in 0.6 :) AFAIK in 0.8 I need to start with building own
> raster, which solves these range problems ...

Would it make sense, before implementing, writing a PEG about these?
That way, everyone would get to comment before the hard code is written?

For diagrams, just sketch on paper and scan (we have a scanner exactly
for this purpose)

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]