From: "Riox92" Newsgroups: comp.os.msdos.djgpp References: <8pqfb2$hmk$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> Subject: Re: What is faster as memcpy??? Lines: 59 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: Date: Fri, 15 Sep 2000 14:05:22 GMT NNTP-Posting-Host: 213.51.72.195 X-Complaints-To: abuse AT home DOT nl X-Trace: zwoll1.home.nl 969026722 213.51.72.195 (Fri, 15 Sep 2000 16:05:22 MET DST) NNTP-Posting-Date: Fri, 15 Sep 2000 16:05:22 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" schreef in bericht news:8pqfb2$hmk$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE... > To answer the 'Subject:' question straight away: nothing, generally. > Not with a memcpy() as clever as the one used by DJGPP. > > Riox92 wrote: > > Its for a VESA2.0 24bit LFB Switch routine. > > > Now i use memcpy. on a screen of 640*480*24bit screen. > > But on little objects dots the switch looks to slow.. > > This is really a rather unclear way of expressing what happens. *What* > exactly do you do with memcpy, here? And how slow is 'too slow', in > numbers? Typically, you almost certainly should not be using memcpy() > to copy single pixels. That would be much more efficiently done via > direct access to an array. memcpy() is meant for at least moderately > large blocks of memory being sent around, not for single 'dots'. > ------------------------------------------------ Ive got a allocation of a virtual screen LFB_virscr what is made of 640*480*3 bytes (unsigned chars) This is when the gfx card is 24 bits. (diamond A50) on a 32bit card its 640*480*4 bytes. I draw my objects in the virtual screen and when finished I memcpy the vir_screen to the LFB_screen 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. Like the screen change/switch is going to fast. Maybe a delay could do the trick like waiting on the horizontal line pos ... Just wanted to know if someone ever had these kind of problems, and knows what to do about it. > Also be aware that, LFB mode or not, access speed of the graphics > card's memory is still a big lot slower than your typical main RAM or > the caches RAM of the CPU. Even more so if you ever read from graphics > memory. This is the reason why it's usually better to do all the > manipulation operations on a RAM buffer, and only after completion of > it, blast the whole thing to the framebuffer in a single large > memcpy(). > 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.... And thats what i want to get rid of. > -- > Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Riox92 www.tested-on-animals.com > Even if all the snow were burnt, ashes would remain.