From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Mon, 3 Aug 1998 21:38:57 +0200 (MEST)

Re: PenguinPlay IRC meeting. GGI developers wanted.

HI (Mailing list seems flakey - so I CC to you directly).

> As some of you might know there is a project called PenguinPlay which
> aims at creating a free games (and incidentally multimedia) development 
> library, similar in scope to DirectX.
> We are currently in the very early stages, we have a little bit of code
> and lots of plans.  Below is a little description of the project, its 
> more reliable than the web pages.
> 
> We are planning to hold two IRC meetings in order to map out our future
> directions.
> The first meeting will be with developers of important open source
> projects, GGI included, this is why I am writing to you now.  We also 
> want people form Mesa and ALSA, as well as

Yeah. Now that the GGI rendering target is in Mesa, GGI/Mesa might be a good
foundation for you. GGI for simple 2D, Mesa on top of it for 3D.

> The details of the second meeting will depend on the outcome of the
> first, but it is intended to be where we find out what comercial 
> developers are looking for.  

Compatibility to Windoze world. We need a lib that is nice and fast and runs
on both worlds. We are working on porting LibGGI to Win, but none of us
are really Win Gurus. If you happen to find someone who might be able to
take that task, please send him along.

> We will contact these developers directly, tell them what we are doing, 
> and try to get them to tell us what we are doing wrong.  We also plan to 
> make a general announcement of this meeting, so random people
> off the net can also tell us what we are doing wrong.
> 
> If any of you could turn up for the first meeting, it would be greatly
> appreciated, our tentative time/location is:
>     21:00 GMT, Saturday 8 August, channel #pplay on Efnet.

O.K. - I'd _love_ to be there, but I will be away on holiday, without net
access, so I have to leave this to others ... hope at least one of us finds
the time. Steffen ? Emmanuel ?

> If you intend to come along, it would be nice if you emailed me some
> time soon, so we know what to expect, but don't feel you have to.

Regardless of if someone from our side can come - could you keep me posted
on the outcome ? I'll be back on Sep 2nd, and will take care personally
if noone else does.

> now portability is a key goal.  We plan to support all Unices we can,

O.K. - Using LibGGI you instantly gain access to all Unixes we have so
far found using X11, on some boxes (Sun e.g.) even using "more direct"
access like /dev/fb and such. Acceleration is provided, if possible.

> Win32 and the PlayStation, at least.
W32 port is under way. PlayStation - oh well ... if someone gets LibGGI
compiled there ...

> The main components we plan to have are:
>     * A sound API + some  kind of sound server to do mixing etc.

Hmm - Wouter has made a nice server called GSI for the GGI-port of descent
(the first one to run on Linux-Alpha :-). Might be worth a look.

>     * Graphics API's (medium to high level C++ ones, we  indend to use
> libggi or something similar for for straight C).

Nice. LibGGI is modular in its functionality, so you can have lightweight
base functionality or "heavy" convenience by just selecting to use different
extensions.

>     * A general file I/O system.  Provides functinality similar to the
> GNU coustom streams or C++ stdstream, only
>         portably and in C.  (Specifically we want this to allow loading
> from "archive files").

Yeah - and "file-dialogs" and separators and such should be abstracted ...
You know that DOS \ vs Unix / thing ...

>     * An input mechanism.

You might want to have a look at EvStack/GGI events.

> It would ease my job (as the maintainer of this pg2d) if we could use
> GGI on all platforms. but if performance issues crop up, or GGI is not 
> available, then pg2d will go native.

O.K. - LibGGI is designed to be a very thin layer. Please notify us, where 
you find out that we are inefficient and going native would be better.
We'll try to fix that problem.

> For lower level needs, there are 3rd party API's which can be used, GGI
> and OpenGL seem like excellent options to me.  If there is a hole 
> (ie something does not exist on some important platform), then PPlay needs
> to fill it.
You can count on us also trying to fill holes we gain knowledge of.

CU,ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =