SCI: LSL5 (and others): port drawing issues

[m-kiewitz]

The current port code seems to have quite a few issues. It's not pixel perfect and in case of for example Larry 5, some left-overs stay on screen, when credits windows were shown.

It has to do with ScummVM's Common::Rect not working as rectangles in original SCI and the current code not always adjusting for it.

In this case the main problem is kNewWindow, but other code is problematic too.

It's not a trivial bug to fix, because there is quite a lot of code that doesn't adjust and it also seems there are a few inaccuracies as well.

[bluegr]

Just to clarify: This bug only occurs in one textbox in LSL5 that is drawn off-screen. The off-screen part is not cleared properly. I'm attaching screenshots of the textbox in question

[m-kiewitz]

If I remember correctly, I found some more off by one errors when compared to the original interpreter. I think it was QfG 1. It's simply not 100% accurate.
Just make screen shots in Dosbox as well as ScummVM and you will see when you flip between them.
It's not a big problem, because the overall behavior is indeed accurate, but it's still not good and there can be issues, especially in fan games.

[sluicebox]

Hi Martin, it's been a while, great to hear from you! =)

I messed up and failed to comment here last year, but this ticket caused me to compare QFG1 EGA screenshots and fix some off-by-one horizontal port discrepancies, especially in the character screen: ​https://github.com/scummvm/scummvm/commit/71235358e3f7c205e514168b5756ea1944ef3323

There are definitely still some mild discrepancies in ScummVM. The QFG1 EGA character creation screen still draws a one pixel vertical line on the right edge that isn't in the original. But i also suspect that may be a bug in the original, because that line is on the left and the symmetry looks nice. Someone also recently showed me a message box in QFG1 EGA PC-98 (or maybe it was SQ3?) that's drawn one pixel higher in ScummVM than the original. My shallow investigation showed that not only is this likely due to the differences between Sierra's and ScummVM's Rect classes, which we all know of, but also that Sierra's own code had its own off-by-one bugs that would be difficult and confusing to replicate, though not impossible.

I propose that we limit the scope of this ticket, or close it, since many things have been fixed since it was created, and open specific tickets as they come up for remaining individual issues and include screenshots. I'm not suggesting we dismiss port issues as "good enough", but at the same time I also think they *are* pretty good and we should investigate remaining individual discrepancies to see if there's anything we can reasonably do.

[antoniou79]

If it helps at all, testing in ScummVM 2.8.1 and ScummVM 2.9.0git developer build, I got the glitch shown in bluegr's screenshots.

Basically while testing for another ticket, and starting from the provided saved game there, I finished the game, got the end credits and then restarted to an earlier point, where I noticed that the top black bar of the game screen had the white artifacts.

[eriktorbjorn]

Would it be in any way useful to compile a list of games where text boxes like these are not drawn quite like the original?

I'd be happy to do that for the games I have (at least the ones I can get to run in an emulator). So far, I've seen discrepancies in Conquests of Camelot, EcoQuest 2, and Codename: ICEMAN.

I saw no discrepancies in Castle of Dr. Brain, Island of Dr. Brain, and Freddy Pharkas.

[m-kiewitz]

not really, this problem exists for all port drawing SCI versions, this means SCI0 up to SCI1.1
it's one off, but it's not simple to fix at all
one of the problems is also that the common ScummVM code like Rect doesn't act like the one in SCI. It's either that common code doesn't include the end of the rectangle, but SCI does, or the other way round, but common code is used, so positions and sizes have to get adjusted accordingly.
It's a mess.

Have you really compared screenshots pixel by pixel?
maybe there are situations, where the code works fine, but as I said it doesn't matter in the end, because tons of code has to get adjusted. I tried to fix it years ago, but it's not trivial at all.

[eriktorbjorn]

Replying to m-kiewitz:

Have you really compared screenshots pixel by pixel?

A few. But since I'm not familiar with the SCI engine, I'm not sure what constitutes a "port".

For instance, in Conquests of Camelot, the normal in-game text boxes (that I looked at) were correct, e.g. the "'Tis the floor plan of your stronghold, Camelot." one. The discrepancies were in other types of textboxes, e.g. the "About" ones.

I stumbled over the LSL5 one (the only one I've seen where the glitch was noticeable to the naked eye) recently. I was about to file a new bug report when I found this one.

But I guess there's no further investigation that I can do, then.

[m-kiewitz]

a port is what SCI calls some kind of virtual window on the screen.
the gameplay screen itself is a port, and even that's not always defined the same way.
I think there are 1 or 2 games, where the interpreter is called with additional options to define that port differently, otherwise the game will not work properly.

for example a message box is internally a port too, but if I remember correctly a port can also be within another port, and coordinates have to get adjusted accordingly.

You can also see it easily in the start screen of Quest for Glory 1 EGA, where you set the character attributes. When you compare it with the original interpreter, I think everything is off by one pixel.

No need to investigate, I already know that it's off-by-one, but it's very complicated.
It's a shame because otherwise the SCI engine works really well.