[Scummvm-devel] 16 bit graphics: Thoughts on how to implement it

Marcus Comstedt marcus at mc.pp.se
Wed Jul 24 08:11:02 CEST 2002


Max Horn <fingolfin at marblehorse.org> writes:

> Hiya,
> 
> 
> I have been thinking a bit about we could implement 16 bit graphics
> "best" in ScummVM. Please read the following, especially if you are a
> porter, and comment on it. Any suggestions, constructive criticism,
> etc. is welcome and desired. This is by no means complete, but I want
> to get this discussion started so that we can eventually start to
> implement this, too (or not... :-)

My comments:

No problem for the Dreamcast port, since I'm converting to 16 bit
before sending the graphics to video RAM anyway.

Something that needs attention though is:

RRRRRGGGGGGBBBBB or XRRRRRGGGGGBBBBB ?

Doesn't make any difference for Dreamcast, but it might for other
ports.  Some might even want BBBBBGGGGGGRRRRR.


> Now here I am a bit uncertain on how to do this exactly. The problem
> is that the New GUI not only needs to write out graphics, but for its
> alpha blending (and for other things, like taking a snapshot of the
> current screen for redraw purposes) it also needs to be able to read
> the data currently on screen. We could add a method to OSystem that
> allows for this, but I am not sure if this would be easy for all
> systems to implement in an efficient manner. Porters, please comment! 
> Alternatively, ScummVM could keep its own 16 bit buffer of the full
> screen for this purpose.

The Dreamcast port keeps everything sent into copy_rect() in a RAM
buffer (nothing is actually drawn on screen).  Then when
update_screen() is called, the whole buffer is sent to the graphics
subsystem.  After that, the graphics can not be reliably read back,
since the graphics processor operates asynchronously.  (The RAM buffer
is still available of course, but will be modified by any further
copy_rect()s.)


  // Marcus






More information about the Scummvm-devel mailing list