home *** CD-ROM | disk | FTP | other *** search
- Path: informatik.tu-muenchen.de!fischerj
- From: fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Demo/game to OS friendly part II
- Date: 7 Jan 1996 23:52:15 GMT
- Organization: Technische Universitaet Muenchen, Germany
- Distribution: world
- Message-ID: <4cpmbf$ong@sunsystem5.informatik.tu-muenchen.de>
- References: <john.hendrikx.44ce@grafix.xs4all.nl> <4cp2tv$d9u@serpens.rhein.de>
- NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
- X-Newsreader: TIN [version 1.2 PL2]
-
- Michael van Elst (mlelstv@serpens.rhein.de) wrote:
- : john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
-
- : >Don't you mean MoveScreen()? With ScrollVPort you'll need to modify the
- : >bitplane offsets yourself,
-
- : Well. You modify the offsets in the RasInfo structure. This is pretty neutral.
-
- What parts of a screen structure and refered structures may be poked ?
-
- : >while MoveScreen() handles this automatically.
-
- : AFAIK MoveScreen synchronizes with VBLANK (i.e. does an implied WaitTOF()).
-
- well, if movescreen was proved to work best on chipset & gfxcards
- you could use a higher pri task to handle the buffering, if the implied
- waittof does not busywait.
-
- : >Changing bitplane offsets will likely not work with gfx-cards.
-
- : Oh. Why ? It just depends on wether the gfx-card uses the ViewPort and associated
- : data.
-
- the question seems to be here which function is supported by most
- drivers. the users of other ones will have to accept speed of screentofront().
-
- : --
- : Michael van Elst
-
- : Internet: mlelstv@serpens.rhein.de
- : "A potential Snark may lurk in every tree."
- ------------------------------------------------------------------------
- fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
-