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

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

 > 
 > On the other hand for the gamewriter it can be confusing what library to
 > use. A game written with a collection of libraries is depend of the
 > support for each of them. Incompatibilities and linking problems are
 > difficult to foresee for every kind of combination. And the portability
 > is defined by the subset of libraries used or different combination have
 > to be used on different platforms. Common case: library A is running on
 > system 'Sa' and 'Sb' but library B is working only with 'Sa' but library
 > C can replace B on system 'Sb' but won't work with 'Sa' (but also needs
 > some rewrite of the game cause of a slightly different
functionality).
Thisi s true.  This is why, if a complete set of pplay components are
available, they would provide developers with a clean set of "headache
free" tools (pplay-in-a-can).


What you are listing here is very, very, similar to PPlay goals.

 > 
 > The functionality is defined for:
 > 
 > 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.

 > 
 > Message system: use Observer/Observable pattern. Or slots like in qt.
 >
Yep.  In fact we have something a bit better than qt, more like gtk--,
which can do everything Qt can do + multicasting.

 > Time: Get fine granular (at least 10ms) system timer and countdowns
 > message system.
 >
Correct.  In fact we do a bit more, we have (plans and a long dead
prototype for ) a low level system with a C interface for getting
basic events such as system signals, alarms, async I/O.  When I
designed this thing, I found that threading came into this part
as well.

 > Network: Basic network functionality. TCP/UDP. Let's look at
zombie.
I have no idea what is going an with networking.

 > 
 > Sound: Basic sound output. Later: Dolby surround, 3D sound etc. IO
 > support for wav-files.
 >
Again no Idea.

 > Graphics: basic pixel operations / Graphics output. Support for
 > 8/16/24/32 bpp at any resolution. IO support for gif (input), jpeg (IO),
 > bitmap (IO) and more to follow.
Working on this.  I'm doing the lowlevel stuff now.  We need a
seperate but realted graphics-file component.

 > 
 > Input: Support for joystick, keyboard, mouse ...
 >
Someone was working on that.  But there is no code in CVS,  and
I am not happy.

 > Resources: Provide a resource control like the registry under Windows or
 > the Xresources under X11 to access global and local (system specific)
 > settings and data.
When we no what resources we have, we will have to design a
configuration sytem like this.   I have no idea what it will
contain.

 > 
 > Be compatible to and maybe partly use following libs:
 > 
 > Threads: posix-threads
Definately.

 > GUI: QT and Tcl/Tk
This is an issue only for the graphics API and that is working
on top of GGI.  The code is modular enough to let other targets
be added, but I have no plans for this, and I wouldn't be thinking
of high level GUI orient systems like GT and Tcl/Tk.

 > 3D-Graphics: OpenGL
Definatly.


 > 
 > --
 > 
 > The implementation uses different libs on different systems and primary
 > the PP-libs. We could name this subproject of PP the
 > 'Penguin-Framework'. Is that ok?
 > 
 > I think i can use some design and implementation of PooG (Portable
 > Object-Orientated Game library) a former project of mine i was working
 > in my spare time for some years.
 > 
 > Are you willing to add a new subproject of PenguinPlay called
 > 'Penguin-Framework'? And to accept me as the coordinator and responsible
 > man of the Penguin-Framework project with all the aims described above?
 > 
 > Then i'll start writing header files and specifications! ;)

I don't mind, but first we would need some more discussion of exactly
what you will be doing.

 >   Die Breite an der Spitze ist dichter geworden. (Berti Vogts)

Ich glaube dass, waere das auf Englisch geschrieben, wuerde ich
es trotzdem nicht verstanden.