At 06:41 �� 19/2/2002 +0100, you wrote: > > > Well some preliminary tests I did through Basic using the Memory Copy > > > facility of Turbo seem to work fine... (No flickering that is up to 48 > > x 48 > > > sprites - above that hmmm okay ;-) I suspect though that through strict > > > assembler that would disappear too - UNLESS of course the absence of > > > flickering has something to do with my fast PC where I run QPC2). > > > >Well, there is just no way to avoid flickering. On fast machines the > >possibility that flicker appears gets smaller but it's never zero. > >Oh yes there is. The trick is not to restore the screen, save and write the >sprite at the new position. 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.
Yes exactly what I was referring to. The calculations involved won't be TOO demanding for small sprites and the area that is to be shifted could be manipulated. Another possibility is to form some kind of caching in the beginning of the process e.g. for x sprites that move on certain directions you generate ALL possible occurences well in advance (it is possible since the sprite positions are limited to the grid you have). This would definately hold a LOT of memory, but it involves (usually) one operation the write-write (next position, previous position) only instead of read-write, compute, write -read. Phoebus >I am pretty sure I wrote something like that for The Painter (long, long >ago). Believe it or not I have NEVER seen the Painter (the only Painter I've seen was a VERY addictive game that I used to have on Microdrive which my daughter destroyed and don't have it anywhere else :-~~( Phoebus
