Hi,
> > worked with c/c++ for the past two years. While I don't know a lot of
> > windows api stuff, or any Linux stuff, I'd be comfortable just debugging/bug
> > testing for starters. Just tell me what needs getting done, and I'll see
> > what I can do.
Your first stop should be the bug tracker, then. While some of the bugs
listed there are conceptional problems, things that are hard to
reproduce, or even closed already (need to review that thing RSN), others
would be relatively simple to fix, have been narrowed down somewhat
already, or aren't relevant because the piece of code affected is supposed
to be replaced with something different anyway.
If there's a bug you'd like to tackle, I'd recommend you to discuss it
with us first (either here on the mailing list, or in IRC)- the
extra information we can give you should make things both easier to fix
(at least most of the time) and easier to understand.
> > the web page, but that seems to be doing great so far. As opposed to the
> > agi engine, I think the sci engine is a lot more robust and could be
> > extended using plugings and other methods to support mp3 songs and different
> > picture/media types.
This is true. Adding new kernel functions is relatively trivial.
> > I think in the long run we could have a full fledged
> > general purpose adventure game engine!!
While this is a worthwhile goal that should be considered in our
architectural decisions, some major changes to the engine would be in
order for that- particularly 32 bit support.
> > The only other experience I've had
> > with sci is the pic resources. I've been trying to figure out why kq1
> > pictures won't display on some screens
The answer is relatively simple: KQ1 (and QfG2) pictures use a feature
(embedded priority band -> y coordinate mapping table) that isn't
supported by the pic drawer and causes it to abort. Skipping over the
table would result in correct graphics, but invalid priorities (in some,
but not neccessarily all cases). Therefore, this hasn't been implemented
yet as a reminder that it needs fixing.
Also note that we don't support SCI01 in the VM yet- SCI01 has more
memory available than SCI0 does. While we could emulate the hack Sierra
used to accomplish this, we've been looking into embedding their address
space into a virtual 32 bit address space instead, which should make
debugging a lot easier and allow a less painful transition to a 32 bit
engine. We weren't planning on doing that before the 0.6.0 fork, though
(which, of course, could be started any time now).
> > so I've been writing a program to
> > decode them, which has turned into a sci pic->scalable vector graphics (svg)
> > converter.
This sounds quite interesting! FreeSCI currently performs pretty badly
when drawing pic resources at higher resolutions (the 'pic0_scaled'
configuration option), mostly because of a number of kludges that needed
to be implemented in order to make sure that screen areas are filled
correctly (or 'mostly correctly', at the very least). One way to fix this
would be to convert the pics to a vector format first, which then would be
trivial to scale.
The critical point here are the fill operations, and the way some areas
are closed wrt filling only because of slight quirks in the Bresenham
algorithm; example:
XX : pixel element of line a
YY : pixel element of line b
ZZ : pixel element of line c
.. : Filled area
0 1 2 3 4 5
ZZZZZZZZZZZZ 0
XX......YY 1
XX....YY 2
XXXX 3
XX 4
XX 5
The filled area is closed wrt the flood fill operation. Now, let's scale
the lines to twice the resolution:
0 1 2 3 4 5 6 7 8 9 a
ZZZZZZZZZZZZZZZZZZZZZZ 0
1
XX YY 2
XX YY 3
XXXX YY 4
XX 5
XX 6
XX 7
XX 8
XXXX 9
XX a
Oops. No subset of this area (excluding the lines themselves) is closed
under flood fill.
We can double the line width to compensate, though, but this is a
sub-ideal solution and doesn't help in all cases:
0 1 2 3 4 5 6 7 8 9 a
ZZZZZZZZZZZZZZZZZZZZZZZZ 0
ZZZZZZZZZZZZZZZZZZZZZZZZ 1
XXXX YYYY 2
XXXXXX YYYY 3
XXXXXXXX YYYY 4
XXXXXXXX YYYY 5
XXXXXX 6
XXXXXX 7
XXXXXX 8
XXXXXXXX 9
XXXXXXXX a
XXXX b
Note that this also affects Sarien's high-res pic drawer, since AGI uses a
pic format very similar to SCI.
Note that this could be fixed by increasing the granularity used by the
flood fill algorithm. This would probably be faster than the current
approach... hmm...
But back to the vector graphics approach: The most sane way I can think of
to compensate for this would be to implement an algorithm which, for a
line A=(a,b) and a line B, determines whether, for a and b, there
exists a point z in the bresenham rendering of B such that
for p=(p_x, p_y) (where p=a or p=b)
and z=(z_x, z_y):
|p_x - z_x| <= 1
AND |p_y - z_y| <= 1
In this case, we can correct the current vector data by adding a new line
between the points p and z (this implies that the algorithm must also
yield z and not just prove its existance). It should be possible to
implement this as an O(1) algorithm.
Doing these checks on all lines in a pic is O(n^2) if no lines must be
added, or O(x^n) for a constant x if we have to keep on adding lines
(worst case). O(n^2) can be enforced by not doing these checks on lines
that were added for compensation, which (IMHO) is appropriate.
This is sufficient iff all of the 'bresenham quirk dependancy' problems
happen on the vertices of a line. However, there is at least one
additional dependancy:
YYYY
YY
XX YYYY
XXXX
XX
XXXX
XX
This can only happen with lines that are almost in parallel and very
close, though. If they're not, they'll either intersect, or the critical
point will be at the end of a line again (note that this is not a formal
proof, it just feels that way).
Checking for near-parallelism and closeness can be done quickly, so a more
expensive test for this condition would be OK.
llap,
Christoph
