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

[Max Horn]

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... :-)



1) Why 16 bit graphics?
=======================

Main reason is that 16 bit graphics will make it vastly easier to 
implement a new in-game GUI (you may have noticed the work some of us 
put recently into a new GUI engine for ScummVM which is soon going to 
replace the old F5 dialog; and one day, it is also meant to be used 
to provide a game selector/startup screen for ScummVM). Since all the 
games use different palettes, it's impossible to come up with a color 
scheme that works everywhere.
Basically all ports use 16/32 bits graphics internally anyway. The 
main drawback of this of course is that we loose support for 8 bit 
systems, but I don't think this is a real concern, is it?

2) How could this be achieved?
===============================

One approach would be to simply change all the code to perform all 
drawings in 16 bits from the start. However, that would require 
changing tons of source code, hence would be guranteed to cause heaps 
of bugs. Plus it is such a major feat that I don't see anybody being 
able to do this w/o dedicating some full time to this. Plus some real 
world problems, like this would make it hard to support color cycling

Thus, what I suggest is a mixed 8/16 bit approach. Almost all the 
current code will stay as it is (that is, keep on drawing into 8 bit 
virtscreens). Only the new GUI code (and anything else that might 
need it of course) will perform 16 bit drawings. These two kinds of 
course have to be "mixed together" somehow. I suggest to do this the 
following way:

2) How could we implement it?
=============================

OSystem will be changed to only deal with 16 bit graphics (instead of 
8 bit graphics), i.e. no palette code there anymore. Functions like 
copy_rect will expect 16 bit buffers now.

ScummVM itself will handle the 8 bit -> 16 bit conversions. That's 
not hard to implement, and if you want to argue that it's slower: I 
believe that internally, most backends have to "hand convert" the 
palette anyway, but please correct me if I am wrong. To this end we 
woulc provide a copy_rect method in class Scumm (or in GDI?), which 
takes 8 bit data, and which gfx.cpp will use instead of 
_system->copy_rect

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.


There is a lot of stuff I left out here, I know, but the mail already 
was to long :-)



Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890