Re: New directions with much less objectives (Was Re: Comments?)

[Adrian Ratnapala <s369625@student.uq.edu.au>]

Peter Breitling writes:
 > Adrian Ratnapala wrote:
 > >  > Basic object functionality: All non-primitive classes are derived from
 > >  > one main class that has reference counter (how often is this class
 > >  > referenced), a 'instanceOf' method for safe casting etc...
 > > Well, we have a base class, which does absolutely nothing when
 > > debugging.  There was also a class derived from that which did
 > > reference counting, but I got rid of that because I decided
 > > it was evil.

 > 
 > Why is that evil? I use the reference method and had only positive
 > experience. I got to know this idea when i was programming Open Inventor
 > ... This system is also used in DirectX (Integral part of COM).

Reference counts aren't evil, sorry I said so. I just didn't the
way I was using them, I found I was using them to cover up for a
sloppy design (not having enough of an idea of what owned what).
I didn't actually delete the reference count based classes, so others
can use it if they wish.

I thought of switching to auto_ptr<>, since that kind of thing
is more to my taste, but I balked because I am not sure if the
auto_ptr<> on GNU systems is standard, so for now I am doing
my own garbage collection, nothing is complicated yet so it
hasn't caused a problem.

 > 
 > > Working on this.  I'm doing the lowlevel stuff now.  We need a
 > > seperate but realted graphics-file component.
 > 
 > You are doing lowlevel stuff? But what interfaces/classes exactly are
 > you implementing?

You've uncovered one huge problem with the project.  The website
currently sucks.  Its out of date, badly.  I shan't be writing a
full interface description in this message, but basically the
functionality I am implementing now is what lets you draw things
to other things:  Three main classes

        ppgSurface: dumb plain-old-data type which just _describes_ an
                    object to draw to.  Surfaces may be rectangles
                    on the screen, or they may be memory buffers or
                    draw lists, or anything.

        ppgGC:      (graphics context) smart object containing state
                    info, most importantly, it provides a nice OO
                    interface to a table of function pointers to
                    the primitives which actually draw into surfaces.

        ppgDevice:  Abstraction of the underlying device which we are
                    drawing into.  This contains (indirectly) all our
                    videomode/pixel format info, as well as a handle
                    to the underlying graphics subsystem.
  

 > 
 > So you say GGI is the graphics API?
 >
No sorry, I didn't make this clear, GGI is not our
graphics API.  The PPlay graphics API runs on top
of GGI, this automatically gives us a lot of graphics
platforms, without us (me) having to do the work.
No user code need even mention the GGI.

I agree with you concerns about relying on one underlying
API.  This is why pg2d is designed to run on top of
anything, once apon a time it had an Xlib target, another
one could be written, as could a raw hardware target
or whatever.  I don't think it will be necessary though.


>Can you use OpenGL and GGI together?
Yes.  Mesa once even had a GGI target in its main distribution, but
that is badly outdated. 

> Is GGI working in Windows?
Yes. I don't know the status of the port, but the GGI people
are working on it.  I know that months agoo they were at the point
where their demos work when displayed on a windows X server,
and I think they have DirectX support too.

They will probably be on Windows before us.  If not, or even
if they are, pg2d is designed to make it easy(ish)
to write a DirectX target.

> Will it be ported to others OS's like
> Be?
I would assume so, however if not we could write appropriate
PPlay targets, or maybe we could port the GGI.


 > 
 > Another thing is the input libary which is also dependend on the GUI
 > library that is used. I would prefer defining inputs for 'active'
 > graphic displays which more reflects the practice ...
Hmmm, I'm afraid I don't quite understand what you mean.  Could
you please elaborate.

> 
 > Well i don't see any implementation lacks in this project but i am
 > missing a clear framework and system design. I won't start implementing
 > special things when i don't see the overall structure of that
project.

Here I have to reiterate what Christian said, much of the reason
you don't see the overall structure is because we haven't documented /
published it properly.

Another reason is because the project is intentionally very loosely
knit, there isn't supposed to be much by way of "overall structure".


Thirdly, there are real problems, the different sub projects haven't
standardized nearly as much as I would like, but I think this is
improving (what is in CVS is pretty consistent, but it needs some more work)


Finally we haven't reach the level where the overall structure is
apparent in the implementation.  For example, I'm doing graphics,
Warewolf and Edheldil are working on the file stuff, but since
I am not yet working on graphics files, there is not much connection.
We do have a plan of how to fit this together
    http://sunsite.auc.dk/penguinplay/PenguinDoc/general.html
which we are working to, but that plan is ancient and incomplete, I'm
pretty sure it that it is still valid in general terms, but I will
agree with you that with the focus now on implementation, I at least have not
being watching out for this issue much.

I think it would be really good if someone like you could help us
keep such plans and the corresponding documents up to date and comlete.

 > 
 > For the graphics part you wrote down some class definitions. However the
 > web documentation of the classes at moment contain broken links. Thus i
 > can not see the methods and the class-hierarchy.
Sorry, I have to attend to my corner of the web site.  I haven't touched
it in months.  By the class heirarchy and methods, I think you are
referring to the autogenerated documentation we used to have, but
which has now rotted.  I'll have to resurrect this.

 > 
 > Why not going the top-to-down method by first defining the functionality
 > and then implementing as necessary? If we would have a working prototype
 > of a nice and consistent interface _then_ implementations will follow
 > much faster...
Again I think there is a failiure of communication.  We have been
through a top-down design process.  However, there are many holes
and incompletely specified pieces to it.  This is where I suppose
you come in.  

 > 
 > I would say a detailed specification of the complete framework would be
 > half of the overall work. Lets start the implementation
_afterwards_!

PPlay is acutally quite an old project, and has moved at a snails
pace, largely due to huge long arguements about design etc.  I am
glad to say we got out of that phase a few months ago, and got
to the point where, in some areas, we were able to actually write
code and detailed designs  in some areas (File, 2d graphics and the
GUI).  While being reasonably confident that these areas were sufficiently
orthogonal to the more murky areas.

We still need to properly specifiy/design the other areas though.