Re: Re: stk and the Dreamcast

On Tue, 2003-07-22 at 14:41, Marc Strämke wrote:
> Mike Melanson wrote:
> > On 22 Jul 2003, Darren Vincent Hart wrote:
> > 
> > 
> >>Libstk has an abstract base surface classes which all backend surface
> >>classes derive from.  So pixel-by-pixel drawing routines are used only
> >>if the backend class hasn't overridden them.  We would have to write a
> >>stk::surface_dreamcast backend class (we currently have
> >>stk::surface_sdl, stk::surface_dfb, and stk::surface_fbdev).
> > 
> > 
> > 	I have the worst aversion to C++ and OOP. But I will see if I can
> > put that aside for now...:) 

I came started this project with a mostly C background, so I can see
where you are coming from.  I believe that OOP and C++ offer an
excellent environment for UI development.  There are some really amazing
things you can do easily with boost::signals for instance.  See widget.h
for some comments on that (just updated).

> I'm looking at the class definition for
> > stk::surface. I need to implement all of the pure virtual functions,
> Not exactly, there is a templated helper class which can be inserted 
> into the class hierachie between the surface interface and the 
> implementation which implements functions as a pixel by pixel access to 
> the graphics card, so the smallest possible backend only ovverides the 
> set_pixel calls. (Look at surface_dfb.cpp for a very simple backend(Read 
> Incomplete/Hacked))
> 

Exactly.  So what features do you have in hardware that you want to
excellerate?  blit probably, fill_rect maybe?  Those are the ones you
will want to implement in the surface_dreamcast class.  The surface
class model is a bit confusing at first glance, but the templated
surface_impl allows for polymorphism without the overhead people like
yourself hate so much :-)


- surface is the abstract base class.
- surface_impl<surface_backend> derives from surface and implements all
  the drawing routines using pixel-by-pixel routines, but accesses the
  backend put_pixel() routine without the need to go to the virtual
  function table (that is why it is templated).
- surface_sdl, surface_dfb, etc are concrete surface classes and derive
  from surface_impl<surface_sdl>, surface_impl<surface_dfb>, etc 
  respectively.  These classes implement put_pixel() and similar 
  routines and override the draw routines for which their backend 
  provides hardware accelerated support.

I suggest you model surface_dreamcast after surface_sdl or surface_dfb.

> > right? What do the *_aa() functions do? Anti-aliasing?
> Yes basicly they are for anti aliasing (darren is the specialist for 
> this stuff ;) ).

The draw_*_aa routines use anti-aliasing, put_pixel_aa blends the passed
color with the pixel in the frame buffer according to a "distance"
measure from the midpoint algorithms used in the draw outines.

> 
> > 
> > 	Thanks...
> > --
> > 	-Mike Melanson
> 
> 
> 
> _______________________________________________
> Libstk mailing list
> [email protected]
> http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk