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: Doublebuffered window??
- Date: 18 Jan 1996 19:18:22 GMT
- Organization: Technische Universitaet Muenchen, Germany
- Distribution: world
- Message-ID: <4dm6du$ql0@sunsystem5.informatik.tu-muenchen.de>
- References: <4couoh$3qc@maureen.teleport.com> <615.6587T733T1336@direktor.voima.jkl.fi> <4ddlip$8jg@serpens.rhein.de> <IzbYx*Uka@aargh.incubus.sub.org>
- NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
- Originator: fischerj@hphalle5.informatik.tu-muenchen.de
-
-
- In article <IzbYx*Uka@aargh.incubus.sub.org>, marc@aargh.incubus.sub.org (Marc 'Nepomuk' Heuler) writes:
- |> In article <4ddlip$8jg@serpens.rhein.de>, Michael van Elst writes:
- |>
- |> > Aye. That's some other kind of double buffering. It is not necessarily
- |> > what he thought of though :) BBMRP takes some time too.
- |>
- |> But it makes a tmap game run in a draggable & depth-arrangable WB window,
- |> too.
-
- I made the experience that if you got a 320x200 window on a 640x400 window,
- it's more unlikely to see the rastersplits. But they're still there, so
- no real doublebuffering.
-
- Using AGA & blitbitmaprastport() to that window will need about
- 2 frames anyway, so for windows with copytime not beyond 1 frame
- doing sync with beam can result in rastersplit always at
- same position, a much worse thing!
-
- no way to get clean display, then, and better use no sync-methods.
-
- a routine testing blitterspeed could however still use sync method on
- gfx-cards for larger windows (ugh, now buggy drivers come back to mind..)
-
- ------------------------------------------------------------------------
- fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer) =:)
-
-