Difference between revisions of "AGOS/TODO"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Update FF issues)
(Added lengthy, rambling note about the line break bug in Oracle.)
Line 22: Line 22:
* Fix glitches when scrolling in Oracle interface.
* Fix glitches when scrolling in Oracle interface.
* Fix crash when moving left at Metro Prime.
* Fix crash when moving left at Metro Prime.
* Fix missing line breaks in Oracle interface.
=== Some observations about the missing line breaks ===
In the article titled '''THE COMPANY''', only the first line is broken. The subsequent lines are not. The reason for this can be found in showmessage_print_char(): Every time an end of word (character codes 0, 10 or 32) appears, the function will check if the currently buffered word fits on the line or not:
<pre>
    } else if (chr == 0 || chr == ' ' || chr == 10) {
        uint count = (getGameType() == GType_FF) ? _printCharPixelCount : _numLettersToPrint;
        if (_printCharMaxPos - _printCharCurPos > count) {
            _printCharCurPos += count;
</pre>
The test checks if the remaining space on the line is larger than the length of the buffered word, i.e. if the test succeeds the word will fit. In this case, <tt>_printCharMaxPos</tt> is always 360.
At the first line break, <tt>_printCharCurPos</tt> is 325 and <tt>count</tt> is 39. The word does not fit, and therefore the line is broken.
Where the second line break should be, <tt>_printCharCurPos</tt> is 366 and <tt>count</tt> is 24. At first glance, it looks like the test will fail, because the remaining space is negative. However, we're using ''unsigned'' variables, so what at first apperas to be a small negative value is actually a large positive one.
So how did this happen? Shouldn't the line have been broken at the previous word? No, in fact it should not. At that point, <tt>_printCharCurPos</tt> is 327 and <tt>count</tt> is 31. The word fits, just barely, and <tt>_printCharCurPos</tt> is increased to 358. Problem is, the line break check is triggered, here as almost always, by a space. And in that case the width of that space will ''also'' be added to <tt>_printCharCurPos</tt>, bringing it up to 366.
So to fix it, we either need to test for "overflow" when adding the width of the space, or - which seems like a better solution to me - we could change the variables to be signed. The strange thing is: the original appears to take neither of these precautions. Is it possible that the compiler ''Adventure Soft'' used behaved differently in this case, or are we missing some subtle detail...?

Revision as of 17:58, 9 April 2006

Simon the Sorcerer 1

  • Add support for decoding graphics in the Amiga verisons
  • Add support for Protracker MOD format, used for music in Amiga versions.
  • Improve support for GMF music format used in DOS versions.
  • Fix chest disappearing in Swampling's house in DOS versions.

Simon the Sorcerer 2

  • Add support for language files used by Amiga and Macintosh verisons.
  • Add support for music fade out in vc62_fastFadeOut() when changing locations.
  • Fix missing trails during lion ride to Goblin Camp in non-English versions.

Feeble Files

  • Add animation sorted by y value
  • Add invertBox differences (video_toggle_colors in ScummVM).
  • Add getPathPosn (Used by case 178 in runScript in ScummVM).
  • Add support for sound/speech in Amiga/Macintosh version.
  • Check all arrays for increased sizes.
  • Fix vertical scrolling when moving.
  • Fix scaling glitches as Feeble moves.
  • Fix glitches when scrolling in Oracle interface.
  • Fix crash when moving left at Metro Prime.
  • Fix missing line breaks in Oracle interface.

Some observations about the missing line breaks

In the article titled THE COMPANY, only the first line is broken. The subsequent lines are not. The reason for this can be found in showmessage_print_char(): Every time an end of word (character codes 0, 10 or 32) appears, the function will check if the currently buffered word fits on the line or not:

    } else if (chr == 0 || chr == ' ' || chr == 10) {
        uint count = (getGameType() == GType_FF) ? _printCharPixelCount : _numLettersToPrint;
        if (_printCharMaxPos - _printCharCurPos > count) {
            _printCharCurPos += count;

The test checks if the remaining space on the line is larger than the length of the buffered word, i.e. if the test succeeds the word will fit. In this case, _printCharMaxPos is always 360.

At the first line break, _printCharCurPos is 325 and count is 39. The word does not fit, and therefore the line is broken.

Where the second line break should be, _printCharCurPos is 366 and count is 24. At first glance, it looks like the test will fail, because the remaining space is negative. However, we're using unsigned variables, so what at first apperas to be a small negative value is actually a large positive one.

So how did this happen? Shouldn't the line have been broken at the previous word? No, in fact it should not. At that point, _printCharCurPos is 327 and count is 31. The word fits, just barely, and _printCharCurPos is increased to 358. Problem is, the line break check is triggered, here as almost always, by a space. And in that case the width of that space will also be added to _printCharCurPos, bringing it up to 366.

So to fix it, we either need to test for "overflow" when adding the width of the space, or - which seems like a better solution to me - we could change the variables to be signed. The strange thing is: the original appears to take neither of these precautions. Is it possible that the compiler Adventure Soft used behaved differently in this case, or are we missing some subtle detail...?