From: "Riox92" <t-bos AT home DOT nl>
Newsgroups: comp.os.msdos.djgpp
References: <CCPv5.8958$l6 DOT 494172 AT zwoll1 DOT home DOT nl> <8pqfb2$hmk$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <C0qw5.499$Sp1 DOT 2298 AT zwoll1 DOT home DOT nl> <8q53ue$l8g$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
Subject: Re: What is faster as memcpy???
Lines: 69
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID: <E3qx5.6196$Sp1.152048@zwoll1.home.nl>
Date: Mon, 18 Sep 2000 14:57:40 GMT
NNTP-Posting-Host: 213.51.72.195
X-Complaints-To: abuse AT home DOT nl
X-Trace: zwoll1.home.nl 969289060 213.51.72.195 (Mon, 18 Sep 2000 16:57:40 MET DST)
NNTP-Posting-Date: Mon, 18 Sep 2000 16:57:40 MET DST
Organization: @Home Network
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


"Hans-Bernhard Broeker" <broeker AT physik DOT rwth-aachen DOT de> schreef in bericht
news:8q53ue$l8g$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE...
> Riox92 <t-bos AT home DOT nl> wrote:
>
> [...]
>
> > I draw my objects in the virtual screen and when finished I memcpy the
> > vir_screen to the LFB_screen
>
> Right. That's how it's supposed to be done; setting aside you might
> want to use _movedata() so you can avoid nearptr mode, as necessitated
> by memcpy() to access the real frame buffer.
>
> > It works ok if i need to draw a lot of polygons and vectors, but if i
want
> > to make a simple starfiel it shows the old screen under the new screen.
>
> Under as in 'behind', i.e. the old stars don't get erased properly, or
> as in 'further down the screen'?

>
> In the latter case, what you observe is a more of a synchronization
> problem than one about speed.  The trick is to start the copying just
> as the CRT's electron beam wrote the first few lines of pixels, so
> you're running after it, and you have about one frame of time to
> complete the blitting. If you don't do this synchronization, you'll
> sometimes be overtaken by the beam, leading to the observed effect
> that the lower part of the picture is older than the upper one.
>

Wel if i fill the screen with a horizontal drawline. ----------- And I make
the width of the line smaller with a speed of xx (ill explane later the xx)
. the generated vertical bar looks like this

     |    |
     |    |
     |    |
    |      |
    |      |
   |        |
   |        |

This happens if I use a calculation where the speed (xx) is fast (big).  If
I do this with the speed set to 1 it works great. It's needed to make a
screen switch in my intro. I think you are right there.
Maybe thats why i want to know how to wait for the CRT-beam till a position.
(on amiga we called it vblank)

> > like i said. but then when i move 1 pixel over the screen over a sin*rad
> > horizontal or vertical it shows a effect like a shading....
>
> That's probably coming from the slowness of the phosphor, partly, plus
> the fact that a point spends much more time at the extreme points of a
> smooth curve (like the sine curve) than in the middle of it (its
> velocity is much larger around y=0 than at y= +/- 1)
> --
Its used on a purple background with a black - till - white fading bar.
Still if anyone can help me out with this, I would be greatfully thankfull.


> Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
> Even if all the snow were burnt, ashes would remain.

Riox. (www.tested-on-animals.com / http://members.home.nl/t-bos )