Opened 18 years ago

Closed 15 years ago

Last modified 6 years ago

#2781 closed defect (outdated)

SDL: AutoComputeDirtyRects bugs

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


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 18 years ago.
A2.gif (52.4 KB ) - added by SF/hibernatus 18 years ago.
B1.gif (52.5 KB ) - added by SF/hibernatus 18 years ago.
B2.gif (52.5 KB ) - added by SF/hibernatus 18 years ago.

Download all attachments as: .zip

Change History (18)

by SF/hibernatus, 18 years ago

Attachment: A1.gif added

by SF/hibernatus, 18 years ago

Attachment: A2.gif added

by SF/hibernatus, 18 years ago

Attachment: B1.gif added

by SF/hibernatus, 18 years ago

Attachment: B2.gif added

comment:1 by Kirben, 18 years ago

Owner: set to Kirben

comment:2 by Kirben, 18 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, 18 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, 18 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, 18 years ago

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

comment:6 by fingolfin, 18 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, 18 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, 18 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, 18 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, 17 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, 17 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-, 15 years ago

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

comment:13 by sev-, 15 years ago

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

comment:14 by digitall, 6 years ago

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