Hi,
> + operations.c: Add full support for state->visible_map
>
> What does this entail? There's no comments that indicate anything
> is wrong/missing.
The pic_visible_map is the currently visible display map. By default it's
zero (which is what the games use), but some games have built-in debug
modes which allow viewing the other maps: Map 1 (priority) and Map
2 (control) (section 3 of the docs call them 'screens', but the new docs
in section 7 correctly refer to them as 'maps'). FreeSCI has no support
for the layered gfx architecture we're using for the visual map on any
other map, so an implementation of this would be inherently slow.
I'm not quite sure what exactly would have to be changed. IIRC the kernel
function doesn't yet call gfxop_set_visible_map() (responsible for this),
and it doesn't do the required update afterwards either. Nor does
operations.c care about the current map setting either, in any place.
control map:
This should be easy. The debug code in scriptdebug.c already demonstrates
how this should be done; since the control map may only be changed by
(permanent) rectangle and line drawing operations (unlike Sierra SCI,
which allows temporary changes- we handle these differently), there's
little updating that needs to be done here. The current valid control map
is available to the operational layer.
priority map:
Pixmap operations may change the priority map; also, this map isn't
available to anyone but the gfx driver. The only map it has is the
priority map of the background pic resource; any views or windows on top
of it aren't present anywhere but in the gfx driver's internal buffer.
There are two approaches to this one:
- Make the operational layer not have to know about past updates of this
buffer; kShow() can do a full widget redraw to facilitate this. We'll need
an additional buffer for the changed priority map, though.
- Force the gfx drivers to support blitting from the priority back buffer
to the visual back buffer (or only support it for those that do).
> * pic_0.c: Add SCI01 support (priority palettes and embedded views)
>
> Does this have to do with the "priority map grab" error in the SDL
> (and xlib) drivers?
No, but that's another SCI01 thing.
> I started looking at this, and noticed a
> large block of code commented out in kOnControl. Why? What
> was wrong with it?
It didn't help ;-)
It's not in the specs anyway and was a wild speculation, but there are a
few bugs related to collission checking/movement left, and this one might
turn out to become useful after all.
(It iterates over the dynview list and checks for collissions).
> (kOnControl() could use some comments.)
Please have a look at the OnControl() specs and the description of
gfxop_scan_bitmask(); I don't see what else there needs to be said.
> If it doesn't have to do with the "priority map" problem,
> where would I start?
Find one of the pictures in SCI01 that exhibits the "white background"
behaviour. Track down the line that prints out the error message and
aborts picture processing for these. Decode the table that's stored in
there (IIRC it's a pretty simple 16 or 15 byte table with priorities),
store the values in some place, change the VIEW_PRIORITY() and
PRIORITY_BAND_FIRST() macros to use that table if it's present (replace
the with functions that handle this).
The problem here is the place where priorities are stored in; right now,
this is not the responsibility of the gfx subsystem. If it was, it
wouldn't be stored in savegames; however, there are kGraph() calls that
alter this after the picture has been drawn, so storing it is neccessary.
But if it's the interpreter's responsibility, we now have a direct
connection between the resource drawing code and the interpreter- this is
easy to implement, but hard to model cleanly.
> * pal_1.c: Fix palettes not to compress colors (doing this is pointless
> and wrong)
>
> sci_pal_1.c appears simple enough, but there are no comments.
Well, it's not particularly complex. The only interesting code is the
color compression stuff, which needs to go anyway.
> What needs to be done here
The color compression (removal of a color if it's present more than once)
algorithm has to be taken care of.
> and what would the repurcussions
> of the change be?
It'd fix SCI1 palettes. Nothing that's of any value for us right now, of
course. I think I fixed it now, though.
llap,
Christoph
