Mail Archives: djgpp/2000/09/15/10:30:25
"Hans-Bernhard Broeker" <broeker AT physik DOT rwth-aachen DOT de> 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 <t-bos AT home DOT nl> 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.
- Raw text -