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

Re: Webpage: Submissions, ideas, etc.



On Tue, 28 Apr 1998, WareWolf wrote:

> Hi Garrett,
> 
> 
> GG> Please send me submissions, suggestions, etc. of stuff you'd like to see
> GG> on the web pages.  I'd particularly like to get all the draft proposals,
> GG> documentation, and pointers to source code and demos updated.
> 
> (1) Some time ago Adrian posted a draft of a general PenguinPlay  
> introduction. We could take this as our "main intro".
I don't actually remember such a docment, but I assume it exists.
Perhaps someone can produce it.
> 
> (2) Who's maintaining the FAQ? The last version I read didn't consider  
> portability and platform independence as very important. This should be  
> changed.
YES YES YES YES.  We should say in big letters that we are for all UNIX
and plan to be for other patforms too.

 
> (3) I think it's time to create an up-to-date overview of the different  
> Parts of the Project. My suggestion:
> 
> Layer P: (these parts will be largely independent of each other and mostly  
> provide only basic functionality)
> 
>         * 2d/3d Graphics
>         * Sound
>         * Networking
>         * Input
>         * File Access
> 
> 
> Layer O: (Here different Parts can depend on each other)
> 
>         * 2d Graphics
>         * 3d Graphics
>         * World engine
>         * Sound
>         * File Access (?)
>         * AI
>         * GUI
>         * Input
> 
> 
> Utilities: (several Utilities for game development)
> 
>         * Sprite editor
>         * Map/scene editor (2d/3d)
>         * 3d object modeler
>         * midi/wave/... editor(2) (don't much about that)
>         * PAK-file compiler
>         * evtl. some visual development tools (GUI designer, network
>           constructor, ...)  
(That last would be a long way off.)

> Yep, sort of, details will be different.  Of course the Utilities should
> be 3rd party software as much as possible.  The spirte editor would be
> GIMP or whatever draw program users want.  I don't even see any need for
> a plug in, except maybe one which could access PAKE file.  The map/scene
> editor on the other hand probably should be made by us.

> (e.g. the one describing the four-layer model) until we have up-to-date  
> versions. IMHO they cause too much confusion.
YES.  BTW, I have attached a document I wrote which will do as the
PenguinGrapics page for now.  It's no masterpiece of HTML, but it should
do.

> 
> (6) Is it possible to provide a facility for downloading (parts of) the  
> homepage as compressed archive (tgz or so) for offline reading? Perhaps  
> generated on the fly by some CGI script?
Can we just use CVS?


Bye Bye.
<TITLE>PenguinGraphics</TITLE>
<H1>The PenguinGraphics Game API</H1>

<P>
WARNING: This page was designed for speed of writing by an HTML know
nothing, and lynx friendliness.  So all those java-html4.0-graphics
freaks can learn to live with the web the way it was meant to be.
(Well, how I  think it was meant to be anyway).  I did write this page
quickly so please mail <A HREF="mailto:s369625@student.uq.edu.au">me
(Adrian Rantapala s369625@student.uq.edu.au)</A> if is incoherent.
Or if you have any other reason to mail me.



<P>
PenguinGraphics is a graphics API designed as part of the <A
HREF="http://sunsite.auc.dk/penguinplay/"> PenguinPlay </A> Game
development kit.  We are still in the planning phase, (although we do
have some code written).  So I will only describe as much as I can.  <P>

PenguinGraphics is based on the <A HREF= "http://synergy.caltech.edu/~ggi">
GGI </A>.  GGI is a multi platform, multi targeted graphics interface
which allows one to display on any of the following: <P>
<UL>
	<LI> X 
	<LI> SVGAlib 
	<LI> KGI (In kernel GGI code for Linux and I Freebsd)
	<LI> And many more...
</UL>
<P>
That's enough about the GGI, now more about us.  So far we can see three
parts to the graphics subsystem of PenguinPlay ppg2d, ppg3d and ppgGui.  
<P>


<H2>ppg2d</H2>
<P>
ppg2d is PenguinGraphics 2d if you hadn't already figured that out.
It is a mid level 2d graphics API, it actually duplicates much of the
functionality of libggi2d (a planned part of the ggi), but thats OK.
I'll soon have a minimal implementation to show off so watch this spot
for sources and docs which should come real-soon-now :). 

Don't believe in any old (pre April 1998) PenguinPlay or GSDK
implementations which you might find, the thing has been completely
rewritten and largely redesigned twice.
<P>

Pending that release and its documentation, here is a little feature list.
(For the full version that is, not the poxy little demo I plan to have out
soon).
<P>
<UL>
	<LI> Object oriented.  It's a C++ API.  If you don't like that
	     then use all that ggi functionality I said we were
	     duplicating, that still fits into the whole PenguinPlay
	     scheme of things.
	     
	<LI> Freakishly  multi-targeted.  You know, you can draw into
	     surfaces which are visible screens or windows, memory  blocks,
	     image files or the smooth skin of the gwondo-beast from
	     the planet Zonk.

	<LI> Supports spites.  (You'd have to hope so wouldn't you).

	<LI> Optional scaling & arbitrary linear transformations.
	     (Rotate, shear, scale for those poor non mathematical
	     sods out there).

	<LI> 2d acceleration (piggybacking off GGI).

	<LI> Optimized routines written in assembler on common platforms.
	     That means i386 and i386-MMX.  (Cash prize for whoever can
	     bring me a genuine 386 with MMX).
</UL>
<P>


<H2>ppg3d</H2>
<P>


We are <EM>really really</EM> vague about this.  We know we will be
using OpenGL, (via Mesa), maybe not exclusively.  That's about all
we know.  Suggestions are <EM>really really</EM> welcome.  If you don't
have any, then come back later when we have a clue.  <P>

<H2>ppgGui</H2>
<P>

Well GUI is not really graphics since it involves lots of issues.
But it's with the graphics team at the moment.  ppgGUI (or PenguinGUI,
or whatever it will be called), will be a GUI toolkit, with windows and
such things.  You'll have to wait to get more info because we are still
in planning.  (Still the situation is better than with 3d).  But I'll
tell you what I can.
<P>

<UL>
	<LI>It's designed for artistic flexibility more than ease of
	use, so it won't be big on precooked dialogs and controls.
	Although we hope to grow a set of such things.

    <LI> It <EM>won't</EM> use "system" windows. I.e, even if we are
    running under X, a window will just be a subrectangle of the main
    display window  as far as the X server is concerned.

    <LI> Your  window backgrounds etc. could be simple colour blocks,
    arbitrary (possibly transparent) textures, or any other graphics
    elements which ppg2d supplies.
</UL>
<P>

With the exception of the last one, these things would be a bit
dysfunctional in a normal GUI toolkit, but for most games a normal GUI
toolkit would be dysfunctional.
<P>

<H2>Conclusion</H2>
<P>

Th-th-th-that's all folks.