BEFORE RELEASE:
Don't know, need to have a look.

36
--
Rename the ppgRGBAXXXX DC's into ppgXXXX, in preperation for their new
role.

--------------------------------
Things to do before the new demo
--------------------------------


------------------
Things to do later
------------------


2
-
fix the FIX  comments.  Don't forget the build system.


3
-
New demo.  Do a bouncing bitmap.  The bitmap itself is changing all the time

Actually it would be best to do a snipes clone for pg2d, ClanLib and GAMES.
(In order to learn those API's).

4
-
Make surface classes factories for their respective surfaces.

Why?
because it is a ppgLinearSurface being drawn into.
?What does that mean?


---------

5
-
Deprecate the "current surface" idea (in the DC handler interface at least).


6
-
Clean seperation of depth and bpp.
(Actually, we should probably use Bpp instead of bpp).


7
-
DOCUMENT!!!!! + Do the preceps documentation.


8
-
CI modes.


9
-
Fill out the complete set of ggi draw command handlers.


10
--
Think about how we synchronize our ops with direct access.  The problem
is that we draw into _Surfaces_ while ggiFlush works on _Displays_.
We could associate each surface with a display and make a ggiFlush
wrapper that way, but that's nasty.


11
--
Make DirectBuffer accessible


12
--
Finish all the slow, "generic" (i.e PutPixel based) drawing primities.


13
--
Make the PutPixel based primitves "prototyping only", i.e. only
compiled in when we are debugging.


14
--
Rename ppUtils.cc
Why?


15
--
Add support for possibly overlapping src and dest for blits.

16
--
Also create a new perceps template.  (Produces man pages
in DocBook).  Maybe fix the man templates for perceps as
will if we see anything wrong with them.

17
--
Start catching GGI errors and turning them into exceptions.


19
--
Put all the other classes in the ppgColour title block.  Probably rename
the file too.

20
--
Think about the conceptual (cosmetic) value of making data PUBLIC in objects
which might be accessed by assembler routines.
	GCs, SurfaceClasses, Surfaces, ColourModes, ?Displays?.

21
--
Move ppgCommon.h into a place where it can be _found_ by external programs.
I HATE HAVING TO MAINTAIN HEADER FILES!!!

23
--
Fix the memory leak.  For some reason two ppgColourModes are created.
Only one is destroyed.

24
--
Fix the mode negotion interface.  Specifically, let the user chose the
colourmode type.

25
--
Make a nonvirtual stub to NewGC and possible Begin/End-Draw() in the
parent classes to avoid duplication.  This stub calls an abstract
protected function.
   * Done the first bit.  Think about the second.

28
--
Search for HELP comments.

29
--
Impelement the coding standard recomendations.


30
--
Get rid of a LOT of macro invocations.

31
--
Do proper graphtype setting in our mode selection bit, i.e use
the "detailed info things rather than the GT_*** macros).

32
--
Frame support.

33
--
Implement ppgDevice::GetMode()

34
--
Try to get rid of ppgSurface::dev

35
--
Think about using auto_ptr and other sensible things like that.

37
--
Think about getting rid of a lot of the macros in CppDefs.inc.
The trouble is that getting rid of COMMON_ARGS turned into a very
bad idea when I actually tried it.  Worse, COMMON_ARGS as
it is has the flaw that "out" is hardwired as ppgSurface&, while
many handlers will know that "out" should be a specific kind of
surface.  So make a file local COMMON_ARGS, or a paramatized version
is in order.

--------------------------------
Optimizations I don't Want to Do
--------------------------------
Performance hacks which might be useful one day if it comes
to the crunch but which we would rather not do.

- Made ppgMode layout compatible with ggi_mode and short circuit the mode
  setting system (saves space, not just speed).  It is meant to be 
  functionally similar.  I don't want to introduce anthing GGI specific into a 
  file which  does not have GGI in its name.
