#2781 closed defect (outdated)
SDL: AutoComputeDirtyRects bugs
| Reported by: | SF/hibernatus | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | --Other-- |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
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)
Change History (18)
by , 18 years ago
by , 18 years ago
by , 18 years ago
by , 18 years ago
comment:1 by , 18 years ago
| Owner: | set to |
|---|
comment:2 by , 18 years ago
comment:3 by , 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 , 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 , 18 years ago
| Component: | → --Unset-- |
|---|---|
| Owner: | removed |
| Summary: | Simon1: Screen not completely redrawn → SDL: AutoComputeDirtyRects bugs |
comment:6 by , 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 , 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 , 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 , 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 , 18 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 , 18 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 , 16 years ago
We removed autocompute dirty rects feature recently, so this bug is oboslete now.
comment:13 by , 16 years ago
| Owner: | set to |
|---|---|
| Resolution: | → outdated |
| Status: | new → closed |
comment:14 by , 6 years ago
| Component: | --Unset-- → --Other-- |
|---|---|
| Summary: | SDL: AutoComputeDirtyRects bugs → SDL: AutoComputeDirtyRects bugs |
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.