I agree completely. The system I described does sometimes suffer from frame shear, but it's nowhere near as objectionable as the flicker from simple sprite redraws.
Cheers Malcolm ZN wrote: > On 2/19/02 at 8:12 PM Marcel Kilgus wrote: > > [no way to prefent flicker] > >> Joachim Van der Auwera wrote: >> >>> Oh yes there is... You have to be more intelligent and shift data >>> in your buffer, restoring what is uncovered and saving what is newly >>> covered. More difficult to write, but always gives good results, >>> independent of execution speed. >> >> Helps, but doesn't solve the problem (I'm talking theoretically here, >> possibly with enough effort the effects can be neglected but they are >> there!). > > > Precisely, Marcel is absolutely right. > One should also make a difference between flicker and what is called 'frame > shear'. > Here is an example: > a) 16 sprites to draw, by restoring the background then redrawing all 16 > sprites in a new place. Effectively, in a short interval of time, there are > no sprites on the screen. > Suppose that this is what happens: > As the screen is traced from top to bottom, the background is first > redrawn. If this is fast enough, at some point in the entire screen scan, > say right in the middle, the entire background will be restored, and the > top half of the screen will show exactly that - no sprites. Next, the > sprites are redrawn, however the scanning of the screen continues > asynchronously, and the new sprites will not be seen in the top half untill > that part is rescanned. You get sprites shown only in the lower half! Now, > depending on how fast the drawing process is in comparison with the > scanning, you can get all sorts of effects, from flicker, 'banding' > horizontal or even slanted bands on the screen where the sprites or the > background is visible only), to areas of the screen where the sprites > remain invisible - and everything between. It would also change dynamically > depending on what else is going on in the system. > b) 16 sprites to draw, by precalculation of new positions from background > in memory, and updating only the parts of the screen that need to be > updated. In this case, as the scan goes from top to bottom, there will bea > point up to which the screen will show the 'old' position, and from there > on, a point where it will show the new position. If the movement of the > sprites is very fast, several updates will occur as the scan of the screen > progresses. This is called frame shear, where the diplayed frame frequencey > and the update frequency are not the same. The effect is quite common and > is actually preferable to the version a) although you can get 'streaking' > effects if a sprite moves downn exactly as fast as the scan progresses. > Given current hardware (except perhaps the Q40/Q60) this is unlikely. > > The only way to completely avoid flicker is a screen update that is > synchronous with the screen scanning rate, which is usually done using an > interrupt that occurs on every vertical retrace (when the screen scan > finishes scanning the last - bottom right - pixel). Only original QL > hardware can do something like that because the poll interrupt is > equivalent to the vertical synch signal, which is a signal generated to > tell the monitor to restart tracing of the screen from top left again. As > far as I know, no other QL hardware does this. It may be possible (but is > probably unduly complex) for QPC to implement tripple buffering, in which > case there would not be frame sheer but frame drop or frame jitter effects, > which are sometimes preferable but the implementation comes at a very high > price. > > The SSG works as a task linked into the poll interrupt list, controlled > through structures in memory that are set up by the basic keywords or calls > to the relevant routines in the extension code. If the interrupt driven > code is executed fast enough, it will update the screen quickly enough so > that the scan will not overtake the update. The scan will therefore always > show the current situation, with no frame sheer or flicker or any other > artifact. IIRC (it was a long time ago...) the SSG also handles what needs > to be updated, transparency, and collision detection using sprite masks. > These are one-bit deep structures that define colision boundaries and which > sprite pixels should be visible. Also, IIRC the SSG has several modes of > operation, and one uses a background reference 'snapshot' to calculate > which parts of the screen need to be modified. The modification is > performed by pre-calculation and only writing to the actual screen RAM. > > Something like this would indeed be a nice addition to the screen driver > but also a seizable complication once the PE is taken into account. OTOH > the PE window save already provides the background reference. > > While at the subject of the PE - I was always under the impression that: > 1) the PE saves the image of the application window, not a background (i.e. > what is under the window), except where saving what is under the menu > panes. > 2) there was a mechanism that alowed jobs to provid for their own window > maintaining regardless of the background save mechanism > 3) a way of signalling the job to refresh it's window in RAM was absent. > > With clever use of the first two, it can be assured that a job only uses as > much memory for it's window as that window takes in RAM, in whatever pixel > organization it happens to be. Basically, the job itself does not > necesairly need to use background saving when the background gets covered > by something else, if it can recreate the background itself. > I also seem to remember that PEX used the stored application windows, by > manipulating window definitions to make the standard routines actually > update the stored image, rather than the screen, and the screen was the > refreshed from the stored image periodically. > > I was also under the impression that programs using old QL modes under GD2 > still save their windows internally as old QL mode bitmap, but the restore > included conversion on the fly (I thought this plus changes in screen > driver to handle cases where direct writing to screen RAM applied, were how > the palette extensions of GD2 were implemented). > > Nasta > > >
