Opened 13 years ago

Closed 11 years ago

Last modified 13 months ago

#2781 closed defect (outdated)

SDL: AutoComputeDirtyRects bugs

Reported by: SF/hibernatus Owned by: sev-
Priority: normal Component: --Other--
Keywords: Cc:


Look at the screenshots.
From A1.gif to A2.gif you can see a small part is not
redrawn, you can "sweep" it with the mouse cursor.
Same from B1.gif to B2.gif.
Happens everytime, with very few names. ("l'arrière du
cottage" for example)

Ticket imported from: #1538880. Ticket imported from: bugs/2781.

Attachments (4)

A1.gif (52.5 KB ) - added by SF/hibernatus 13 years ago.
A2.gif (52.4 KB ) - added by SF/hibernatus 13 years ago.
B1.gif (52.5 KB ) - added by SF/hibernatus 13 years ago.
B2.gif (52.5 KB ) - added by SF/hibernatus 13 years ago.

Download all attachments as: .zip

Change History (18)

by SF/hibernatus, 13 years ago

Attachment: A1.gif added

by SF/hibernatus, 13 years ago

Attachment: A2.gif added

by SF/hibernatus, 13 years ago

Attachment: B1.gif added

by SF/hibernatus, 13 years ago

Attachment: B2.gif added

comment:1 by Kirben, 13 years ago

Owner: set to Kirben

comment:2 by Kirben, 13 years ago

I think these text related bugs, occured in the original
French version too.

It would be helpful if you could try the game under dosbox,
to confirm if the issue occurs in the original game too.

You can use the saved game from ScummVM. in the original
game too. You will just need to unpack (They are gzip
compressed) and rename the filenames of the saved games.

comment:3 by SF/hibernatus, 13 years ago

This bug doesn't occur under DosBox.
This may be a bug which is not specific to Simon engine.
In backends/sdl/graphics.cpp, if i remove the use of
addDirtyRgnAuto in copyRectToScreen the bug disappears.
The dirty area is incomplete.

comment:4 by eriktorbjorn, 13 years ago

The automatic calculation of which parts of the screen need
to be redrawn has caused glitches in the past. I guess the
problem is in the way we calculate the checksum for each 8x8
pixel area of the screen: We only use the pixel values. So
as long as the area contains the same number of pixels of
each colour, it will result in the same checksum no matter
which order they are in.

This would be particularly likely to happen in reas that use
only two colours, e.g. the status line or in Feeble File's
"Oracle" (where indeed glitches do happen every now and then).

Perhaps it would help if we made the pixel's value a
function of both its colour and its position within the square?

Of course, in an ideal world, the engine would be smart
enough to only redraw changed parts of the screen, without
having to use the checksum approach...

comment:5 by Kirben, 13 years ago

Component: --Unset--
Owner: Kirben removed
Summary: Simon1: Screen not completely redrawnSDL: AutoComputeDirtyRects bugs

comment:6 by fingolfin, 13 years ago

I am not sure what you mean with "we only use the pixel values". The Adler
checksum algorithm we use does indeed take the order of the pixels into
account. So the checksum of "1 2" and "2 1" differs.

Of course, though, the checksum is just that -- a checksum. Obviously, a 32
bit checksum can't detect all possibly changes in an 8x8 byte block, no
matter what you do.

The only possible alternative I see is to do keep a full backup of the graphics
buffers (before being scaled or anything, i.e. the raw 320x200x8 thing). Then
you can do a full and proper check for changes. Of course, that will take up
more memory, and will be slower (since you now have to compare 8x8=64
bytes instead of 4). On modern desktop machines, this should still be fast
(and I know some emulators that use this techinque already), but on some
systems, it might be faster to just do full screen updates instead...

comment:7 by eriktorbjorn, 13 years ago

> So the checksum of "1 2" and "2 1" differs.

Oops, you're right. I mistakenly thought it was the same.

In at least most cases, it ought to be possible - and
worthwhile - to make the engine smarter about redrawing
without having to resort to the checksum method at all. I
was surprised at how much difference it made for Broken
Sword 2, for instance.

In case of the Simon engine, things get complicated - last
time I checked, at least - by it drawing to more than one
buffer. Kirben might know more about how that works.

comment:8 by Kirben, 13 years ago

The Simon engine uses three or four screen buffers,
depending on the game. The buffer types seem to be:
_frontBuf - Front buffer
_backBuf - Back buffer
_backgroundBuf - Background buffer
_scaleBuf - Scale buffer (Feeble files specific)

It sounds like it would be best to no longer use of the
autoComputeDirtyRects feature in Simon engine. Since larger
memory usage and slower speed would mean it no longer
offers an advantage on slower systems, which is was meant
to help.

comment:9 by Kirben, 13 years ago

I removed the use of AutoComputeDirtyRects feature of
backends in the Simon engine for now, since we have several
reports of minor glitches.

I'm leaving the bug report open, since similar bugs could
occur in other game engines making due of this fearue.

comment:10 by bluegr, 13 years ago

Perhaps this bug report should be closed now? It's been more than 6 months and there haven't been any relevant bug reports

comment:11 by fingolfin, 13 years ago

The issue behind this remains valid, though: WE use an incomplete heuristic to detect dirty areas, and it will always be possible for similar issues to crop up, at semi-random occasions. The whole thing should be rewritten. I'd like to leave this open as a reminder.

comment:12 by sev-, 11 years ago

We removed autocompute dirty rects feature recently, so this bug is oboslete now.

comment:13 by sev-, 11 years ago

Owner: set to sev-
Resolution: outdated
Status: newclosed

comment:14 by digitall, 13 months ago

Component: --Unset----Other--
Summary: SDL: AutoComputeDirtyRects bugs SDL: AutoComputeDirtyRects bugs
Note: See TracTickets for help on using tickets.