Mail Archives: djgpp/2000/05/25/19:17:06
Yes, you are right, I have no way of telling when each of the threads disply
thier image.
My program works now, It just doesn't display things in the right order. It
displays them whenever the thread happens to hit.
How it works is that each thread (running at the same time) blits to the
back buffer, under certain conditions. Sometimes alot, sometimes not at all.
Then the main thread freezes the muli-threads. Blits the back buffer to the
screen, and then starts the threads. Works great, if I can get it depth
sorted.
> Alexei A. Frounze <alex DOT fru AT mtu-net DOT ru> wrote:
> > You don't really need any Z-buffers. At least Z-buffer is a computer gfx
> > term usually used in 3d gfx.
>
> Usually, but not only there. In the situation the original poster
> describes, he *does* need a z buffer. You didn't read the question
> completely, I think: he was talking about multiple _concurrent_
> threads blitting windows to a common framebuffer. In that case he
> cannot z-sort the windows, simply because there's no point in time
> when they're all available, so they can be sorted and output.
>
> His situation requires either a z-buffer or a datastructure that
> partitions the plane into rectangles or similar areas of common
> 'depth', which is somewhat equivalent to the 'dirty rectangles'
> blitting method for sprites.
> --
> Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
> Even if all the snow were burnt, ashes would remain.
- Raw text -