home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!edcastle!hwcs!neil
- From: neil@cs.hw.ac.uk (Neil Forsyth)
- Newsgroups: comp.sys.atari.st.tech
- Subject: Re: Is page flipping safe, and I need to know about syncing
- Message-ID: <1992Jul30.151057.26935@cs.hw.ac.uk>
- Date: 30 Jul 92 15:10:57 GMT
- References: <Bruq9M.FI7@acsu.buffalo.edu> <1992Jul23.184657.5699@wam.umd.edu> <1992Jul23.222019.27222@infoserver.th-darmstadt.de>
- Sender: news@cs.hw.ac.uk (News Administrator)
- Organization: Dept of Computer Science, Heriot-Watt University, Scotland
- Lines: 51
-
- In article <1992Jul23.222019.27222@infoserver.th-darmstadt.de>
- wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
- >In article <1992Jul23.184657.5699@wam.umd.edu> dmb@wam.umd.edu
- (David M. Baggett) writes:
- >>The Setscreen and Vsync (X)Bios calls work fine for double buffering
- >>(aka "page flipping"). There are some subtleties but for most
- >>practical purposes you'll get good results using these calls and your
- >>code will work with all versions of TOS (including, in theory, those
- >For most practical purposes you do get good results with this.
- >
- >BUT: the disadvantage is that you don't have precision page flipping. It
- >just may happen that on screen1 you are done drawing in 2 screens and flip
- >then, while on screen2 you need 3 screens. The net effect of that would
- >be that if your flip rate is 4 that screen 1 will be displayed 5 VBIs, where
- >screen2 will be displayed only for 3 VBIs. If your game nears completion
- >and you are not 100% satisfied with the animation I'd suggest that you
- >use the VBL directly to flip pages (you can use Setscreen()) there too.
- >Until then Setscreen() + Vsync() + frclock will suffice.
-
- The trick is to set the physical screen base before the last frame that you
- are waiting for. ie. If you are running at 3 frames per turn then set the
- new screen address when you reach a count of two (which means the current
- screen is being displayed for a third time) so that it takes effect at the
- end of frame three. "Why?" I hear you ask (or maybe I don't:-).
- Well if you set the physical screen base the SHIFTER chip will not use that
- address until it finishes scanning the current screen. However this happens
- before SHIFTER causes the vertical blank interrupt so if you change the
- screen address in a VBL interrupt then you are too late.
-
- You want more proof? Take a look at the system variable 'screenpt' ($45E).
- The system VBL routine copies this to the physical screenbase if it's non-zero
- but foolishly neglects to zero it afterwards. You might think that this is
- the variable that Setscreen sets. Nope. Setscreen blasts the hardware itself
- and ignores screenpt. In fact TOS *NEVER* writes to screenpt. If you do
- then your in trouble because that means that the screen address is getting
- changed to screenpt every VBL thereafter EVEN after a soft reset. Can you
- imagine coming up with a 4MB machine in which the video RAM is at a low
- address in memory belonging to no-one. Why did Atari do this? Because they
- originally thought that screenpt/VBL would be the way to ensure a clean
- screen change but in the end the video hardware took care of it and the
- method became redundant/unworkable. However there are dark grey clouds on the
- horizon regarding this issue ...
-
- +----------------------------------------------------------------------------+
- ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
- ! !
- ! Neil Forsyth JANET: neil@uk.ac.hw.cs !
- ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk !
- ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil !
- ! Edinburgh, Scotland, UK "That was never 5 minutes!" !
- +----------------------------------------------------------------------------+
-