Well, most of the time I use z-buffering because it is all my hardware supports. However, reading into the spirit of the question for just a minute yields this more useful responce . . .

The scan-line related algorithms are more complicated but for scenes with a reasonable amount of overlap typically end up faster. This is obvious and is because genuine pixel-computations are certainly avoided for sections that end up unseen. Also, for many scenes with a suitably designed data structure, scan-line algorithms are easier on the processor cache.

However, if you can get even a reasonably bad front to back sort on your objects before drawing, often you can lose the majority of the speed benefit of scan-lining because you can still throw away large parts of the per-pixel computations without doing them. And in that case you are much nicer on the code cache and it is easier to be sure you are using the data cache the best way you can given the data you will use because a z-buffer is a static data structure.

Also z-buffer's are algorithmically and processing cost wise much easier to work with if you want to do anything involving only partial updates of your display, because they are so very easy to duplicate.

It really depends on what you intend to do, but in most cases I personally would probably still go with a scan-line approach.

First of all, what do you define as "scan-line"? By the phrasing of the question, I'll assume that, by "scan-line", you mean, "non-z-buffered scan conversion."

note: the following discussion assumes hardware acceleration. The days of software-based rendering for even modestly-performing games are over.

The z-buffer is good. Most modern hardware implements z-buffering virtually for free. Some of them even use special early-z-culling modes (GeForce3+ or Radeon) that will cull out entire groups of pixels at a time. You can even use the z-buffer to implement various effects.

The only time to turn off a z-buffer is when you have to. You turn it off for transparency. You turn it off for certain effects. Otherwise, there's really no reason to bother not using a z-buffer. It can only help.

I agree with Ben. Whatever Hardware can do Software can do just as well, but at lesser speeds. In fact, some of the best experimentation can take place only if you are using Software coz the effects are visible due to the code and not the amount of OpenGL extensions supported by your card . Disregarding a whole way of creating realtime 3D in favour of the next-best-thing by NVIDIA or ATI is not required.
Too many people keep suggesting switching to Hardware as a solution to learning Rendering techniques. Thats just a speed issue. Good-looking games require speed, but learning requires more than card or API specific knowledge. Switching to Direct3D or OpenGL (which seems to Korval's suggestion for any of my threads ) is step two, and I agree that it is required for any top of the line game or for professional purposes.
Software will never be Dead (just like DOS isn't ) coz of programmers like me who can't afford the Radeon's and GeForce's of the world!

Thomas has already shown how this is possible on modern cards. I'd like to add that there are much more asthetically pleasing ways to do explosions than relying on palatte hacks.

Not true. What you're talking about is an animated texture. I have 2 options:

1) Put all of the animation frames in one gigantic texture. Simply alter the texture coordinates (via the texture matrix) at run-time.

2) Actually swap the texture it is using each frame. Unless the card cannot store all of these textures in video memory, the upload doesn't actually happen. And, even if it does, it won't hurt much at all. It is, after all, an AGP copy, which is pretty cheap (unless the texture is huge).

This doesn't cover the case of a procedural texutre, where you're actually generating the texture every frame. That can be somewhat painful.

Here's a question about software rendering: are you actually using the advantage of software rendering? Are you actually doing something with per-vertex or per-pixel computations that modern (non-shader-equipped) hardware cannot handle? Are you employing bump-mapping, anisotropic lighting, 1D point sprites, volumetric fog, or any number of the other effects that requires specialized hardware that may not even exist yet? If you're just rendering some texture-mapped polygons, potentially with basic alpha blending, I just can't see the point of your arguments.

Actually, with a 9700, I'd probably encode the procedural program in the pixel shader.

I thought Rash's question was about the VSD techniques and not the cutting-edge of EVERYTHING (DX8.1 pixel shaders!!??!). All I was saying was that why can't a question be answered just for itself? Z-buffering vs. scan-line! Simple, huh? Anyway, I guess my knowledge is too amateurish.

But then, conversely, you can render a height map using the ROAM technique (an adaptive meshing approach) and be assured your polygons will never get very small.

I wouldn't have brought up the whole software/hardware issue if it had been immediately obvious what Rash was talking about.

A "scan-line" has a particular meaning. Rash, apparently, assumed that by putting it in the context of "z-buffer vs. scan-line" that this would obviously be refering to some alternative to z-buffering known as s-buffering. The assumption was valid only for those who had any knowledge of this technique. I freely admit I have no idea what an s-buffer is.

Well, it could very easily have worked in your case. As I'm sure you realise, even the implementations people use in perspective engines don't just think about perspective but also about variance, so even once you'd factored out perspective you'd almost certainly still end up with a more optimal meshing of your shape than the most basic heightmap implementation. The obvious case is an n by m grid where all height values are the same - even without perspective ROAM would come up with two triangles, whereas you would come up with something like 2*(n-1)*(m-1) triangles.

The moral of the story : even if ROAM can't make things better, it can't hurt!

Naturally I assume you're not stupid and discarded any idea of using ROAM because you knew it would not help regardless of whether you forget to mention whatever thoughts you had on here, but in a public forum I thought it was a good idea to make clear to casual readers not to dismiss ROAM out of hand purely because perspective is not involved.

P.s. if your map did not rotate, then why did you not pre-render it, not necessarily all of it but the sorts of quantities that would allow scrolling without much redraw, including depth information and simply do a blit (including depth information)? I'll assume because : it did rotate.

I'm sorry, but I'm the sort of person who gets quite annoyed when other people feel they must religiously stick to some particular use of the language just because they've seen other people do so a few times. Yes, a scan-line has a particular meaning for graphics people, which is specifically the horizontal line along which an electron gun moves in a cathode ray tube. So, there you have it, every game I've ever written has used a scan-line approach. Assuming we are never allowed to expand the possibilities described by a particular set of words, then that is all scan-line can ever mean and there is no point arguing about it!