At 11:24 AM -0400 6/27/05, Lars Jensen wrote:
If so, that's by luck. You should put UpdateGameScreen into your Paint
event, but UpdateGameScreen shouldn't reference your Canvas directly
(otherwise no buffering will occur); it should draw to the Graphics object
that is passed to the Paint event.
Ick. How do you force this to be invoked when you need to update the
display, then?
The "classic" way for the control window to force a redraw of the canvas is
for it to call canvas.Refresh. However, that erases the canvas first on some
systems, causing flicker. That's what AutoBufferingCanvas.PaintBuffered is
for; it cause a Paint event to fire, but without erasing the canvas first.
Oh. Well that answers that question. :) Still, it seems not
substantially easier to me, especially given this limitation:
This works as long as your Paint event completely redraws the entire visible
rectangle, so that no pixels from the previous image are left. (I just draw
the entire image and worry about optimization later if needed.)
...which could be a serious problem for games.
Best,
- Joe
--
Joe Strout REAL Software, Inc.
Vote for REALbasic (twice!) in the LinuxWorld Reader's Choice Awards:
http://linux.sys-con.com/general/readerschoice.htm
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|