From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Z-Buffered Bitmaps Date: 26 May 2000 11:15:52 GMT Organization: Aachen University of Technology (RWTH) Lines: 25 Message-ID: <8glmd8$cao$1@nets3.rz.RWTH-Aachen.DE> References: <8gfm6n$51g6$1 AT newssvr04-int DOT news DOT prodigy DOT com> <392C41AC DOT B5D4B0E0 AT mtu-net DOT ru> <8giri3$8us$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <8gk9ad$ais$1 AT newssvr03-int DOT news DOT prodigy DOT com> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 959339752 12632 137.226.32.75 (26 May 2000 11:15:52 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 26 May 2000 11:15:52 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Robert Boles wrote: > 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. You cannot depth-sort, in your current setup. To sort, you'ld have to stop blitting everything to the back buffer directly. Instead, each of the 'source' threads would have to supply a bitmap image of its own, plus depth ordering information for it. Then, the routine that currently freezes the threads and blits to the frame buffer would have to freeze, sort all those bitmaps by z, draw them to the back buffer (front-to-back with avoidance of already drawn-to pixels, or straight back-to-front with overpainting), and blit the result to the frame buffer. Or you really need a z-buffering method, instead of z-sorting. This is drifting away from the topic of this newsgroup. You should ask this again in comp.graphics.algorithms, I think. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.